mac80211: enable IBSS merging

net/mac80211/ieee80211_sta.c +5 -0

+
+       /* check if we need to merge IBSS */
+       if (sdata->vif.type == IEEE80211_IF_TYPE_IBSS && beacon &&
+           !local->sta_sw_scanning && !local->sta_hw_scanning &&
+           mgmt->u.beacon.capab_info & WLAN_CAPABILITY_IBSS &&

Adding Johill and Michael as they are maintainers of mac80211 and they need to review this. Please add them on further mac80211 patches.

Note to driver authors: zd1211rw, rt2x00 drivers and adm8211 will need to set mactime if they want IBSS merge to work as this functionality would be added with this. I believe all other drivers set it, but didn't do a thorough grep.

Hi,

Quoted 3 lines

Adding Johill and Michael as they are maintainers of mac80211 and they need to review this. Please add them on further mac80211 patches.

Quoted 4 lines

Note to driver authors: zd1211rw, rt2x00 drivers and adm8211 will need to set mactime if they want IBSS merge to work as this functionality would be added with this. I believe all other drivers set it, but didn't do a thorough grep.

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

one workaround could be to simply use the current TSF at the time in the tasklet or interrupt handler (to be more close to the actual rx time). this should be sufficient to catch most cases where an IBSS merge is necessary - usually the beacon's TSF will be much higher than the local TSF.

Hi,

Quoted 4 lines

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

Quoted 4 lines

one workaround could be to simply use the current TSF at the time in the tasklet or interrupt handler (to be more close to the actual rx time). this should be sufficient to catch most cases where an IBSS merge is necessary - usually the beacon's TSF will be much higher than the local TSF.

Should the driver to this, or should mac80211 handle that?

Personally I think it is something for the mac80211 layer since the driver will give what it can, and can be sure that it is what mac80211 expects instead of drivers interpreting what mac80211 might want as replacement.
If mac80211 needs the TSF value when no mac time is given, it could just use the get_tsf() callback function to the driver to get the substitute. When the get_tsf() callback is not provided, then mac80211 can complain about missing information.

Quoted 10 lines

Quoted 8 lines

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

one workaround could be to simply use the current TSF at the time in the tasklet or interrupt handler (to be more close to the actual rx time). this should be sufficient to catch most cases where an IBSS merge is necessary - usually the beacon's TSF will be much higher than the local TSF.

Should the driver to this, or should mac80211 handle that?

The driver should if it has access to some the mactime of the received packet otherwise yes -- I think mac80211 can handle this using the supplied get_tsf().

Quoted 7 lines

Personally I think it is something for the mac80211 layer since the driver will give what it can, and can be sure that it is what mac80211 expects instead of drivers interpreting what mac80211 might want as replacement.
If mac80211 needs the TSF value when no mac time is given, it could just use the get_tsf() callback function to the driver to get the substitute. When the get_tsf() callback is not provided, then mac80211 can complain about missing information.

Agreed, how about something like this modified to Bruno's patch:

(quoted diff) +13 -0

+               if (rx_status->flag & RX_FLAG_TSFT)
+                       mactime = rx_status->mactime;
+               else {
+                       if (!local->ops->get_tsf) {
+                          WARN_ON(1);
+                          mactime = -1LLU;
+                          if (net_ratelimit())
+                             printk(KERN_WARNING "%s: cannot determine if "
+                                   "IBSS merge is required", dev->name);
+                      }
+                      else {
+                           if (net_ratelimit())
+                             printk("Could not get detailed timestamp

of beacon "
+ during reception, using the
driver's TSF timer for mactime\n")

net/mac80211/ieee80211_sta.c +3 -0

+                           mactime = local->ops->get_tsf(local_to_hw(local));
+                   }
+               }

We could just not support IBSS for driver's without a get_tsf(). Thoughts?

Hi,

Quoted 45 lines

Quoted 10 lines

Quoted 8 lines

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

one workaround could be to simply use the current TSF at the time in the tasklet or interrupt handler (to be more close to the actual rx time). this should be sufficient to catch most cases where an IBSS merge is necessary - usually the beacon's TSF will be much higher than the local TSF.

Should the driver to this, or should mac80211 handle that?

The driver should if it has access to some the mactime of the received packet otherwise yes -- I think mac80211 can handle this using the supplied get_tsf().

Quoted 7 lines

Personally I think it is something for the mac80211 layer since the driver will give what it can, and can be sure that it is what mac80211 expects instead of drivers interpreting what mac80211 might want as replacement.
If mac80211 needs the TSF value when no mac time is given, it could just use the get_tsf() callback function to the driver to get the substitute. When the get_tsf() callback is not provided, then mac80211 can complain about missing information.

Agreed, how about something like this modified to Bruno's patch:

(quoted diff) +13 -0

+               if (rx_status->flag & RX_FLAG_TSFT)
+                       mactime = rx_status->mactime;
+               else {
+                       if (!local->ops->get_tsf) {
+                          WARN_ON(1);
+                          mactime = -1LLU;
+                          if (net_ratelimit())
+                             printk(KERN_WARNING "%s: cannot determine if "
+                                   "IBSS merge is required", dev->name);
+                      }
+                      else {
+                           if (net_ratelimit())
+                             printk("Could not get detailed timestamp

of beacon "
+ during reception, using the
driver's TSF timer for mactime\n")

(quoted diff) +3 -0

+                           mactime = local->ops->get_tsf(local_to_hw(local));
+                   }
+               }

Quoted 1 line

We could just not support IBSS for driver's without a get_tsf(). Thoughts?

I am not sure if we should print error warning messages when the mactime is not provided. But other then that I agree with the above change, as it would allow rt2x00 to use the IBSS syncing. :)

Quoted 3 lines

I am not sure if we should print error warning messages when the mactime is not provided. But other then that I agree with the above change, as it would allow rt2x00 to use the IBSS syncing. :)

Ah yes, ignore my printks and instead replace them with better comments :)

