Analytics Tracking Code

Monday, May 27, 2013

Running an OpenBSD Laptop

I've been a long time user of OpenBSD for various projects since I worked for Nortel back in the good old days (2004? Wow, that's nine years and counting). My experience with the operating system is mostly on howling servers that you would never run on your desk.

Anyway, I've been working on porting some software to OpenBSD for a couple months and kept thinking to myself
"Boy I should get a proper workstation setup"
At first I was just using an ssh shell to one of my servers and working off that, which was a pain in the ass when the network was slow or out, or otherwise unavailable.

Second thought was,
"Maybe a VM on my main laptop will do?"
Uh, no. I don't like VMs, and to be honest I need a bit more performance than typing into a VM console. I have friend that is a VM hipster who thinks they are the best thing since butter, but I'm just not that kind of guy.

Anyway, after setting up a workstation on a spare P4 that has been sitting on the shelf behind me for a couple years and enjoying the experience, I grabbed a Dell D620 from a local company which sold all its old gear to me for a tuppence.

Power Management

Last year I sat through a talk by Theo de Raadt where he claimed that OpenBSD has the best ACPI implementation of any of the free operating systems. After noticing that the stock installation of OpenBSD ran a little hot on the D620, I opened the acpi(4) man page which said:
"Userland may access acpi by using the apm(4) device."
After a little bit of reading, I concluded that editing rc.conf.local to start the apmd daemon (responsible for handling the power management stuff) in "keep my computer cool mode" should do the trick.

apmd_flags="-C"
On the advice of a random webpage I un-commented the line in /etc/sysctl.conf which tells the system to suspend whenever the laptop lid is closed.
machdep.lidsuspend=1
After a nice demo by Henning Braur after his talk at BSDCan this year I am pleased to confirm a nice suspend and resume experience. Not only does the laptop take a nice nap when the lid is closed, it actually gets out of bed and back to work when its open.

Docking

Along with the laptop came a dock, which I specifically wanted to enable a modest transition from mobile to fixed workstation. And after a solid 7 minutes of rummaging through man pages I couldn't find any hooks to detecting when the machine has been docked.

Basically I wanted the following to automatically happen when the laptop is docked
  1. Turn off wifi
  2. Disable suspend on closed lid
  3. Turn on my desktop monitor
  4. Turn off the LVDS laptop panel
1 and 2 require some root permissions which means configuring sudo, 3 and 4 are easy with xrandr (thanks keith packard).

Upon undocking, I want to reverse this behaviour.

So far I have two scripts sitting on my desktop called docked and undocked which I can run to manually cut things over to the preferred state. I suppose this will do for now, since I have other things that need my attention.

Does anyone know of a more elegant way to do this? Or would someone like to write up a small daemon to handle this in the background? Maybe it could be called dockd?

Summary

In anycase, getting the system up and running has not been terribly difficult, and I should have no more excuses when it comes to getting to work on the OpenBSD port of FreeSWITCH I was going on about recently.

Saturday, March 30, 2013

Aastra MBU 400 and FreeSWITCH

Today I'm hanging out at my parents gas station/gallery/cafe/grocery store/internet publishing company. I took some time today to configure an Aastra MBU 400 for use with FreeSWITCH. The MBU 400 is a discontinued Aastra product apparently targeted towards residential or small office deployments where users would want portable handsets, akin to standard wireless portables that people already have in their homes.

Aastra 420d Portable handset which connects to MBU 400 base station, supports multiple handsets
The MBU 400 base station in my possession has a traditional POTS RJ11 port on the back for connecting to standard phone systems as well as a 10/100 network port to get the device onto the network and communicate with a SIP server.

It is possible to provision the network configuration for the base station through one of the handsets, selecting between static IP or DHCP. Also it seems possible to provision some aspects of the SIP configuration though the handset as well, although the experience would probably be tedious and is likely missing many fine grained settings. Like most SIP phones, the configuration can be pushed out with some proprietary gear from Aastra, which I don't own, and wouldn't buy anyway.

The MBU 400 has a web interface, for which the default credentials are:
  • Username: admin
  • Password: 22222
The SIP account configuration seems to require both the Registrar and Outbound Proxy fields to be filled (even if they have the same information). I pointed these towards my FreeSWITCH instance, to which I had already setup a new user extension.

