I sadly discovered today that nothing on my MythTV was recording, and even live TV was not viewable. "What gives?" I pondered as I poured through the logs.

# tail -f /var/log/mythtv/mythbackend.log
2010-02-21 22:06:29.747 TVRec(2): Changing from None to WatchingLiveTV
2010-02-21 22:06:29.757 TVRec(2): HW Tuner: 2->2
2010-02-21 22:06:30.768 HDHRChan(xx/1), Error: device not found
2010-02-21 22:06:31.780 HDHRChan(xx/1), Error: device not found
2010-02-21 22:06:31.782 HDHRChan(xx/1): SetChannelByString(6-1), Error: Channel object will not open, can not change channels.
2010-02-21 22:06:31.783 TVRec(2) Error: Failed to set channel to 6-1. Reverting to kState_None

Well, that didn't bode well. I sauntered into the data center (the nook under the stairs without adequate power, lighting or cooling) and found the power light on my HDHomeRun was blinking and worse, so was the light on the power supply. A quick google turned up a known failure with the power adapters on some versions of the HDHomeRun. Guess who was lucky enough to receive one of them?

So this post is just an FYI to anybody else who bought an HDHomeRun. The RMA process is dead simple, just enter your device ID, and they'll send you a replacement for free. But the question is, what are we going to do for 3-7 business days while we wait? Back to live TV again? Oh the humanity!

A few weeks ago I completed an upgrade from OpenSER 1.2 to Kamailio1.5. Overall it's been working quite well and actually was not nearly as hard as I feared it might be. Now that I've got this new version with a ton of new bells and whistles, I thought I'd try out a few of them. One of the most exciting is shared memory hashtables.

First a quick primer on hashtables. Currently whenever the proxy needs a value from the database it simply queries the database and gets the value. Straightforward, right? But as the system grows, the database can be greatly put under strain. In my Kamailio cluster the single biggest CPU user is in fact the MySQL database by a large margin. And since the database changes pretty infrequently it would be nice if we could cache those values.

The problem is that Kamailio is a multi-process daemon, so what's cached in one isn't going to be cached in another. Enter shared memory hashtables. The same cache is shared among all the processes. Usage is pretty simple. Here's an example:

# IP based authentication
if ($sht(ht1800=>$var(fU)::ipauth) == null){
	if (is_user_in("From", "ipauth")){
		$sht(ht1800=>$var(fU)::ipauth) = "yes";
	}
	else{
		$sht(ht1800=>$var(fU)::ipauth) = "no";
	}
	$var(ipauth) = $sht(ht1800=>$var(fU)::ipauth);
}
else{
	$var(ipauth) = $sht(ht1800=>$var(fU)::ipauth);
}

if ($var(ipauth) == "yes"){
	# do whatever...
}

Don't worry too much about the nitty-gritty. First we check to see if the value is cached (($sht(ht1800=>$var(fU)::ipauth) == null)). If it's set, we just use the cached value and continue. If not, we have to ask the database (is_user_in("From", "ipauth")) and then save the result in the cache. It actually is that easy.

But the $64,000 question, has it helped? Luckily I thought ahead and got some data before I made the change. I grabbed the query log for a day before and after the change. I made sure to select two days where the call usage was the similar (1% difference). Overall there was a 20% reduction in SQL queries.

I only put in the one change as a proof of concept. Since it sure seems to have panned out I'll continue wrapping all my database calls with hashtable caches. One thing I still need to work out is how to invalidate the cache when I make a change through my provisioning system. And once I'm able to upgrade to Kamailio 3.0 I'll switch over to memcached, which has all the benefits of a shared memory hashtable but it's also clustered. Ooh, I'm so excited!

So, just a word to the wise: dpkg --configure -a is not the same as dpkg-reconfigure -a. The former will continue configuring packages where an interrupted session left off. That's a good thing. The latter will reconfigure every package on your system. That, I think I can safely say, is a bad thing.

And no, I don't know anyone who's made that mistake recently. Nope, nobody.

For whatever reason last night my OpenWRT access point decided to stop working. My laptop would connect for a second and then disconnect. I tried another wifi card and it did the same thing, which eliminated my laptop as the culprit. I turned off WEP and was able to connect. The weirdest thing was when I would try to turn WEP back on, I got this error (in bold):

[root@alberto ~]# iwconfig wl0
wl0 IEEE 802.11-DS ESSID:"zmonkey.org"
Mode:Master Frequency:2.437 GHz Access Point: 00:0F:66:4A:DF:08
Tx-Power:19 dBm
RTS thr:2347 B Fragment thr:2346 B
Encryption key:<too big>

I'm not comfortable without encryption (although honestly I would like to run a captive portal alongside my encrypted network), so after a few reboots and unsuccessful attempts to get WEP working I gave WPA a shot. It's really what I should be running anyway but I've had WEP set up for so long I just didn't feel like dealing with it.

