From: Dan Williams <dcbw@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Bruno Randolf <bruno@thinktube.com>,
mcgrof@gmail.com, jirislaby@gmail.com, mickflemm@gmail.com,
linux-wireless@vger.kernel.org, linville@tuxdriver.com,
Ivo van Doorn <ivdoorn@gmail.com>
Subject: Re: [PATCH] mac80211: enable IBSS merging
Date: Wed, 23 Jan 2008 12:22:26 -0500 [thread overview]
Message-ID: <1201108946.4929.49.camel@localhost.localdomain> (raw)
In-Reply-To: <1201099729.3454.17.camel@johannes.berg>
On Wed, 2008-01-23 at 15:48 +0100, Johannes Berg wrote:
> > enable IBSS cell merging. if an IBSS beacon with the same ESSID and=
a TSF
> > higher than the local TSF (mactime) is received, we have to join it=
s BSSID.
>=20
> Can you back that up with standard references? I see no such requirem=
ent
> in the standard text. I can see that under some circumstances this ma=
y
> be desirable, but maybe not.
>=20
> In fact, this seems to *break* standard behaviour, as per 11.1.3.1:
> (emphasis mine)
The way I understood Ad-Hoc to work was that if you weren't using the
SSID + BSSID as somebody else, you weren't part of that adhoc network.
Ad-Hoc + roaming isn't supported and is even less defined, which is wha=
t
this patch would enable IIUC. When joining an adhoc network, your
card/driver must scan around to find the SSID + (optionally) BSSID of
that adhoc network. If it finds one that matches criteria, it joins
that adhoc network, which means using the same BSSID. If it doesn't, i=
t
creates a new adhoc network with a generated BSSID and the specified
SSID.
If this patch were applied, then you'd pretty quickly get split adhoc
networks where some people were automatically moved to a different BSSI=
D
and the rest are left on the old BSSID (maybe missed a beacon, or
whatever), and therefore can't talk to each other. If only because
mac80211 would jump adhoc BSSIDs, while all other drivers (including
fullmac parts) would not.
A cell is identified uniquely by the combination of BSSID + SSID,
nothing less. You don't combine infrastructure networks of the same
SSID and a different BSSID, nor does this happen for adhoc.
Dan
> When a STA starts a BSS, that STA shall determine the BSSID o=
f
> the BSS. If the BSSType indicates an infrastructure BSS, then
> the STA shall start an infrastructure BSS and the BSSID shall=
be
> equal to the STA=E2=80=99s dot11StationID. ***The value of th=
e BSSID
> shall remain unchanged***, even if the value of dot11StationI=
D
> is changed after the completion of the MLME-START.request. If
> the BSSType indicates an IBSS, the STA shall start an IBSS, a=
nd
> the BSSID shall be an individual locally administered IEEE MA=
C
> address as defined in 5.2 of IEEE Std 802-1990. The remaining=
46
> bits of that MAC address shall be a number selected in a mann=
er
> that minimizes the probability of STAs generating the same
> number, even when those STAs are subjected to the same initia=
l
> conditions.
>=20
> Remember that BSSIDs, *not* SSIDs are used to identify BSSes uniquely=
=2E
>=20
> Of course you could argue that "merging" is simply tearing down the o=
wn
> and then joining the other IBSS.
>=20
> Comments on the code now.
>=20
> > --- a/net/mac80211/ieee80211_sta.c
> > +++ b/net/mac80211/ieee80211_sta.c
> > @@ -80,6 +80,9 @@ static void ieee80211_rx_bss_put(struct net_devic=
e *dev,
> > struct ieee80211_sta_bss *bss);
> > static int ieee80211_sta_find_ibss(struct net_device *dev,
> > struct ieee80211_if_sta *ifsta);
> > +static int ieee80211_sta_join_ibss(struct net_device *dev,
> > + struct ieee80211_if_sta *ifsta,
> > + struct ieee80211_sta_bss *bss);
>=20
> No way, order the code properly, this mess needs to be cleaned up not
> added to.
> =20
> > - if (bss->probe_resp && beacon) {
> > + if (sdata->vif.type !=3D IEEE80211_IF_TYPE_IBSS &&
> > + bss->probe_resp && beacon) {
> > /* Do not allow beacon to override data from Probe Response. */
>=20
> Ahem. Comment update required.
>=20
> > + /* check if we need to merge IBSS */
>=20
> Could use a plural, but whatever.
>=20
> > + if (sdata->vif.type =3D=3D IEEE80211_IF_TYPE_IBSS && beacon &&
> > + !local->sta_sw_scanning && !local->sta_hw_scanning &&
> > + mgmt->u.beacon.capab_info & WLAN_CAPABILITY_IBSS &&
> > + memcmp(elems.ssid, sdata->u.sta.ssid, sdata->u.sta.ssid_len) =
=3D=3D 0) {
>=20
> I think that needs a check "&& ssid_len" or something. Someone's boun=
d
> to try making an IBSS with a hidden SSID and we really don't want tha=
t
> to work.
>=20
> > +#ifdef CONFIG_MAC80211_IBSS_DEBUG
> > + static unsigned long last_tsf_debug;
> > +#endif
>=20
> Let's just get rid of that, it's not usable with multiple devices.
>=20
> > + if (rx_status->flag & RX_FLAG_TSFT)
> > + mactime =3D rx_status->mactime;
> > + else {
> > + mactime =3D -1LLU;
> > + printk(KERN_WARNING "%s: IBSS mode needs mactime for "
> > + "beacons\n", dev->name);
>=20
> Very bad, you'll be flooded by this when others send beacons. Also, I
> doubt its truthfulness.
>=20
> > + printk(KERN_DEBUG "%s: beacon TSF higher than local TSF"
> > + " -> IBSS merge with BSSID %s\n",
> > + dev->name, print_mac(mac, mgmt->bssid));
>=20
> No way. At the very least you need to ratelimit this.
>=20
> johannes
-
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-01-23 17:28 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-18 12:52 [PATCH] mac80211: enable IBSS merging Bruno Randolf
2008-01-20 10:17 ` Luis R. Rodriguez
2008-01-20 10:43 ` Ivo van Doorn
2008-01-21 1:52 ` bruno randolf
2008-01-21 16:05 ` Ivo van Doorn
2008-01-22 19:47 ` Luis R. Rodriguez
2008-01-22 19:54 ` Ivo van Doorn
2008-01-22 20:32 ` Luis R. Rodriguez
2008-01-22 20:51 ` Ivo van Doorn
2008-01-23 1:59 ` [ath5k-devel] " bruno randolf
2008-01-22 23:16 ` Adam Baker
2008-01-22 23:25 ` Ivo van Doorn
2008-01-23 14:49 ` Johannes Berg
2008-01-24 5:51 ` bruno randolf
2008-01-21 1:57 ` bruno randolf
2008-01-23 14:48 ` Johannes Berg
2008-01-23 17:22 ` Dan Williams [this message]
2008-01-24 3:49 ` bruno randolf
2008-01-24 3:26 ` bruno randolf
2008-01-24 16:55 ` Johannes Berg
2008-01-25 8:01 ` bruno randolf
2008-02-02 23:22 ` Luis R. Rodriguez
2008-02-05 1:50 ` bruno randolf
2008-02-05 1:56 ` Luis R. Rodriguez
2008-02-06 10:01 ` Johannes Berg
2008-02-06 4:34 ` Jouni Malinen
2008-02-06 18:33 ` Luis R. Rodriguez
2008-02-06 20:10 ` John W. Linville
2008-02-07 3:58 ` Jouni Malinen
2008-02-08 9:22 ` Luis R. Rodriguez
2008-02-12 2:00 ` bruno randolf
2008-02-15 1:06 ` Luis R. Rodriguez
2008-02-15 1:40 ` bruno randolf
2008-02-07 3:52 ` Jouni Malinen
2008-02-08 9:10 ` Luis R. Rodriguez
2008-01-24 5:43 ` bruno randolf
2008-01-24 8:51 ` Kalle Valo
2008-01-24 14:27 ` Johannes Berg
2008-01-24 14:30 ` Johannes Berg
2008-01-25 6:16 ` bruno randolf
-- strict thread matches above, loose matches on Subject: below --
2008-02-05 11:08 [PATCH 2/2] " Johannes Berg
2008-02-06 2:49 ` [PATCH] " Bruno Randolf
2008-02-06 23:52 ` Johannes Berg
2008-02-08 9:25 ` Luis R. Rodriguez
2008-02-12 3:25 ` bruno randolf
2008-02-12 9:50 ` Johannes Berg
2008-02-14 6:19 ` bruno randolf
2008-02-14 14:12 ` Johannes Berg
2008-02-12 9:52 ` Johannes Berg
2008-02-14 10:19 ` bruno randolf
2008-02-08 9:41 Joerg Pommnitz
2008-02-15 15:09 [PATCH 3/3] " Johannes Berg
2008-02-16 2:29 ` [PATCH] " Bruno Randolf
2008-02-17 9:11 ` Johannes Berg
2008-02-18 1:42 ` bruno randolf
2008-02-18 11:15 ` Johannes Berg
2008-02-18 2:03 ` bruno randolf
2008-02-18 11:16 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1201108946.4929.49.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=bruno@thinktube.com \
--cc=ivdoorn@gmail.com \
--cc=jirislaby@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mcgrof@gmail.com \
--cc=mickflemm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.