Seeing as how my FreeSWITCH server is remote (I don't leave it sitting around my parents place), it needs to communicate over an IPv4 NAT.  The out of the box configuration didn't seem to work, but with a lot of diddling around with settings I managed to get it to connect.

To get inbound and outbound calling working, I needed to turn on stun, rport and turn the keepalive time down.

The MBU 400 is definitely an aged device which doesn't support a lot SIP features, notably there is no support for any type of encryption at any point in the communication process. Nor does the device support TCP SIP connections, which I prefer over UDP for a variety of reasons (which I might get into some other time). Codec support is pretty sparse and I ended up with vanilla PCMU audio.

Some conclusions:
  • The device is out of production. Don't buy a new one. Support has expired from Aastra too.
  • Nice for setups like my parents, it answers legacy POTS calls by default, but automatically dials out on my SIP circuit.
  • Works with FreeSWITCH for inbound and outbound dialing, but I haven't tested other features like message waiting or holding calls.
  • Buttons are a little small, and the ergonomics kind of suck.
Modern implementations like the Cisco SPA232D and correlated SPA302 portable handset does everything the MBU 400 does and much better.

Thursday, March 28, 2013

FreeSWITCH on OpenBSD

Been a while since I posted. If you're reading this post you, you probably came in from your favourite search engine while searching for OpenBSD and FreeSWITCH.

FreeSWITCH is a software voice switch which handles any manner of voice related activities.

These days voice is pretty important, and the backend infrastructure which implements it is in a decades long process of migrating from the traditional  POTS (Plain Old Telephone System) to an all IP phone system. FreeSWITCH is definitely going to be on the platforms that ushers in the next generation of telecom. While I have some reservations about how the project is developed and maintained, it has a lot of things going for it like stability and a remarkable feature set.

Using FreesSWITCH on OpenBSD might seem like a good idea seeing as how OpenBSD has the spectacular pf firewall, excellent security history and doesn't move very far in weird and zany directions.

FreeSWITCH on the other hand can't seem to stop moving in weird and zany directions. They (even after moving to stable release tarballs) suggest that checking the source out from git is the best way to the most current and stable versions and don't blink twice at dragging the entire source tree of their dependencies into their git repository. The FreeSWITCH developers attitude towards using system versions of their dependencies ranges from aggressive no's to rampant apathy. I understand their reasoning (which is not exactly wrong), though for me this is pretty odd considering that pretty much every other major project doesn't have this problem.

So OpenBSD and FreeSWITCH... Where to start.

At the time of writing there is no port of FreeSWITCH for OpenBSD, or any substantial package built for any major open source operating system.  Nor is there likely to be without some serious effort. The only way to use the software is to jump though the git checkout hoops and run their gigantic build process through from start to finish (yawn). Debugging their build process on other operating systems than linux is a pain as well, given the dependency on stuff like gnu make, the position of the planets in the night sky and the inclusion of dependencies in their source tree.

There have been thousands of hours of effort put into making those dependencies 'work' properly on OpenBSD (nevermind all the other platforms out there). And replicating all that work into FreeSWITCH source tree just seems dumb and a waste of time (which it is).

My proposed solution (and admittedly a work in progress without a finish line in sight) is the creation something along the lines of a shallow fork of upstream FreeSWITCH that could actually be used as an OpenBSD port.

First order of business is the build system, and again since we're talking about OpenBSD, I am not talking about using autoconf, gnu make, cmake, imake, scons, or any number of build suites. Really, I'm just talking about vanilla OpenBSD make (here is an interesting thread on BSD Make). Of course, use system libraries or existing tested ports wherever possible.  The source tree should contain just those files actually needed for creating a bare installation


There are a long list of modules that also need porting, including some core requirements like mod_sofia.

After that there needs to be some work done on things like moving configuration to /etc, logs to /var/log and various other activities consistent with making FreeSWITCH a valid citizen on OpenBSD.

As I said, this is a work in progress, you can see the progress here on github.

Monday, October 3, 2011

Copyright Modernization Act - My View

For some pre-reading for this article:

I am not satisfied by what I read about the upcoming Copyright Modernization Act. As a technology industry expert I am quite familiar with the methodologies and rationale involved with the implementation of Digital Rights Management

Most importantly is the implications around digital content locks and their viability.

Foremost in my concern is that otherwise legitimate usage of digital content is permanently restricted simply by the presence of a digital lock of any kind. The implications of this is that legally purchased content can only be accessed through pre-approved processes and devices. Otherwise fair access to the locked content becomes illegal under the provisions of the new bill.

For instance, my mother has been a subscriber to Audible.com where she purchases recorded audio books which are stored in the DRM encumbered audible format. However, one of her intentions for purchasing the content is to be able to consume it while in her vehicle.  Unfortunately her vehicle does not include authorized audible decryption software, so it becomes necessary to convert the encrypted files to a format which the vehicle does comprehend (in this case MP3). In no way is this an illegal activity, nor should it be under any appropriate copyright law, however with the new digital lock provisions, doing this becomes illegal.

There are a number of other consequences to the act that I am uncertain are covered by exemptions such as recovering installation keys to installed software products on Microsoft Windows and viewing encrypted content over an unsecured monitor.

Effectively the law has the digital locking aspects backwards, where fair dealing with content should trump any locking provisions, not the other way around.

Tuesday, September 27, 2011

SMART Payout Software Demonstration in .net WPF

I wrote a WPF demonstration software for use with the Innovative Technology SMART Payout recently. I am available to provide software consulting services around this device and its cousin the SMART Hopper.



Features:

My software is a good demonstration of how to interact with the device. Naturally it needs to not look crummy :)  Was written in C# .NET 4 WPF inside of Expression Blend 4.


