I’m going to cry.

January 17th, 2008

If you can remember back to my woes with SATA-II disks and 3Ware 9500S cards, you’ll probably be feeling my pain right about now.

The wonderful set of Western Digital RE2 drives, which saved the day all those months ago, now seem to be dropping out of the RAID5 array. :(

However, the biggest clue as to why, was provided by the following 3DM2 alert e-mail:

20080117061603 - Controller 0
ERROR - Drive timeout detected: port=0

Searching the 3Ware knowledge base for ‘WD timeout’ leads us to this KB article, concerning certain WD drives that inadvertantly drop-out of an array because of a fault in their ‘doze time’ implementation. Whether or not the firmware patches describe rid the drive of any ‘doze time’ altogether, or just tweak it for better compatibility is beyond me, but the corrected firmwares can be had from this download page on the Western Digital website.

So, I guess I’m going to UKS on monday to upgrade the firmware on four WD5000YS drives. :(

Update: As it turns out, the disk firmware was already up to date! Now I wish I’d known you could check the drive firmware in 3DM2 before I bothered connecting each drive to the on-board controller, booting up with an FDD and waiting to be told 4 times that the firmware was already current! Whoops ;)

If anyone else comes across this, and they’re sure their drives are from the older firmware set, you would do well to upgrade your 9500S (or other 3Ware controller) firmware first. The latest release (at least for the 9500S) has an update that allows the WD firmware upgrade to transverse the 3Ware controller: so no need to meddle about with connecting disks to on-board controllers.

Anyway. The array has been fine since; no time-outs at all. As above, I upgraded the 3Ware card’s firmware by a few revisions, so hopefully that will sort the issue out. Guess we’ll just have to wait another 6 months to find out! ;)

TFTP Server via Netgear DB834GT

January 14th, 2008

I’ve written a short guide on how to configure a Netgear DB834GT (and possibly other variants of the DB834) to forward a device to a TFTP server, via the router’s built-in busybox/linux-based udhcpd server. I’ve recently been setting up a Cisco IP phone at home, and this functionality has proven to be extremely useful.

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. :)

Windows’ Wonderful Network Routing

January 8th, 2008

Update: I’ve since realised (after doing this on another machine) that if you enable the RRAS (Routing and Remote Access) service under Server 2003, it actually does behave in the correct manner.

Why can Linux just do this out of the box, eh?

Running multiple NICs, on different networks, is not something I’ve had to do before with Windows. I’ve always been using Cisco routers or *nix-based devices for my routing needs. However, I came across something really quite annoying when I was fiddling with the above.

Imagine this: A Windows 2003 Server VM, with two virtual NICs. One has a public IP configured, bridged to the Public Address LAN, and the other has a private IP configured (which was obviously bridged to our internal Gigabit LAN.)

Now, possibly for reasons of clarity, 2K3 issues a notification when you configure more than one default gateway, if they’re from differing networks. Something to do with it not working well in load-balancing situations. Fair enough. But I immediately think that if it’s going to complain about something like that, then it obviously doesn’t need a second default gateway, and indeed it shouldn’t (as the networks are in completely separate IP ranges - it should work out where best to send it.)

Unfortunately, someone forgot to mention to Mr. Microsoft, that the term ‘default gateway’ is otherwise known as a ‘gateway of last resort’ and not the ‘gateway of only resort’!

So for the last few hours or so I’d been racking my brains over why connections to the internal LAN weren’t being routed back. The last thing I thought to check, was the damned Windows Server. Why on Earth would it ever decide to route packets for a 10.16.0.0 address over it’s default gateway on another network, when it’s already connected to 10.16.0.0 directly?!

Setting a default gateway (ignoring any notifications) for the internal LAN fixed it immediately. Grr.

m0n0wall under VMWare Server

December 27th, 2007

Recently, the company I work for has been looking for a way to simulate poor or slow connections to the server component of their next software product. I’m sure you’d all agree that it’s important to know how well your server compensates for those with less than ideal Internet connectivity, so we decided to try out the traffic shaping facilities provided by m0n0wall.

Now, of course we have Cisco routers and the like, but setting them up for something like this could take ages. With m0n0wall, it’s all web interface, and therefore is far more intuitive. So far I’ve not got around to setting up the actual connectivity, but I thought I would make a post covering the nuances I experienced whilst installing it in a virtual environment.

