I have 2 WRT54GS-DE Version 1.1 and installed the latest experimental OpenWRT on both of them. I want them to bridge the local wired attached LAN's over the WLAN connection - and thought, WDS would be the easyest. No WLAN clients are involved so far - to throughput shouldn't be a problem.

I have set 1 box to wl0_lazywds=1 - and the other one to wl0_wds=XX:XX:XX:XX:XX:XX - rebooted both, but nothing happens - no additional devices or anything.

Here is the nvram config of the first box:

root@OpenWrt:~# nvram show
os_ram_addr=80001000
wl0_net_mode=mixed
wl0_frameburst=off
il0macaddr=00:13:10:15:23:d2
boardrev=0x10
et0macaddr=00:13:10:15:23:D0
bootnv_ver=2
watchdog=5000
boot_wait=on
wl0_infra=1
et0mdcport=0
wl0_country_code=DE
pmon_ver=CFE 3.61.13.0
lan_gateway=
wl0_ifname=eth1
vlan0ports=1 2 3 4 5*
gpio5=robo_reset
wl0_mode=ap
wl0_ap_isolate=0
os_flash_addr=bfc40000
sromrev=2
wl0_gmode=1
boardtype=0x0708
lan_netmask=255.255.0.0
wl0_ssid=OpenWrt
wl0_dtim=1
wl0id=0x4320
wl0_key1=
wl0_key2=
wl0_key3=
wl0_key4=
ag0=255
wl0_closed=0
wl0_rate=0
wl0_plcphdr=long
wl0_macmode=disabled
wl0_radioids=BCM2050
wl0gpio2=0
wl0_phytype=g
wl0gpio3=0
wl0_lazywds=1
boardflags2=0
wl0_afterburner=auto
wl0_antdiv=-1
wl0_wpa_psk=
wan_proto=none
wl0_unit=0
wl_country_code=AU
pa0itssit=62
wl0_wds=
cctl=0
lan_ifnames=vlan0 eth1
lan_dns=
wl0_auth=0
wl0_radius_port=1812
wl0_radius_ipaddr=
pa0maxpwr=0x4e
lan_ipaddr=172.23.129.11
clkfreq=200
lan_proto=static
aa0=3
vlan1hwname=et0
wl0_phytypes=g
wl0_wep=disabled
wl0_frag=2346
sdram_config=0x0062
wl0_country=
vlan1ports=0 5
eou_private_key=1b1863b45a926af91f02ee3da2f081f746df5485bf68e1d6c2b6a7203f7b1108befd45da74b4653799ab42a88edbb0bea0562d6599efc38cbadf64438761abe78436331da4d3acd4594e6ea6a51a912ccc266105551aab388bb09ec433940fa6880119f35ba66254277b74f68532cf298c87dd51a721a6fd0a2a3d1f8aa9f431
scratch=a0180000
ccode=0
wl0_rateset=default
eou_device_id=V59X4V5R
lan_ifname=br0
boardflags=0x0318
sdram_refresh=0x0000
sdram_ncdl=0xfdfe09
wl0_rts=2347
wl0_wpa_gtk_rekey=3600
wl0_key=1
et0phyaddr=30
wl0_radio=1
wl0_bcn=100
wl0_hwaddr=00:13:10:15:23:D2
pa0b0=0x15eb
wl0_gmode_protection=auto
pa0b1=0xfa82
wl0_maclist=
pa0b2=0xfe66
sdram_init=0x000b
vlan0hwname=et0
dl_ram_addr=a0001000
wl0_radius_key=
wl0_corerev=7
wl0_channel=11
wl0_auth_mode=open
boot_ver=v3.4
boardnum=42
wl0_crypto=tkip
eou_public_key=998a34fe013db383afbb4607f0a835ce919c344b3ca7aa6ba4b5b30c12640b318f9b3680955392e5bc1fcf107edce98d8c93013fbda3fec822f1e2d3ff2978cc247abf9c52d010e4657e9f800450562097cfcda10f95ea6a3132dadd00f3f70c4399d8b1b88c0ad19340d4f3489bca716072c00c3220533cb92ab5761247bc8711

And here the nvram of the second one:

