Sunday 27 July 2008

Asterisk, TDM400P and reliable Caller ID in the UK

Since my post back in March, I've been quite remiss in keeping my own Asterisk box up to date. As it has been getting significantly more use in the last couple of weeks, I've noticed that I sometimes get external calls appearing to come from "asterisk asterisk" instead of the usual Caller ID information. Delving into the logs, it seems I've been failing to capture the calling party's CID about once in every five calls.

Blindly hoping that a freshened install may help, after having already shamed myself by running code that was over four months old(!), I brought the Zaptel software up to 1.4.11 and Asterisk up to 1.4.21.2. Unfortunately, and very predictably, this didn't alter the CID behaviour.

Reading around the subject I learned that for each incoming call my UK BT line undergoes a polarity reversal, a 300ms delay and then receives a burst of V23 CID information before the first ring. My ATCOM TDM400P clone and the wctdm drivers support the polarity reversal detection. Watching the Asterisk console showed that, on a failed CID capture, a "Got event 2 (Ring/Answered)..." was processed just before the CID information should have been displayed. Some further Googling eventually turned up this 2006 post and the answer.

I had to update chan_zap.c manually and have taken a new diff file that can be found here. To apply it, save the file to the root of your Asterisk source code and from there "patch -p0 <reliable-uk-callerid-1.4.21.diff", compile and install. I've tested this patch successfully on Asterisk 1.4.21, 1.4.21.1 and 1.4.21.2 and now Caller ID information is captured every time.

Friday 11 July 2008

Progress of the beast

Seven weeks with our new companion seem to have, quite literally, trundled by. I knew having a puppy would be hard work but, to be quite honest, I didn't think it would be quite so tiring. We've been very fortunate I'm sure, managing to have Belle toilet trained almost from the start, sleeping for most of the night in her cage and accepting the same confinement when we have to go out, leaving her behind. She's continued to grow at a frightening rate and we're beginning to wonder just how big she's likely to get.

Last weekend we found the first puppy teeth on the carpet, hopefully signalling the start of the end of the biting. Belle has been responding to our controlled play and whilst she still enjoys a good gnaw on arms and legs if she can get away with it, at least she now has some appreciation of how hard she can bite down and for it still to be fun. Her chewing on the furniture, woodwork and table legs has just about been brought to an end and her barking always seems to have good reason.

The boy should be awarded a "NoBelle!" prize for his attempts to instil some discipline into our girl. It seems she interprets his shorter (than adult) stature as meaning he is more of an equal, seeing this as an invitation to chase, wrestle and bite him. He keeps plugging away reasserting his authority and, sometimes even through teary eyes, I can see he really likes her.

Our back garden has taken a bit of a beating in recent weeks. Belle likes nothing better than depotting the hard work of my green-fingered wife and digging holes in the lawn that seem to be joining up (imagine puppy-scale WWI trenches!). With hindsight, Horiko ("堀子" meaning "digger girl") would not have been a bad choice of name. She doesn't mind getting dirty either and we've had to hose her down more than a couple of times. Sadly, she thinks this is a great game and I'm sure she gets herself dirty just to play it.

Other moments of horror have included finding Belle gently chewing on the "skin" case for my iPod Nano 3G, having somehow removed it from the device all by herself. Amazingly, neither the case nor the iPod had any visible damage but for the thick layer of canine saliva that had to be carefully washed away.

Puppy training will continue this weekend after it was rained off last Sunday. We're going to try to accelerate her learning, particularly her walking to heel which is not quite(!) there yet.

Wednesday 9 July 2008

XP SP3 won't install? Back to the command line!

After my post back in May reporting no problems with the installation of XP SP3, it was inevitable that I would come across a machine that wouldn't play ball.

A client's XP SP2 machine was reporting errors during the Registry backup phase, complaining of "access denied" to the keys of "HKCR\MsTscAx.MsTscAx" and "HKCR\MsRDP.MsRDP" and some of their numbered duplicates.

