Well that was a bit of process.

The best set of instructions I found were here.

I think a lot of the other instructions I found assumed you were at firmware version 1.00.62. The CYT unlocker program seems to only work with this firmware version.

The CYT unlocker program is a Windows console-mode program. It seems to run under Wine, but I switched to Windows before I realised that possibly my problems running it under Wine were related to the firmware version on the RTP300 and not a problem talking to the network.

All of the remaining steps on the above page could have been performed on Linux. In fact, the CYT unlocker program merely makes a HTTP POST to a specific URL (and I think it could just as easily be an HTTP GET) and then starts up a webserver on port 2400 to hand an XML blob of provisioning information when the RTP300 requests it as a result of the HTTP POST. A Linux version would be easy to implement.

In all of the futzing around, I noticed this gem in the HTML source of the web interface:

*********************************************************
*   Copyright 2005, CyberTAN  Inc.  All Rights Reserved *
*********************************************************

This is UNPUBLISHED PROPRIETARY SOURCE CODE of CyberTAN Inc.
the contents of this file may not be disclosed to third parties,
copied or duplicated in any form without the prior written
permission of CyberTAN Inc.

This software should be used as a reference only, and it not
intended for production use!

Now that I've unlocked it, I guess I should try and make it talk to my Asterisk box...

When we first moved to the US, I wanted to try and do the telecoms and Internet stuff as cheaply as possible, while still trying to be technologically "fun" as well.

I elected to get the cheapest home phone line (local calls only) I could get with AT&T (then SBC) (which is still remarkably expensive) so that I could get DSL (which, while three times faster than what I'd had previously in Australia, was still not that fast). (I went for DSL over cable because I'd heard horror stories about Comcast's reliability, and also they weren't cool with running servers or inbound services, Sonic is, and is a great ISP). I chose Vonage for US long-distance, I think because I'd heard of them previously, and was interested in trying out VoIP.

We initially used Vonage for calling Australia as well, until I played around with Engin, and then deployed Asterisk.

Anyway, I've been a loyal Vonage customer for exactly three years. The truth is, we hardly make any US long distance calls. We've got friends in Phoenix (hi Craig and Sarah!) that we call infrequently. I guess there might be the odd cell phone that isn't considered a local call, but we tend to use our cell phones more than the home phone anyway... So we were a very cheap $14.99 a month for Vonage.

So when I called T-Mobile to purchase a SIM card for the Android Dev Phone 1 I'd been recently given, the opportunity to have their T-Mobile @Home in place of Vonage, for an extra $9.99 on top of what I was paying for the cell phone line seemed like worthwhile cost saving. I have no attachment to the incoming number for the Vonage line, we give out the AT&T land line number to people as our "primary" home number.

Later that day, Vonage announced they were increasing their monthly fee from $14.99 to $17.99, which made the decision seem all the more prodigious.

I did a spot of research while I was waiting for the @Home box to ship to me, and it turns out that they have a wireless router and non-wireless router option. They hadn't specified what I was getting at order time, and I was hoping I'd get the non-wireless router, since I already had an access point I was perfectly happy with it. As luck would have it, I received the wireless router model (a Linksys WRTU54G-TM). I'd mentally prepared myself to be receiving just another Linksys RTP300, like what Vonage used, and so I was quite surprised by the differences in technology used.

It's been a while since I tried to do any reverse-engineering of the Vonage ATA, but I think from memory, it was essentially that: an ATA. It talked SIP back to Vonage. My DSL provider gave me a few static IP addresses, so when I got it, I just allocated one for Vonage, and did a static NAT through my firewall to for it, and everything just worked.

It was fairly apparent that the WRTU54G-TM was nothing at all like this (given it was also an access point). It takes a GSM SIM card (up to two in fact), which I presume has all of the provisioning information on it. I was initially worried that I was going to need to completely rejig my network to accommodate it. I guess the SIM card approach means there's no customer specific provisioning that presumably otherwise needs to be done to the device itself, and they can just ship vanilla devices. I presume the Vonage RTP300 had some sort of customer-specific configuration, because I never had to do anything.

I briefly toyed with the idea of running two access points, and having a "guest" wireless network, but I am interested in reducing heat and power consumption in my linen cupboard, so I decided to try and just swap over to using the WRTU54G-TM as my access point, retiring my Linksys WAP54G.

