o80211s: (mac80211s) basic mesh interface support

include/net/mac80211.h +3 -0

 static int ieee80211_change_mtu(struct net_device *dev, int new_mtu)
 {
+	int meshhdrlen;
+	struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+

+EXPORT_SYMBOL(ieee80211_get_mesh_hdrlen);

+EXPORT_SYMBOL(ieee80211_new_mesh_header);

include/net/mac80211.h enum ieee80211_if_types { · line 477

Quoted 7 lines

include/net/mac80211.h +1 -0

@@ -474,6 +474,7 @@ enum ieee80211_if_types {
      IEEE80211_IF_TYPE_AP,
      IEEE80211_IF_TYPE_STA,
      IEEE80211_IF_TYPE_IBSS,
+     IEEE80211_IF_TYPE_MESH,

What happened to Dan's suggestion of calling this MESH_STA? And maybe in nl80211 as well? I might've missed something, was there a conclusion?

A mesh AP would have two interfaces, each with a different MAC address. One IF_TYPE_MESH, the other IF_TYPE_AP. Support for MAP, as you suggested, would be implemented in hostapd.

As far as I understand the specification, this
[different MAC address for the mesh interface] is not required. Since we currently have no drivers supporting multi-MAC operation, this is quite a severe limitation and the draft seems to allow MAP operation with a single address, cf. the description of the SSID element in 7.2.3.1 (Beacon frame format). ("Note: the SSID is a required IE in beacon frames. To avoid having non-mesh STAs [...]")

Therefore, I think that having a separate MAP type device would be beneficial because that allows hostapd to generate a beacon including an SSID, respond to probe requests and still be a mesh point on the same interface. The only way hostapd would have to be aware of this is that it needs to create a different type of interface and include the mesh information in the beacon.

Do you see anything precluding such operation? Some more logic would have to be provided to achieve the appropriate mesh broad/multicast vs. AP broad/multicast behaviour, of course, as described elsewhere wrt. mesh broad/multicast frames being broad/multicast to associated STAs.

Quoted 15 lines · Johannes Berg

As far as I understand the specification, this
[different MAC address for the mesh interface] is not required. Since we currently have no drivers supporting multi-MAC operation, this is quite a severe limitation and the draft seems to allow MAP operation with a single address, cf. the description of the SSID element in 7.2.3.1 (Beacon frame format). ("Note: the SSID is a required IE in beacon frames. To avoid having non-mesh STAs [...]")

Therefore, I think that having a separate MAP type device would be beneficial because that allows hostapd to generate a beacon including an SSID, respond to probe requests and still be a mesh point on the same interface. The only way hostapd would have to be aware of this is that it needs to create a different type of interface and include the mesh information in the beacon.

Quoted 4 lines

Do you see anything precluding such operation? Some more logic would have to be provided to achieve the appropriate mesh broad/multicast vs. AP broad/multicast behaviour, of course, as described elsewhere wrt. mesh broad/multicast frames being broad/multicast to associated STAs.

The issue of mesh beacons is an open discussion at TGs right now (and by now I mean this week, in the IEEE 802.11 plenary in Atlanta). It looks like a different mac address will be needed for the mesh interface if collocated with an AP. That will be necessary for security and to avoid conflicts with legacy equipment. In that case, the stack should generate the mesh beacons and hostapd generate the infrastructure beacons.

Anyway, I see no problem in renaming this IEEE80211_IF_TYPE_MESH_POINT (even though I just heard of a proposal to rename Mesh Points as Mesh Stations... )

Quoted 3 lines

Anyway, I see no problem in renaming this IEEE80211_IF_TYPE_MESH_POINT (even though I just heard of a proposal to rename Mesh Points as Mesh Stations... )

How concrete is that?

It could obviously be changed later but best to keep the code terminology consistent with the standards terminology unless the standards terminology is completely wack.

Quoted 2 lines

As far as I understand the specification, this [different MAC address for the mesh interface] is not required.

Quoted 5 lines

Since we currently have no drivers supporting multi-MAC operation, this is quite a severe limitation and the draft seems to allow MAP operation with a single address, cf. the description of the SSID element in 7.2.3.1 (Beacon frame format). ("Note: the SSID is a required IE in beacon frames. To avoid having non-mesh STAs [...]")

Quoted 4 lines

Therefore, I think that having a separate MAP type device would be beneficial because that allows hostapd to generate a beacon including an SSID, respond to probe requests and still be a mesh point on the same interface.

Quoted 2 lines

The only way hostapd would have to be aware of this is that it
needs to create a different type of interface and include the mesh information in the beacon.

Quoted 4 lines

Do you see anything precluding such operation? Some more logic would have to be provided to achieve the appropriate mesh broad/multicast vs. AP broad/multicast behaviour, of course, as described elsewhere wrt. mesh broad/multicast frames being broad/multicast to associated STAs.

The issue of mesh beacons is an open discussion at TGs right now (and by now I mean this week, in the IEEE 802.11 plenary in Atlanta). It looks like a different mac address will be needed for the mesh interface if collocated with an AP. That will be necessary for security and to avoid conflicts with legacy equipment. In that case, the stack should generate the mesh beacons and hostapd generate the infrastructure beacons.

Anyway, I see no problem in renaming this IEEE80211_IF_TYPE_MESH_POINT (even though I just heard of a proposal to rename Mesh Points as Mesh Stations... )

include/net/mac80211.h enum ieee80211_if_types { · line 477

Quoted 7 lines

include/net/mac80211.h +1 -0

@@ -474,6 +474,7 @@ enum ieee80211_if_types {
 	IEEE80211_IF_TYPE_AP,
 	IEEE80211_IF_TYPE_STA,
 	IEEE80211_IF_TYPE_IBSS,
+	IEEE80211_IF_TYPE_MESH,

What happened to Dan's suggestion of calling this MESH_STA? And maybe in nl80211 as well? I might've missed something, was there a conclusion?

Quoted 4 lines

include/net/mac80211.h +1 -1

 	/* FIX: what would be proper limits for MTU?
 	 * This interface uses 802.3 frames. */
-	if (new_mtu < 256 || new_mtu > IEEE80211_MAX_DATA_LEN - 24 - 6) {
+	if (new_mtu < 256 ||

include/net/mac80211.h

Quoted 4 lines

include/net/mac80211.h +1 -0

+		new_mtu > IEEE80211_MAX_DATA_LEN - 24 - 6 - meshhdrlen) {
 		printk(KERN_WARNING "%s: invalid MTU %d\n",
 		       dev->name, new_mtu);
 		return -EINVAL;

Are you sure this is appropriate? As the comment says, interface is 802.3 framed. Don't the 802.11 specifications usually keep the frame payload length and require the device to handle longer frames?

include/net/mac80211.h

Quoted 2 lines

include/net/mac80211.h +1 -0

+	atomic_t mesh_seqnum;

Hmm. Do we really need an atomic_t here?

include/net/mac80211.h

Quoted 10 lines

include/net/mac80211.h +9 -0

+	case IEEE80211_IF_TYPE_MESH:
+		if (!mesh_allocated) {
+			/* Allocate all mesh structures when creating the first
+			 * mesh interface.
+			 */
+			mesh_pathtbl_init();
+			mesh_allocated = 1;
+		}
+		/* fall thru */

Will there be other structures to allocate? Maybe we should instead push the "already" check into the _init()?

include/net/mac80211.h

Quoted 3 lines

include/net/mac80211.h +3 -0

+	/* TODO: check for expired neighbors, paths and frames to non resolved
+	 * hw addresses
+	 */

Seems dangerous to actually run the code w/o this, no?

include/net/mac80211.h

Quoted 4 lines

include/net/mac80211.h +2 -0

+	mgmt->u.beacon.beacon_int =
+		cpu_to_le16(local->hw.conf.beacon_int);

Hmm. This is interesting. The beacon interval is a pure beacon configuration after my patches, but here we're using it without having userspace set up a beacon. What do we do in the IBSS case?

include/net/mac80211.h

Quoted 5 lines

include/net/mac80211.h +5 -0

+static int o80211s_getmeshpath(struct sk_buff *skb, struct nlmsghdr *nlh,
+		void *arg)
+{
+	return 0;
+}

Uh huh. Why is this here? Should it be filled?

include/net/mac80211.h ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx) · line 235

Quoted 6 lines

include/net/mac80211.h +2 -0

@@ -230,6 +231,9 @@ ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx)
 	     (tx->fc & IEEE80211_FCTL_STYPE) != IEEE80211_STYPE_PROBE_REQ))
 		return TXRX_DROP;
 
+	if (tx->sdata->type == IEEE80211_IF_TYPE_MESH)
+		return TXRX_CONTINUE;

Is this right or should there be some other "is forwarded frame" check to go with this? I'm not sure but it seems that frames we send via the netdev need to be still checked? Or not because they're just injected into the mesh? I think I'm confused.

I think you should use RCU for the locking in the neighbour table. This code should (IIRC) be under rcu read-side lock already so the neighbour table reading would be lockless. Since updates are infrequent, RCU is a good tradeoff.

There wasn't such suggestion, we were talking about renaming interface state from IEEE80211_MESH to something more specific. I suggested _ACTIVE, _ON or something like that... any preferences? As for the interface name, we have discussed about how MAP would be a different interface type, so it would be a good idea to be more precise with the it. I would go for MESH_POINT though, to follow the nomenclature in the standard.

Quoted 4 lines

Quoted 4 lines

net/mac80211/ieee80211.c +1 -1

 	/* FIX: what would be proper limits for MTU?
 	 * This interface uses 802.3 frames. */
-	if (new_mtu < 256 || new_mtu > IEEE80211_MAX_DATA_LEN - 24 - 6) {
+	if (new_mtu < 256 ||

Quoted 8 lines

net/mac80211/ieee80211.c static void ieee80211_master_set_multicast_list(struct net_device *dev) · line 141

Quoted 4 lines

net/mac80211/ieee80211.c +1 -0

+		new_mtu > IEEE80211_MAX_DATA_LEN - 24 - 6 - meshhdrlen) {
 		printk(KERN_WARNING "%s: invalid MTU %d\n",
 		       dev->name, new_mtu);
 		return -EINVAL;

Are you sure this is appropriate? As the comment says, interface is 802.3 framed. Don't the 802.11 specifications usually keep the frame payload length and require the device to handle longer frames?

802.11s does not modify the PHY at all, and AFAIK does not impose any additional requirement on the devices. So regardless if the code already there was needed, it is necessary to decrease the MTU by meshhdrlen bytes. Another problem is that mesh headers do not always have the same length, but that will be dealt with when support for different length headers is added.

Quoted 5 lines

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

Quoted 3 lines

net/mac80211/ieee80211_sta.c +3 -0

+	/* TODO: check for expired neighbors, paths and frames to non resolved
+	 * hw addresses
+	 */

Seems dangerous to actually run the code w/o this, no?

No, right now we only add paths by manually from user space.

Quoted 7 lines

net/mac80211/mesh_pathtbl.c line 106

Quoted 5 lines

net/mac80211/mesh_pathtbl.c new file +5 -0

+static int o80211s_getmeshpath(struct sk_buff *skb, struct nlmsghdr *nlh,
+		void *arg)
+{
+	return 0;
+}

Uh huh. Why is this here? Should it be filled?

Of course. Please note this is work in progress. I guess I should return a ENOTSUPP instead.

Quoted 11 lines

net/mac80211/tx.c ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx) · line 235

Quoted 6 lines

net/mac80211/tx.c +2 -0

@@ -230,6 +231,9 @@ ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx)
 	     (tx->fc & IEEE80211_FCTL_STYPE) != IEEE80211_STYPE_PROBE_REQ))
 		return TXRX_DROP;
 
+	if (tx->sdata->type == IEEE80211_IF_TYPE_MESH)
+		return TXRX_CONTINUE;

Is this right or should there be some other "is forwarded frame" check to go with this? I'm not sure but it seems that frames we send via the netdev need to be still checked? Or not because they're just injected into the mesh? I think I'm confused.

I'm confused too. ieee80211_subif_start_xmit checks if the frame is forwarded, ieee80211_tx_h_check_assoc does not care about if the frame is forwarded or not. Since there is no interface-wide "association state" in mesh, the association check would always be true.

Quoted 4 lines

I think you should use RCU for the locking in the neighbour table. This code should (IIRC) be under rcu read-side lock already so the neighbour table reading would be lockless. Since updates are infrequent, RCU is a good tradeoff.

Updates are not that infrequent, every mesh path might be updated every few seconds (about 5 or 10). Would RCU be a good trade off in this situation?

This commit introduces mesh interface support for the mac80211 stack. It provides support for pre-802.11s frame format, static unicast forwarding, mesh beaconing, mesh statistics through debugfs.

Btw. I just reviewed draft 1.0 (currently have no access to later ones) and it talks a lot about probe responses but never when to send them. Is this clarified later and should it be implemented here? Or is that part of the "mesh AP" stuff that is removed?