26 (edited by login_denied 2005-04-24 19:18:47)

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

acidbits wrote:

I did the tests myself. You get the same bandwith using "client in breaked bridge mode (mode=sta)"  and "client in bridged mode (mode=wet)". I used a Dlink-900AP as an AP (802.11b) and configured a WRT54G as client in the two different ways:

[http://woz.gs/wifi/openwrtbridge.html ]
wl0_mode=wet
lan_ifname=br0
...

[http://openwrt.org/ClientModeHowto]
wl0_mode=sta
nvram set lan_ifname=vlan0             
nvram set wifi_ifname=eth1         
...

In the two configurations I used Iperf to test the bandwith and always had the same result: 5 Mbit/sec
The bandwith didn't decrease as I exepected.

I followed [http://openwrt.org/ClientModeHowto], but i can only ping my PCs behind the WRT. Looks like that there are some residual declarations from tryings before. Do you have a list a complete setting?

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Sadly I have to say that works the same way to me. I posted the results done at home with a very simple setup and didn't notice those problems. When I set the WRT54G in the WLAN (25 WRT54G behind this one) I had exactly the same problems.

It looks like this setup works fine if there's only 1 PC connected to the WRT54G's LAN ports. Right now I have one WRT54G configured in client-wet mode at home with 1 PC connected at it and it works right. If I connect another one problems come up.

Had no time to work on this because I have a much serious problem with a WRT54G in AP mode that crashes on heavy traffic transfers. Once I got this fixed I'll go again on the client-wet mode, I guess there's something to do with ARP, maybe have to tell WRT54G to modify the routing, to put there a static ARP routing or something like this.

I'm  considering to use some kind of tunneling between them, this way you can set as many NATs as you need in the WLAN and it would be transparent to them. Looked at OpenVPN but it takes too much WRT54G's CPU usage and you get less bandwith, need to find a tunneling without cypher cause I don't need that level of security, the underlying WEP is enough. Don't want to configure a VPN in each PC, WRT54G should manage the tunneling.

I know this is not easy to apply to a small WLAN and that would be more reliable to have an easy way to solve this.

Any expert can help us on this?

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

muchod wrote:
1.- I can't telnet or ping the wrt54g from the main lan, but I can telnet and ping the pc's behind the wrt54g from the main lan. Sometimes the ping or the telnet works and I can see the telnet login screen or some ping responses. But the ping looses practically all the packets. No problems with pings to hosts behind the bridge. Also not problems connecting to the bridge from the pcs directly conected to it.

Has someone found a solution for this problem?

I have a simple test-setup right now:

-------LAN-------                    Notebook
          I                                      I
          I                                      I
   WRT54GS   <=======>  WRT54GS
  (in AP mode)                   (in WET mode)

Now my PING/ICMP tests that I have done so far:

from  \  to I  LAN     AP   WET   Notebook
------------+--------------------------------
LAN          I     -      OK     *          OK
AP            I   OK      -       *          OK
WET         I   OK     OK      -          OK
Notebook  I   OK     OK    OK          -

where:
     OK     means, that PINGs are going through without problems
       -      n.a. (loopback)
      *      means, that about 85% of the PING/ICMP packages are not OK, and no answers are received

Looks weird to me, and I have no idea. /etc/init.d/S45firewall ist disabled - so definitely no firewall rules are killing the ICMPs.

Seems to be the same problem as muchod's - has someone any idea?

TIA
Daniel

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

I've been reading this bridge thread and researching WDS.  All I really want to do is connect two wired networks in different buildings with a wireless bridge just like I used to do with the Linksys WAP11.  With the WAP11, I select bridge and put in the MAC of the other device. 

Can't OpenWRT and the WRT54GS do this?  Everything I've read so far always connects to an AP.  I really don't want an AP in this case .... I just want to connect the wired network in each building to the LAN ports and use the wireless interface as a bridge between the two buildings with two WRT54GS.

How can I do this with OpenWRT?

Thanks,

Brian

P.S. by the way, I'm typing this via the http://woz.gs/wifi/openwrtbridge.html setup and I'm not seeing the ping problems others talked about.  I can ping any machine (including the two wrt54gs) on the network.  I built from CVS just the other day.

30 (edited by NathanA 2005-05-01 01:15:49)

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hey, guys.

I'd be surprised if there is a way to get true "client-mode bridging" to work without some kind of layer 3/proxy-ARP-esque solution.  I believe that the problems that people are seeing with this method of wireless bridging has to do with a limitation in the 802.11 spec, and is not specifically a limitation of the WRT54G hardware or the OpenWRT software.  Basically, as I understand it, an AP knows where to send a packet to by looking at the MAC addresses that clients used to identify themselves TO the AP when they registered/associated with it.  So, if the wireless client identifies itself with its own MAC and then tries to "bridge" ethernet traffic over to the AP, the AP is going to be receiving ethernet frames which bear MAC addresses that are different from the one that the AP knows the wireless client by.  If someone else connected to the AP tries to send traffic to one of the devices plugged into the "client bridge", it will prepare an ethernet frame with the target MAC address being the device it wants to talk to, *not* the wireless client.  Once that packet reaches the AP, it doesn't know what to do with it because there ARE no clients associated to it with that MAC address.  The associated stations list *IS* the AP's learn table.  In some cases/implementations, the AP may not even bother accepting packets from a wireless client to begin with if the MAC in the ethernet frames it is receiving from it does not match the MAC that the client used to identify itself by to the AP during association.

I work for a wireless ISP, and the equipment that we use to connect our clients to the APs on our towers have solved this dilemma in one of two ways, traditionally:

1) The wireless client "clones" the MAC of the first ethernet device it sees behind it, associates to the AP using that MAC, and then bridges traffic back-and-forth between the AP and that ethernet device ONLY.  If it sees the MAC change on its ethernet interface (either because someone plugged in a different device or because there are multiple devices behind it), it will re-associate using the new MAC so that it can bridge traffic to THAT device.

2) The wireless client associates to the AP using its own MAC and then does what we like to call "MAC-NAT": it maintains an internal layer 2 "NAT" table that maps this IP address to this MAC address, and then re-writes the ethernet frames as they're going out to the AP so that they all look like they're coming from the wireless device itself.  When a packet comes in bound for a certain IP address, it consults its "MAC-NAT learn table" to detemine which host on the ethernet side of the bridge the packet should go to, and re-writes the packet accordingly before sending it on.

Neither of these are truly "ethernet bridges."

From the sounds of it, the Linux bridge device coupled with the Broadcom wireless driver in client mode is doing something similar to #1 above; that's the only way I'm able to explain why pings come back from all hosts, but only from one-at-a-time.  It'd be interesting to see what is going on during these "ping tests" from the AP's perspective: is the MAC of the WRT54G "changing" to match the MAC of the host that you are seeing ping responses from at that given instant?

I don't know too terribly much about WDS itself (it's something we've never felt the urge to put into production anywhere on our network; our backhauls use more robust wireless solutions, and 802.11 is simply the "last-mile" hop to the customer), but I'd guess that it was drafted up precisely because bridging devices behind an 802.11 client -- with the way the standard is written up -- simply doesn't work without some magic involved, and so another solution for effective "wireless bridging" was needed.  Thus, if you want a REAL ethernet bridge over 802.11 links, you'll have to go with WDS.  Otherwise, if you want multiple hosts behind the client bridge, you'll need to set up Proxy-ARP and use it as your "MAC-NAT" solution.

Hope this helps,

-- Nathan

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

hutchman wrote:

I've been reading this bridge thread and researching WDS.  All I really want to do is connect two wired networks in different buildings with a wireless bridge just like I used to do with the Linksys WAP11.  With the WAP11, I select bridge and put in the MAC of the other device. 

Can't OpenWRT and the WRT54GS do this?  Everything I've read so far always connects to an AP.  I really don't want an AP in this case .... I just want to connect the wired network in each building to the LAN ports and use the wireless interface as a bridge between the two buildings with two WRT

How can I do this with OpenWRT?

This is the question. I haven't solved tzhe problem yet. But I have done some more investigation - and it seems also, that pings to and from the two bridged wired networks are behaving "asynchonously".

Pinging from the net behind the "WET" configured bridge (using ping's or flood ping's) gets about 100% of the answers back. Pinging from the network behind the "AP" configured bridge looses about 2-4% of the packets (don't know if the pings are lost, or the answers).

I also have exchagend the Notebook in my original configuration with a "real PC" (and Linux) - because I believed, that maybe the Notebook looses some packet (I never trust Notebooks with Windows ;-)

This is really strange.

hutchman wrote:

P.S. by the way, I'm typing this via the http://woz.gs/wifi/openwrtbridge.html setup and I'm not seeing the ping problems others talked about.  I can ping any machine (including the two wrt54gs) on the network.  I built from CVS just the other day.

I believe you - from behind the WET-bridge it's really easy to work - but from behind the AP, TCP sessions allways "stall" for half a second or so - which seems to be a problem of the 2-4% packets lost.

Can you be more specific about your configuration - maybe PM - I'm really interested. Which WRT's are you using? Version? OpenWrt Version/Build? IP network configuration? .....

Does anybody know of another configuration I can try? Is it possible, to put both WRT54GS into WET-mode, and connect them with "infra=0" (peer-to-peer mode) - maybe this would solve my problems?

TIA
Daniel

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

I wrote:

Does anybody know of another configuration I can try? Is it possible, to put both WRT54GS into WET-mode, and connect them with "infra=0" (peer-to-peer mode) - maybe this would solve my problems?

So tried this - works, but same problem - so I switched back to WDS - which works fine now.

Bye
Daniel

33 (edited by NathanA 2005-05-02 22:36:15)

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

nieslpriem wrote:

So tried this - works, but same problem - so I switched back to WDS - which works fine now.

Like I said above... smile  802.11 "client-mode" bridging (as in, real bridging) will never work correctly because of 802.11.

-- Nathan

34 (edited by acidbits 2005-05-04 14:51:17)

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Ok I finally found a way to make it work. :-)

In my tests at home I have this layout:

Home network: 192.168.1.0/24

AP (Linksys DWL 900+): 192.168.1.10

[Wired to 192.168.1.10 (AP)]
DSL-router: 192.168.1.1
PC1 (Windows 98): 192.168.1.2
Server1 (Debian): 192.168.1.3
Server2 (Debian): 192.168.1.6

Wireless client in "acidbits' mode" (WRT54G): 192.168.1.61 (eth1) & 192.168.1.60 (vlan0)

[Wired to 192.168.1.60 (WRT54G LAN Ports)]
PC2 (WinXP): 192.168.1.33
Laptop (Ubuntu): 192.168.1.233

Here we go. What I did is to "break the bridge" and put each of the Interfaces in the same "home subnet":

nvram set lan_ifname=vlan0              #  "vlan2" on hardware version 1
nvram set wifi_ifname=eth1              #  "eth2" on hardware version 1
# Config ifaces
nvram set lan_proto=static 
nvram set lan_ipaddr=192.168.1.60
nvram set lan_netmask=255.255.255.0
nvram set lan_dns=80.58.0.33
nvram unset lan_gateway
nvram set wifi_proto=static
nvram set wifi_ipaddr=192.168.1.61
nvram set wifi_netmask=255.255.255.0
nvram unset wifi_gateway
# Client mode
nvram set wl0_mode=sta
# WiFi Settings
nvram set wl0_ssid=aCiDBiTS-home
nvram set wl0_wep=disabled

Make sure your firewall doesn't makes any MASQUERADE, for testing purposes you can disable it. In /etc/init.d/ I set this script named S70routing:

#!/bin/sh

#Enable proxy_arp for each interface, so WRT54G eth1 and vlan0 allow packets 
#going to other IPs than themselves (192.168.1.60 & 192.168.1.61)

echo "1" > /proc/sys/net/ipv4/conf/vlan0/proxy_arp
echo "1" > /proc/sys/net/ipv4/conf/eth1/proxy_arp

#Tell him in which Interface is the gateway:

route add default gw 192.168.1.1 dev eth1

#Teach WRT54G in which interface is placed each device in the network:

route add -host 192.168.1.1 dev eth1
route add -host 192.168.1.2 dev eth1
route add -host 192.168.1.3 dev eth1
route add -host 192.168.1.6 dev eth1
route add -host 192.168.1.10 dev eth1
route add -host 192.168.1.33 dev vlan0
route add -host 192.168.1.233 dev vlan0

And that's it! Everything works as expected, all devices are in the same subnet. Problem is that each time you add a new device you have to add a new entry to the routing table to specify in wich interface it is. I love OpenWRT :-)

UPDATE: Broadcasts doesn't work, in windows you won't find the resources of your workgroup. But you can make "hard links" like: change your \\WorkGroup\printer1 by \\192.168.1.x\printer1

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hi acidbits!

lots of thanks! Its working fine on my WRT54GS V1.1.

Bye.

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hi all!

I've the same problem ...

NathanA talked about MAC-NAT and that proxy_arp could do that.

Mmmhh ... could it be possible that the use of ebtables leads to
working solution for our problem?

http://ebtables.sourceforge.net/

greetz
kao

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

It might be possible with ebtables too, but I've solved the issue as follows:

* split the br0 to vlan0 and eth1
* set 192.168.0.253/32 for vlan0 and 192.168.0.253/24 for eth1
* ip r add 192.168.0.25/32 dev vlan0 (thats the only box behind the wrt, add host routes / network routes as you need)
* echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
* echo 1 > /proc/sys/net/ipv4/conf/vlan0/proxy_arp

This made the WRT a semi-bridge between 192.168.0.25 on the LAN port and 192.168.0.* on the WLAN, which now works reliably for me.

The only thing you can't do is to move machines from one side to the other without changing the routes on the WRT

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

why not drop bridging idea whole together and stic with complete routing ?
much faster
much secure
scale well
spread network easy
less overhead on wrt-cpu

wireless joe

39 (edited by kaobiore 2005-05-23 21:14:30)

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hi all!

"Complete routing" is not an option for me!

I've tried to do a "MAC-NAT" with ebtables with no success! :-(

Now, i found something new :-) ... please take a look at:
http://freshmeat.net/projects/parprouted/?topic_id=150