But luckily, it worked out quite flawlessly. Following a guide I found here I got it set up quite simply. I did have to reboot to get the changes to take, but not a big deal. The only remaining problem is reliably getting my laptop to use WPA. That's the real reason I've delayed. I've gotten it to work before, but it's sometimes been a pain. All in the name of progress, I suppose.

I heard about MindTouch on FLOSS Weekly last week and decided to give it a try. It's a fork of MediaWiki, the framework behind Wikipedia. I've been looking for a wiki for a while so this was a perfect opportunity. Based on the FLOSS Weekly interview I had high hopes, but unfortunately I was quite let down.

The tech in MindTouch is actually pretty cool. The install goes very smoothly. It requires a number of web packages, including Apache, MySQL, and PHP which I already had installed so nothing further was required. The setup was just a few more clicks and away I was going, setting up my wiki.

At that point things seemed great. I spent a few hours creating pages and linking them around. It worked rather smoothly. I really like the embedded FCKeditor which made markup a snap. Life seemed good.

I did have a few problems with the configuration, mainly because just about anything interesting you want to do with the software, beyond an RSS feed, is locked away in the "enterprise" versions. I wanted to set up LDAP authentication or Twitter integration, but no go. Looking through the version lists it seems that they're trying to only put the bare minimum into the open source version. But I figured it was worth a test drive for a few weeks at least.

And then Monday morning hit and I got a curious email in my mailbox. Sam Montes had written to see if I needed any assistance with my MindTouch install. He just wanted to know more about my company and how we planned to use it. Say what?! I went through the roof. At no point during the install was there a "phone home" option displayed. If there had been you can rest assured I wouldn't have selected it (in fact there was an option to join their mailing list and I declined). The fact that they would spy on my like that leads me to suspect their motives. How do I know they're not keeping tabs on all my data? At this point I can't trust anything they say.

I responded to Sam and voiced my concerns. He replied with some drivel about providing the highest level of service and integrity. I'm sorry but I just can't forgive this affront of my privacy. This is the sort of behavior I might expect from a proprietary software company, but I expect more from open source developers.

I've received further email from MindTouch because apparently they put me on their mailing list, despite my request otherwise. I just can't get past this and I shall be uninstalling MindTouch soon. What a shame.

And with that, I've uploaded all my slides for the Utah Open Source Conference. My goal was to have them ready by last night, so I'm a bit late. Still better than last year where I only had one presentation and I was still updating my notes the night before. If you're looking for me make sure to check the schedule as there have been some changes, and there may well be more to come. Also look for my late addition where I'll be joining Gabe Gunderson of izeni to talk about VoIP (specifically FreeSWITCH and Asterisk).

I will be presenting at the Utah Open Source Conference (UTOSC) again this year. On tap are 3, count 'em, 3 presentations. I'm still not quite sure what possessed me to submit 3 abstracts but I did and (just to spite me I think) they accepted all of them.

Refer to the schedule for any last minute changes but for now here are the times I'm speaking.

• Oct 08, 3:00 p.m. Networking 101
• Oct 08, 7:15 p.m. Are you ready for IPv6
• Oct 10, 11:00 a.m. Introduction to Perl for scripting

Hope to see you there.

Lately I've been feeling rather disappointed by Evolution. I've been a long time user (7 years I think) and for the most part it works great. But it's that "most part" bit that really is starting to grind. The last few iterations that I've tried (whatever is bundled with Ubuntu Feisty, Gutsy, Intrepid and Jaunty) have all had a a few quirks, none of them the same of course, For instance, The Intrepid version had an annoying habit of leaving messages marked as unread, even after I, you know, read them. Made for an annoyance when filing messages away. Worse, many of the messages that Evolution said were read, weren't really marked as such on the server so sometimes messages would magically unread themselves.

So I decided to give KMail another shot. I tried it last year sometime I think it was and decided it just didn't cut the mustard. But I'm a few revs forward on KDE now so it was worth a try. Over the last few days I have found it to be less annoying and much snappier than Evolution so I am considering a permanent switch, but it too does have issues. One major oddity is that when I open up a new folder, the unread messages count will reset while the folder is rescanned. That's just crazy. I can see why in a way, but there's just no need for it. A second complaint is that there's no way to move to the next message without closing the currently open message and opening a new window (I turn off the preview pane).

On the other hand, KMail excels in a quite a few ways. Contact auto completion is much much (much!) faster. I like the idea of the "favorite folders", although to date I haven't made much use of it. I like the way it integrates with my Spam Assassin. It handles multiple identities perfectly (although the configuration is kind of spread out).

Of course the elephant in the room is Exchange support. It's a necessary evil at least at my company (better than Groupwise!). Evolution has an Exchange plugin which works via Outlook Web Access to give you all the features of Exchange in Linux. In theory anyway. While many features do work, not all are flawless. The address book doesn't work for me. My calendar doesn't seem to sync with the server calendar. I've had previous problems with server-side calendar reminders not working, although the version in Jaunty seems to work fine.

Is there anything better out there that I should take a look at? Exchange support would be great, but frankly I don't use all the extra features all that often and if I have to fire up Outlook (via terminal services) once a week, that's not a deal breaker. I would like it to be rock solid, though.

