Draytek modems

The Draytek Vigor series of dsl modems are starting to become available here in NZ, which is of interest of those running Linux router boxes due to the pppoa to pppoe translation these products offer. The Vigor 120 will be in stores this month, but the 2700 and 2800 series are already around if pricey. My experience so far is that they are good products.

 

Here we describe how to set these up with an Etch gateway box.

 

Before you bork your existing net connection, get the packages:

 

 

Modem config

First configure the modem into pppoe pass though mode, if it isnt already. This is real simple. Login to it at default 192.168.1.1, using a dhcp or same subnet static connection. Default login is blank blank.

Under internet access, enter the pppoa vci vpi and vcmux, tick pppoe pass through (for wired lan). That, folks is the extent of it. I found that initially i was able to still log in to the web interface on its ip, but later couldn`t. Not sure why. You dont need to anyhow. Proceed to setup your router box for pppoe.

 

Router config

The files and tools youll need are:

 

Before you do anything though, read on. Running pppoeconf is straightforward until you reach the question about mss clamping.

 

 

First a brief mss primer. Max segment size is basically the payload that the packet is capable of carrying after the tcp headers have been used. In an ideal world computers negotiate the mss for their conversation based on the smallest mss of the two ends, using a process called pmtu discovery. Generally with a standard ethernet mtu of 1500, you would be running a mss of around 1460 bytes. Add pppoe on one end to this mix, however, and you lose 8 bytes needed for its own header. That reduces the effective max mss to 1452. However that isnt the end of it. On occasions tcp headers can grow beyond the usual 40 bytes, and one such likely occurrence is under NAT masqerading. And it gets worse. Evidently the occasional webserver around the world over zealously filters ICMP to the point where correct mss negotiation is prevented. Hotmail is an example. Hence the warning about trying lower figures. (As a guide Windows XP PPPoE adopts an mss of 1440. This gives it a bunch of bytes to spare, without depending on pmtu).

 

So coming back to practice:   If you answer yes, contrary to the documentation pppoeconf makes no changes to the lines in dsl-provider that refer to mss, and altering them yourself has no effect because they relate to user mode pppoe. Instead it will insert a single firewall rule into your netfilter system like so:

 

 

Things to realise about this:

1. Its inserted without telling you about it.

2. Its reinserted every time you pon dsl-provider -- therefore you will end up with several of them if you fiddle with your connection. Not what you want.

3. It doesn`t always work!

 

For reasons 1 and 2, i recommend answering no. Instead add the rule yourself into your firewall script that runs at boot time. (Edit: even if you select No it still installs the rule! Just delete 0clampmss.)

 

Now as for the issues with it: The problem and symptoms are outlined here and Jan Seiffert kindly suggested a fix.

 

 

Basically sometimes something somewhere shields the connection from correct mss/pmtu negotiation. So manually specifying the mss clamp manually solves the problem. It transpires that one key cause of this is the users own software firewalls (ICMP3).

 

But the dilemma here is whether or not to clamp mss to a fixed size or to rely on the correct functioning of pmtu. This is complex and im on the edge of my knowledge, so ill just tell you what works. Either:

• clamp to a fixed size that you know none of your users will have issues with (the XP method)
• rely on clamp to PMTU, and warn users, about issues with personal firewalls and certain webservers.
• change the MTU of all your LAN users to 1492 bytes.

 

Other config tweaks

1. Beware that pppoeconf doesnt remove your old eth1 settings. So in order for pppoe to work correctly you will need at a minimum to remove any static gateway you have in /etc/network/interfaces. The docs say that the eth interface should be up but not configured. I found in practice you can leave a static IP set and it still works. But you can read more about this at here

 

2. With pppoe set to persist, it seems very robust. Any net disruptions are recovered from gracefully and the overall connection is stable as a rock. But make sure your etc/ppp/peers/dsl-provider has these:

 

 

Even with persist, if your isp craps out for an extended period, with the default install, ppp will stop trying to redial after 10 minutes, and exit. Ironically this was seen as a bug and supposedly fixed here. The default maxfail is 10, setting it to 0 means infinite.

 

3. If you are using dnsmasq to provide caching dns proxy for your LAN you need to answer no to the use peer dns question, and check that the script /etc/ppp/if-up.d/0000userpeerdns is disabled. The point of dnsmasq is that both the server and its lan clients should all use dnsmasq for its lookups. So you dont want anyone messing with resolv.conf. The bullet proof solution is:

 

Notes

• More info about mss see: mss primer and mss initiative.
• If you are following the   whole series of howtos you will need to change the WAN definition in your firewall ruleset from eth1 to ppp0. Other than that it should just go. Make sure you have a icmp type 3 code 4 accept rule as that is used to send fragmentation issue communications, and adversely effects PMTU otherwise.
• mss clamping is not a pretty thing, and certainly doesnt enhance your throughput. Some sources   however claim a mss of 1414 is efficient as it evenly splits the pppoe packet into pppoa`s 48/53 byte frames.   Other sources have looked at optimising an Ethernet or pppoe packet through a dsl link. All interesting stuff, that i am sure Cisco knows and has implemented in its high end gear, but which we have to figure out for ourselves.
• If you mess with mss you can look at optimising clients RWINs to be a multiple of mss.   See [http://www.speedguide.net/analyzer.php]
• See also debian pppoe bug report

www.webspaces.net.nz/page.php?view=draytek-modems 2011-08-02