It's a daemon called parprouted ... and here is the description out of the man-page:

parprouted is a daemon for transparent IP (Layer 3) proxy ARP bridging.  Unlike standard bridging, proxy ARP bridging allows to bridge Ethernet networks behind wireless nodes. Normal L2 bridging does not work between wireless nodes because wireless does not know about MAC addresses used in the wired Ethernet networks. Also this daemon is useful for making transparent firewalls. The daemon listens for incoming ARP requests, and in case the location of the requested IP address is unknown, forwards them to other interfaces, as well as updates kernel ARP table with the received replies. When necessary, the daemon generates an ARP reply itself, which causes the stations to send traffic to the host daemon is running on. By automatically adding appropriate /32 routes to Linux kernel IP routing table for the hosts learned via ARP, daemon ensures that the Linux kernel will be able to route the packets to the destination host when it receives them with-out any need routing/subnetting manually. All routes entered by the daemon have a metric of 50.
Unless you use -p switch, all entries in the ARP table will be refreshed (rechecked by sending ARP requests) every 50 seconds. This keeps them from being expired by kernel. Normally it takes about 60 ms for a bridge to update all its tables and start sending packets to the destination.

Ahhhmmm ... am I completely wrong or isn't that exactly what we need?!? ( ... looks like that there is no precompiled openwrt-package available for this ...)