I still think we should inform the user if the user switches to IBSS at some point, perhaps better during interface addition if their driver's IBSS mode is going to have some issues. How about we add to the enum ieee80211_hw_flags a "IEEE80211_HW_RX_MACTIME". Then we can warn accordingly during ieee80211_if_add() if the interface type is IBSS"

* If driver supports IEEE80211_HW_RX_MACTIME we don't warn anything
* If IEEE80211_HW_RX_MACTIME is not supported and get_tsf() is implemented inform user IBSS merge may not behave accurately
* If IEEE80211_HW_RX_MACTIME is not supported and get_tsf() is not implemented warn IBSS merge will not work

We could add:

static inline u64 __approx_mactime(struct ieee80211_local *local) {
   BUG_ON(!local || !local->ops);
   return (local->ops->get_tsf) ?

local->ops->get_tsf(local_to_hw(local)) : -1LLU;
}

Then in ieee80211_rx_bss_info() we can do something like:

Quoted 18 lines · Ivo van Doorn

Hi,

Quoted 16 lines

Quoted 11 lines

Quoted 9 lines

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

one workaround could be to simply use the current TSF at the time in the tasklet or interrupt handler (to be more close to the actual rx time). this should be sufficient to catch most cases where an IBSS merge is necessary - usually the beacon's TSF will be much higher than the local TSF.

Should the driver to this, or should mac80211 handle that?

The driver should if it has access to some the mactime of the received packet otherwise yes -- I think mac80211 can handle this using the supplied get_tsf().

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Personally I think it is something for the mac80211 layer since the driver will give what it can, and can be sure that it is what mac80211 expects instead of drivers interpreting what mac80211 might want as replacement. If mac80211 needs the TSF value when no mac time is given, it could just use the get_tsf() callback function to the driver to get the substitute. When the get_tsf() callback is not provided, then mac80211 can complain about missing information.

I still think we should inform the user if the user switches to IBSS at some point, perhaps better during interface addition if their driver's IBSS mode is going to have some issues. How about we add to the enum ieee80211_hw_flags a "IEEE80211_HW_RX_MACTIME". Then we can warn accordingly during ieee80211_if_add() if the interface type is IBSS"

* If driver supports IEEE80211_HW_RX_MACTIME we don't warn anything
* If IEEE80211_HW_RX_MACTIME is not supported and get_tsf() is implemented inform user IBSS merge may not behave accurately
* If IEEE80211_HW_RX_MACTIME is not supported and get_tsf() is not implemented warn IBSS merge will not work

We could add:

static inline u64 __approx_mactime(struct ieee80211_local *local) {
   BUG_ON(!local || !local->ops);
   return (local->ops->get_tsf) ?

local->ops->get_tsf(local_to_hw(local)) : -1LLU;
}

Then in ieee80211_rx_bss_info() we can do something like:

Hi,

Quoted 24 lines

Quoted 11 lines

Quoted 9 lines

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

one workaround could be to simply use the current TSF at the time in the tasklet or interrupt handler (to be more close to the actual rx time). this should be sufficient to catch most cases where an IBSS merge is necessary - usually the beacon's TSF will be much higher than the local TSF.

Should the driver to this, or should mac80211 handle that?

The driver should if it has access to some the mactime of the received packet otherwise yes -- I think mac80211 can handle this using the supplied get_tsf().

Quoted 7 lines

Personally I think it is something for the mac80211 layer since the driver will give what it can, and can be sure that it is what mac80211 expects instead of drivers interpreting what mac80211 might want as replacement. If mac80211 needs the TSF value when no mac time is given, it could just use the get_tsf() callback function to the driver
to get the substitute. When the get_tsf() callback is not provided, then mac80211 can complain about missing information.

Quoted 16 lines

Quoted 16 lines

Quoted 11 lines

Quoted 9 lines

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

one workaround could be to simply use the current TSF at the time in the tasklet or interrupt handler (to be more close to the actual rx time). this should be sufficient to catch most cases where an IBSS merge is necessary - usually the beacon's TSF will be much higher than the local TSF.

Should the driver to this, or should mac80211 handle that?