Now I find working with VMs is fantastic in many respects, though it can sometimes be infuriating to not have physical hardware to work with when something isn’t right. Thankfully, I’ve recently learnt that diagnosing network faults/complexities surrounding VMs and their bridges, is as simple as checking out the contents of /proc/vmnet/ (under Linux 2.6.x - don’t ask me about Windows!) and digesting the information contained there-in.

As it turns out, I thought my host’s bridge configuration was wrong. After many different tests, and lots of cat’ing files within /proc/vmnet, I realised that I wasn’t doing anything wrong (well, maybe not directly.. See below) with my host configuration. The ‘default’ NIC chipset used by VMWare Server is covered by the AMD PCNET32 driver. Under Gentoo/Windows this works great, however, it wouldn’t bring up the correct interfaces within m0n0wall. Cue my helpful colleague, who suggested that adding a EthernetN.virtualDev = "e1000" line to the .vmx file; one for each NIC you have configured. In my example, this was simply a case of replicating the line for both ‘Ethernet0′ and ‘Ethernet1′ (but you may very well require a third NIC.)

Once m0n0wall was booted with the e1000 (A.K.A. Intel Gigabit) NICs, each one was described as ‘up’ immediately. But unfortunately, it was apparent that something else was also going wrong with the way I had chosen to setup the VM itself.

What really threw me was the inability of m0n0wall to intelligently use the hardware I provided it with. I configured a fairly generous machine (given the slim system requirements for m0n0wall) which included 96MB RAM and a 512MB IDE virtual drive. I mounted the CD ISO, and provided added a Floppy Disk drive with a blank disk.

However, even with a blank virtual floppy inserted, there was no provision for formatting this - and no complaint when m0n0wall attempted to save it’s configuration and couldn’t. On top of that, why was it preferring the FDD over the HDD? Granted; neither was formatted, but I didn’t think it would be too hard to provide some warning or message regarding your choice of non-volatile storage.

So, I needed a formatted virtual floppy image. I couldn’t help think how annoying the following options would be:

    Power off a (live) Windows guest to add an FDD
    Re-compile a Gentoo VM for FDD support, and add the FDD whilst it’s off
    Install VMWare on my workstation so I could install XP/Gentoo, just to format an FDD

How about no.

In the end I opted for using a Gentoo (minimal) live CD on the VM I had already prepared for m0n0wall. Using links (yep, the bridging worked just fine) to obtain the latest CF card .img file, I issued the command:

gunzip -c generic-pc-x.xxx.img | dd of=/dev/hda bs=16k

Which unpacks the image and copies it to the block device (no need to format, or partition.)

After that, I abandoned the idea of the CDROM/FDD combo, removed their devices from the VM configuration and started it up again. Of course this time it booted straight from the image on the HDD, and coupled with the ‘new’ NICs, everything began working as it should. I had a web interface in no time at all. :)

My words of wisdom? Forget using the CD ROM ISO image! Another little tip I could offer, would be to edit the scsi0.present = "TRUE" attribute in the .vmx file to read "FALSE". You don’t need it, but for some reason you can’t disable it from the VMWare console. It helped to speed up m0n0wall’s boot time, due to removing the need to ‘wait at least 15 seconds for SCSI devices to settle’. ;)

Over-all, I’m quite liking it so far. I may write again soon with some reflections. In the mean time, where did I put that WRAP box? ;)

Whoops.

December 21st, 2007

Had a slightly embarrassing problem yesterday, although I’m not entirely sure it’s my (our) fault…

One of our servers, for historical reasons, is actually hosted in the same rack at UKS as four more; all owned by one of our larger customers. We happen to manage all of these servers, too.

