Hello list,
* Michael Renzmann <mrenzmann@...> [2007-08-18 19:12]:
> > The major difference between "0.9.3.1" and "trunk" is " use4addr = 1;"
> > after remove " use4addr = 1;" from "trunk", I find that ad-hoc mode
> > bridge can work. Remove " use4addr = 1;" seems not feasible; but it works.
>
> This should be fixed in trunk with r2657 (thanks, mentor), please try.
Even though 4-address-mode is not explicitly included in the 802.11 IBSS
specs, I don't see any reason not to let it remain in the driver,
especially when you consider the side effects of deactivating it with
r2657 and r2658:
the "performance issue" reported with ad-hoc WDS has one simple reason:
without use4addr=1, the ad-hoc interface is using the ethernet source
MAC as sender address - when you bridge the adhoc ath0 to some ethernet
card, that means you are sending frames with transmitter address != your
own MAC, thus you never get the ACKs and retry, retry, retry, ...
This also makes the AAR reduce the tx rate to the basic rate - even less
performance for the user.
use4addr appears as the perfect solution for this problem to me (just
imagine for a moment an ad-hoc distribution system in the style of
802.11s):
Receiver Address = NextHop (the one who shall ACK your frame)
Transmitter Address = your MAC (the ACK receiver)
Destination Address = final receiver behind NextHop
Source Address = the station on your bridge which sent the packet
Probably there is another problem in the receive path, which prevents
the whole thing from working in that way, but I'm going to investigate
it in the next weeks. Qualified bug reports and scenario descriptions
(including tcpdump traces from an external monitor station) are highly
appreciated.
Kind regards,
Georg
--
|| http://op-co.de ++ GCS/CM d? s: a-- C+++ UL+++ !P L+++ E--- W++ ++
|| gpg: 0x962FD2DE || N++ o? K- w---() O M V? PS+ PE-- Y+ PGP++ t* ||
|| Ge0rG: euIRCnet || 5 X+ R tv b+(+++) DI+(+++) D+ G e* h! r* !y+ ||
++ IRCnet OFTC OPN ||________________________________________________||
|