I came across irssi-libnotify integration in a picture in blog post I read this morning.

I thought about this, and decided that this was something I had to have. I often don’t pay attention to my IRC while I’m busy with something else, and miss out on a conversation that I’m being hailed in. (By something else, I’m meaning non-important, non-masked-interrupts-something-else.)

It isn’t an easy problem to solve, though. Irssi is running on a remote machine inside screen. I’ll be accessing it from one of many machines, possibly NATed, and possibly unable to receive incoming TCP connections.

I googled around a bit, and came across 3 main classes of solution to this problem:

1. Run libnotify directly on the irssi-box, and use ssh’s X-forwarding to display it on my client. This is sub-optimal, because your X server isn’t always available. Example: irssi-libnotify (which requires the module to be reloaded every time you re-attach screen)
2. Output all hilighted messages to a log file (using fnotfiy), and tail that log file with a second ssh session into a local script that calls libnotify. Sub-optimal, because it requires manually running a second ssh session, and restarting it in the event of network issues. Example
3. Send notify events down the Print Channel of the terminal. This will pass through screen, and pop out at your terminal-emulator. xterm and rxvt are both capable of then sending them to an arbitrary command (which could call libnotify). This is quite a clever hack, except that gnome-terminal doesn’t support it. Example

As you can see, they all have major short-comings, and I wasn’t about to implement any of them.

Finally, I realized that Jabber would be a good way to hail me. My laptop / desktop / n800 / foo all run jabber clients. Perfect. I googled, and found a few pre-canned solutions. I settled for jabber-hilight-notify. It runs a jabber client in a perl irssi script. This then sends me a message whenever a hilighted line crops up. (Assuming I’m not in “Do Not Distrub” mode)

I initially had some problems with getting jabber-hilight-notify working. It turns out that setting a custom resource string is a bad idea. My final config was:

My Pidgin provides the libnotify integration, although jabber-hilight-notify’s designed to work with Tavu (a desktop-notification frontend for KDE). I think a better approach would be to use Telepathy. If such a general telepathy-based solution could be found, then it would be easy to have multiple remote daemons send notifications to you via jabber transport.

Now to see if I’m still happy with it after a week of it interrupting me.

I had an interesting discussion with “bonnyrsa” in #ubuntu-za today. He’d re-arranged his partitions with gparted, and copied and pasted his / partition, so that he could move it to the end of the disk.

However this meant that he now had two partitions with the same UUID. While you can imagine that this is the correct result of a copy & paste operation, it now means that your universally unique ID is totally non-unique. Not in your PC, and no even on it’s home drive.

Ubuntu mounts by UUID, so now how do we know which partition is being mounted?

• “mount” said /dev/sda2
• /proc/mounts said /dev/disk/by-uuid/c087bad7-5021-4f65-bb97-e0d3ea9d01a6 which was a symlink to /dev/sda2.

However neither were correct.

Mounting /dev/sda4 (ro) produced “/dev/sda4 already mounted or /mnt busy”.

Aha, so we must be running from /dev/sda4.

/dev/sda2 mounted fine, but then wouldn’t unmount: “it seems /dev/sda2 is mounted multiple times”.

Aaaargh!

I got him to reboot, change /dev/sda2s UUID, and reboot again (sucks). Then everything was better.

This shouldn’t have happened. Non-unique UUIDs is a really crap situation to be in. It brings out bugs in all sorts of unexpected places. I think parted should (by default) change the UUID of a copied partition (although if you are copying an entire disk, it shouldn’t).

I’ve filed a bug on Launchpad, let’s see if anyone bites.

PS: All UUIDs in this post have been changed to protect the identity of innocent Ubuntu systems (who aren’t expecting a sudden attack of non-uniqueness).

The CS Department at UCT has some Wireless APs on Channel 13. This is quite cool (for geeky reasons), but my MacBook (purchased in the US) did not agree. As far as it is concerned, the only 802.11g channels in existence are 1-11.

