As regular readers know, I recently turned up a new DSL circuit at home, replacing an older, slower line that Verizon had refused to upgrade for months. As part of the upgrade process, I needed to buy a new DSL modem. Instead of using an external DSL modem (DSL-Ethernet bridge would probably be more accurate, but “modem” seems to have stuck), I decided to buy a Sangoma S518 PCI ADSL modem. I had two main reasons for preferring this internal modem to a generic external model:

1. Better control over upstream buffering, for better VoIP QoS.
2. Better visibility into the modem’s state, so I can syslog minor outages and notice things like speed changes.

I chose the Sangoma model instead of a cheap, generic card because the manufacturer strongly supports its use with Linux, and a number of people on the Asterisk-Users mailing list have recommended it. I paid $115 plus shipping from BSD Mall.

Packaging and physical installation

The card arrived via UPS about a week after I ordered it from BSD Mall. Historically, Sangoma has mostly made cards for T1s and leased lines; the S518 is their lowest-end product, but it uses the same configuration tools and drivers as their more expensive cards. Since this is Sangoma’s only product line, and Linux is a big part of their market (and has been for over 10 years), the drivers are much more mature and stable then you’d really expect for a DSL card.

The packaging for the card is fairly generic–it looks like Sangoma uses the same box for all of their products. Inside, there was a RJ11 cord, the PCI card, wrapped in an anti-static bag and bubble-wrap, a manual, and a CD with drivers.

Drivers

I downloaded their most recent drivers from their web site a few days before the card arrived and pre-installed them, so I’d be ready to install the card as soon as it arrived. After untarring the drivers, all you have to do to install them is run ./Setup install and their setup script takes care of everything else. Rather impressively, it located the source for the 2.6 kernel that I’m running, patched it (after asking my permission), built new kernel modules for everything needed, installed them, and then compiled and installed the user tools for configuring their interfaces. It also installed a startup script into /etc/init.d/wanrouter and created all of the right links in /etc/rc*.d to make sure that it starts on boot. The fact that it all worked correctly on my Debian unstable system was rather impressive, and a sign that Sangoma’s been doing this for a while.

Configuration

Configuring the card was also relatively easy. The setup program installed a tool called wancfg that provides a curses-based UI for setting up their network interface cards. It took me a couple minutes to tell it that I was about to install a S518, guess which ADSL encapsulation I’d need, and tell it to assign the new interface the name dsl0 and a dummy IP address.

Initial Use

Once the drivers were installed and configured, I shut the system down, installed the card in a spare PCI slot, and rebooted. The system came back up, loaded the S518 drivers successfully, set up the ADSL interface using the specs that I’d provided, and started training. After about 30 seconds, it told me that training had failed, and it couldn’t find a signal on the line. Since the line wasn’t supposed to be live for two more days, this didn’t seem like a problem. I left the interface installed in the box, perpetually attempting to re-train, and went to bed.

The problem

At 8:19 the next morning, Verizon finished configuring their end of the DSL line. The S518 immediately trained on the line, syslogging:

Feb  9 08:19:22 guam kernel: wanpipe1: ADSL Link connected (Down 1792 kbps, Up 448 kbps)
Feb  9 08:19:30 guam kernel: wanpipe1: Link connected!

About two seconds after logging the last line, the system locked up. I rebooted the box, only to discover that the system could no longer see the S518 card. Even lspci failed to detect anything–the card was locked up so hard that PCI bus probing no longer worked. I had to power the system down before I could access the card. I tried rolling the driver back to the previous stable version, without any luck, and rolled it forward to a newer beta, but that didn’t work, either. Everything was stable until it trained, so I unplugged the DSL line from the S518 and left for work.

During the day, I contacted Sangoma’s tech support department and asked what was wrong. Then emailed me back within 15 minutes and asked a few questions – “is this a 64-bit system in 64-bit mode?” for example. They suggested several things that I’d already tried–rolling forward or back to new releases. They looked through my lcpci output and noticed the Digium cards that I use with Asterisk and suggested removing them, just for testing. Their support engineer admitted he was grasping at straws–they had the same card with the same drivers and kernel working in the labs. They suggested re-compiling the driver, targeting it for a generic 386 kernel, instead of the Athlon-optimized version that built by default.

That night, I tried the re-compiled drivers: no luck. I pulled both Digium cards: no luck. It still crashed immediately after training.

Finally, I moved the S518 to a new PCI slot, and discovered that that worked perfectly. So, either the S518 driver had a hard time sharing an IRQ with my Ethernet card, or I have a bad PCI slot in my system. Since it’s a cheap motherboard, and it’s almost 5 years old, I’m going to go with ‘bad slot’. I re-installed the Digium cards, cleaned everything up, and it all continued working perfectly.

I was very pleased with Sangoma’s support–they seemed competent, they responded quickly to my request for help, they asked sensible questions, made decent suggestions, and didn’t disappear once they ran out of easy fixes. Frankly, this is why I paid more then I had to for their card–good support. In the future, when people come to me for recommendations on T1 or ADSL cards, I’m going to recommend Sangoma without any reservations at all.

ADSL and IP configuration