How to secure a computer in an hour

I'm not a security expert.

Well, let me say that I am the most technically skilled security expert that I know, however, I do not consider myself to be a security expert. My general approach to security is, turn off as much as possible, block everything except those few things I need and while I am at it, update everything to fix as many vulnerabilities as possible.

So I am now administrating a server rack full of equipment running a slew of operating systems from linux to OpenBSD, to Windows Server 2003, 2008 and 2008 R2.  Now there is nowhere nearly enough time in my day to audit these systems for vulnerabilities, and beyond running windows update, patching the linux/bsd machines, turning features off and putting a pf firewall in front of the entire rack, I am not certain what else I should be doing?

I'd love some input here? If I were to spend a single hour tomorrow above and beyond my regular work securing the services, where would the best place to start be?

Sunday, September 25, 2011

QNX Blackberry Devices and the Future of RIM

I've been reading a lot of negative reviews and opinions about the Blackberry PlayBook and the future of RIM and I want to put my input in before things get out of hand. I own a PlayBook (really I do), and I read the reviews and general disrepute which people are holding RIM, and I don't really get it.

Many of the complaints about RIM are that they are behind the times with the deployment of messaging and contact software on the PlayBook.  Obviously, this isn't the case with their current mobile phones, where they dominate the mobile messaging market with their email and bbm.

So, then what's up with the PlayBook; how come to so many people they appear to be struggling (as reflected by their stock price, and the plethora of nasty comments by people on the Ars forums)?

In the world right now we have a handful of mobile platforms to work with; Apple, Google, Microsoft, Nokia, Palm (HP) and RIM share almost the entirety of the mobile smart device market and with HP out and Nokia walking away from the software game with the recent deal with Microsoft, that leaves us with a grand total of four vendors supplying most of the worlds software platforms.

When Apple released their tablet platform in 2010, it looked cool which had many people buy it, however, for many others, their was a major level of uncertainty as to how useful it would be to, you know, get something done. And of course, it's not a good device to get something done on; the form factor is simply not conducive to actual real world work unless someone goes out of their way to write custom software which addresses the relevant silo (hence the app store). The iPad got relegated to the world of entertainment, which it appears to do well since people seem to enjoy movies and browsing the web and playing target games.

Now, the real problem is that all that fun stuff goes only so far, and when it comes down to it, a $400 laptop is a heck of a lot more useful than a $600 tablet.

And into this market comes the rest of the industry, which is super keen on exploiting and investigating this new form factor to see if any fortunes can be made; and of course they are running into the issues of usability, time to market and competition. The real fortunes in tablets might already have been made by Apple, and from now on the prices don't have a heck of a lot to go except down.

Now the rest of the industry has a couple options:

  1. Develop a new tablet platform from scratch (With plenty of time to do it right)
  2. Develop a tablet platform from existing non-tablet technology (and hopefully do it right)
  3. Adapt an existing handset platform for use on tablets (and maybe do it right, but end up with effectively the same product as any competitor which follows suit)
  4. Don't enter the tablet market
When the iPad was originally released it was very clear that Apple had simply shoehorned the iPhone operating system onto a bigger device and called it the iPad, and the vast majority of the competitors looking in on that thought that would be a good idea to follow with the Android platform. So in short order the world was engulfed in tablet computers running handset operating systems.

