[CUWiN-Dev] Re: Re: IBSS Split aka BSSID wars?

Ronald in 't Velt Ronald.intVelt at tno.nl
Thu Mar 1 13:09:14 CST 2007


Dave,

"David Young" <dyoung at pobox.com> wrote in message
news:20070202212728.GW31900 at che.ojctech.com...
> On Fri, Feb 02, 2007 at 05:48:12PM +0100, Ronald in 't Velt wrote:
>> If I can briefly revive this old thread: Is there any more information on
>> those bugs you fixed? Can you recall / retrieve what changes you made and
>> when this was (roughly)? I am using the Madwifi (ng) driver for Atheros
>> chipsets under Linux. I believe that the net80211 MAC-layer in that
>> driver
>> descends from the NetBSD one. I would like to check whether your fixes
>> are
>> also part of Madwifi now.
>
> I just scanned the NetBSD sources for changes that are relevant
> to IBSS merges, according to my recollection.  The changes are in
> sys/net80211/ieee80211_node.c and in src/sys/dev/ic/ath.c.
>

Many thanks for your elaborate answer and apologies for my very late
reaction. It took a while before I got around to having a look at this
again. I compared your modifications against recent Madwifi source code
(ieee80211_node.c only). The outcome is inconclusive: some changes seem to
have made it into Madwifi, for others I find no evidence. It looks like I
will have to delve deeper into the Madwifi sources to better understand IBSS
creation and merging. There have been reports recently of problems with
beaconing / TSF in IBSS mode:

http://article.gmane.org/gmane.linux.drivers.madwifi.devel/3901
http://madwifi.org/ticket/1033
http://madwifi.org/ticket/1093

Currently I am experimenting with a patch that changes the way in which the
BSSID is derived in IBSS. In my code, the BSSID is generated by applying a
hash function to the ESSID (string). This means that all nodes configured
with a given ESSID will set the same BSSID, even if they initially do not
'see' each other. Of course, this is non-standard, but sofar it seems to be
working pretty well. Basically, it is the same approach as presented here:
http://www.orbit-lab.org/wiki/HowTo/bssidFix , but using a proper hash
function (MD5).

Thanks again,
Ronald in 't Velt

P.S. I really liked your testing approach for revision 1.44 of ath.c. Too
bad there aren't any elevators at the site where I am doing this work.

