Now, when updating Gentoo’s ‘world’ package base, you do get some problems occassionally. This is a downside to being ‘on the cutting edge’ and, it’s obviously no wonder why distributions such-as Ubuntu, Red Hat and SuSe, stick to well-tested release schedules.

Recently, after a well over-due profile update (from 2006.0 to 2008.0) and the following emerge -av –newuse –deep world command, Asterisk simply stopped working. No warning, and it took a while for me to notice.

Once I had noticed, it became apparent that something was really quite awry. Asterisk wouldn’t start via the init script (with has a seemingly immortal, and hideously annoying process), nor via just calling the executable. I eventually realised, with the help of this bug report and the /var/log/asterisk/full logfile, that Asterisk was failing to find the speex modules it required.

Long story short, as per the bug report, you need to downgrade (and mask for good measure) speex to 1.1.12 to retain functionality on anything older than a January/Febuary release of Asterisk 1.4.x.

The fact that Portage still only has Asterisk 1.2.x, means that unless you switch to using the voip overlay, you’re going to find this issue will affect you.

Oh Gentoo, how I love and hate you!

Disclaimer: I am NOT responsible if you screw up, over-write your config, brick your router, forget your password, kill your dog or set fire to the living room. There’s no reason why you should do any of these things, given the simple commands below, but if you do see fit to go a-wandering through the files stored within your router, then it’s not my fault if you break it!

Anyway, to start, you’ll need to enable the debug mode on your Netgear router. Simply construct a link like the one below, paste it into your web browser and login with your username (most-likely ‘admin’) and the configured password:

http://192.168.0.1/setup.cgi?todo=debug

Of course, you’ll need to replace ’192.168.0.1′ with the LAN IP that you’ve chosen for your router.

Now for the fun part. We need to see what the DHCP server is configured to do at present, so issue the following command:

cat /etc/udhcpd.conf

You should see the contents of the udhcp.conf file printed out. It will look something like this:

server 192.168.0.1
start 192.168.0.20
end 192.168.0.254
interface br0
option subnet 255.255.255.0
option router 192.168.0.1
option dns 208.67.222.222
option dns 208.67.220.220
option lease 259200

To setup the TFTP server re-direction, you first need to add a line to this config file. I had to look up a sample config file for udhcpd, but thankfully it lists a number of DHCP options that can be utilised (but aren’t directly supported by the web interface) to extend its usefulness.

Sadly there’s no text file editor included on the router, but one can achieve the same effect with simple shell operators:

echo "option tftp 192.168.0.20" >> /etc/udhcpd.conf

This simply prints a line and appends it to the file. You can check your addition by using the ‘cat’ command above.

Now you need to stop the DHCP server and restart it. This is so that udhcpd will re-load it’s configuration file and take note of your changes. If you issue the command ‘ps’, you’ll see something like this:

# ps
PID Uid VmSize Stat Command
1 root 252 S init
2 root SWN [ksoftirqd/0]
3 root SW< [events/0]
4 root SW< [khelper]
5 root SW< [kblockd/0]
17 root SW [pdflush]
18 root SW [pdflush]
19 root SW [kswapd0]
20 root SW< [aio/0]
26 root SW [mtdblockd]
104 root 244 S /sbin/klogd
147 root 400 S /usr/sbin/hostapd -B /etc/hostapd.conf
163 root 260 S /usr/sbin/netgear_ntp -z GMT+0 -h 208.69.32.170
165 root 256 S /usr/sbin/mini_httpd -d /www -r NETGEAR DG834GT -c *
172 root 268 S /sbin/syslogd -f /etc/syslog.conf
173 root 244 S /usr/sbin/crond
175 root 168 S /usr/sbin/scfgmgr
179 root 184 S /usr/sbin/cmd_agent_ap
180 root 168 S /usr/sbin/pb_ap
193 root 252 S init
602 root 220 S /usr/sbin/utelnetd -d
1835 root 524 S /usr/sbin/pppd plugin pppoa 0.38 user lol@adsl.net
2056 root 300 S /usr/sbin/reaim
2153 root 244 S /usr/sbin/udhcpd /etc/udhcpd.conf
2155 root 396 S /bin/sh
2157 root 268 R ps

