Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #1131 (assigned enhancement)

Opened 15 years ago

Last modified 12 years ago

WDS / bridging in Ad-Hoc mode

Reported by: georg@boerde.de Assigned to: mrenzmann (accepted)
Priority: minor Milestone: version 0.9.4
Component: madwifi: 802.11 stack Version: trunk
Keywords: adhoc wds Cc:
Patch is attached: 1 Pending:

Description

After getting a user report about bridging not working with Ad-Hoc mode devices, I've looked into the code and enabled 4-address mode (WDS) for Ad-Hoc VAPs. The change is almost straight forward, but I haven't tested anything besides compiling it.

Please test and report ;)

To activate WDS, you have to do the following with the patched driver:

wlanconfig ath0 create wlandev wifi0 wlanmode ad-hoc
iwpriv ath0 wds 1
ifconfig ath0 up
ifconfig eth0 up

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 ath0
ifconfig br0 10.23.42.1

I don't know yet about its side effects, don't blame me if you can't send broadcast frames or if the universe collapses.

P.S: While looking at the code, I've found a slightly inefficient handling of the common case (two MACs are compared before looking at a single flag in hostap/station mode), so I'm attaching commoncase.diff to this ticket too, which substitutes the cheap and the expensive comparison operations.

Attachments

commoncase.diff (1.1 kB) - added by georg@boerde.de on 02/04/07 15:57:50.
slight optimization
adhoc_wds.diff (1.7 kB) - added by georg@boerde.de on 02/04/07 15:58:35.
Ad-Hoc WDS support
adhoc_wds-2076.diff (1.1 kB) - added by georg@boerde.de on 02/06/07 17:32:12.
Ad-Hoc WDS support for r2076 and following releases
adhoc-bridge.diff (3.6 kB) - added by Ronald.intVelt@tno.nl on 06/25/08 00:38:51.
Support for bridging in IBSS/AHdemo mode - new attempt
adhoc-bridge.2.diff (4.1 kB) - added by Ronald.intVelt@tno.nl on 06/30/08 23:30:45.
Support for bridging in IBSS/AHdemo mode - new attempt (fix)
adhoc-bridge.3.diff (4.2 kB) - added by Ronald.intVelt@tno.nl on 07/24/08 18:39:57.
Support for bridging in IBSS/AHdemo mode - new attempt (minor update)
adhoc-bridge-bssma.diff (5.8 kB) - added by Ronald.intVelt@tno.nl on 06/15/09 15:30:28.
Support for bridging in IBSS/AHdemo mode, with multicast filtering

Change History

02/04/07 15:57:50 changed by georg@boerde.de

  • attachment commoncase.diff added.

slight optimization

02/04/07 15:58:35 changed by georg@boerde.de

  • attachment adhoc_wds.diff added.

Ad-Hoc WDS support

02/05/07 06:54:40 changed by mrenzmann

  • version set to trunk.
  • milestone set to version 0.9.3.

Thanks for the patches. Please sign them off so that we can commit them after review.

02/05/07 08:59:22 changed by georg@boerde.de

Whoops... I'm always forgetting this one...

Both patches are of course

Signed-Off-By: Georg Lukas <georg@boerde.de>

02/05/07 16:58:43 changed by mrenzmann

  • status changed from new to assigned.
  • owner set to mrenzmann.

02/06/07 13:56:57 changed by kelmo

  • milestone changed from version 0.9.3 to version 0.9.x - progressive release candidate phase.

commoncase diff was applied to r2076.

Since the side effects of adhoc_wds.diff are yet to be documented here, moving milestone from 0.9.3.

02/06/07 17:32:12 changed by georg@boerde.de

  • attachment adhoc_wds-2076.diff added.

Ad-Hoc WDS support for r2076 and following releases

05/16/07 20:16:35 changed by Thor

Hi, I´m using exactly this configuration for bridging but I have performance problems. I´m using 2 wrap.1e boards with wistron cm9 minipci and two PC as follow:

PC_1<---(ETHER)--->WRAP_1<---(ADHOC)--->WRAP_2<---(ETHER)--->PC_2

I have very poor performances beetween PC_1 and PC_2, something like 3-4Mbit/s UDP (iperf test).

Instead of bridging I configured static routes beetween PC_1 and PC_2 and I reached more than 30Mbit between PC_1 and PC_2.

Moreover I configured a bridge using sta and ap mode instead of adhoc mode and I reached again more than 30Mbit/s UDP.