The reason for this is that my Atheros (madwifi) network card is a software-defined radio. Atheros interprets the FCC regulations to mean that it cannot provide an Open Source driver for this card, allowing it broadcast on any random channel. Thus the madwifi driver contains a binary HAL, produced by Atheros, which is responsible for regulating frequencies and power levels. (This HAL has been reverse-engineered by the OpenBSD people, but not for my card, unfortunately).

The card has two values stored in it’s EEPROM, a “countrycode”, and a “regdomain”. The countrycode is overrideable in software (you modprobe ath_pci countrycode=710), but only if the countrycode you specify is valid for the card’s regdomain. Some cards have a 0x00 or 0xFF regdomain (wildcard values), but mine had 0x64. This meant that whenever I tried to specify a country code, I’d get an error, and the madwifi module would refuse to load:

There has been some success with changing the regdomain in the EEPROM, using the hard-to-find ar5k utility (or possible the ath_info utility?). However, again this didn’t work with my model. But I found an e-mail from somebody who’d been playing with similar stuff. I mailed Salvatore, and he replied almost instantly, pointing me to a public Windows utility for changing regdomains. It depends on a special driver, available in the demo of “CommView for Wireless”.

I installed Windows in my swap partition (it’s not an operating system I normally have around). (Naturally, I forgot to have an Ubuntu CD handy, to rebuild my grub, but that was easily remedied.). After a few blue screens of death (install all necessary drivers first), I got my regdomain changed to 0x37, which is the regdomain for South Africa & Europe.

Now, I’m writing this from a couch in the CS department, using a channel 13 AP. Success.

You’d think that telecoms (esp in South Africa, where being one is a license to print money) would do everything they could to get you to spend money with them? If only.

Cellphones (at least Vodacom) have always required you to manually enable International phone calls & International roaming, by giving them a call and requesting it. This is a pain, to say the least. And you normally forget until you are already in another country.

But Telkom have taken this to a new level. I got a new phone line last month (which still doesn’t have working DSL, grr!), and just noticed that I can’t make International calls on it. So I phone telkom. Amazingly I didn’t have to wait on hold at all (something never before experienced when calling the beast), and the lady I spoke to told me I have to “Visit a Telkom Shop with my ID”. WTF? How hard are they making it to spend money on them?

Is there any legitimate reason that international calls are blocked? With our pricing, it’s easy to knock up a multi-k-ZAR bill without even thinking about dialling an international number, so they aren’t protecting anyone.

In related news, the reason you can’t have incoming connections on Vodacom 3G (even with “internetvpn”) is because then you’d be liable for the cost of any DOS you received. Isn’t this a problem that hosting providers and ISPs already have to deal with? Why are mobile operators special? We need some Internet Neutrality and Telecoms sense in this country…

Update This is no longer available, the internet APN has public IPs.

A quick tip for Vodacom 3G / GPRS / EDGE users in South Africa.

There is a special APN called “internetvpn” for laptop users who connect to corporate VPNs. While this probably doesn’t interest most readers, it is a useful APN to use because:

• You get a real Public IP address, not a private NATted one.
• You get lower latency.
• The cost is the same. (i.e. regular data bundles work fine)

If you use a VPN, this will probably make it more reliable, and if you don’t it will at least make your ssh use more comfortable.

Unfortunately, the following vodacom issues will still be present:

• No incoming TCP connections (i.e. you can’t serve web pages from or ssh into your laptop)
• Often you get “martian” DNS servers (10.11.12.13 and 10.11.12.14). Either reconnect, or manually set your DNS servers to 196.43.46.190 (SAIX) and 196.207.40.165 (Vodacom).
• TCP connections are regularly reset. (Overloaded NAT/Firewall hardware?)

How to get it:

1. Call vodacom customer care (111).
2. Follow the IVR menu options in the directions of data cards.
3. Ask them to enable the “internetvpn APN” (you might have to explain it to them)
4. Reconfigure your phone / chat script / “data card driver” to use “internetvpn” instead of “internet”
5. Profit! :-)