By the way ... I've red somewhere in the sveasoft-forum that the upcoming release will support multi-clients!?!

greetz
-=kao=-

*Edit* I've already compiled it for openwrt ... will post my results tomorrow!

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

parprouted doesn't support broadcast though.

I have the following (have had it for a little while, so it's stable):

WRT in client mode
wpa_supplicant doing WPA/PSK (as the netgear supplicant is broken for client mode)
Routes to 'major' machines hardcoded (fileserver, AD server)
parprouted handling everything else.
dhcp-relay relaying dhcp requests across the bridge.

What parprouted is basically call 'route add' dynamically when it sees an IP on one side of the bridge.
This doesn't solve the big issue though - broadcasts.  They simply don't cross the bridge.  I partially solved this
with dhcp-relay but other broadcast-specific things (Windows networking, mdns) don't work at all.

I'm pretty sure it would be possible for parprouted to be modified to relay and reply to broadcasts (specific ones presumably.. you don't
want to relay arp broadcasts!).  Anyone looking at this?

Tony

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hello all. I want to set up my WRT54G to function purely as a bridge so that I may hook two LAN's in my office together and make them function as one. Currently, each LAN has a WRT54G supplying them access and interconnectivity. Both of the Linksys WRT54G are receiving internet access from the same source, but I cannot get the LAN behind one linksys to reach the other LAN behind the second linksys and function as one.
Anyone know how I may do this.?
I thought disabling DHCP totally might help, but I haven't been able to get that done either. The Linksys' still keep assigning IP's to devices connected to them. I really need some help on this please.

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