This ticket I the only one that talk about bridging in adhoc mode. Maybe #507 is correlated...

Thor

07/06/07 15:04:25 changed by georg@boerde.de

Thor, have you applied the adhoc_wds patch before running your experiments? If not, please do so and re-test.

Without the patch, wrong sender MAC addresses are used, thus making the automatic rate detection algorithm reduce the TX rate down to the lowest possible value, while resending every packet several times. The patch attachede here fixes this issue and allows better ad-hoc bridge performance.

07/07/07 01:50:17 changed by mentor

07/09/07 06:35:54 changed by mrenzmann

  • milestone changed from version 0.9.x - progressive release candidate phase to version 0.9.4.

08/10/07 03:31:44 changed by hiwu.tw@msa.hinet.net

On madwifi-0.9.3.1, an error message will appear.
ath_mgtstart: discard, no xmit buf
Ad-hoc wds will stop work.

08/10/07 11:28:24 changed by hiwu.tw@msa.hinet.net

on trunk svn version r2649, the ad-hoc wds cannot work.

08/10/07 11:34:39 changed by georg@boerde.de

The "no xmit buf" problem is generally appearing in ad-hoc mode - see ticket #581 for more details. Please describe your last report in more depth. What exactly doesn't work? Is it a patching / compile / runtime problem?

08/10/07 16:32:29 changed by hiwu.tw@msa.hinet.net

madwifi-0.9.3.1 ad-hoc wds can work but still has performance problem.

PC_1<---(ETHER)--->WRAP_1<---(ADHOC)--->WRAP_2<---(ETHER)--->PC_2

using madwifi-0.9.3.1, the ICMP response time between PC_1 and PC_2 is more than 2ms. Ftp performance is less than 3Mbps.

I also repeat the same test on svn version r2649.
PC_1 cannot ping PC_2, and WRAP_1 cannot ping WRAP_2

08/14/07 18:33:54 changed by georg@boerde.de

Oh, actually the patch has been included in r2559.

When WRAP_1 and WRAP_2 don't see each other, you probably have other problems than WDS not working - are channel, mode (11g/11a) and ESSID set up correctly? Are both nodes in the same BSSID? Is antenna diversity set to the right values?

Wrt. WDS: Have you enabled "iwpriv athX wds 1" on both sides of the Ad-Hoc link? What is the data transfer performance from WRAP_1 to WRAP_2, and then whats the performance from PC_1 to PC_2?

08/18/07 21:45:19 changed by mentor

r2559 has been reverted in r2657 as it was causing crashes (see 'Ethernet to Wireless Bridge Function' on the madwifi-devel list).

11/23/07 21:33:24 changed by anonymous

Hi, I am facing out the same problem reported by Thor. I also tried all tips posted on this ticket. Has anyone found the solution for this situation? Thank you.

11/23/07 21:41:00 changed by mtaylor