By this point, Verizon had emailed me my new static IP address, so I configured dsl0 for the right IP and tried pinging my gateway. No luck–I couldn’t ARP the gateway, so ping wasn’t working. I fired up tcpdump, and saw that there was traffic on the link, but it didn’t look right–the source MAC address was 00:00:00:ff:ff:ff and the Ethernet frame type was ffff. So, most likely, the DSL framing option that I’d picked when I’d configured the link was wrong. I fired wancfg back up and looked over my options:

• Bridged Eth LLC over ATM (PPPoE)
• Bridged Eth VC over ATM
• Classical IP LLC over ATM
• PPP (LLC) over ATM
• PPP (VC) over ATM (PPPoA)

I was pretty sure that I was being fed bridged Ethernet, although Verizon hadn’t actually told me what they were using, so I’d picked ‘Bridged Eth VC over ATM’. I looked at the configuration screen for a minute, deciding which one to try next, when I noticed the next line down: ATM_AUTOCFG-> NO. I set that to yes, ran /etc/init.d/wanrouter restart, and watched syslog. Within 30 seconds, it reported that the link was up, that there was traffic on VCI 35, VPI 0 (which was the default in wancfg), but that it wasn’t framed right. The kernel driver said that it was expecting Bridged Eth VC over ATM, but it was seeing Bridged Eth LLC instead. So I ran wancfg, turned off autoconfig, and changed the encapsulation to ‘Bridged Eth LLC over ATM (PPPoE)’, saved, and re-ran /etc/init.d/wanrouter restart. As soon as it came back up, I was able to ping the gateway; everything was working. For what it’s worth, the PPPoE in the encapsulation name is a complete misnomer in this case–there’s no PPP involved anywhere in this system.

If I’d spent a bit of time with Google, I probably wouldn’t have had to fiddle with encapsulation settings, but it was nice to see that it could auto-detect it for me.

Once I was confident that the link was up, I changed IP addresses in DNS, edited my system startup scripts to use the new IP address and device dsl0 instead of eth1 and rebooted. I noticed that the Sangoma /etc/init.d/wanrouter was set to run at step 20 in /etc/rc3.d, while my IP configuration script ran way earlier, and this was causing problems, because DNS was failing for some system services, like NTP and Apache, because the WAN link wasn’t up before they started. So I deleted the calls to start wanrouter out of /etc/rc*.d, and then called it by hand right before configuring my IP addresses and firewall. One more quick reboot, and everything seems to be working fine. I was able to download a kernel image over the DSL line at nearly 150 KB/sec, which was around twice as fast as before.

QoS

My main reason for ditching my old DSL line and modem and installing a new DSL line with the S518 was lower latency and jitter for VoIP. With normal external Ethernet-to-DSL modems, the modem had a buffer that it uses to hold outgoing packets. If you’ve every tried uploading a large file over DSL, only to discover that it takes 5 or 6 seconds to ping packets to cross the link, you’ve discovered the joys of big buffers in DSL modems. While a 5 second delay is bad for SSH, it’s horrible for VoIP.

The usual way around this is to install a rate limiter on your router’s outbound Ethernet interface, like Wondershaper on Linux. This works by limiting how fast your router’s Ethernet interface can transmit data. If you slow the router down so it’s just a bit slower then the DSL line, then the router can prioritize packets and let VoIP packets go to the head of the line, without letting the DSL modem receive enough traffic to fill up its buffers. This works, but it’s always a spotty thing–for best results, you need to set Wondershaper to be a bit slower then your DSL line, so you lose some performance there. In addition, Wondershaper’s default settings don’t really pay full attention to the ToS headers on IP packets, so you have to spend some time tweaking its idea of high-priority and low-priority traffic. In addition, it’s really hard to make changes–Linux’s QoS tools are powerful, but they’re complex and hard to understand.

The first thing that I did when I brought the S518 up was to turn off Wondershaper completely and see how well the kernel’s default QoS scheme (pfifo_fast) worked. By default, Linux prioritizes packets based on the ToS field on the IP header, and most tools actually seem to set the header to reasonable values. Or, at least Asterisk and BitTorrent both use reasonable settings. Since the S518 doesn’t have a buffer built into it, the kernel’s native queueing works perfectly, and I’m seeing nearly perfect Asterisk VoIP performance, even without a complex set of shaping tools.

Since this was my primary goal when I bought the S518, I’m quite pleased with the card.

Conclusion

I’d strongly recommend this card to anyone with a need for decent QoS over ADSL, as long as they have the technical skills needed to get it to work. As mentioned, the drivers did a good job of installing themselves, and Sangoma’s tech support is good, but it still took some understanding to get the system working correctly. Sangoma supports most of the *BSDs as well as Linux and Windows, so the only people left out in the cold are the ones trying to use OS X as a router.

In addition, based on what I’ve seen of Sangoma’s drivers and toolset, as well as their tech support, I’d recommend that people in the market for 1-4 channel T1 cards for data or voice check their offerings out as well. Sangoma supports Asterisk directly on their T1 cards, and while they’re slightly more expensive then Digium’s cards, they probably come with better support. Given what I’ve seen of their tools, setting up data T1s with Sangoma’s drivers looks like child’s play.

If Sangoma’s looking for suggestions, I’d love to see a model of the S518 that can act as a FXO card with Asterisk while still acting as a ADSL card. One card could handle voice and DSL at the same time. The market for this isn’t huge today, but it’s a relatively simple change that could have huge benefits as Asterisk grows.