Undoubtedly RIM was looking at this situation, and it's decision makers weighed the value of shoehorning their Blackberry OS onto a tablet like Apple and Google's vendors have or jumping on the Google bandwagon and making yet another Android device. However RIM is different from every other current vendor in that they have an enormous investment and market share in their current technology platform (including BES, BBM and BIS email) and are obligated to support their existing customer base. In one weird sense, RIM is held back from just whipping up a hardware product and installing the latest head release of Android by the fact it has a reputation to uphold (I don't believe RIM could have used Android as it's tablet OS and maintained credibility).

Moreover, when RIM examined its own software stack to see how it would fit onto a tablet, I am certain that key decision makers in the company saw (rightfully so too) that a handset platform is not a good fit for a tablet, especially if you actually want to get something done on it, and that an investment into a fresh design would be the only way to actually distinguish the product on the market in the long run.

With that in mind RIM acquired the QNX platform for use on the PlayBook.

Now, out of the box QNX was not a tablet operating system, but neither was it burdened by years of specialization as a handset operating system. Pressured by time to market considerations, and the imminent depreciation of the entire tablet market with ever lowering prices RIM got a functional 1.0 release out the door by April of 2011. However, the product didn't include direct support for existing RIM technologies likely because their simply wasn't time to rewrite all the necessary software for the new operating system.

That said, RIM did ensure that existing customers would be able to still use their BES, BBM and BIS email technology by using their existing fully featured blackberry handsets as a proxy for the service and writing thin clients on the PlayBook to interact with the handsets.

Thus the PlayBook came to market.

The criticisms that RIM has faced are that the the PlayBook doesn't have a built in email client, messaging software, calendaring or contact manager. However it is important to note that, while this is true, RIM did manage to bring their product to market with support for their existing customers, even if the product didn't have a great deal to attract new ones out of the gate. The promise being that since their is so much at stake for the company, that they will continue to support the PlayBook for the foreseeable future.

Which brings us to the current date.

Still unanswered is the actual real world usefulness of the tablet form factor. Data input via typing is painful, and will probably never be considered a strength of the form factor, however gestures and the multi-touch interface go an incredibly long way towards making the device usable, however, this is limited to only certain classes of software.

The QNX platform though is quite advanced and likely offers the best long term software choice in the industry. The migration to the handset from the tablet will likely prove much easier in the long run than the reverse.

Where the PlayBook really shines, and needs special attention is how it is used in a business context. The onboard HDMI port makes the device entirely usable for presentations, and with a little more work on the built-in powerpoint clone, this could be one of the main selling points of the device.

Still missing is a robust way to share files with a standard desktop computer running Windows or other portable devices.  The necessity to use BlackBerry Desktop Manager to sync and manage files on the PlayBook is completely untenable. MTP/Bluetooth, MTP/WIFI and standard MTP are how this should be done and RIM should know that by now.

File format support should be expanded to include all the same formats as supported by the latest BlackBerry handsets. Notably missing are ogg vorbis and webm formats (in addition to a handful of others).

The built in video conferencing software needs a great deal more attention. Support for interactions via Microsoft Lync, Skype, Jabber and SIP are critical to the business story of the device.  Since a native full BBM client is imminent, I haven't included it in this list.

Fallback to a tethered handset data provider is not seamless, and appears inaccessible from some applications, notably the bundled mapping software.

The developer story is poor.  Really an add-in to visual studio is what is needed here with a preconfigured 'run on simulated device', 'publish to hardware' and 'submit to app world' with support for digital signatures out of the box.

I'll summarize this post with the following comments:

I feel that the platform has a great deal of potential, especially with the imminent Android application software compatibility layer arriving in October and the rest of the basic messaging services like email and BBM arriving as full native clients. Since RIM is hardly going anywhere from the corporate point of view and QNX is the future of the company, owners can expect a long product life cycle which will probably only be matched by Microsoft with Windows 8.

Shareholders should stop panicking, and running.  RIM has done a good job with what they had available in front of them, had they taken any other actions, their credibility would have been worse off. Yes, it takes a while to do this kind of work properly, for hints at just how long, look at Microsoft (arguably the most capable software manufacturer in the world) and how much R&D they are putting into the tablet user experience.

RIM, the tablet needs more ongoing support for new features. Some of these I have already mentioned, however others are simple things like copy/paste, or more complex like messaging and notifications while "in-app".  Tile based window management would be a good feature to add, since the device already supports concurrent software.

Anyway, Good Luck and keep on swimming, Canadian high tech is depending on you.