root@OpenWrt:~# nvram show
os_ram_addr=80001000
wl0_net_mode=mixed
wl0_frameburst=off
il0macaddr=00:13:10:15:23:cf
boardrev=0x10
et0macaddr=00:13:10:15:23:CD
bootnv_ver=2
watchdog=5000
boot_wait=on
wl0_infra=1
et0mdcport=0
wl0_country_code=DE
pmon_ver=CFE 3.61.13.0
lan_gateway=
wl0_ifname=eth1
vlan0ports=1 2 3 4 5*
gpio5=robo_reset
wl0_mode=ap
wl0_ap_isolate=0
os_flash_addr=bfc40000
sromrev=2
wl0_gmode=1
boardtype=0x0708
lan_netmask=255.255.0.0
wl0_ssid=OpenWrt
wl0_dtim=1
wl0id=0x4320
wl0_key1=
wl0_key2=
wl0_key3=
wl0_key4=
ag0=255
wl0_closed=0
wl0_rate=0
wl0_plcphdr=long
wl0_macmode=disabled
wl0_radioids=BCM2050
wl0gpio2=0
wl0_phytype=g
wl0gpio3=0
wl0_lazywds=0
boardflags2=0
wl0_afterburner=auto
wl0_antdiv=-1
wl0_wpa_psk=
wan_proto=none
wl0_unit=0
wl_country_code=AU
pa0itssit=62
wl0_wds=00:13:10:15:23:D2
cctl=0
lan_ifnames=vlan0 eth1
lan_dns=
wl0_auth=0
wl0_radius_port=1812
wl0_radius_ipaddr=
pa0maxpwr=0x4e
lan_ipaddr=172.23.129.22
clkfreq=200
lan_proto=static
aa0=3
vlan1hwname=et0
wl0_phytypes=g
wl0_wep=disabled
wl0_frag=2346
sdram_config=0x0062
wl0_country=
vlan1ports=0 5
eou_private_key=14981b6e4f9478f3a32425efed446e636e91c82a4b109e0c7d6dd90b17b96bec92e19cb29dbc2635dc85852cd9396e0e4c193aed415828fd7bbf09df78252888eedf93cba5abd0addd0b237d9565d1bfa6bcf2cf82b68740d8379331f815988e3d8fb29136a07b77d7354c3772a6eb5a466781a5f0e70156ef8496d44c29faf1
scratch=a0180000
ccode=0
wl0_rateset=default
eou_device_id=EB2ZJC5H
lan_ifname=br0
boardflags=0x0318
sdram_refresh=0x0000
sdram_ncdl=0xfd0008
wl0_rts=2347
wl0_wpa_gtk_rekey=3600
wl0_key=1
et0phyaddr=30
wl0_radio=1
wl0_bcn=100
wl0_hwaddr=00:13:10:15:23:CF
pa0b0=0x15eb
wl0_gmode_protection=auto
pa0b1=0xfa82
wl0_maclist=
pa0b2=0xfe66
sdram_init=0x000b
vlan0hwname=et0
dl_ram_addr=a0001000
wl0_radius_key=
wl0_corerev=7
wl0_channel=11
wl0_auth_mode=open
boot_ver=v3.4
boardnum=42
wl0_crypto=tkip
eou_public_key=af0ce929a46e0416eab3427760c5aa4d2bd725677e0d3f6a2a25b4de49a8155ae07db3ee3cbf44c9d26eebfd3668277986d674e0ab6d5c6a9bd7d3eb7d3bd88d96f456548c4dd8a1fa9b58837c523dcefa9258759ba9611d27ca7f86a6877e7744c42249fba1d52e317fa01f47b112f731a4f7cce3acaa549db7e3b5fd26cbcd11

I don't know, what I have done wrong - the ifconfig on both boxes looks like that:

1st box

root@OpenWrt:~# ifconfig
br0       Link encap:Ethernet  HWaddr 00:13:10:15:23:D0
          inet addr:172.23.129.11  Bcast:172.23.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17437 errors:0 dropped:0 overruns:0 frame:0
          TX packets:767 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1357560 (1.2 MiB)  TX bytes:63764 (62.2 KiB)

eth0      Link encap:Ethernet  HWaddr 00:13:10:15:23:D0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:19154 errors:0 dropped:0 overruns:0 frame:0
          TX packets:956 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1852708 (1.7 MiB)  TX bytes:179098 (174.9 KiB)
          Interrupt:5 Base address:0x2000

eth1      Link encap:Ethernet  HWaddr 00:13:10:15:23:D2
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:260
          TX packets:16901 errors:138 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1620312 (1.5 MiB)
          Interrupt:4 Base address:0x1000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vlan0     Link encap:Ethernet  HWaddr 00:13:10:15:23:D0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17557 errors:0 dropped:0 overruns:0 frame:0
          TX packets:767 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1434474 (1.3 MiB)  TX bytes:66832 (65.2 KiB)

vlan1     Link encap:Ethernet  HWaddr 00:13:10:15:23:D0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:189 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:112266 (109.6 KiB)

