On Tue, Oct 25, 2005 at 09:35:06AM +0200, Konstantin KABASSANOV wrote:
> Greg,
> 
> Thanks for your reply. Of course I sent only a part of the wlanctl results,
> the part concerning this "strange" behaviour. I agree of course with your
> definition of BSSID, but I still don't understand why wlanctl must report a
> bssid address created from the mac address of this node. The real bssid
> comes from another node:
> 
> ath0: mac 00:02:6f:20:f7:e7 bss 02:02:6f:20:f7:e7
>         node flags 0001<bss>
>         ess <TEST123>
>         chan 36 freq 5180MHz flags 0140<ofdm,5GHz>
>         capabilities 0402<ibss,short slot-time>
>         beacon-interval 100 TU tsft 5222517 us
>         rates [*6.0] 9.0 *12.0 18.0 *24.0 36.0 48.0 54.0
>         assoc-id 0 assoc-failed 0 inactivity 300s
>         rssi 60 txseq 6384 rxseq 32

Konstantin,

You found a bug.  After an IBSS node is "promoted" to the BSS node
(ic->ic_bss), net80211 will never update its BSSID, timestamp
(tsft), etc., as it reads new beacons from the BSS.  The bug is in
ieee80211_recv_mgmt, near line 2003, where net80211 inappropriately
compares address 2 with the BSSID in IBSS mode,

>                if (ni == ic->ic_bss &&
>                    !IEEE80211_ADDR_EQ(wh->i_addr2, ni->ni_bssid)) {
>#ifdef IEEE80211_DEBUG  
>                        if (ieee80211_msg_scan(ic))
>                                dump_probe_beacon(subtype, 1,
>                                    wh->i_addr2, chan, bchan, capinfo,
>                                    bintval, erp, ssid, country);#endif  

creates a new entry,

>                        /*
>                         * Create a new entry.  If scanning the entry goes
>                         * in the scan cache.  Otherwise, be particular when
>                         * operating in adhoc mode--only take nodes marked
>                         * as ibss participants so we don't populate our
>                         * neighbor table with unintersting sta's.
>                         */
>                        if ((ic->ic_flags & IEEE80211_F_SCAN) == 0) {
>                                if ((capinfo & IEEE80211_CAPINFO_IBSS) == 0)
>                                        return;
>                                ni = ieee80211_fakeup_adhoc_node(&ic->ic_sta,
>                                                wh->i_addr2);
>                        } else
>                                ni = ieee80211_dup_bss(&ic->ic_scan, wh->i_addr2);

and updates that.  That explains why the tsft is so low:   

> ath0: mac 00:02:6f:20:f7:e7 bss 02:02:6f:20:f7:e7
>         node flags 0001<bss>
>         ess <TEST123>
>         chan 36 freq 5180MHz flags 0140<ofdm,5GHz>
>         capabilities 0402<ibss,short slot-time>
>         beacon-interval 100 TU tsft 5222517 us
>         rates [*6.0] 9.0 *12.0 18.0 *24.0 36.0 48.0 54.0
>         assoc-id 0 assoc-failed 0 inactivity 300s
>         rssi 60 txseq 6384 rxseq 32

That also helps explain why I have *two* nodes in my node table for
this node:

ath0: mac 00:02:6f:20:b2:3f bss 02:02:6f:21:0a:ac
        node flags 0001<bss>
        ess <cuwireless.net>
        chan 11 freq 2462MHz flags 00e0<cck,ofdm,2.4GHz>
        capabilities 0022<ibss,short preamble>
        beacon-interval 100 TU tsft 18446742750255920381 us
        rates [*1.0] *2.0 5.5 11.0
        assoc-id 0 assoc-failed 0 inactivity 300s
        rssi 11 txseq 43079 rxseq 23392
ath0: mac 00:02:6f:20:b2:3f bss 02:02:6f:21:0a:ac
        node flags 0000
        ess <cuwireless.net>
        chan 11 freq 2462MHz flags 00e0<cck,ofdm,2.4GHz>
        capabilities 0022<ibss,short preamble>
        beacon-interval 100 TU tsft 18446742758895101060 us
        rates *1.0 *2.0 5.5 [11.0]
        assoc-id 0 assoc-failed 0 inactivity 300s
        rssi 3 txseq 53 rxseq 34816

The tsft on the <bss> node hasn't changed the whole time I wrote this
email; the other has changed.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933