I'm working on an upgrade of a RADIUS server and I need the ability to verify that my changes won't alter the behavior of the server. So what would be really nice is a way to record all the network traffic going to my RADIUS server with a tool like tcpdump and then resend it to my test server and compare the results. As luck would have it, there is such a tool and it's named tcpreplay.

While I haven't run the full tests on my RADIUS server, I have done a few simple tests with ICMP and UDP packets just to verify that it will work with protocols other than TCP, despite its name. It does. Here's an example.

In on root shell, run the following command to capture packets:

# tcpdump -np -s0 -i eth1 -w icmp.pcap icmp and dst host 192.0.20.1

Then, in another shell, start a ping to the IP address in question:

$ ping -c 5 192.0.20.1
PING 192.0.20.1 (192.0.20.1) 56(84) bytes of data.
64 bytes from 192.0.20.1: icmp_seq=2 ttl=64 time=1.63 ms
64 bytes from 192.0.20.1: icmp_seq=3 ttl=64 time=1.49 ms
64 bytes from 192.0.20.1: icmp_seq=4 ttl=64 time=1.55 ms
64 bytes from 192.0.20.1: icmp_seq=5 ttl=64 time=1.55 ms

--- 192.0.20.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4021ms
rtt min/avg/max/mdev = 1.490/1.567/1.639/0.049 ms

Now you've got a PCAP file that you can feed to tcprelay. This is a very basic, and fun, way to run tcprelay so that you can watch and confirm each packet. There are many other options for how you can alter the replay.

# tcpreplay --intf1=eth1 --oneatatime --verbose icmp.pcap
sending out eth1
processing file: icmp.pcap
reading from file -, link-type EN10MB (Ethernet)
15:45:37.376377 IP 192.0.20.189 > 192.0.20.1: ICMP echo request, id 58216, seq 1, length 64
**** Next packet #1 out eth1. How many packets do you wish to send? 1
Sending packet 1 out: eth1
15:45:38.383298 IP 192.0.20.189 > 192.0.20.1: ICMP echo request, id 58216, seq 2, length 64
**** Next packet #2 out eth1. How many packets do you wish to send? 1
Sending packet 2 out: eth1
15:45:39.391925 IP 192.0.20.189 > 192.0.20.1: ICMP echo request, id 58216, seq 3, length 64
**** Next packet #3 out eth1. How many packets do you wish to send? 1
Sending packet 3 out: eth1
15:45:40.394081 IP 192.0.20.189 > 192.0.20.1: ICMP echo request, id 58216, seq 4, length 64
**** Next packet #4 out eth1. How many packets do you wish to send? 1
Sending packet 4 out: eth1
15:45:41.398076 IP 192.0.20.189 > 192.0.20.1: ICMP echo request, id 58216, seq 5, length 64
**** Next packet #5 out eth1. How many packets do you wish to send? 1
Sending packet 5 out: eth1
Actual: 5 packets (490 bytes) sent in 15.14 seconds
Rated: 32.4 bps, 0.00 Mbps/sec, 0.33 pps

Statistics for network device: eth1
Attempted packets: 5
Successful packets: 5
Failed packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0

My boss surprised me the other day with a new phone. Nothing was particularly wrong with my old phone, but we had a bunch of these new Samsung phones due to some staffing changes so I got nominated for one. Ostensibly it's to make on-call easier since I'll be able to read and respond to emails without having to run home. Hopefully that will work out.

So far I think the phone will work out alright. It's fairly bulky, but so was my LG enV, so no big change there. The screen seems big enough to be functional, although it certainly has its limitations. Can't say I can see much solution there short of packing around a netbook though. I love finally being able to synchronize my calendar, something that in theory the enV can do but which Verizon (curse their souls) forcibly disabled. Mobile email also cool. I've installed some applications such as Facebook, Twitter, IRC, that may or may not be really useful in the long run but are fun to have around.

But of course there's bad news too. The battery life is not what I'd like it to be. I'm not sure how it compares to other smart phones since this is my first, but with any reasonably heavy usage I'm looking at charging it a few times a day, and that's going to be my usage pattern during on-call, so I'm a bit disappointed.

It also runs Windows Mobile. I was rather apprehensive about it, but so far it's doing better than I thought. I'd give it a solid mediocre (which is high praise from me).

The application support is disappointing, although not really unexpected. See, with a Free/Open Source background I expect high quality software to just be available for free. With Windows Mobile, yeah not so much. There are a few but they're somewhat hard to find. I could really use an apt-get if you know what I mean. This is an area where Linux users get pampered and it's tough to go without.

Those are the major drawbacks. The one other minor glitch I would mention is that whenever I'm connected to my wifi it constantly tries to bring up a data connection. Well what's the point of that? To get the thing (I named it Aristotle) to knock it off I set up a dummy ISP connection using the irDA port. Hee, hee.

It's a keeper so far. We'll see how I feel after I go on-call this weekend. If you see this blog full of Brittany Spears posts you'll know it's driven me off the deep end. Your pity is all I ask.