2nd box:

root@OpenWrt:~# ifconfig
br0       Link encap:Ethernet  HWaddr 00:13:10:15:23:CD
          inet addr:172.23.129.22  Bcast:172.23.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18349 errors:0 dropped:0 overruns:0 frame:0
          TX packets:389 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1426511 (1.3 MiB)  TX bytes:39872 (38.9 KiB)

eth0      Link encap:Ethernet  HWaddr 00:13:10:15:23:CD
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:20179 errors:0 dropped:0 overruns:0 frame:0
          TX packets:587 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1949073 (1.8 MiB)  TX bytes:159040 (155.3 KiB)
          Interrupt:5 Base address:0x2000

eth1      Link encap:Ethernet  HWaddr 00:13:10:15:23:CF
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:136
          TX packets:18080 errors:123 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:1735259 (1.6 MiB)
          Interrupt:4 Base address:0x1000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

vlan0     Link encap:Ethernet  HWaddr 00:13:10:15:23:CD
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18478 errors:0 dropped:0 overruns:0 frame:0
          TX packets:389 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1507605 (1.4 MiB)  TX bytes:41428 (40.4 KiB)

vlan1     Link encap:Ethernet  HWaddr 00:13:10:15:23:CD
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:117612 (114.8 KiB)

Can someone please tell me, what I'm missing?

TIA

Daniel

The afterburner/speedbooster causes problems with wds.

To disable it, change boardflags variable and reboot.

0x318 --> 0x118 (gs v1.1 or above)
0x388 --> 0x188 (gs v1.0)

Thanks mbm - after that, the wds0.2 if comes up, and I was able to ping from one WRT to the other - but that's it - no wired LAN bridging, no pinging from wired LAN to WRT on both sides.

Because of this, and because I have read, that WDS does not support WPA, I decided, to dump WDS, and set up an AP/Client (WET) bridge - re-configured the one WRT back to simple AP, and configured the other as an WET client ethernet bridge ... simple - and seems to work.

Right now, I have only one problem, but I think I will post this in a new thread, because it has nothing to do with WDS.

OK - after trying around with WET, and having some strange problems with traffic from one bridged wired network to the other - I switched back to WDS. And I was really surprised, that this time everything was fine.

I haven't set the "boardflags" - instead I have done:

nvram set wl0_afterburner=off
nvram set wl0_gmode=2
nvram set wl0_mode=ap
nvram set wl0_netmode=g-only
nvram set wl0_closed=1
nvram set wl0_wds=xx:xx:xx:xx:xx:xx
nvram set wl0_maclist=xx:xx:xx:xx:xx:xx
nvram set wl0_macmode=allow

(where xx:xx:xx:xx:xx:xx is the MAC address of the eth1 interface of the other AP)