patrix wrote:

Hello all. I want to set up my WRT54G to function purely as a bridge so that I may hook two LAN's in my office together and make them function as one. Currently, each LAN has a WRT54G supplying them access and interconnectivity. Both of the Linksys WRT54G are receiving internet access from the same source, but I cannot get the LAN behind one linksys to reach the other LAN behind the second linksys and function as one.
Anyone know how I may do this.?
I thought disabling DHCP totally might help, but I haven't been able to get that done either. The Linksys' still keep assigning IP's to devices connected to them. I really need some help on this please.

Use the search feature of these forums and search for WDS.  Basically you plug in the MAC address of the far side WRTGS and vice versa.  I'd suggest turning on WPA for encryption too so the traffic going over the wireless link is secure.  Here is a howto I've been following but haven't actually been able to get is working with whiterussian yet http://jean.nu/view.php/page/openwrt

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Does anyone know how to disable DHCP on the Linksys WRT54G running Openwrt firmware?

I was able to get a web interface running on it from http://davidoffdotnet.net/openwrt/ipkg/ … mipsel.ipk From this interface, I disabled DHCP, but found that the linksys was still assigning IP addresses to any station connected to it via cable or wireless cards. I would like to assign an IP to the linksys and stop it from assigning IP's to the clients so I may setup a seperate DHCP server on my LAN. Is this possible?