The driver should if it has access to some the mactime of the received packet otherwise yes -- I think mac80211 can handle this using the supplied get_tsf().

Quoted 9 lines

Quoted 8 lines

Quoted 7 lines

Personally I think it is something for the mac80211 layer since the driver will give what it can, and can be sure that it is what mac80211 expects instead of drivers interpreting what mac80211 might want as replacement. If mac80211 needs the TSF value when no mac time is given, it could just use the get_tsf() callback function to the driver
to get the substitute. When the get_tsf() callback is not provided, then mac80211 can complain about missing information.

I see one problem with this. At the moment rt2x00 doesn't implement get_tsf for USB devices. In the case of RT73 this is because mac80211 requires get_tsf to be atomic which precludes waiting for a USB device to reply to a request. Ivo has got an implementation in the code but it is disabled as the fact it sleeps was causing bugs. Presumably other USB devices would have the same problem.

I'm not sure if the code path for IBSS merging would require an atomic version, I'm guessing it wouldn't. If so do we need to consider whether to either have both get_tsf and get_tsf_atomic or have a flag to get_tsf indicating if it can sleep if it needs to?

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

Quoted 3 lines

Then there is a problem for rt2x00. Since the mactime isn't known. rt2400pci is the _only_ device which has a RX_END_TIME field in the RX descriptor.

I don't think it's required for IBSS to function, only for this from my POV dubious "merge" functionality.

Adding Johill and Michael as they are maintainers of mac80211 and they need to review this. Please add them on further mac80211 patches.

Quoted 14 lines

net/mac80211/ieee80211_sta.c +6 -0

+
+       /* check if we need to merge IBSS */
+       if (sdata->vif.type == 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)