After doing this, everything was fine after a reboot - and right now, i have several flood pings ($ ping -f aaa.aaa.aaa.aaa) and some really heavy traffic (infinite loop with wget of a 10 MB file across the bridge) - and no packets are lost so far. And I get about 2 MByte/s - parallel to the flood pings, and the broadcasts of our whole network (with about 80 PC's).

My only "problem" now is - while WDS does not support WPA - will this be secure enough for a wireless bridge across the street? I think WEP will be useless because it's too easy to crack. The distance is about 300m - 250 on our own "property", and about 50 crossing a street. We will use special directed antennas (AFAIK 30° Yagi) on both sides about 6m above the ground. So I think anyone in a Car on the street will be able to get into the network, once he knows, that it's there - or not?

TIA for some thoughts about that "problem" - maybe someone has a good idea.

Bye
Daniel

Actually wds can support wpa, just that we haven't fully investigated & documented it yet.

Install & configure nas. Create a symlink from nas to /usr/sbin/nas4not. Hotplug will now attempt to run nas4not to notify nas of each new wds connection.

i had the same concerns as you do, and just two AP's, and i went with WDS+WEP for a week.

then i finally had some time, disabled WDS, set up WPA in one and clientmode+wpa (with wpa_supplicant) on the other, and set up a static route on the ap, (like this: "route add -net 192.168.11.0 netmask 255.255.255.0 gw 192.168.12.2" 12.2 is client, 11.0 is the network on the client-side, 12.1 is the ap) and some iptables/DNAT port forwarding. (you might also need a static route pointing towards the AP on clientside, i didn't, as it's already on defaultroute)

Thanks, but this wouldn't work for me - we just try to replace/extend a wired 2 MBit/s ethernet bridge - and it would be too difficult, to switch from the bridge configuration to a routed network, because we use the same network address (192.168.1.0/24) on both sides of the bridge.

That sounds good - I will give it a try, as soon as a come to my office today. Any other "special configuration hints" for /etc/nas.conf? Do I have to configure one "node" as supplicant and the other as authenticator? I ask, because I allready tried to run nas manually from the command line on both nodes - and as soon, as I started nas, no packets were bridged anymore.

But on http://forum.chupa.nl/printthread.php?t=967 is mentioned, that you have to start nas as nas4not (or maybe nas4wds?) and it will then behave different. May I should say, that I use the binary nas from the package http://nthill.free.fr/openwrt/ipkg/stab … mipsel.ipk - I hope this is the right one?

So thank you - at least I know, that it is possible - and all I have to do, is try.

Bye
Daniel

Hm, are you sure that for GS 1.1 it's correct to set 0x188? I have set it, rebooted and since that time I'm unable to access the WRT. I am running latest experimental (jffs2, 2005-04-23), default configuration - no manual changes made. Network configuration is quite normal with exception of removed br0 interface - eth1 (wifi, static IP), vlan1 (WAN, DHCP), vlan0 (LAN, static IP). I have tried to erase NVRAM (holding RESET while powering WRT up) but it did not help. Any idea how to bring it back to life?

If mbm is not sure - I am. I have done it with 2 GSv1.1, and both came back to life without a problem.

But afterburner was still on with these boardflags - I have tested

nvram set boardflags=0x0318
nvram set wl0_afterburner=off
nvram set wl0_gmode=2
nvram set wl0_net_mode=g-only
nvram commit

is working with my two GSv1.1 and WDS.

HTH and bye
Daniel
(edited by mbm - correct boardflags - sorry.)

I found (too late..) that in other post mbm wrote that for GS 1.1 one should set boardflags to 0x118 which makes more sense.
But the question is - how to revive WRT?

EDIT: Finally, several pin shortcuts & firmware flashes brought WRT back to life.
(edited by mbm - correct boardflags - sorry.)

(Last edited by tosuja on 4 May 2005, 11:03)

Mbm, could you elaborate somewhat on the nas4not part?

I am running experimental 2005.03.29 build on 2 WRT54GS boxes: a v1.0 and a v1.1. WDS without WPA works fine. I have installed /usr/sbin/nas that I got from a linksys-utils.tar.gz package. Someone from #wrt54g pointed me to this one about 5 weeks ago, while I was searching for a suitable nas binary for the experimental build. I quickly tried WPA-PSK/TKIP on a single AP and by itself it seemed to work fine as well.

Now I have set on both WRTs:

wl0_mode=ap
wl0_ssid=<ssid>
wl0_lazywds=0
wl0_wds=<other wrt eth1 mac addr>

wl0_auth_mode=psk
wl0_wpa_psk=AABBCCDDEE
wl0_wpa_gtk_rekey=3600
wl0_crypto=tkip

Nas runs with: /usr/sbin/nas /tmp/nas.conf /tmp/nas.pid lan as per the FAQ suggest. (Autogenerated) /tmp/nas.conf reads:
nas -P /tmp/nas.pid -l br0 -H 34954
-i eth1 -A -m 2 -k AABBCCDDEE -s <ssid> -w 2 -g 3600

This doesn't work; each AP and its' clients don't communicate with the other side.

I have read on the Chupa Asus WL500g forums about nas4not and nas4wds symlinks (here: http://forum.chupa.nl/showthread.php?p=5663). After that it is unclear to me if I have to invoke separate instances of nas or what.

As per your suggestion I link /usr/sbin/nas4not -> nas

Doesn't change anything. I also link nas4wds -> nas but still no luck.

Then I find this thread on that forum again:
http://forum.chupa.nl/showthread.php?t= … hlight=WDS
Michael there got this to work by adding the AP's own wifi interface mac address to the WDS member mac address list (i.e. wl0_wds). So the AP also creates a WDS link to itself.
No matter how crazy that sounded, I tried it too. No difference...

I have stumbled across numerous technical explanations why WPA and WDS should not work, and they all seemed quite reasonable. However if this does actually work after all, as various ppl have mysteriously reported here and there, I believe it would have to involve something as running a separate instance(s) of NAS over the WDS link so as the clients of each AP can authenticate, if need be, to the other AP as well? Or something crazy along that line.

Since available information (not to mention a howto..) on this topic is rather scarce (and often contradictive), would you mind describing how this nas4not scheme works and what one needs to get it to happen?

Anyone read the above? mbm, nieslpriem ?

Hi cajoline,

I've read it - but I have no sollution/sugestion for you - I'm really sorry.

After "fumbling" around with "WPA for WDS" I've given up because of 2 reasons:

1. I havn't found a solution - sorry.

2. I think that WPA is too weak for a bridged network - I think it's only a matter of time, until WPA is hacked - so I have decided, to go for a IPsec tunnel - bridged over WDS.

The idea is, to use 2 separate routers/bridges which build a IPsec VPN tunnel over the two completly open WRT's (OK - a least MAC list on both sides). In addition these seperate routers/bridges are building a second tunnel over a 4 MBit/s 4-wire DSL line - and they are doing "load balancing". So if one connection fails, the other one is allready up.

So I'm sorry, that I can't help you ...

Bye
Daniel

I got WDS+WPA working and have given copies of my S41wds and /sbin/hotplug scripts that work with current nas to the openwrt dev's  they can be reached at http://www.bingner.com/openwrt

You need to have the following set in nvram

wl0_crypto=(aes|tkip|aes+tkip)
wl0_wds_crypto=(aes|tkip|aes+tkip) - optional but can be different from wl0_crypto
wl0_auth_mode=psk
wl0_wpa_psk=YOURPRESHAREDKEY
wl0_wds_wpa_psk=PSKFORWDSLINKS - optional but can be different from wl0_crypto
wl0_ssid=YOURSID
wl0_wpa_gtk_rekey=REKEYINTERVAL - default 3600

This should also work properly if you are using wifi as your wireless interface name

Can you please post the settings of your lan_ifname, wifi_ifname, and so on parameters? Couldn't get it to work - if I set lan_ifname=eth0 - I can't connect to the boxes anymore.

TIA
Daniel

PS: How if the format of the wl0_wpa_psk parameter? Is if a "hex-code" or a simple ASCII string? And what si the maximum length of the key?

(Last edited by nieslpriem on 25 May 2005, 10:04)

you have to have the ifname for the interface that is your wireless interface as a bridge, or it won't be able to add the wds links to said bridge...

shouldn't have broken any connections from the wired networks either way...

psk has to be at least 8-63 characters, as ascii or it can be hex as 64 characters

My config for my main router:

lan_gateway=192.168.1.1
lan_ifname=vlan0
lan_ipaddr=192.168.1.10
lan_netmask=255.255.255.0
lan_proto=static
wan_hostname=wrt54gs-main
wan_ifname=vlan2
wan_ipaddr=192.168.0.2
wan_netmask=255.255.255.0
wan_proto=static
wifi_ifname=br0
wifi_ifnames=eth1
wifi_ipaddr=192.168.100.1
wifi_netmask=255.255.255.0
wifi_proto=static

wan ifname is vlan2 bevcause I have vlan tagging on, and it's actually a vlan on my cisco switch, would normally be vlan0 and lan as vlan1

Hi sbingner,

thanks for helping me so far ... but it doesn't work ...

After booting the WRT's I don't get any error messages, and I can see (using ps) that nas is running:

/usr/sbin/nas -P /tmp/nas.lan.pid -l br0 -H 34954 -i eth1 -A -m 2 -k AABBCCDDEEFF -s BridgeHiPP -w 2 -g 3600

But I cannot see nas4not.

So after short study of your /sbin/hotplug I tried:

root@OpenWrt:~# export INTERFACE=wds0.2
root@OpenWrt:~# /sbin/hotplug

I receive the following message immediately: "device wds0.2 is already a member of a bridge; can't enslave it to bridge br0." Which is obviously a message of brctl - because wl0_wds... is allready active and bridged.

And after about 10 seconds, I reaceive the error message: "No interface specified. Quitting..." Which seems to be an error from the /usr/sbin/nas4not symlink to nas ...

The nas4not command line (in "your" nas4not script procedure) is expanded like this:

/usr/sbin/nas4not lan wds0.2 up auto tkip psk AABBCCDDEEFF BridgeHiPP

(extracted using an echo command just before the command)

So everything seems to be like it should be ... or not ???

Do you know anything further?

TIA
Daniel

PS: Here are some (maybe) important nvram settings:

...
lan_ifname=br0
lan_ifnames=vlan0 eth1
lan_ipaddr=172.23.129.22
lan_netmask=255.255.0.0
lan_proto=static
lan_stp=0
...
wl0_auth=0
wl0_auth_mode=psk
wl0_crypto=tkip
wl0_ifname=eth1
wl0_maclist=00:13:10:15:23:d2
wl0_ssid=BridgeHiPP
wl0_wds=00:13:10:15:23:d2
wl0_wep=disabled
wl0_wep_bit=128
wl0_wpa_gtk_rekey=3600
wl0_wpa_psk=AABBCCDDEEFF
...

(Last edited by nieslpriem on 25 May 2005, 11:36)

OK ... please forget everything I said, about the not working WDS-WPA link ... it works like a charm

My problem was, that I had installed one of the nas ipkg's (I think it was version 0.2 or so) - and I have read now that these packages are all broken. So I extracted the nas binary from the LinkSys source package wrt54gs.3.37.2.tgz - and replaced the binary directly on both routers.

And now, everything works fine, and seems to be encoded with WPA - as far as I can see/check this. We will try both routers in this configuration now for some days, to make sure, that it also works over a long time (esp. rekeying ...). I will post the results of our tests in a few days in this thread.

So thank you very much - you're really great, and you will get one of the top places in my personal "all-time-top-100-:cool:-it-gurus" charts ;-)

Bye for now,

Daniel

I'm trying to setup wds using wpa tkip between two wrt54g (one version 2, the other version 2.2).  I don't know if I'm having the same problem or not.  I'm able to connect to either router using wpa, so I'm fairly sure I have the correct version of nas.

I've tried downloading sbingner's scripts and that hasn't helped either.  I created the nas4not symlink.  When they come up, they both show wds0.2 interfaces and those interfaces show up under brctl show.  However, neither of them can ping the other.  I've tried the suggestions in this thread... I've tried setting both mac addresses on each's wl0_wds setting.  I've tried changing wl0_lazywds on or off on one or the other.

Strangely, the hotplug script doesn't seem to be launching nas.  Shouldn't I be seeing two nas/nas4not processes or am I reading that wrong?  I only see a line that says:

/usr/sbin/nas -P /tmp/nas.lan.pid -l br0 -H 34954 -i eth1 -A -m 2 -k test -s basement -w 2 -g 3600

logread shows this on both routers.  Is the attempt to add interface with same source the problem?  If so, what could that be?

Dec 31 19:00:14 (none) kern.info kernel: device wds0.2 entered promiscuous mode
Dec 31 19:00:14 (none) kern.info kernel: wds0.2: attempt to add interface with same source address.
Dec 31 19:00:14 (none) kern.info kernel: br0: port 3(wds0.2) entering learning state
Dec 31 19:00:14 (none) kern.info kernel: br0: port 3(wds0.2) entering forwarding state

Well I tried everything that sbingner mentions, but it doesn't seem to work.

I installed S41wpa and replaced hotplug with your script.

I don't know what version of nas I have, so I downloaded http://www.linksys.com/support/opensour … 3.37.2.tgz and extracted nas from it (WRT54GS_3_37_2_1109_US/release/src/router/mipsel/install/nas/usr/sbin/nas), replaced my binary and created the link /usr/sbin/nas4not -> /usr/sbin/nas.

However this version of nas, whenever I run it and no matter what arguments, it always says on stderr "nas: not found" and returns 127. So I guess this version doesn't run properly on the OpenWRT build I am running (experimental 20050329). Anyway.

I set the nvram variables exactly like you suggested. I even used a different key for wds, setting it in wl0_wds_wpa_psk.

When the system comes up the only thing I notice is a process like the one below:
  355 root        444 S   /bin/ash -x /sbin/hotplug net
I don't know what is calling hotplug, but by looking at the script it sure seems it's being called in the wrong way. hotplug expects to find a variable INTERFACE in the environment, and not an argument. But even that argument seems wrong..
Apart from that there is no nas process running, since obviously it has died due to the "nas: not found" error above. I do see /tmp/nas.lan.conf however:
/usr/sbin/nas -P /tmp/nas.lan.pid -l br0 -H 34954 -i eth1 -A -m 2 -k AABBCCDDEE -s mousmoul -w 2 -g 3600
The above clearly shows an attempt to run nas from /etc/init.d/S41wpa.

So I go back to the nas binary I had and try again. This time I see the above instance of nas running. But I see no other nas or nas4not process and no trace of one whatsoever.

As I have noted before, this is my lan/wan configuration:
lan_ifname=br0
lan_stp=on
lan_ifnames=vlan0 eth1
vlan0hwname=et0
vlan0ports=0 1 2 3 4 5*
lan_proto=static
lan_ipaddr=192.168.0.3
lan_netmask=255.255.255.0
lan_gateway=192.168.0.1
lan_dns=192.168.0.1 192.168.0.3
wl0_ifname=eth1
wan_proto=none
wan_ifname=vlan1
(yes I don't do any routing on this box, only switching and bridging)

I really have no clue what is happenning. What is supposed to call hotplug? wlconf? And what is supposed to happen when nas4not is called? Another instance of nas running, or does it signal the nas process somehow? Can you please give some insight? Apart from getting it to work, I'd really like to understand how this works...

(Last edited by cajoline on 26 May 2005, 08:52)

Hi grOk,

I have "played around" with the scipts and nas4not not for a long time, and now it seems to work.

Here are some tipps, which I think, you could try:

1. Check the nas binary:

root@OpenWrt:~# ls -l /usr/sbin/nas*
-rwxr-xr-x    1 root     root       126444 Jan  1 00:02 /usr/sbin/nas
lrwxrwxrwx    1 root     root            3 Jan  6  2000 /usr/sbin/nas4not -> nas
lrwxrwxrwx    1 root     root            3 Jan  6  2000 /usr/sbin/nas4wds -> nas

I should have the right size - at least, only the "123 kB" version works for me - I have extraced it from the LinkSys "source" package (wrt54gs.3.37.2.tgz).

2. Check that WDS is running without WPA

3. Check that /etc/init.d/S41wpa (from http://www.bingner.com/openwrt/) is starting nas correctly on both WRT's:

root@OpenWrt:~# ps fax
  PID  Uid     VmSize Stat Command
(...snip...)
  370 root        496 S   /usr/sbin/nas -P /tmp/nas.lan.pid -l br0 -H 34954 -i eth1 -A -m 2 -k mySimpleTestKey
(...snap...)

Even after running /sbin/hotplug only this nas process is active all the time - the nas4not call only seems to register the WDS link.

4. Check iwconfig - it should look like this:

root@OpenWrt:~# iwconfig
(...snip...)
eth1      IEEE 802.11-DS  ESSID:"BridgeSSID"
          Mode:Master  Frequency:2.462 GHz  Access Point: 00:13:10:15:23:D2
          Tx-Power:22 dBm
          RTS thr=2347 B   Fragment thr=2346 B
          Encryption key:****-****-****-****-****-****-****-****-****-****-****-****-****-****-****-****
(...snap...)

If the ESSID is empty - you may have the wrong nas binary.

4. Try to run the /sbin/hotplug (from http://www.bingner.com/openwrt/) manually with:

root@OpenWrt:~# export INTERFACE=wds0.2
root@OpenWrt:~# /sbin/hotplug
device wds0.2 is already a member of a bridge; can't enslave it to bridge br0.

You should receive the brctl error message, because wds0.2 is allready part of the bridge - but if you wait for about 10 seconds, and you get another error message ("No interface specified. Quitting...") something is wrong - I my case it was the wrong nas binary.

5. For diagnosis, put an echo into the hotplug script - locate the nas4not procedure, and edit it like this:

nas4not() {
  (
    while ! nasrunning; do
    sleep 1
    done
    # Wait - nas dosn't always accept registration immediately
    sleep 10
    echo /usr/sbin/nas4not $@     # <- insert this line
    /usr/sbin/nas4not $@
  ) &
}

Now try step 4 again - after 10 seconds (or so) you should receive a copy of the nas4not command line on the console, which should look like this one:

/usr/sbin/nas4not lan wds0.2 up auto tkip psk mySimpleTestKey BridgeSSID

6. Check the nvram - I have found out, that the S41wpa script (from sbingner) likes to have some variables set, which are otherwise not neccessary - e.g.:

lan_ifname=br0
lan_ifnames=vlan0 eth1

And double check the other important nvram variables:

wl0_auth=0
wl0_auth_mode=psk
wl0_crypto=tkip
wl0_ssid=BridgeSSID
wl0_wds=00:13:10:15:23:cf
wl0_wep=disabled
wl0_wpa_gtk_rekey=3600
wl0_wpa_psk=mySimpleTestKey

This list is eventually not fully complete - so try to check every setting again.

If you have WDS working without WPA and you have the "sbingner-scripts", IMHO there must be an error with the nas binary or the nvram variables - I have no other idea.

Right now, my two WRT54GS (v1.1) are running WDS with WPA for about 17 hours - without any problem. I have started simultanious flood pings (ping -f ...) on both sides each crossing the bridge. And I have also startet bing on one side, to "measure" the throughput of the WDS/WPA link - with 22.5 Mbit/s it seems OK for me ;-)

I hope this will help - if not, contact me again, first we can try to cross-check the nvram variables on our boxes - second, I'm trying to write a short documentation, of what I have done with my 2 WRT's (I'm in the IT department of a mid sizes logistics company in Germany) to make it "reproduceable" - I have planned to post this doc on the openwrt.org Website, to help others.

HTH and bye
Daniel

(Last edited by nieslpriem on 26 May 2005, 08:58)

Thanks for taking the time to give me more suggestions!

At this point, wds works with wpa turned off.  (duh I should have tried that first)  And I'm using sbingner's scripts.  I'm pretty sure the nvram variables are set right, just in case here they are:

wl0_auth=0
wl0_auth_mode=psk
wl0_crypto=tkip
wl0_ssid=buser_basement
wl0_wds=00:12:17:C9:C5:3D
wl0_wep=disabled
wl0_wpa_gtk_rekey=3600
wl0_wpa_psk=test

Only difference is mine has:

lan_ifnames=vlan0 eth1 eth2 eth3

So, thinking it could be a bad nas, I downloaded http://www.linksys.com/support/opensour … 3.37.2.tgz which seems wrong, considering I'm not running gs, I'm running just g.  Now the weirdest thing is, it can't execute nas as if it's not there, but it is there.  See:

root@buser_basement:~# ls -lh /usr/sbin/nas
-rwx------    1 root     root       123.6k May 26 18:12 /usr/sbin/nas
root@buser_basement:~# /usr/sbin/nas
-ash: /usr/sbin/nas: not found

?? So anyway... I'm now downloading http://www.linksys.com/support/opensour … 3.01.3.tgz and will give that a try once it's finished.  At this point, I can remember where I got the version of nas I was running.  I think I got it by extracting it from the firmware image from WRT54GV2_3.01.3_US_code.bin.  Perhaps the nas from the .tgz will be better... 200 meg download... for a 123k file...

(Last edited by gr0k on 27 May 2005, 00:33)

Woops, I was using the nas in the mipsel directory instead of the mipsel-uclibc. 

So, I've tried the nas from the latest wrt54g and wrt54gs 200 meg .tgz downloads... still not working. 

I don't know, should I upgrade to the latest openwrt?  The one I'm running is from 2005.04.23 (according to the busybox login message, what is the correct way to tell the version?)

OK, finally success thanks to all of you guys!

The procedure that sbingner described and nielspriem further explained in detail definitely works.

At least for OpenWRT experimental 20050329 you need indeed the specific version of the nas binary (126444 bytes, 043685e8e6b8be97fd2a720d221f62a3 md5sum). I got this one from someone in #wrt54g. The one I initially extracted from the Linksys distribution (wrt54gs.3.37.2.tgz) was *not* the same, as by mistake I got the one from the mipsel tree instead of mipsel-uclibc. That one is 126536 bytes long.
gr0k, if you use the mipsel-uclibc one, as you noted yourself, this should work, no matter what distribution you get it from!

Using this version of nas, bringner's init script successfully starts nas, which authenticates the AP clients. Then his hotplug script, which is probably called when the wds0.2 interface is brought up, registers the key for the WDS link through nas4not,  10 seconds later. You can indeed have a separate key for WDS links, and actually it looks like you can have a separate key for every WDS link.

What fooled me the first time I tried this was first of all the nas binary, I was trying to use the wrong one.
Then I have also experienced a quite weird problem. I have a wireless client, a laptop running Windows XP SP2 with a Cisco Aironet 350 PCMCIA card. The Windows miniport driver, as it happens for many older 802.11b drivers, did not support WPA-PSK, so I had to install the current Cisco driver. Of course I had to install their complete suite, including the client manager and all the EAP drivers, which I later had to uninstall because it comes with a lot of (completely useless to me) bells and whistles which loads up the system considerably and also inevitably takes away some Windows easy-cheesy functionality (such as fast user switching). Removing the package you are left with a set of drivers which supports WPA-PSK, and from what others have reported, you can now use the crappy Windows Wireless Zero Configuration to manage the interface and connect to the network using WPA-PSK.

However, after I've done all the above and finally try to connect to my WPA+WDS AP it seems like the Aironet client is completely crashing the wifi interface on the wrt54gs! I am not sure what is happening, I have used tcpdump trying to capture anything coming from the Aironet card that could give me some insight, and all I see is these two broadcasts:
23:27:33.271625 00:07:50:ca:fd:f2 > Broadcast null xid/R: 01 00 len=0
23:27:33.272135 00:07:50:ca:fd:f2 > 00:12:17:e7:7e:0b snap ui/C len=39
After that it just looks like eth1 is completely frozen, nothing comes in or out, and the WDS link eventually goes down...
Everything magically goes back to normal a few seconds after the Aironet radio shuts down.
You don't happen to have any clue what is going on here? I'm not sure these are WPA related at all.

Anyway once again a big thank you to all three of you guys.

(Last edited by cajoline on 27 May 2005, 05:27)