I’ve recently had the displeasure of having to update the copy of WANPIPE that we ship with our product at work from the old stable 2.2 family to the beta 3.3 family in order to support their new Synchronous Serial adapter (The A14x family which is replacing the old S514x family). We use these cards to support Frame Relay communications. Frame Relay is still reasonably popular in Australia for private point to point communications, and, to be frank, our product with a supported Sangoma card and annual support probably still costs substantially less than the cheapest Cisco with 100mbit ethernet + sync serial for frame relay support and equivalent support.
So far I’m not impressed with the A142 kit or drivers.
The kit itself is pretty shoddy. Whilst the card is a nice small dual-layer card which will fit into a low-profile PCI slot (and even comes with the half-height edge-bracket), the cabling that comes with it is atrocious. The card has a mini-centronics connector with screw-terminals which the Y cable attaches to (A142 is a two port card, and is the smallest they offer now) and that itself is OK. The dodgy comes in with the V.35 cable kit which attaches a V.35 to DB25 cable to the DB25-Y cable that you screw into the card. The main problem being that both the DB25M on the V.35 cable and the DB25F on the Y cable have screw terminals – so you can’t secure the two to each other making it the weakest (and usually highest-tension because the Y cable is short and usually dangles off the back of the system) join in your V.35 cable run.
And then there were the drivers… After spending a while chasing my own tail because my old 2.4.30 build tree had been damaged (but was still churning out valid modules, just without valid ksyms), I finally was able to get a build of the 3.3 modules that worked.
Then I had to slave out and accommodate the new user-space tools, changed configuration file layout for wanconfig (the WANPIPE stack configuration tool), all to discover that they’ve managed to break DLCI state indication in two places: First of all, you used to be able to check IFF_RUNNING to find out if the DLCI was active or not, not anymore. Secondly, the LIP layer (Sangoma’s own WAN stack) reports via dmesg transitions in card and DLCI state. I did my usual FRAD power-down test to make sure it was even tracing DLCI failure correctly, and LIP didn’t even notice the DLCI had gone silent/failed until I turned the FRAD back on and it was in it’s resynchronising state.
At least I got an email back from Sangoma technical support confirming that they had indeed broken the support unintentionally, and it’ll be fixed next release. Shame they didn’t mention when that would be.