As you can see by this line:

2153 root 244 S /usr/sbin/udhcpd /etc/udhcpd.conf

..the udhcpd server is running with PID 2153. To stop it, just kill it:

kill 2153

Note: Although my example shows udhcpd using PID 2153, yours will most-certainly be different, so remember to substitute the the kill command above with one that uses the correct PID value. Killing the wrong PID could mean that you break something vital, and you’ll need to start over again (ie. restart the router, and go back to the beginning of this guide.)

Issuing ‘ps’ once more should show that the udhcpd server has been sucessfully stopped (it won’t appear in the list of running processes). The router won’t restart udhcpd by itself thankfully. Note that whilst you have the DHCP server disabled, any clients expecting a lease or renew won’t get it. I can only recommend that the machine you do this from is assigned a static IP, to avoid any [possible, however unlikely] hassle.

Since we’ve pre-edited the udhcpd.conf file, all that is left to do is restart udhcpd:

/usr/sbin/udhcpd /etc/udhcpd.conf &

The ampersand at the end is important, don’t forget it!

Finally, issue another ‘ps’ command to check that udhcpd has been restarted successfully, and you’re all done.

Unfortunately these changes will not be permanent. If your router is restarted, or power cycled, you will lose these settings. At present, I do not know of a way to successfully add the TFTP option to the configuration saved within the router’s non-volatile memory. It would be nice if Netgear could build some of this functionality into their firmwares (and thus the web interface), and whilst third-party firmwares do exist, I’ve not had the beef to test one out as of yet.

Still, this helped me configure my SIP phone, so hopefully it’ll help someone else.

Update: On my last trip to the hosting facility where this router’s stored, I took the opportunity to test the theory of a non-Cisco CF card knobbling the successful restart of a router. I was sure I’d checked already, but I wanted to be sure.

Thankfully, it restarted without a hitch. So I guess there’s zero cause for alarm.

I know I’ve not written on this log in a long while; I’ve been so busy following the departure of my predecessor, that it’s left me with little time (or will) to write about technology. More to come on this though. I’m still meant to be using this blog as a placement log, so I should really document what I’m doing.

Anyhow, as it happens I’m sat with very little to do at the minute, so I thought I’d write about something that really got me annoyed a week or so ago.

OK, so anyone who’s had the pleasure of setting up a VoIP system based around Cisco CME will know that the flash: directory rapidly fills up with a tonne of files. Config files, language files, firmware files… Basically; a lot of individual little files inhabit your CF card.

Now, on a recent trip to our co-location facility of choice, I wanted to take the opportunity to upgrade the flash card in our voice router. This is a 2811, with the basic 64MB CF card pre-installed, and recently it’s become a pain in the arse working with newer phones (7941′s, in my case) because the firmware files were just taking up too much room. Not to mention you’re only left with ~14MB free space after uploading the IOS image.

So I purchased a 256MB CF card, for about £8 inc. delivery (a mere shadow of the £202-400+ that Cisco wanted for a god-damn CF card of the same size!) and grabbed a standard-affair USB flash drive to use as temporary storage whilst shifting files from one card to the other.

Now, when you’re deleting files en masse from a Cisco flash: directory, it’s possible to use wildcards in order to catch multiple, similarly-named files and delete them all in turn. Which is quite useful if you’re working with 20 config files that all begin with ‘SEPSomethingOrOther’. So because of this included [20th Century] functionality, one would also assume that Cisco would have also included the use of wildcards into the copy command…

Have they bollocks!


RouterX# copy flash:its\SEP* usbflash0:
LOL * IS NOT A VALID FILENAME CHARACTER



RouterX# copy flash:its usbflash0:
LOL CAN'T COPY FOLDERS!


So not only is it retarded enough to not recognise ‘*’ as ‘please copy anything that begins with the preceeding phrase’, it’s also completely inable to copy an entire directory! I cannot believe that Cisco are up to release 12.4(15) and haven’t included some way of copying files en-masse.