So that's exactly what I sat down to do last night. Sometimes in their efforts to make these things "simple", they end up making things more complicated. What I wanted to do was just plug the "Internet" side of the device into my internal network, have it get an IP address with DHCP, and then let me get on with configuring it. The "advanced" setup instructions talked about the box having a default IP address of 192.168.0.1 ("or try 192.168.24.1 if that doesn't work"). I figured the DHCP IP address would override that, so I was trying to hit the IP address I could see the unit had picked up from my DHCP server.

No response from the HTTP server. I could see it replying to ARP requests, and I could see what appeared to be an IPsec NAT-T connection. After some fiddling around, I twigged that I was trying to manage it over the Internet port, and any device worth its salt was going to be very hardened out of the box on what it expected to be the raw Internet-facing side, so I plugged my laptop directly into one of the four Ethernet ports that it also had, and then I could hit the 192.168.0.1 IP address and access the management interface.

It never occurred to me prior to fighting with getting the WRTU54G-TM configured, that the RTP300 might have been more than a black box, as I'd never tried plugging anything into the "inside" ports on it, mainly because I'd never intended to use it as a router or a switch.

Out of the box, the WRTU54G-TM was configured to be a router, which I didn't need, and it was configured to be a DHCP server for 192.168.0.0/24, which I definitely didn't want. An interesting side-effect of putting it into bridging mode was the MAC address changed (to the one that was printed on the unit, which was not how out of the box it presented itself). I have no need or intention of plugging anything into the "inside" Ethernet ports on the WRTU54G-TM, as I have a separate switch for that, and indeed I run my wireless network on a different interface of my firewall to my wired network. Fortunately I was able to enable the management interface via the "Internet" interface.

The added benefit of the device doing NAT-T is I don't need to allocate an IP address to it for the VoIP stuff it work, it all just works fine without it, so I've freed up an IP address, removed two devices from my linen cupboard, added one new one, and saved some money. Woot!

Next, just because I can, I'm going to try and break into the RTP300 and see if I can reconfigure it as a general purpose ATA to talk to Asterisk. There's evidence it's possible. It's otherwise of no further use to me. Even if I get it working with Asterisk, it's not of a lot of use to me. Maybe I can send it to a family member, and they can call us over the Internet for free instead of for the cost of a call to Brisbane...

It's not a holiday without a road trip, especially with petrol prices being lower now than they were three years ago when we arrived here.