== 0) { +#ifdef CONFIG_MAC80211_IBSS_DEBUG

net/mac80211/ieee80211_sta.c +7 -0

+               static unsigned long last_tsf_debug;
+#endif
+               if (rx_status->flag & RX_FLAG_TSFT)
+                       mactime = rx_status->mactime;
+               else {
+                       mactime = -1LLU;
+                       printk(KERN_WARNING "%s: IBSS mode needs mactime

Quoted 1 line

for " + "beacons\n", dev->name);

Does this merit a WARN_ON() ? This essentially will prevent IBSS merges for drivers that haven't set mactime yet.

Quoted 10 lines

net/mac80211/rx.c +0 -0

index 6cc1e7e..5617e17 100644
@@ -1609,7 +1609,10 @@ static int prepare_for_handlers(struct

ieee80211_sub_if_data *sdata, case IEEE80211_IF_TYPE_IBSS:

                if (!bssid)
                        return 0;

net/mac80211/rx.c +1 -1

-               if (!ieee80211_bssid_match(bssid, sdata->u.sta.bssid)) {
+               if ((rx->fc & IEEE80211_FCTL_FTYPE) ==

Quoted 2 lines

IEEE80211_FTYPE_MGMT && + (rx->fc &
IEEE80211_FCTL_STYPE) == IEEE80211_STYPE_BEACON)

Since we are letting all beacons through how about adding a check for ssid on ieee80211_rx_bss_info()?

(memcmp(elems.ssid, sdata->u.sta.ssid, sdata->u.sta.ssid_len) == 0)

Just not sure exactly we'd check for it yet.

Quoted 3 lines

net/mac80211/rx.c +2 -0

+           mgmt->u.beacon.capab_info & WLAN_CAPABILITY_IBSS &&
+           memcmp(elems.ssid, sdata->u.sta.ssid, sdata->u.sta.ssid_len)

== 0)

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 its BSSID.

Quoted 1 line

enable IBSS cell merging. if an IBSS beacon with the same ESSID and=

Quoted 1 line

higher than the local TSF (mactime) is received, we have to join it=

=20
Can you back that up with standard references? I see no such requirem=

in the standard text. I can see that under some circumstances this ma=

be desirable, but maybe not.
=20
In fact, this seems to *break* standard behaviour, as per 11.1.3.1:
(emphasis mine)

When a STA starts a BSS, that STA shall determine the BSSID o=

the BSS. If the BSSType indicates an infrastructure BSS, then the STA shall start an infrastructure BSS and the BSSID shall=

equal to the STA=E2=80=99s dot11StationID. ***The value of th=

shall remain unchanged***, even if the value of dot11StationI=

is changed after the completion of the MLME-START.request. If the BSSType indicates an IBSS, the STA shall start an IBSS, a=

the BSSID shall be an individual locally administered IEEE MA=

address as defined in 5.2 of IEEE Std 802-1990. The remaining=

bits of that MAC address shall be a number selected in a mann=

that minimizes the probability of STAs generating the same number, even when those STAs are subjected to the same initia=

conditions.
=20
Remember that BSSIDs, *not* SSIDs are used to identify BSSes uniquely=

=20
Of course you could argue that "merging" is simply tearing down the o=

and then joining the other IBSS.
=20
Comments on the code now.
=20

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_put(struct net_devic=

Quoted 3 lines

net/mac80211/ieee80211_sta.c +0 -0

@@ -80,6 +80,9 @@ static void ieee80211_rx_bss_put(struct net_devic=

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_put(struct net_device *dev, · line 85

Quoted 6 lines

net/mac80211/ieee80211_sta.c +3 -0

                                 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

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 1935

Quoted 4 lines

net/mac80211/ieee80211_sta.c +2 -1

-	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

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2054

Quoted 1 line

net/mac80211/ieee80211_sta.c +1 -0

+	/* check if we need to merge IBSS */

=20
Could use a plural, but whatever.
=20

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev,

Quoted 4 lines

net/mac80211/ieee80211_sta.c +4 -0

+	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) =

=20
I think that needs a check "&& ssid_len" or something. Someone's boun=

to try making an IBSS with a hidden SSID and we really don't want tha=

to work.
=20

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2061

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+#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

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2067

Quoted 6 lines

net/mac80211/ieee80211_sta.c +6 -0

+		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

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2085

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+			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

Quoted 8 lines · Johannes Berg

Quoted 3 lines

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 its BSSID.

Can you back that up with standard references? I see no such requirement in the standard text. I can see that under some circumstances this may be desirable, but maybe not.

Quoted 2 lines

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 what 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, it 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 BSSID 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.

Quoted 1 line

enable IBSS cell merging. if an IBSS beacon with the same ESSID and=

Quoted 1 line

higher than the local TSF (mactime) is received, we have to join it=

Quoted 1 line

BSSID.

Can you back that up with standard references? I see no such requirem=

in the standard text. I can see that under some circumstances this ma=

be desirable, but maybe not.

In fact, this seems to *break* standard behaviour, as per 11.1.3.1:
(emphasis mine)

When a STA starts a BSS, that STA shall determine the BSSID o=

the BSS. If the BSSType indicates an infrastructure BSS, then the STA shall start an infrastructure BSS and the BSSID shall=

equal to the STA=E2=80=99s dot11StationID. ***The value of th=

shall remain unchanged***, even if the value of dot11StationI=

is changed after the completion of the MLME-START.request.

If=20
the BSSType indicates an IBSS, the STA shall start an IBSS, a=

the BSSID shall be an individual locally administered IEEE MA=

address as defined in 5.2 of IEEE Std 802-1990. The remaining=

bits of that MAC address shall be a number selected in a mann=

that minimizes the probability of STAs generating the same number, even when those STAs are subjected to the same initia=

conditions.

Comments on the code now.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_put(struct net_devic=

Quoted 3 lines

net/mac80211/ieee80211_sta.c +0 -0

@@ -80,6 +80,9 @@ static void ieee80211_rx_bss_put(struct net_devic=

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_put(struct net_device *dev, · line 85

Quoted 6 lines

net/mac80211/ieee80211_sta.c +3 -0

 *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);

No way, order the code properly, this mess needs to be cleaned up not added to.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 1935

Quoted 4 lines

net/mac80211/ieee80211_sta.c +2 -1

-	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. */

Ahem. Comment update required.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev,

Quoted 4 lines

net/mac80211/ieee80211_sta.c +4 -0

+	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) =

Quoted 1 line

{

I think that needs a check "&& ssid_len" or something. Someone's boun=

to try making an IBSS with a hidden SSID and we really don't want tha=

to work.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2061

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+#ifdef CONFIG_MAC80211_IBSS_DEBUG
+		static unsigned long last_tsf_debug;
+#endif

Let's just get rid of that, it's not usable with multiple devices.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2067

Quoted 6 lines

net/mac80211/ieee80211_sta.c +6 -0

+		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);

Very bad, you'll be flooded by this when others send beacons. Also, I doubt its truthfulness.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2085

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+			printk(KERN_DEBUG "%s: beacon TSF higher than local TSF"
+				" -> IBSS merge with BSSID %s\n",
+				dev->name, print_mac(mac, mgmt->bssid));

No way. At the very least you need to ratelimit this.

i can see now how you could interpret this as only applying to timers, but i think that does just not make sense - why would you want to sync timers and adapt beacon intervals if you don't share the same BSSID?

i agree that the standard is quite ambigious when it comes to IBSS, but practically speaking, it is necessary to merge IBSS cells most of the time if you want to have IBSS working as expected. therefore i tend to interpret the ambigious parts of the standard in a way that will improve functionality.

please see my last post where i suggest to use:

(quoted diff) +9 -0

+               if (rx_status->flag & RX_FLAG_TSFT)
+                       /* in order for correct IBSS merging we need mactime*/
+                       mactime = rx_status->mactime;
+               else if (local && local->ops && local->ops->get_tsf)
+                       /* second best option: get current TSF */
+                       mactime = local->ops->get_tsf(local_to_hw(local));
+               else
+                       /* can't merge without knowing the TSF */
+                       mactime = -1LLU;

instead.

Quoted 3 lines

i can see now how you could interpret this as only applying to timers, but i think that does just not make sense - why would you want to sync timers and adapt beacon intervals if you don't share the same BSSID?

Hmm. Well I thought that was pretty much just for optimising performance but now that I think about it again...

Quoted 5 lines

i agree that the standard is quite ambigious when it comes to IBSS, but practically speaking, it is necessary to merge IBSS cells most of the time if you want to have IBSS working as expected. therefore i tend to interpret the ambigious parts of the standard in a way that will improve functionality.

I think "working as expected" is stretching it a bit ;) How do you expect IBSS to work?

I'd expect only the simplest use case from it:
start IBSS on one station and have another one in the vicinity find it while scanning and join it. That works regardless of merging or not.

Quoted 12 lines

please see my last post where i suggest to use:

(quoted diff) +2 -0

+               if (rx_status->flag & RX_FLAG_TSFT)
+                       /* in order for correct IBSS merging we need

mactime*/ + mactime = rx_status->mactime;

(quoted diff) +3 -0

+               else if (local && local->ops && local->ops->get_tsf)
+                       /* second best option: get current TSF */
+                       mactime =

local->ops->get_tsf(local_to_hw(local)); + else

(quoted diff) +2 -0

+                       /* can't merge without knowing the TSF */
+                       mactime = -1LLU;

Quoted 1 line

instead.

Not sure. That's a bit on a fine line, if you have a slow device get_tsf() might be well off and this could trigger a BSSID change in both stations.

Quoted 7 lines · On Friday 25 January 2008 01:55:04 Johannes Berg wrote:

Quoted 3 lines

i can see now how you could interpret this as only applying to timers, but i think that does just not make sense - why would you want to sync timers and adapt beacon intervals if you don't share the same BSSID?

Hmm. Well I thought that was pretty much just for optimising performance but now that I think about it again...

Quoted 8 lines

Quoted 5 lines

i agree that the standard is quite ambigious when it comes to IBSS, but practically speaking, it is necessary to merge IBSS cells most of the time if you want to have IBSS working as expected. therefore i tend to interpret the ambigious parts of the standard in a way that will improve functionality.

I think "working as expected" is stretching it a bit ;) How do you expect IBSS to work?

i think it's a reasonable expectation from a users point of view that two or more IBSS nodes using the same ESSID on the same channel can communicate with each other, regardless of when and where they were configured.

Quoted 3 lines

I'd expect only the simplest use case from it:
start IBSS on one station and have another one in the vicinity find it while scanning and join it. That works regardless of merging or not.

this is probably a valid, but a most conservative interpretation of the standard, which makes IBSS practically unusable in many (or most) occasions.

i guess you have never actually used IBSS much. otherwise you would know from experience that your simplest use case practically rarely happens. usually you have situations where you miss the others BSS while scanning and end up with 2 different BSSIDs. or what happens if there is a third station within station 2's reach but out of range for station 1? sta2 will adopt the BSSID of sta3, but sta1 will not and start a new BSSID. so not even your simplest use case of two newly started stations will just work (without ibss merge). examples and scenarios are endless, do you want me to continue? ;)

also i am not inventing this "non-standard merge". it is *not* non-standard, it's just not directly obvious from reading the standard.

IBSS merges are done like this by various cards and drivers: prism54 does the same (in firmware), hostap driver did it like this (probably does but i haven't used it in quite a while), the broadcom driver in openwrt acts like this, madwifi merges like this (ups, maybe i shouldn't have said that ;)) and so on...

aren't there any other serious IBSS users out there who can support this case and confirm that we need IBSS merge functionality?

Sure ACK. Also as was stated, even with IBSS merge functionality working you could up with nodes splitting up due to missing the "leader" beacon due to interference or even strange radio node problems. A solution to this we implemented at Orbit with MadWifi was that instead of generating "random" BSSIDs you'd create one based on the hash of the SSID [1]. This ensures that nodes with identical SSIDs end up with identical BSSIDs, regardless of any strange problems. Technically from what I have gathered this doesn't break the specs but would prevent this split-IBSS problem. I actually like to see this technique added into mac80211 too.

[1] http://www.orbit-lab.org/wiki/HowTo/bssidFix

Quoted 11 lines · On Sunday 03 February 2008 08:22:12 Luis R. Rodriguez wrote:

Sure ACK. Also as was stated, even with IBSS merge functionality working you could up with nodes splitting up due to missing the "leader" beacon due to interference or even strange radio node problems. A solution to this we implemented at Orbit with MadWifi was that instead of generating "random" BSSIDs you'd create one based on the hash of the SSID [1]. This ensures that nodes with identical SSIDs end up with identical BSSIDs, regardless of any strange problems. Technically from what I have gathered this doesn't break the specs but would prevent this split-IBSS problem. I actually like to see this technique added into mac80211 too.

Quoted 1 line

[1] http://www.orbit-lab.org/wiki/HowTo/bssidFix

this looks like a good idea to avoid many ibss merge problems, and it could be really useful to have that (maybe as an option?) in mac80211. but unless we have ibss merge functionality you won't be able to join older networks (higher TSF) which don't use that scheme, so we still need that to be able to communicate with other ("standard") drivers.

i guess the general question for mac80211 is: do we want and allow more liberal interpretations of the standard concerning IBSS mode or do we strictly stick with the "book"?

in my opinion these "extensions" are necessary in order to make IBSS mode useful at all and therefore we need them! and as long as they are able to interoperate with other drivers in IBSS mode i don't see a problem.

Quoted 4 lines

A solution to this we implemented at Orbit with MadWifi was that instead of generating "random" BSSIDs you'd create one based on the hash of the SSID [1].

this looks like a good idea to avoid many ibss merge problems, and it could be really useful to have that (maybe as an option?) in mac80211. but unless we have ibss merge functionality you won't be able to join older networks (higher TSF) which don't use that scheme, so we still need that to be able to communicate with other ("standard") drivers.

problems. A solution to this we implemented at Orbit with MadWifi was that instead of generating "random" BSSIDs you'd create one based on the hash of the SSID [1]. This ensures that nodes with identical SSIDs end up with identical BSSIDs, regardless of any strange problems.

Technically from what I have gathered this doesn't break the specs but would prevent this split-IBSS problem. I actually like to see this technique added into mac80211 too.

[1] http://www.orbit-lab.org/wiki/HowTo/bssidFix

Quoted 4 lines · Luis R. Rodriguez

problems. A solution to this we implemented at Orbit with MadWifi was that instead of generating "random" BSSIDs you'd create one based on the hash of the SSID [1]. This ensures that nodes with identical SSIDs end up with identical BSSIDs, regardless of any strange problems.

How does that work with multiple channels?

The patch did not seem to do
more than just use a very weak "hash" of the SSID to generate the BSSID.

In other words, I would assume it leaves IBSS STAs on whatever channel they end up selecting, i.e., in separate groups, unless all STAs are forced to use the same channel by not allowing them to initialize the IBSS on other channels.

This would also likely require hardcoding the
STAs not to allow merging to other BSSIDs should there be any such (i.e., any STA that does not implement this hack).

Quoted 5 lines

Technically from what I have gathered this doesn't break the specs but would prevent this split-IBSS problem. I actually like to see this technique added into mac80211 too.

[1] http://www.orbit-lab.org/wiki/HowTo/bssidFix

I don't see how this alone would either prevent the split-IBSS problem

or be compliant with the IEEE 802.11 standard. The change in this patch makes it likely to get same BSSID for different IBSS since the first six octets of the SSID is used as the BSSID. That would not be very desirable..

Furthermore, it is unlikely to work well with STA implementations that do not implement the identical mechanism for generating the BSSID.

The BSSID generation as a hash from SSID does not sound like something that would match the requirements of IEEE 802.11 11.1.6 ("a number selected in a manner that minimizes the probability of STAs generating the same number") since it is actually maximizing that probablity for the case of same SSID ;-).

As far as joining of separate STA groups in an IBSS (same SSID) is concerned, 11.1.4 seems to indicate that the STA in IBSS shall adopt _all_ parameters (i.e., also BSSID and channel) contained in the Beacon frame when the Timestamp field of the received Beacon is later than the STA's own TSF timer. This seems to be a requirement for supporting merging of separate IBSS groups..

Actually hearing a Beacon from another
channel may be an issue, though,

but at least as far as separate groups
using different BSSIDs, but same SSID, on the same channel is concerned, the merging behavior seems to be defined in the standard.

Quoted 5 lines · Jouni Malinen

The BSSID generation as a hash from SSID does not sound like something that would match the requirements of IEEE 802.11 11.1.6 ("a number selected in a manner that minimizes the probability of STAs generating the same number") since it is actually maximizing that probablity for the case of same SSID ;-).

Heh, good catch :)

FWIW, that wouldn't be the first time we (i.e. Linux) chose to do something that did not completely comply with a standard. If it interoperates with other equipment and is good for users, I don't think picky standard compliance is worthwhile.

Please note that I am not really taking a stand in favor of this ATM, only asserting that blind standard compliance is not a good reason to NAK it IMHO.

Quoted 4 lines · John W. Linville

FWIW, that wouldn't be the first time we (i.e. Linux) chose to do something that did not completely comply with a standard. If it interoperates with other equipment and is good for users, I don't think picky standard compliance is worthwhile.

Sure, there are cases where this is reasonable.

Quoted 3 lines

Please note that I am not really taking a stand in favor of this ATM, only asserting that blind standard compliance is not a good reason to NAK it IMHO.

In this case, standard compliance is certainly not the only concern I have. I'm worried about interoperability with non-mac80211 implementations. If mac80211 were to hardcoded the BSSID for IBSS and refuse to change it no matter what (i.e., behave against the IEEE 802.11 standard), IBSS would not interoperate with any other implementation if the other implementation happens to be the creator of the IBSS..

Same issues shows up (but in somewhat less frequent form) in an IBSS splitting up and re-joining. In order to allow the STAs using other implementation (no BSSID hacks) to join the IBSS, mac80211 will need to be prepared to change the BSSID (or use some much more questionable hacks to make sure it is always the mac80211-STA that wins in the selection of which BSSID will survive.. ;-).

Quoted 12 lines · Jouni Malinen

Quoted 4 lines · John W. Linville

FWIW, that wouldn't be the first time we (i.e. Linux) chose to do something that did not completely comply with a standard. If it interoperates with other equipment and is good for users, I don't think picky standard compliance is worthwhile.

Sure, there are cases where this is reasonable.

Quoted 3 lines

Please note that I am not really taking a stand in favor of this ATM, only asserting that blind standard compliance is not a good reason to NAK it IMHO.

Quoted 6 lines

In this case, standard compliance is certainly not the only concern I have. I'm worried about interoperability with non-mac80211 implementations. If mac80211 were to hardcoded the BSSID for IBSS and refuse to change it no matter what (i.e., behave against the IEEE 802.11 standard), IBSS would not interoperate with any other implementation if the other implementation happens to be the creator of the IBSS..

OK so you're saying that some people might actually expect that when using the same SSID and same channel in close vicinity they'd get separate BSSIDs generated? If so I don't see why people would expect this functionality as a feature, I think this is more of a problem than an expected result of how the standard is designed.

Quoted 6 lines

Same issues shows up (but in somewhat less frequent form) in an IBSS splitting up and re-joining. In order to allow the STAs using other implementation (no BSSID hacks) to join the IBSS, mac80211 will need to be prepared to change the BSSID (or use some much more questionable hacks to make sure it is always the mac80211-STA that wins in the selection of which BSSID will survive.. ;-).

How would the IBSS be split up to generate a new BSSID? If you are part of an IBSS and you don't see anyone generate a beacon between the random backoff time you simply generate it, but the BSSID would still be the same.

Quoted 33 lines · On Friday 08 February 2008 18:22:52 Luis R. Rodriguez wrote:

Quoted 12 lines · Jouni Malinen

Quoted 4 lines · John W. Linville

FWIW, that wouldn't be the first time we (i.e. Linux) chose to do something that did not completely comply with a standard. If it interoperates with other equipment and is good for users, I don't think picky standard compliance is worthwhile.

Sure, there are cases where this is reasonable.

Quoted 3 lines

Please note that I am not really taking a stand in favor of this ATM, only asserting that blind standard compliance is not a good reason to NAK it IMHO.

Quoted 6 lines

In this case, standard compliance is certainly not the only concern I have. I'm worried about interoperability with non-mac80211 implementations. If mac80211 were to hardcoded the BSSID for IBSS and refuse to change it no matter what (i.e., behave against the IEEE 802.11 standard), IBSS would not interoperate with any other implementation if the other implementation happens to be the creator of the IBSS..

OK so you're saying that some people might actually expect that when using the same SSID and same channel in close vicinity they'd get separate BSSIDs generated? If so I don't see why people would expect this functionality as a feature, I think this is more of a problem than an expected result of how the standard is designed.

Quoted 6 lines

Same issues shows up (but in somewhat less frequent form) in an IBSS splitting up and re-joining. In order to allow the STAs using other implementation (no BSSID hacks) to join the IBSS, mac80211 will need to be prepared to change the BSSID (or use some much more questionable hacks to make sure it is always the mac80211-STA that wins in the selection of which BSSID will survive.. ;-).

Quoted 4 lines

How would the IBSS be split up to generate a new BSSID? If you are part of an IBSS and you don't see anyone generate a beacon between the random backoff time you simply generate it, but the BSSID would still be the same.

i think the point here is that we still need to be prepared to merge IBSS (i.e. switch to another BSSID when we receive a beacon with an older TSF) no matter how we generate our own BSSID in the first place.

using a hash of the BSSID and channel would reduce the necessity to merge IBSS for mac80211 drivers but we still need to be able to join older IBSS from other drivers.

Quoted 3 lines

i think the point here is that we still need to be prepared to merge
IBSS (i.e. switch to another BSSID when we receive a beacon with an older TSF) no matter how we generate our own BSSID in the first place.

Well that is still possible.

Quoted 3 lines

using a hash of the BSSID and channel would reduce the necessity to
merge IBSS for mac80211 drivers but we still need to be able to join older IBSS from other drivers.

Sure, how is it that this prevents that?

Yes I see your point, this is definitely an issue, unless of course the driver/stack is configured to default to use a specific channel by default. But regardless its a problem.

Well the idea is that if it misses the timer from the leader it'll try to create the IBSS but will end up using the same BSSID as the leader would have, eventually causing a merge amongst the nodes. So you would not merge unless its with the same BSSID.

I haven't run the test myself but I am informed this hack helps to try to solve the issue with 400 nodes on IBSS mode.

Quoted 3 lines · Luis R. Rodriguez

Yes I see your point, this is definitely an issue, unless of course the driver/stack is configured to default to use a specific channel by default. But regardless its a problem.

It doesn't really help even if the driver/stack would be configured to default to a specific channel. This has to work with other implementations, too.

Hardcoding BSSID based on SSID may be fine for
most cases when a new IBSS is created, but still, the implementation will need to allow this to be changed when merging with other parts of the IBSS since those other parts may not implement this type of hack.

I'm somewhat concerned about the possibility of getting the same BSSID on different channels, though. Using the same BSSID for different groups is not really a very good solution.. Including the channel number in the hash data would resolve this concern.

Quoted 4 lines

Well the idea is that if it misses the timer from the leader it'll try to create the IBSS but will end up using the same BSSID as the leader would have, eventually causing a merge amongst the nodes. So you would not merge unless its with the same BSSID.

I'm not completely what the "misses the timer from the leader" is referring to or even what this "leader" would be in context of IBSS. Anyway, the implementation has to merge regardless of what BSSID is used (i.e., SSID match is enough).

Quoted 2 lines

I haven't run the test myself but I am informed this hack helps to try to solve the issue with 400 nodes on IBSS mode.

Sure, if you can control all the STAs in the IBSS. That just is not the case in general and Linux wireless stack must not be designed with the view point of all STAs following the exact same rules (unless those rules are based on a required standard behavior)..

Taken into account that we should really implement proper IBSS merge to allow interoperation with non-mac80211 implementations, I don't know how much of a benefit this BSSID=hash(SSID,chan) mechanism would really provide.

If it can be shown that the IBSS merges in a large network are not stable,

this could of course be helpful and I don't think I would object it as long as the BSSID is going to end up being same only on the same channel and the mac80211 implementation allows the BSSID to be changed if a Beacon frame is received with a larger timestamp value than the local TSF timer.

Comments on the code now.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_put(struct net_device · line 85

Quoted 9 lines

net/mac80211/ieee80211_sta.c +3 -0

@@ -80,6 +80,9 @@ static void ieee80211_rx_bss_put(struct net_device
 *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);

No way, order the code properly, this mess needs to be cleaned up not added to.

Quoted 5 lines

net/mac80211/ieee80211_sta.c +4 -0

+	if (sdata->vif.type == 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) == 0)

{

I think that needs a check "&& ssid_len" or something. Someone's bound to try making an IBSS with a hidden SSID and we really don't want that to work.

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2085

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+			printk(KERN_DEBUG "%s: beacon TSF higher than local TSF"
+				" -> IBSS merge with BSSID %s\n",
+				dev->name, print_mac(mac, mgmt->bssid));

No way. At the very least you need to ratelimit this.

Quoted 4 lines

Quoted 4 lines

net/mac80211/ieee80211_sta.c +0 -0

@@ -80,6 +80,9 @@ static void ieee80211_rx_bss_put(struct net_device
 *dev, struct ieee80211_sta_bss *bss); static int

Quoted 8 lines

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_put(struct net_device *dev, · line 85

Quoted 5 lines

net/mac80211/ieee80211_sta.c +3 -0

 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);

No way, order the code properly, this mess needs to be cleaned up not added to.

Do you care to explain what's so bad about function declarations?

Quoted 3 lines

Do you care to explain what's so bad about function declarations?

I don't know about Johannes, but I just see them as unnecessary burden. If I change some parameters in a function, I'll get a compiler error and only after that I realise to change the declaration as well.

With public (ie. non-static) functions it's a different issue, because I know that there's a declaration in the header file. But with static functions this is not the case.

Quoted 4 lines

I think that needs a check "&& ssid_len" or something. Someone's bound to try making an IBSS with a hidden SSID and we really don't want that to work.

why? i know, hidden SSIDs are pretty useless but if somedody wants them... why would you want to make extra effort so it does not work?

Quoted 5 lines

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2085

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+			printk(KERN_DEBUG "%s: beacon TSF higher than local TSF"
+				" -> IBSS merge with BSSID %s\n",
+				dev->name, print_mac(mac, mgmt->bssid));

No way. At the very least you need to ratelimit this.

well, it should not happen very often, and for debugging i would like to see this case. would

if (CONFIG_MAC80211_IBSS_DEBUG || net_ratelimit())
printk(KERN_DEBUG "%s: beacon TSF higher than "

be ok with you?

Quoted 6 lines

Quoted 3 lines

I think that needs a check "&& ssid_len" or something. Someone's bound to try making an IBSS with a hidden SSID and we really don't want that to work.

why? i know, hidden SSIDs are pretty useless but if somedody wants them... why would you want to make extra effort so it does not work?

Uh, I think you should rethink your question. Consider two different hidden-SSID IBSSes.

Quoted 8 lines

Quoted 5 lines

net/mac80211/ieee80211_sta.c static void ieee80211_rx_bss_info(struct net_device *dev, · line 2085

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+			printk(KERN_DEBUG "%s: beacon TSF higher than local TSF"
+				" -> IBSS merge with BSSID %s\n",
+				dev->name, print_mac(mac, mgmt->bssid));

No way. At the very least you need to ratelimit this.

well, it should not happen very often, and for debugging i would like to see this case. would

Well, "should" is pretty soft. It can also be trivially triggered as a DOS attack by sending beacons with fake timestamps.

Quoted 4 lines

if (CONFIG_MAC80211_IBSS_DEBUG || net_ratelimit())
printk(KERN_DEBUG "%s: beacon TSF higher than "

be ok with you?

Maybe && would be better?