It took me bloody ages to copy each of the 62 files from flash: to usbflash0:, swap the CF cards over, and then copy 62 files back to the new CF card. What a horrid waste of time, Cisco.

My good friends at Cisco: if you’re reading this, for the sake of all that’s useful, bloody-well sort it out!

The phone registers fine and can make external calls via the SIP trunk absolutely fine. The phone will also accept transfers of internal calls (ephones), but if I attempt to transfer an external call form an ephone, to the Granstream – the external call is cut-off. I’ve isolated the ‘debug ccsip messages’ output which describes what is happening, but I’m by no means an expert in debugging SIP output.

Aug 14 09:16:49.807: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REFER sip:07xxxxxxxxx@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP cme-router:5060;branch=z9hG4bK3432633
From: ;tag=2CD733C8-216A
To: "Tom" ;tag=as221e2abe
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 102 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-SIPGateway/IOS-12.x
Timestamp: 1187083009
Refer-To: sip:2007@cme-router?Replaces=E72682C6-497D11DC-90D890FC-79F613F8%40cme-router
%3Bto-tag%3Ddb0457357be0d469%3Bfrom-tag%3D2CD77068-25C3
Referred-By:
Content-Length: 0


Aug 14 09:16:49.811: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP cme-router:5060;branch=z9hG4bK3432633;received=cme-router
From: ;tag=2CD733C8-216A
To: "Tom" ;tag=as221e2abe
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 102 REFER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Length: 0


Aug 14 09:16:49.811: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
NOTIFY sip:0116@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK49b17aad;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Contact:
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 104 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: refer;id=102
Subscription-state: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 49


SIP/2.0 481 Call leg/transaction does not exist


Aug 14 09:16:49.815: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK49b17aad;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Date: Tue, 14 Aug 2007 09:16:49 GMT
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 104 NOTIFY
Content-Length: 0


Aug 14 09:16:49.843: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:0116@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK136ae0fa;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 105 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


My voice service voip config is as below:

voice service voip
allow-connections sip to sip
no supplementary-service sip moved-temporarily
sip
registrar server expires max 240 min 60
no call service stop


And the Grandstream phone config is:

voice register dn 1
number 2007
allow watch
refer target dial-peer
mwi
!
voice register pool 1
id mac 000B.820D.0536
number 1 dn 1
template 1
dtmf-relay rtp-nte
voice-class codec 1
description Grandstream


Where ‘cme-router’ is the router on which CME 4.2 is installed and running, and ‘asterisk-sip-gateway’ is our SIP gateway (which the CME 4.2 SIP-UA connects to) that handles more advanced call routing features.

If anyone has any ideas – I’d appreciate the help! It’s not a massive problem, but I’m keen to see this one through.

Don’t assume that just because there is no output from the test, that nothing has been matched. If there are no matches across any of your rules, you will see:

01234555321 Didn't match with any of rules


If there’s no output, then you have a partial match. If you issue ‘debug voice translation’, and watch carefully, you will see output such as this:

Router(cfg-translation-rule)#do test voice translation-rule 1 0123
Router(cfg-translation-rule)#
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=1
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=2
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=3
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=4
//-1/xxxxxxxxxxxx/RXRULE/regxrule_rule_match: partial match found, partial_match 4


There is a problem with this: if your translation rules are mistakenly waiting for any number (as mine was this morning; I’d left a .* on the beginning of the expression!), then your calling will exhibit some odd behaviour.

For instance, when dialling extensions from one ephone to another (simply across CME) your call will be subject to the ‘timeout interdigit’ value (as set in telephony-service). Why? Well, if your translation rules pick up a partial match they wait for a predefined length of time to see if you dial any other digits. The time waited is predefined by the interdigit timeout!

Even if the number matches the correct dial-peer (eg. 20001, 20002) and eventually dials correctly, you will still be subjected to the interdigit timeout, despite the lack of any ‘T’ in your destination-patterns. This is purely because the translation rules are waiting on your dial pattern.

Just thought I’d mention it. Really confused me this morning – many thanks to Tele for helping out!