There is a known issue that i have written about on the WDS page in the Wiki. The VAP for the IBSS or AP needs to be a different MAC than the WDS links if you want to bridge them. The problem is that the bridge takes the lowest MAC address of the enslaved devices (typically your master device's MAC), then you wind up with a bridge having the master device's MAC for the bridge, all WDS links, and the IBSS vap.

The workaround is to use -bssid when creating the IBSS VAP. Then bridging will work because the IBSS vap will not get confused and consume packets that should have been forwarded to the bridge and vise-versa.

I'm not sure if this is something that can/should be fixed in the driver but I have also submitted a fix to svn that allows WDS likes to be assigned locally managed (sometimes called "cloned") MAC addresses.

Try to make sure the device of the bridge and the main IBSS or AP ap are not the same. Spent all day figuring this one out yesterday.

Cheers,

Mike

11/23/07 21:42:23 changed by mtaylor

What I meant to say above was that the IBSS node gets the master device's MAC, and all WDS nodes in previous SVN versions were hardcoded to ignore -bssid and always get the master device's MAC. The bridge would then take the smallest MAC (of these - which are all the same). This really confuses the hell out of the kernel and/or driver.

06/25/08 00:38:51 changed by Ronald.intVelt@tno.nl

  • attachment adhoc-bridge.diff added.

Support for bridging in IBSS/AHdemo mode - new attempt

06/25/08 00:59:17 changed by Ronald.intVelt@tno.nl

Here's a new patch, against trunk (r3745) The transmit side (in ieee80211_output.c) was provided by Georg Lukas. In fact, he did too much :-) I removed some spurious lines from his patch. I also added the receive side (in ieee80211_input.c). Georg's warning w.r.t. potential collapse of the universe still applies, so use at your own risk! (But I hope some people will give it a try and report their findings). You may still experience occasional crashes (though fewer than before). My guess is that tighter filtering of input frames might remedy this.

06/25/08 01:10:23 changed by Ronald.intVelt@tno.nl

Getting sleepy. Forgot:

Signed-off-by: Ronald in 't Velt, TNO ICT <Ronald.intVelt@tno.nl>

06/30/08 23:30:45 changed by Ronald.intVelt@tno.nl

  • attachment adhoc-bridge.2.diff added.

Support for bridging in IBSS/AHdemo mode - new attempt (fix)

07/01/08 00:11:34 changed by Ronald.intVelt@tno.nl

OK, confession time: I first tested my patch on a couple of systems that are still running 0.9.3.2 . After I convinced myself it was working, I had a look at trunk and saw there hardly was a difference in the code of the affected sections of ieee80211_input.c and ieee80211_output.c . So I carried over my changes, made sure everything compiled and posted the diff here, without further testing... Until today. Really, you would think that by now I knew better than to try and cut corners :-\ I had completely forgotten about mentor's evil change set 2658. Here's the new diff. This time it has been tested with r3745.

Signed-Off-By: Ronald in 't Velt, TNO ICT <Ronald.intVelt@tno.nl>

07/02/08 15:46:46 changed by Teco Boot

I run the patch, provided by Ronald. It works fine; on 20 nodes, highly loaded (fixed 1mbps). Ronald: you did a great job!

07/24/08 18:39:57 changed by Ronald.intVelt@tno.nl

  • attachment adhoc-bridge.3.diff added.

Support for bridging in IBSS/AHdemo mode - new attempt (minor update)

07/24/08 18:58:42 changed by Ronald.intVelt@tno.nl

Updated diff, against trunk (r3823). This adds better support for the asymmetric case, where bridging is used only on one side. Note that the WDS flag still needs to be set on each ad hoc mode interface involved, in order to make it send and accept 4-address frames:

iwpriv ath0 wds 1

Thanks to T. Harvey for pointing out this possibility.

Signed-Off-By: Ronald in 't Velt, TNO ICT <Ronald.intVelt@tno.nl>

06/15/09 15:30:28 changed by Ronald.intVelt@tno.nl

  • attachment adhoc-bridge-bssma.diff added.

Support for bridging in IBSS/AHdemo mode, with multicast filtering

06/15/09 15:32:14 changed by Ronald.intVelt@tno.nl

Here's a new patch, against trunk (r4029). This code introduces a new concept: the Basic Service Set Multicast Address (BSSMA), which is derived from the BSSID by setting the I/G-bit (i.e. the least significant bit of its first octet). Rationale: Ad Hoc mode bridging is based on the use of 4-address frame headers. The four address fields are designated Receiver Address (RA), Transmitter Address (TA), Destination Address (DA) and Source Address (SA). Since no field is available to contain the BSSID, the latter is omitted. This is acceptable for unicast frames, The transmitting wireless node must somehow have determined that the DA is associated with the RA, which is the address of the wireless interface of the receiving node. However, multicast frames are potentially received and processed by all nodes within range, even by nodes that use the same channel but belong to a different IBSS. (Note that the Linux bridging code tells MadWifi to put the device into promiscuous mode when the wireless interface is added to the bridge). Not only does this waste processor cycles, it also leads to pollution of the Linux bridging table, as can be observed with the aid of the command brctl showmacs br0. In previous incarnations of the Ad Hoc mode bridging patch, in case of a multicast frame the RA was simply copied from the DA field. In the new version, the RA is set to the BSSMA, which is a multicast address that is unique to the IBSS. This allows receiving nodes to distinguish between 4-address multicast frames they should process and frames they can discard. The DA field still holds the actual multicast / broadcast address.

This patch is also believed to fix ticket #1648 for normal 3-address unicast frames.

Even though I tested the patch extensively myself, it would be good if others could exercise it as well and report their findings. If it appears not to be breaking anything, I would like to ask the developers to consider it for inclusion in trunk.

Signed-Off-By: Ronald in 't Velt, TNO ICT <Ronald.intVelt@tno.nl>