> In src/sys/net80211/ieee80211_node.c:
>
> ----------------------------
> revision 1.46
> date: 2005/11/20 10:04:21;  author: dyoung;  state: Exp;  lines: +32 -23
> Repair adhoc mode.
>
>        1 Complete initialization of "faked up" ieee80211_nodes,
>          whose capabilities and other fields are wrong, when we
>          first receive a beacon or probe response from the
>          corresponding neighbor.  This entails factoring
>          ieee80211_init_neighbor out of ieee80211_add_neighbor.
>
>        2 In adhoc mode, ic->ic_bss is present in the neighbors
>          table, ic->ic_sta, and it is not necessarily the wrong
>          node on which to mark statistics for a rx'd packet.  Do
>          not reject ic->ic_bss and fake-up a new node without
>          comparing its MAC address with the address of the sender
>          in the rx'd packet.  This fixes a memory leak.
>
> ...
>
> ----------------------------
> revision 1.37
> date: 2005/01/04 00:56:52;  author: dyoung;  state: Exp;  lines: +4 -4
> branches:  1.37.2;  1.37.4;
> IBSS-merge clean-up, inspired by some Linux patches from Jon Anderson
> (mail at janderson.ca): remove ieee80211_ibss_merge's TSFT argument.
> Do the TSFT comparison in the drivers (ath, atw).  Remove a lot of
> extraneous debug statements from ieee80211_ibss_merge.
>
> Set the ieee80211_node's state to IEEE80211_STA_BSS after it's been
> copied to the ic_bss, not before.
>
> In struct ieee80211_node, make the ni_tstamp field a union of a
> uint64_t and the 8 TSF octets so that it's easier to compare a
> neighbor's TSF with the local TSF.
>
> Log IBSS merges (Greg Troxel's suggestion).  Also log IBSS creation.
> These are rare and important events that deserve to be logged.
>
>
> ************************
>
> In src/sys/dev/ic/ath.c:
>
> ----------------------------
> revision 1.68
> date: 2006/03/02 03:38:45;  author: dyoung;  state: Exp;  lines: +444 -194
> branches:  1.68.2;  1.68.4;
> Miscellaneous ath(4) and net80211 updates and bug-fixes coming from
> sam@ and various open source repositories:
>
> ath(4):
>
>        Ignore "phantom" beacon misses: should stabilize connections
>        to access points (no more ceaseless link-UP/DOWN indications).
>        Also, re-synchronize beacon timer using the TSF in the
>        first beacon received after joining a BSS---this should
>        also help suppress spurious beacon misses.  I am hopeful
>        that this will help ath(4) lossage reported by perry@ and
>        smb at .
>
> ...
>
> ----------------------------
> revision 1.44
> date: 2005/01/19 04:56:42;  author: dyoung;  state: Exp;  lines: +3 -3
> branches:  1.44.2;
> For a proper IBSS merge, we have to discard the old beacon packet,
> create and queue a new one that carries the new BSSID.  I mined
> net80211 in FreeBSD for the solution, which is to make an
> IEEE80211_S_RUN->IEEE80211_S_RUN state transition---ath_newstate
> discards the old beacon packet creates a new one by calling
> ath_beacon_alloc.
>
> I tested the merge as follows.  Starting at my desk on the second
> floor of the building where I work:
>
> soekris% ifconfig ath0 mediaopt adhoc ssid zzz chan 11 down
>
> powerbook% ifconfig rtw0 mediaopt adhoc ssid zzz chan 11 up
>
> soekris% sleep 25; ifconfig ath0 up
>
> I raced to the elevator with my Powerbook, pressed the "Down"
> button, got in, and pressed "Floor 1."  At the first floor:
>
> powerbook% ifconfig rtw0 | grep bssid
>        bssid 02:p:p:p:p:p chan 11
>
> I waited 25 seconds.  I pressed "Floor 2."  At Floor 2, I returned to my
> desk.
> I checked to make sure that the Soekris console read:
>
> soekris% ath0: creating bss 02:s:s:s:s:s
> ath0: bss merge 02:s:s:s:s:s -> 02:p:p:p:p:p
>
> 0:s:s:s:s:s is the Soekris' WLAN MAC.  0:p:p:p:p:p is the Powerbook's
> WLAN MAC.  Each created an ad hoc-mode BSSID from its WLAN MAC by
> OR'ing 0x2 with the first octet.
>
> My Powerbook created a network while the Soekris radio was off.
> The Soekris radio turned on while I was in the 802.11-impervious
> elevator with my Powerbook.  When I returned to the second floor,
> the Soekris "heard" beacons from my Powerbook as the elevator door
> opened.  Since the Powerbook's network was approximately 25 seconds
> older than the Soekris', and since it had the same SSID (zzz) as
> the Soekris', the Soekris merged with the Powerbook's network (by
> setting its BSSID) as it should.
> ----------------------------
> revision 1.43
> date: 2005/01/16 11:43:34;  author: dyoung;  state: Exp;  lines: +13 -3
> branches:  1.43.2;
> It's necessary to stop DMA on the beacon ring and reconfigure the
> beacon after an IBSS merge, or else beacons transmissions may not
> resume like we expect.  From Sam Leffler.
> ----------------------------
> revision 1.41
> date: 2005/01/04 00:56:51;  author: dyoung;  state: Exp;  lines: +21 -4
> IBSS-merge clean-up, inspired by some Linux patches from Jon Anderson
> (mail at janderson.ca): remove ieee80211_ibss_merge's TSFT argument.
> Do the TSFT comparison in the drivers (ath, atw).  Remove a lot of
> extraneous debug statements from ieee80211_ibss_merge.
>
> Set the ieee80211_node's state to IEEE80211_STA_BSS after it's been
> copied to the ic_bss, not before.
>
> In struct ieee80211_node, make the ni_tstamp field a union of a
> uint64_t and the 8 TSF octets so that it's easier to compare a
> neighbor's TSF with the local TSF.
>
> Log IBSS merges (Greg Troxel's suggestion).  Also log IBSS creation.
> These are rare and important events that deserve to be logged.
> ----------------------------
> revision 1.36
> date: 2004/08/10 01:03:52;  author: dyoung;  state: Exp;  lines: +71 -11
> IBSS fixes: get IBSS beacon generation right.  Merge with a same-SSID,
> same-channel IBSS.
>
>
> -- 
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
>






More information about the CU-Wireless-Dev mailing list