Also, anyone have an idea where or how I could get another web interface (perhaps another may have more features)?

Thanks,
Patrix

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hi all,

I configured my Linksys WRT54G according to the guidelines at http://woz.gs/wifi/openwrtbridge.html after this. I was able to get the linksys to perform the way I want, but only in failsafe mode. When I boot to failsafe mode, the linksys becomes transparent like any ordinary switch and allows my workstations connected to it to receive IP addresses from any DHCP server on my LAN (the linksys is also connected via the WAN port to my LAN) instead of assigning any IP's. This is the result I want, but it only happens in failsafe mode.

Can anyone tell me why this happens, and how I can achieve the same result in normal mode?

Thanks
Patrix

45

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hi all,

I'm a newbie to openwrt and I managed to scape together a wireless bridge by using the howto at http://woz.gs/wifi/openwrtbridge.html.  for whatever reason, after a power cycle, I must log into my wrt54gs and run
>wl wet 1
This is undesirable since the only device I want to have connected to the wrt54gs is my xbox.
From the howto I set the wl0_mode variable to "wet", but I'm guessing there's something else I need to set to get this setting to persist.

If it matters, I'm using the firmware from:
http://downloads.openwrt.org/people/nbd/whiterussian/

Thanks,

Chris

46

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Hi again,

The answer to my own question: nvram set wl0_wet=1

I'm now happily streaming music on my xbox.  Will this setup be fast enough to stream MPEG2 across the network?  I will have to try tomorrow... too late tonight...

47 (edited by olli_04 2005-10-08 09:39:19)

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

You need a recent White Russian version (snapshot) from http://downloads.openwrt.org/people/nbd/whiterussian/

Than use the following Howto from http://wiki.openwrt.org/ClientModeHowto

Please report if it works for you.

Olli has since left the OpenWrt project; these posts remain for historical reasons.

48 (edited by /usr/local/fox 2005-09-11 21:03:40)

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

I tried all the configurations show here and cannot get this to work. I had Alchemy installed before I installed OpenWRT and wonder if my NVRAM settings are misconfigured.

In this thread some one mentioned that the configuration works with the FailSafe NVRAM settings, is there a way to load and commit NVRAM back to stock and restart from a fresh configuration? I'm new to this and I think it will help is I start fresh and follow the howto verbatum.

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Some one that has this setup working... Please do this so people who cannot get this working can do a compair.

nvram show > nvramsettings.txt

Then zip or tar the nvramsettings.txt and all the files in the /etc/inet.d directory so we can see what is being setup.

Thanks!!

/usr/local/fox

Re: Bridged Client mode (not WDS, not routed/NAT) - Howto

Sweet! I found what the problem was..
I used nvram to set lan_ifnames .. Problem is I needed to quote the vlan0 eth1

nvram set lan_ifnames="vlan0 eth1"

This solved the problem all together..

lan_gateway=192.168.1.1
lan_netmask=255.255.255.0
lan_ifnames=vlan0 eth1
lan_dns=192.168.1.1
lan_proto=static
lan_ipaddr=192.168.1.6
lan_ifname=br0
wan_proto=none
wan_ifname=vlan1
wl0_mode=sta
wl0_ssid=<wirelessssid>
wl0_wet=1