Anyway, sometime around 4pm yesterday (just as I’m about to leave - typical) one of the redundant PSU modules in their primary VM host, and as a horrible, unexpected side-effect, it blew the fuse in the rack’s power bar! Which really shouldn’t happen, but.. Well.. It did! :(

UKS inspected the issue as soon as we noticed, and promptly replaced the fuse. Of course, [almost] all of the machines are set to ‘power-on after AC power loss’ in their BIOS settings. As they all do, the resultant surge in power draw once-again trips the fuse.

We were blamed for not using staggered start-up on our APC PDU. But they don’t all support it? Why should the fuse blow at the sight of four >2A servers starting up? It’s not like the rack was purchased on a fixed ampage - the servers are all paid on single-server hosting packages!

Anyway, as I’m actually off on holiday today, I’ve had to convince the admin girl to drop a spare PSU down to Redditch.. No big deal, as UKS are more than capable of swapping the PSU out.

The bigger problem was the extended downtime of our main web server. It hasn’t got a working LED, so it was “quite difficult” for the on-site engineer to determine if it was up or not. I suppose checking the airflow through the back of the machine, or the multitude of drive lights weren’t obvious options…

After a night of down-time, it’s actually up again. The backup VM didn’t go quite to plan, which I think we’ll need to investigate in the future. And I suppose I’ve got a LED to fix when I’m next in the data centre!

The Cisco IOS copy command

October 14th, 2007

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!

A rescue mission!

September 14th, 2007

What a day yesterday!

One of our customers has had a very similar primary/secondary DRBD/VMWare system to ours, setup for their London HQ operations. This means, one server has the VMs loaded, whist another sits in a warm fail-over mode, courtesy of DRBD mirroring of the VMs.

It’s a bit of a resource drain (power mostly, as space wasn’t much of an issue) but it does mean that the VMs can be resumed on another machine really quite quickly, minimising any downtime in the event of a catastrophic host failure.

Well, two days ago, the system experienced one such failure (we’re not sure what it was; perhaps a kernel panic..) and refused to reboot when power-cycled. A few attempts were made by one of my colleagues to diagnose the issue via IMPI, but this just wasn’t as useful as we’d have hoped (difficulties displaying the AMI BIOS and the grub boot-loader to name the main two woes) and eventually we reverted to bringing VMs up on the spare machine.

The problem here is that, at some point, the primary machine (now inactive) was upgraded from 4GiB, to 8GiB of RAM. A costly upgrade (when you consider that all memory fitted to these server boards must be of either Registered ECC or FB-DIMM calibre - age-depending) at the best of times, which meant that the decision before my time to upgrade one host without upgrading the backup, was now quite a problem.

VMs can consume a monumental amount of memory. Be it with virtual allocation of the host’s memory, to the guest, or by the host OS’s caching of frequently-accessed VM disk data (which the kernel sees as ‘just another large file’, for want of a better explanation.) This is particularly noticeable when one attempts to run a Windows 2003 Server VM, with both MSSQL Server 2005 and Idiom’s [hideous|inefficient|bloated|pick-one] WorldServer software. Not a great idea…

As a result, the VM in particular hogs the host machine’s resources, and when we attempted to start a virtual machine with 3.6GiB of RAM allocated to it, on a host with only 4GiB in total.. We had a few performance problems. Uh-oh! :)

So yesterday, I had another 4GiB memory delivered to the customer’s office, and made my way from Birmingham to London at around 7:45am. I was on-site for about 9am, and much to my surprise, the C.E.O. had already fitted the memory for me! Well, that was nice of him? :)

However, I did spend the entire day (and quite a bit longer) diagnosing the issues with the primary host (which, incidentally runs Gentoo Linux.) On top of this, I’ve also now catalogued the hardware specifications of the machines (that were somewhat lacking), and even set up an old APC PDU that was lying around, which should give us the ability to power-cycle the machines in future without the pre-requisite telephone call to a random member of staff, in-which I ask them to ‘hold the power button for 4 seconds’ (whilst praying that they’ve found the right machine.) :D

A good, if not tiring day, given that I didn’t get home until 11pm! At least the taxis/food is all on expenses. :)

Note to self

September 10th, 2007

Do not write an extremely long e-mail, highlighting the ups and downs of our current VoIP system, and send it to the boss.

You will receive an even longer reply. :(

Bad SIP transfers in CME 4.0/4.1/4.2

August 17th, 2007

Whilst I’ve been messing about with registering a Grandstream GXP2000 to our CME 4.2 server’s SIP service, I’ve found quite an annoying problem.

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.

Testing translation rules

August 1st, 2007

When you’re testing translation rules on a CME setup, you need to be very careful. An example of the test command:

test translation-rule 1 01234555321

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!