The tech had chosen to ignore the errors, so allowing all the file updates to proceed, unfortunately only to be rolled back at the very end of the update process. Thankfully, as he'd also chosen not to take notes of the message details, "%SystemRoot%\svcpack.log" provided me with a full list. Trying to view the errant keys with RegEdit also reported the same error and attempting to repermission them did the same.

There are all sorts of misleading reports on the Web, most of which suggest hacking around while in "safe mode". In fact, Microsoft KB article 949377 provided the answer with its "method 3". Running "subinacl.exe" as suggested on each key solved the problem, allowing SP3 to install itself with no further issues.

Whilst it remains a mystery what caused these keys to become inaccessible, there are a number of discussions on the Web suggesting these particular keys often cause problems. It's amusing that one of MS's own products seems to have caused the difficulty.

Monday 7 July 2008

RJ25 to DB9 serial port adapter

Hopefully this post will help others in a similar predicament. Recently I needed an APC 990-0144 RJ25 to DB9 serial cable so I could configure one of their Switched Rack PDUs but (rather predictably) the original wire was nowhere to be found. Extensive Googling did not provide many answers so I set about with a multi-meter to make my own. To make a long story short...

The pinouts of the RJ25 socket/plug, the RJ45 plug and the RJ45 socket to DB9F adapter are shown in the following table. The minimum three wires to provide the terminal connection are highlighted in bold. (Note that most of the Cisco adapters only have these three wires connected.)

RJ25My cableRJ45
DB9F
1 - Not connectedBlue


2 - GNDYellow5 - GND5 - GND
3 - RxGreen2 - RX2 - RX
4 - TxRed3 - Tx3 - Tx
5 - CTSBlack

8 - CTS
6 - RTSWhite

7 - RTS

I took a trip to Maplin and picked up a "FCC68 6P6C" (RJ25) IDC plug, one metre of "FCC68 6-core" cable. From my own box of tricks I collected an RJ45 IDC plug and a spare Cisco RJ45 to DB9F adapter (so as to eliminate the need for any soldering). Assembling the cable as per the table above, and shown close-up in the picture, worked first time.

As only pins 2,3 and 4 from the RJ25 are used, if you have a more common and spare RJ11 (6P4C) telephone cable you could chop one end off and terminate it with a RJ45 in a similar way to end up with the same cable.

This cable would appear to have the same pinout as used on, amongst others, some old DEC equipment and IBM FastT200 controllers (the IBM part number for the same cable appears to be FRU 19K1179).

Saturday 5 July 2008

The sun shines on the righteous

Despite a few showers on the drive down to RAF Waddington air show and the fifteen minute monsoon as we progressed through the checkpoints into the parking area, the boy and I have managed to stay reasonably dry all day. By 11am there was no more than drizzle and by 12:30pm the precipitation had ceased altogether.

We'd followed TomTom's shortest route that brought us into the village from the West and we headed down Mere Road and Manchester Road, maintaining a straight line until we managed to park not 50 yards from the front and bang in the middle of the runway. To our right on the old cross runway was a B-52H and just in front of that was the reason for our trip, the Avro Vulcan XH558 attending her first air show in 15 years after a mammoth restoration project. I couldn't quite believe how lucky we were, having almost the same view as the Vulcan Trust VIP area.

The air show stayed pretty much to schedule and was action packed to say the least. A departing Typhoon, heading for the competing Yeovilton air show, was spectacular even in the rain. The first few displays were limited by the cloud base being not much more than 1500 feet, the Red Arrows being the most noticeable casualties. We had a good scout around in the hangars, found a great example of a British Leyland Allegro and had a clamber around a Shackleton cockpit. By the time we emerged into the daylight once again it was bright and blue was beginning to spread across the sky.

Shock and awe was the order of the afternoon. The French AF Mirage 2000C was stunning, a Chinook followed by a Royal Navy Merlin both did things helicopters just should not be able to do and a second Typhoon accompanied a Spitfire before blasting around the heavens in a superlative demonstration of the meaning of agile. The Spanish CASA 101 display team put on a good show but by then everyone was waiting for the main event.

