DLink 320T, the reason it is unreliable

Bought one of these thinking it was a good replacement for my 5 year old adsl modem. The main feature is that its a adsl to ethernet bridge, there is no NAT (well, there is but it can be turned off), and no need for port forwarding. You can only connect one machine to its ethernet port, but that machine has the real internet IP address. After I'd bought it however, a quick search showed a lot of people having problems with it, claiming it was flaky with p2p. I saw the same problem, seemed fine for a few days, then it wasn't fine at all - the machine connected to it would claim it was out of memory while doing simple network related operations and other similar very unusual network related errors.

The first problem is the DHCP response of the modem given to the connected computer. The modems response says the default route is the ethernet interface connected to the computer. Reasonable? No, the computer thinks every machine it ever talks to on the internet is locally connected, and so it should be finding that machine's mac address. The out of memory errors come from the mac address look up table (ARP cache, or neighbour cache) running out of free space. It also means your machine is continously asking your modem (and possibly machines on the internet) what their mac address is, as the cache needs to be kept up to date. The arp cache should have a handful of entries (ie. one entry for each machine in your house that was recently contacted).

So what to do about it? Have found a solution, which is to configure the interface with dhcp, and then add these rules (eth1 is my external (internet) network card):
route add -net netmask eth1
route add default gw
route del default gw <my external IP>

The last line deletes any default route that says your external IP address (your internet address) is the default gateway, it is this route that will make your machine think all internet computers are locally connected and mac cachable. Don't know your external IP? Use this script instead of the last line above:
netstat -nr | grep ^0 | awk -- '{printf "route del default %s\n",$2;}' | grep -v 192.168 | bash

The full script looks like this.

This will allow the modem to work for a few days, but will eventually stop passing packets. Suspect it is because the dhcp timeout is nothing like the actual timeout, so the lease expires and nothing is done about it. All the network stats say the same as before, but it doesn't pass packets (even to the modem) until dhcp is manually restarted, and the above rules readded.

Fortunately, running dhclient every day stops this problem from showing up. It does however need scripts to do all this in an automated way. Running dhclient with an early expire time might work, but chances are it will then add the broken routes to your routing table, so you will need to get dhclient to run the above commands on each dhcp renewal. I opted to cron the commands rather than use dhcp expire times. From a single script (link above), I run dhclient, kill the old dhclient, and run the above route commands. This works for me beacuse my ISP uses static IP addresses by default. Dynamic IPs are more difficult because you don't know when your IP changes, the client side dhcp always asks for an address, there is no mechanism for the server side to tell the client without the client asking first.

To get around this problem, you could ask the modem its IP every minute, and run the above dhclient and route commands if it changes. You could also run dhclient every minute regardless, probably without serious side effects.

The next problem is the connection tracking parameters. If you see tcp connections timing out after a few days of P2P use, it is because the tcp parameters for connection tracking use a time out of days instead of minutes, filling the modems connection tracking table and making it drop random connections. Even seeing this problem is itself an error, as this is supposed to be a bridging modem. For some reason, the modem contains a NATing rule which NATs all outgoing connections. This rule can be safely removed.

You need to run these commands in the modem to set the parameters to something more reasonable. The iptables line removes the unnecessary NAT:
echo 4096 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 1200 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
iptables -t nat -D POSTROUTING -j MASQUERADE -o ! br0
To automate this, the corresponding Expect script is:
/usr/bin/expect << EOF
proc expectprompt { txt } {
expect {
\$txt {}
timeout exit;
eof exit;

set timeout 60

spawn telnet

expectprompt "login:"
send "admin\r"

expectprompt "Password:"
send "admin\r"

expectprompt "#"
send "echo 4096 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max\r"

expectprompt "#"
send "echo 1200 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established\r"

expectprompt "#"
send "echo 120 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait\r"

expectprompt "#"
send "iptables -t nat -D POSTROUTING -j MASQUERADE -o ! br0\r"

expectprompt "#"
send "exit\r"


Remember to chmod u+x this script to make it executable.

Fixing the modems problems directly involve changing the firmware and/or filesystem. These can be extracted using the webserver approach (described by other people), or using the built in tftp command, of the form:
cd /dev/mtdblock/
tftp -p -l 0 # get squashfs filesystem
tftp -p -l 1 # get kernel?
tftp -p -l 2 # no idea, spare?
tftp -p -l 3 # no idea, spare?
tftp -p -l 4 # get kernel?
and on the server side:
ip addr add dev eth1 # Add another IP to the NIC connected to the modem
touch /tftpboot/{0,1,2,3,4}
chmod a+w /tftpboot/{0,1,2,3,4}

I've not done this yet, as I've yet to find why the dhcp response is wrong. Killing the running udhcpd server and starting another, the server refuses to follow the configuration file (which tells it hand out 192.168.1.x addresses), and instead resorts to the external IP, with the wrong gateway. If I could find why, a solution to the other problems could be hacked into the filesystem.

Update - dynamic IP monitoring scripts

Have written scripts that run on the modem and the connected Linux machine, monitoring and changing the external IP address if pppd dies. These scripts also do all the above (re)configuration of the modem and remove NAT. Having written the scripts, they could be written differently and be far less complicated - the PC could just keep asking about the status of modems pppd rather than a modem side script checking and then telling the PC via tftp.

Have yet to write the simplified version, as the over-engineered version works ok. The current script is here, and requires a Linux PC, expect, a tftp server (I used tftpd-hpa) and ip command (from the iproute2 package).


There is updated firmware available from the German DLink web site (but not the UK DLink web site). It was released toward the end of 2006, around 10 months later than the standard firmware. However, it doesn't fix any of the problems mentioned above. It adds remoted access options (ie. internet side) for www, telnet and ssh. At least, that is what the frontend says, in the modem I can find no trace of an ssh daemon.


Written by Greg: greg at csc liv ac uk. Would welcome any comments.