OpenWRT WDS between legacy WRT54G and recent TP-Link devices

Mar 30 2014 Published by under howto

For a while now I had a multiple wifi routers all providing access points, and a connection to each other, using a feature called WDS. All of the routers run OpenWRT. Recently one of them died and everything kind of stopped working properly. I actually had the following configuration:

TP-LINK <--wired,bridged--> ASUS WL500G <--wireless,WDS,bridged--> Linksys WRT54G

Now this all worked because the conventional wisdom appears to be that WDS works when the device at each end is the same, i.e. Broadcom to Broadcom (which I had in the case of WL500G and WRT54G) and is problematic at best otherwise.

Documentation alluding to this includes:

So with the WL500G out of the picture, the TP-Link and WRT54G were no longer able to see each other, and I experienced a loss of connectivity from my workshop where the WRT54G was physically located.

However if you look under the covers a bit, it seems this configuration can be made to work, as suggested by the folk over at DD-WRT.

So with a bit of tweaking I was able to get WDS working between the TP-LINK and WRT54G as follows.

TP-LINK Router (WR1043ND, OpenWRT 10.03 Backfire)

Content of /etc/config/wireless:

WRT54G Router (WRT54G, OpenWRT 10.03 with legacy 2.4 kernel for broadcom wireless)

Content of /etc/config/wireless:


  • xx:xx:xx:xx:xx:xx is the MAC address of the WR1043ND, and yy:yy:yy:yy:yy:yy the MAC address of the WRT54G
  • Both devices have to be on the same channel
  • On the secondary router (WRT54G) you actually connect on the ssid LOCALSSID but all DHCP, etc. comes from the TP-LINK

Note also you need to ensure that DHCP on the LAN is disabled on the second router!

I am unsure why this configuration has apparently been problematic for some – perhaps it is quite router specific as to whether it works.

No responses yet

How to Enable / Disable remote X connections in Debian Squeeze

Jan 19 2012 Published by under howto, linux


Using my AspireOne at LCA2012 I realised I had a hole that really needed to be tightened before using the Most Excellent LCA2012 wireless network instead of a 3G dongle.

One of these is that I was gaining an ipv6 address on the LCA network. (This was not the hole.) My 3G only has ipv4 and at I only run ipv4 at home.

After connecting I had both ipv6 and ipv4 addresses, but importantly upon running netstat -antp realised I had kdm [1] listening on 6000 wide open – I had it firewalled out on ipv4 but had never setup ip6tables (oops)

To sort things quickly I subsequently disabled ipv6 [2] but I first killed off my local X/server from accepting connections anyway (you cant be too cautious, in a large crowd of very skilled people, potentially prank-minded, right? following good advice – ‘take precautions’ …)

me@xxxxxxx:~$ sudo netstat -lntp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0  *               LISTEN      13494/X         
tcp6       0      0 :::6000                 :::*                    LISTEN      13494/X  


To disable network connections on port 6000 using kdm:

  1. Edit /etc/kde4/kdm/kdmrc
  2. Look for a section [X-:*-Core]
  3. If missing or commented out, add the line ServerArgsLocal=-nolisten tcp, if it is already there, instead append -nolisten tcp to the line starting with ServerArgsLocal
  4. Either reboot, or kill X and restart kdm


me@xxxxxxx:~$ sudo netstat -lntp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

To _enable_ connections, simply ensure the -nolisten tcp arguments are not present.

FWIW I have had to do this on gdm in the past as well.
Instructions for this are actually provided in the Debian Reference Manual, Chapter 7 (section 7.4.2, tips)

YMMV if you have more than a basic configuration or are running some other variant or distribution.

[1] I only use kdm for login, for performance I run openbox
[2] Yes, I know, I should use ipv6, I even agree with all the reasons listed by Julien Goodwin at his excellent SysAdmin miniconf talk on why I should use ipv6, but that will need to wait until I get home (and depends on my ISP.)
(And facepalm to self for mixing up selinux with ipv6 before coffee this morning)

No responses yet