Almost perfectly on cue, the sun started to shine down from an uninterrupted sky. Vulcan departed in age old style by giving it a huge amount of beans to climb steeply and deafeningly. She lurked in the background as a Lancaster, Spitfire and Hurricane put on a great show. Vulcan then slotted in behind the Lancaster and pursued it on a circuit of the airfield - a scary sight to have in your mirrors! A quick flash over her open bomb-bay doors preceded her signature gear-down go-slow along the display line before once again finding the on switch to lurch skywards in immense fashion. On landing she also managed her usual party trick of decelerating with her nose wheel high off the ground until she was at taxiing speed. Just before shut-down the pilot ran up the engines to 80% with the brakes hard on to give us one last treat and shake. To be honest, it was all a bit too safe and short but I suppose they're wanting to be ultra careful with the old girl, so new from her rebirth.

Many started their journey home once Vulcan was safely down but that was a mistake. They missed a "tactical scenario" enacted by a Chinook, an Apache, an AWACS E-3 Sentry and four utterly terrifying Tornados as they dropped smoke bombs and generally caused sensory mayhem. A Lynx helicopter display followed and to finish, the first Typhoon returned from its other engagement and took advantage of the now clear skies to rampage around without limits.

Amazingly, most of the 1127 photos (3.26GB!) from my DSLR are in focus, reasonably well exposed and actually have a decently sized subject. Admittedly there are a few duplicates in there but I reckon I'll have about 800 keeps. With the snaps from the compacts we had with us, I fear a storage review is going to have to be on the cards.

All in all, a brilliant boys day out. I wonder if I could get away with returning for day two tomorrow...

Thursday 3 July 2008

Lead us not into temptation

Here's an interesting method of protecting people's personal data. In the Eye Clinic at my local NHS Infirmary I saw a notice, pictured to the right, in a waiting area outside the consultants' rooms. It reads "ATTENTION Please refrain from looking at these notes as they are STRICTLY confidential". Whilst it's true many of the people sitting opposite this invitation appeared to have very little vision at all, other bored hangers-on and passers-by could not but help take a glance at the intriguing pile of documents.

It may be that the damage from recent spate of Civil Servants leaving secret Government papers on trains and in taxis could have been mitigated by similar highly visible notices. Sadly, I think not. I'll continue trying to keep all my secrets far away from prying eyes as I fear there may be far too many people sharing Mark Twain's view; "I deal with temptation by yielding to it".

Wednesday 2 July 2008

VMware VirtualCenter 2.5 installation foibles

Earlier this week I was helping a customer update their VMware ESX environment to v3.5 build 82663 (from v3.0) and the associated VirtualCenter management server to v2.5 build 84782 (from v2.0), after they ran into problems trying to do the work themselves.

Following the successful installation of the "Infrastructure Client" and "VirtualCenter Server" packages, both the "Update Manager" and the "Converter Enterprise for VirtualCenter" plugin packages failed to complete, instead giving errors 25089 and 25086 respectively - "Error 2508x: Unable to logon to VirtualCenter". Knowing the that username and password supplied were correct, I started digging around the log files but there was nothing of interest to be had.

The customer's password was a complex one and happened to include a ";" (semi-colon) character. As the installation process connected to VirtualCenter over the SSL based (broswer) interface, and having prescious little else to go on, I wondered whether this might be the trouble. Sure enough, setting the password to a simple alphanumeric-only string solved the problem and setting the password back to its original form after in the install left everything as it should. I imagine this may prove a good deal trickier in some environments where a minimum password complexity standard is enforced, as I suspect more the just the semi-colon character may cause the same symptoms.

Final testing revealed one more problem. We couldn't manage to get to any of the virtual machine consoles. Network sniffing revealed the VI Client was making a connection to the ESX host on TCP:902 successfully but then trying also to connect on TCP:903 and this was failing. Examining the ESX host itself confirmed it wasn't even listening on TCP:903. This post on the VMware forums provided the answer and adding "vmauthd.server.alwaysProxy=TRUE" to "/etc/vmware/config" restored full service (VI Client now only uses TCP:902).