So we headed off on Christmas Day for San Simeon, with the general plan to tour Hearst Castle on Boxing Day (which isn't a public holiday in the US, but is a company holiday), and then head to Thousand Oaks, to visit a friend of Sarah's who also had heart surgery this year, and then head home.

We'd hatched this plan a few months ago, and afterwards, saw a news piece on the "Civic Musical Road", and when we discovered it wasn't too far from Thousand Oaks in the grand scheme of things, we decided to throw that on the itinerary as well.

I found a five-part "making of" documentary on YouTube, along with what I presume is the original commercial, and of course, we had to record the experience.

Making of, part 1

Making of, part 2

Making of, part 3

Making of, part 4

Making of, part 5

Presumably the final commercial

Our experience (on the relocated version)

Seriously.

It reads more like a worked example, without enough of the underlying theory. It doesn't help that I have a slightly more complicated situation, in that I have a filesystem on a logical volume that spans 6 physical volumes.

So maybe writing all of this down will help...

I know the disk with the problem: /dev/sdc

I know the LBA of the sector where the rot starts: 754238963

I know that the physical volume is on /dev/sdc1 and that the partition starts at sector 63 (via sfdisk -luS /dev/sdc)

Therefore, within /dev/sdc1, we're talking about block number 754238899 (754238963 - 64)

I know the physical extent size is 4096 Kb (via pvdisplay -c /dev/sdc1 | awk -F: '{ print $8 }'). In LBA block size this becomes 8192 (2 x 4096)

I know the physical extents start 192K (into the partition, presumably) (via pvs -o+pe_start /dev/sdc1)

This is where the Bad block HOWTO starts to quicken the pace a bit on me...

I'm supposed to take the physical partition's bad block number (754238899) and divide it by the size of the physical extent (in LBA block size) (8192). So that'd be 92070.

This is where I think I end up completely departing the HOWTO, because my filesystem spans multiple physical volumes. Here's my general musings...

lvdisplay --maps /dev/data/srv tells me this about /dev/sdc1:

  Logical extent 272326 to 391559:
    Type                linear
    Physical volume     /dev/sdc1
    Physical extents    0 to 119233

So I'm inferring from this, given that I know I want physical extent 92070 of this device, that this corresponds to logical extent 92103 (again, I'm expressing this in LBA block size, so that's (272326 / 8192) + 92070

So now I supposedly know the logical extent (in LBA size) of the bad block. Now what? I think I'm wandering up too many layers, closer to the physical filesystem, but I'll continue wandering around...

So presumably at this point, I just want to convert the logical extent to an actual filesystem block number. Maybe the logical extent number divided by the extent filesystem block size divided by the LBA block size? 92070 / (4096 / 512) = 11508. That feels awfully low though. The dd test suggests this is incorrect.

At this point I'm feeling fairly lost. If someone out there is reading this, and they've done this before, I'd love to hear from you.

So it turns out if you wait long enough, you do get to piece the information together:

.
.
.
Too many illegal blocks in inode 209158151.
Clear inode? yes

Restarting e2fsck from the beginning...
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'denemo_0.7.7-3.1_hppa.deb' in /debian/pool/main/d/denemo (211845291) has deleted/unused inode 209158151.  Clear? yes
.
.
.

I'm watching paint dry while e2fsck does its thing on a ~2TB filesystem (the one with all the good stuff on it on mirror.linux.org.au).

I'd seen a spate of kernel errors during the week about "attempt to access beyond end of device" so I figured it was due for one.

Let's take this output for example:

apollock@disco:~$ sudo e2fsck -y /dev/data/srv
e2fsck 1.40-WIP (14-Nov-2006)
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 209158151 has illegal block(s).  Clear? yes

Illegal block #12 (1620503259) in inode 209158151.  CLEARED.
Illegal block #13 (2992116621) in inode 209158151.  CLEARED.
Illegal block #14 (1657577172) in inode 209158151.  CLEARED.
Illegal block #15 (1168774619) in inode 209158151.  CLEARED.
Illegal block #16 (993415032) in inode 209158151.  CLEARED.
Illegal block #18 (1611893880) in inode 209158151.  CLEARED.
Illegal block #20 (2939071693) in inode 209158151.  CLEARED.
Illegal block #21 (1714919190) in inode 209158151.  CLEARED.
Illegal block #22 (1450852455) in inode 209158151.  CLEARED.
Illegal block #23 (3482149179) in inode 209158151.  CLEARED.
Illegal block #24 (4143923374) in inode 209158151.  CLEARED.
Too many illegal blocks in inode 209158151.
Clear inode? yes

Restarting e2fsck from the beginning...
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
.
.
.

How much more work would it be to tell the administrator the name of the file associated with inode 209158151? That'd be a lot more useful to most mere mortals than the inode number. I suppose if the filesystem is in a really bad state, ascertaining that information may be difficult...

Time to play with debugfs while I continue watching paint dry...

Mike Hommey took some inefficient shell scripting to task.

I feel obligated to point out that more $file | wc | awk '{print $1}' is not the same as wc -l $file.

To get the same output, you're going to need one of:

cat $file | wc -l

or

wc -l $file | awk '{print $1}'

I suspect cat is going to have a faster startup time than awk... (On my system, gawk is an order of magnitude bigger than cat)

My home Asterisk configuration has been pretty static for a while. It works well, and so I haven't had a need to mess around with it.

There's a couple of outstanding features I've wanted to implement for a while though, and I've now got one of them out of the way.

All calls that come in from the local PSTN line, the Vonage ATA, and the SIP connection to Engin, hit a menu, where the caller selects whether they want to speak to Sarah or myself. The sole purpose of this is to determine what to do with the call if no one answers (which voicemail box or cell phone to send the call to). A convenient side-effect of this is that it defeats most telemarketers.

Ages ago, I set up caller ID announcement to my MythTV setup, so if we happened to be watching TV or a recording when a call came in, it briefly popped up on the TV.

Fortunately, we're not huge square-eyes, and spend more time goofing off on our laptops, so I wanted a way to display notifications on our laptops when calls came in as well.

I had this crazy design in my head of having a server process on my Asterisk box, and then clients on our laptops could connect to it, and be informed of new calls. Before I went on a coding frenzy, and did something with the Observer pattern and more socket programming than I really wanted to, I thought I'd check if this was solved problem. Turns out, it kind of is.

I found the Notify application for Asterisk (which I've made a package for Debian Etch), which blats a UDP message to particular host as part of a dialplan. It's more intended to go in person-specific extensions, but as the majority of calls go into the main menu and never come out before hitting a person-specific extension, and I still wanted to know about them for my own perverse pleasure, I added multiple calls to the Notify application in the main menu dialplan.

The site for the application also mentioned some third-party clients for Linux and MacOS, but I've been looking for an excuse to try and write something that used Growl, so I wrote my own Python application, initially on Linux, and then I essentially swapped out the pynotify code for the equivalent Growl code, and it worked just as well on Sarah's Mac.

So it's not quite the solution that I had in mind, because it doesn't really scale, but for our two-user home setup, it's adequate. I might still try and write some middleware between a client for this application and an infinite number of observers, but there's no urgency.

The dialplan for our main menu now looks something like this:

exten => s,1,Background(for)
exten => s,n,AGI(mythtv-cid.agi)
exten => s,n,Notify(${CALLERID(num)}|${CALLERID(name)}|${EXTEN}/icarus)
exten => s,n,Notify(${CALLERID(num)}|${CALLERID(name)}|${EXTEN}/iapyx)
exten => s,n,Set(TIMEOUT(digit)=5)      ; Set Digit Timeout to 5 seconds
exten => s,n,Set(TIMEOUT(response)=10)  ; Set Response Timeout to 10 seconds
exten => s,n,Background(names/sarah)
exten => s,n,Background(press-1)
exten => s,n,Background(for)
exten => s,n,Background(names/andrew)
exten => s,n,Background(press-2)
exten => s,n,WaitExten

A call comes in, hits the menu, and the caller ID info is displayed on MythTV (if something's being watched) and our two laptops (if they're awake).

Unfortunately my Git-fu is atrocious, so I can't figure out how to link to a web-browseable repository that contains the source for my client, but if I figure that out, I'll update this with a link later.

Update

I managed to summon enough Git-fu to put the repository online. It's available at http://git.andrew.net.au/?p=asterisk-notify-client.git;a=summary

Now I just have to use it properly.

There seems to be a bit of a meme here...

I have a set of computers that I frequently reinstall for testing purposes. The "zomg! The host key has changed!" gets very tiresome very quickly.

Host reinstallalot
        UserKnownHostsFile /dev/null
        StrictHostKeyChecking no

I'm reading the Red Hat I/O Performance Tuning Guide, because hey, it's all Linux, and I might just learn something.

So far, I've learned that RHEL doesn't have sysfsutils. How very weird.

Unlike the /proc/sys/ file system, the /sys/ file system does not have a utility similar to sysctl that can make such changes persistent thoughout (sic) system reboots.

and

However, as mentioned in Section 4, “Selecting a Scheduler”, any tuning made though echo commands to the /sys/ file system is not persistent throughout system reboots. As such, to make any scheduler selection/request queue settings persistent throughout system reboots, use /etc/rc.d/rc.local.

Of course, for all I know, this information may be out of date with respect to the current release, but Debian's had sysfsutils since November 2003.

Netflix really is a great service. (That is why I bought some shares in them after all) I like their core product offering, and I like that they're fairly switched on technically with their website. Now I also like their phone support.

We were supposed to receive Clerks: Tenth Anniversary Edition, but we received the bonus disk instead (I'm not even sure how you can do that, it doesn't appear to come up when you search for "Clerks"). I reported it as mislabeled, via the website, but this wasn't really accurate: the sleeve said it was the bonus disk. We'd just been shipped the wrong disk.

I wasn't sure whether the mistake was that we'd received the wrong disk, or that it was misrepresented in the DVD list on the website. I discovered that our $13.99 a month seems to entitle us to 24-hour telephone support (can you believe that?), so I called them up, bashed in our customer identification number, and in under a minute at 11:48pm on a Saturday night, was connected to an all-American sounding "Jill", who very quickly identified that we had indeed been shipped the wrong DVD, and so organised for the right one to be shipped out.

The entire experience was delightful. Yay for Netflix having competent phone support.

It wasn't me.

I just learned about Rovio courtesy of an advertisement in last month's Wired, magazine.

My initial thought was that it might be useful for Sarah's feral cat trapping antics, but alas the FAQ says it's not recommended for outdoor use, so I doubt it would perform well in low light.

Having just watched the promotional videos, I see where this would come in very handy in the smart home I'd like to build one day... It'd be so cool if when we were away from home and the home detected an intrusion, notified me, and then dispatched a Rovio to show me what was going on. Then I could call the police if necessary.

The one immediate downside I can see is that it only seems to support WEP. How 2001.