d80211: Add software sequence support

Most hardware can keep track of sequence numbers themselves, unfortunately *most* doesn't cover all devices. ;) This patch will keep track of the (per-bss) sequence number if the flag IEEE80211_HW_SOFTWARE_SEQUENCE has been set.

net/d80211/ieee80211.c +12 -0

+static void ieee80211_include_sequence(struct net_device *dev,
+				       struct ieee80211_hdr *hdr)
+{
+	struct ieee80211_sta_bss *bss;
+	u8 *bssid = ieee80211_get_bssid(hdr, sizeof(*hdr));
+
+	bss = ieee80211_rx_bss_get(dev, bssid);
+	if (!bss)
+		return;
+
+       /*
+        * Set the sequence number for this frame.

Then the driver can just call it whenever it needs the sequence number for a frame. It'll need to be a bit smart about fragmentation but I think that's ok.

I may be radical, but I think that a lot of things hardware can do belong into library functions the driver can use instead of cluttering the stack with it.

Quoted 7 lines

Then the driver can just call it whenever it needs the sequence number for a frame. It'll need to be a bit smart about fragmentation but I think that's ok.

I may be radical, but I think that a lot of things hardware can do belong into library functions the driver can use instead of cluttering the stack with it.

I'm inclined to agree, FWIW...

Quoted 4 lines · Ivo van Doorn

Most hardware can keep track of sequence numbers themselves, unfortunately *most* doesn't cover all devices. ;) This patch will keep track of the (per-bss) sequence number if the flag IEEE80211_HW_SOFTWARE_SEQUENCE has been set.

Can this be a library function instead? Our TX path is already cluttered enough...

If we're going to switch to a library approach, let's do it all at once. I don't want some features requiring flags to toggle and others requiring a function to call.

If we're going to switch to a library approach, let's do it all at once. I don't want some features requiring flags to toggle and others requiring a function to call.

To be specific, I don't like the library approach when we can simply set a flag and let the stack handle it.

Can this be a library function instead? Our TX path is already cluttered enough...

I am not so sure that storing this information in struct ieee80211_sta_bss is correct. As far as I can tell, that is strictly for storing information scan results and beacon information. Nothing outside of ieee80211_sta.c uses it. struct sta_info or struct ieee80211_if_ap (sta interfaces have a pointer to the struct ieee80211_if_ap on the master device) may be a better choice. I think struct sta_info is the right one though there is a problem - it isn't allocated until a successful association.

Quoted 1 line

I am not so sure that storing this information in struct ieee80211_sta_bss

is

Quoted 1 line

correct. As far as I can tell, that is strictly for storing information

scan

Quoted 1 line

results and beacon information. Nothing outside of ieee80211_sta.c uses

it.

Quoted 1 line

struct sta_info or struct ieee80211_if_ap (sta interfaces have a pointer

to

Quoted 2 lines

the struct ieee80211_if_ap on the master device) may be a better choice. I think struct sta_info is the right one though there is a problem - it

isn't

Quoted 1 line

allocated until a successful association.

Thinking about it more, sdata should be the correct place. It's more per-interface thing than per-BSS (although the difference is small in this particular case).

Thinking about it more, sdata should be the correct place. It's more per-interface thing than per-BSS (although the difference is small in this particular case).

Quoted 3 lines · Jiri Benc

Thinking about it more, sdata should be the correct place. It's more per-interface thing than per-BSS (although the difference is small in this particular case).

...and thinking about it even more, that won't work with WDS.

Quoted 6 lines · Jiri Benc

Quoted 3 lines · Jiri Benc

Thinking about it more, sdata should be the correct place. It's more per-interface thing than per-BSS (although the difference is small in this particular case).

...and thinking about it even more, that won't work with WDS.

You mean storing the sequence counter per-interface won't work, or per-bss?

Quoted 10 lines · Ivo van Doorn

Quoted 6 lines · Jiri Benc

Quoted 3 lines · Jiri Benc

Thinking about it more, sdata should be the correct place. It's more per-interface thing than per-BSS (although the difference is small in this particular case).

...and thinking about it even more, that won't work with WDS.

You mean storing the sequence counter per-interface won't work, or per-bss?

Both.

When you have a WDS link and some other wireless interface at the same time, their source addresses are (in most cases) the same. You want to have the sequence control counter shared by them. Actually, it will probably work most of time even when they have different counters. The situation where it won't work is if you have two virtual interfaces, one in STA and second in WDS mode, both connected to the same AP. I can't figure out how this particular setup could be useful but it's generally not disallowed.

Anyway, using different counter for a WDS interface probably violates 802.11 (although it's not much specific in this case). I believe it will work in most cases, though.

Any ideas how to solve that?

Both.

When you have a WDS link and some other wireless interface at the same time, their source addresses are (in most cases) the same. You want to have the sequence control counter shared by them. Actually, it will probably work most of time even when they have different counters. The situation where it won't work is if you have two virtual interfaces, one in STA and second in WDS mode, both connected to the same AP. I can't figure out how this particular setup could be useful but it's generally not disallowed.

Anyway, using different counter for a WDS interface probably violates 802.11 (although it's not much specific in this case). I believe it will work in most cases, though.

Any ideas how to solve that?

Quoted 11 lines · Jiri Benc

Both.

When you have a WDS link and some other wireless interface at the same time, their source addresses are (in most cases) the same. You want to have the sequence control counter shared by them. Actually, it will probably work most of time even when they have different counters. The situation where it won't work is if you have two virtual interfaces, one in STA and second in WDS mode, both connected to the same AP. I can't figure out how this particular setup could be useful but it's generally not disallowed.

Quoted 5 lines

Anyway, using different counter for a WDS interface probably violates 802.11 (although it's not much specific in this case). I believe it will work in most cases, though.

Any ideas how to solve that?

Make the counter per-mac address?

Quoted 17 lines · Johannes Berg

Quoted 15 lines · Jiri Benc

Both.

When you have a WDS link and some other wireless interface at the same time, their source addresses are (in most cases) the same. You want to have the sequence control counter shared by them. Actually, it will probably work most of time even when they have different counters. The situation where it won't work is if you have two virtual interfaces, one in STA and second in WDS mode, both connected to the same AP. I can't figure out how this particular setup could be useful but it's generally not disallowed.

Anyway, using different counter for a WDS interface probably violates 802.11 (although it's not much specific in this case). I believe it will work in most cases, though.

Quoted 3 lines

Quoted 1 line

Any ideas how to solve that?

Make the counter per-mac address?

Wouldn't that be the same as per-interface?

Quoted 4 lines · Ivo van Doorn

Quoted 1 line · Johannes Berg

Make the counter per-mac address?

Wouldn't that be the same as per-interface?

Don't WDS interfaces have the same MAC as the corresponding AP interface?

Per-MAC address counters would work but it's another overhead we need to add (allocate a new reference-counted structure, put a pointer to it into sdata, correctly deal with it when MAC address changes).

I think we can live with the counter in sdata. It's not perfect but it should work for all useful cases. The only situation where it won't work I have been able to imagine is the case I described (STA and WDS with the same address) and this particular setup is currently being denied by d80211 (and it's not allowed by 802.11, btw).

If we consider this as a problem later, we can always change to per-MAC address counters or something as it's completely internal to the stack and no driver changes would be required.

Quoted 3 lines

If we consider this as a problem later, we can always change to per-MAC address counters or something as it's completely internal to the stack and no driver changes would be required.

Ok. I'm fine with putting it into the stack. I'll take Michael by the word though that he'll do dynamically registered tx handlers later ;)

So just to be clear, this patch does not need any tweaking anymore right?

Quoted 1 line · Ivo van Doorn

So just to be clear, this patch does not need any tweaking anymore right?

Just stick the counter in sdata if you haven't done so already. Should be fine once that's done.

Most hardware can keep track of sequence numbers themselves, unfortunately *most* doesn't cover all devices. ;) This patch will keep track of the (per-bss) sequence number if the flag IEEE80211_HW_SOFTWARE_SEQUENCE has been set.

This 3rd version of the patch has the sequence number stored in the ieee80211_sub_if_data structure.

Signed-off-by Ivo van Doorn <[email protected]>

---

include/net/mac80211.h +3 -0

index 82ea43f..e32e28a 100644
@@ -515,6 +515,9 @@ struct ieee80211_hw {
 	 * normal operation. */
 #define IEEE80211_HW_MONITOR_DURING_OPER (1<<9)
 
+	/* Does the HOST need to insert the frame sequence counter */
+#define IEEE80211_HW_SOFTWARE_SEQUENCE (1<<10)
+
 	/* please fill this gap when adding new flags */
 
 	/* calculate Michael MIC for an MSDU when doing hwcrypto */

net/mac80211/ieee80211.c +33 -1

index 577dbe3..79c2a60 100644
@@ -54,6 +54,20 @@ static u8 * ieee80211_get_bssid(struct ieee80211_hdr *hdr, size_t len);
 static int ieee80211_mgmt_start_xmit(struct sk_buff *skb,
 				     struct net_device *dev);
 
+static void ieee80211_include_sequence(struct ieee80211_sub_if_data *sdata,
+				       struct ieee80211_hdr *hdr)
+{
+	/*
+	 * Set the sequence number for this frame.
+	 */
+	hdr->seq_ctrl = cpu_to_le16(sdata->sequence & IEEE80211_SCTL_SEQ);
+
+	/*
+	 * Increase the sequence number.
+	 */
+	sdata->sequence = (sdata->sequence + 0x10) & IEEE80211_SCTL_SEQ;
+}
+
 struct ieee80211_key_conf *
 ieee80211_key_data2conf(struct ieee80211_local *local,
 			const struct ieee80211_key *data)

@@ -445,6 +459,7 @@ ieee80211_tx_h_fragment(struct ieee80211_txrx_data *tx)
 	size_t hdrlen, per_fragm, num_fragm, payload_len, left;
 	struct sk_buff **frags, *first, *frag;
 	int i;
+	u16 seq;
 	u8 *pos;
 	int frag_threshold = tx->local->fragmentation_threshold;
 

@@ -463,6 +478,7 @@ ieee80211_tx_h_fragment(struct ieee80211_txrx_data *tx)
 		goto fail;
 
 	hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREFRAGS);
+	seq = le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_SEQ;
 	pos = first->data + hdrlen + per_fragm;
 	left = payload_len - per_fragm;
 	for (i = 0; i < num_fragm - 1; i++) {

@@ -490,7 +506,7 @@ ieee80211_tx_h_fragment(struct ieee80211_txrx_data *tx)
 		memcpy(fhdr, first->data, hdrlen);
 		if (i == num_fragm - 2)
 			fhdr->frame_control &= cpu_to_le16(~IEEE80211_FCTL_MOREFRAGS);
-		fhdr->seq_ctrl = cpu_to_le16(i + 1);
+		fhdr->seq_ctrl = cpu_to_le16(seq + ((i + 1) & IEEE80211_SCTL_FRAG));
 		copylen = left > per_fragm ? per_fragm : left;
 		memcpy(skb_put(frag, copylen), pos, copylen);
 

@@ -900,6 +916,17 @@ ieee80211_tx_h_check_assoc(struct ieee80211_txrx_data *tx)
 	return TXRX_CONTINUE;
 }
 
+static ieee80211_txrx_result
+ieee80211_tx_h_sequence(struct ieee80211_txrx_data *tx)
+{
+	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)tx->skb->data;
+
+	if ((tx->local->hw.flags & IEEE80211_HW_SOFTWARE_SEQUENCE) &&
+	    ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control)) >= 24)
+		ieee80211_include_sequence(tx->sdata, hdr);
+
+	return TXRX_CONTINUE;
+}
 
 /* This function is called whenever the AP is about to exceed the maximum limit
  * of buffered frames for power saving STAs. This situation should not really

@@ -1770,6 +1797,10 @@ struct sk_buff * ieee80211_beacon_get(struct ieee80211_hw *hw, int if_id,
 	skb_reserve(skb, local->hw.extra_tx_headroom);
 	memcpy(skb_put(skb, bh_len), b_head, bh_len);
 
+	if (hw->flags & IEEE80211_HW_SOFTWARE_SEQUENCE)
+		ieee80211_include_sequence(sdata,
+			(struct ieee80211_hdr *)skb->data);
+
 	ieee80211_beacon_add_tim(local, ap, skb);
 
 	if (b_tail) {

@@ -4381,6 +4412,7 @@ static ieee80211_rx_handler ieee80211_rx_handlers[] =
 static ieee80211_tx_handler ieee80211_tx_handlers[] =
 {
 	ieee80211_tx_h_check_assoc,
+	ieee80211_tx_h_sequence,
 	ieee80211_tx_h_ps_buf,
 	ieee80211_tx_h_select_key,
 	ieee80211_tx_h_michael_mic_add,

net/mac80211/ieee80211_i.h +2 -1

index 9df8ef0..4b7c427 100644
@@ -317,6 +317,8 @@ struct ieee80211_sub_if_data {
 	int ieee802_1x; /* IEEE 802.1X PAE - drop packet to/from unauthorized
 			 * port */
 
+	u16 sequence;
+
 	/* Fragment table for host-based reassembly */
 	struct ieee80211_fragment_entry	fragments[IEEE80211_FRAGMENT_MAX];
 	unsigned int fragment_next;
-

To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines · Ivo van Doorn

Most hardware can keep track of sequence numbers themselves, unfortunately *most* doesn't cover all devices. ;) This patch will keep track of the (per-bss) sequence number if the flag IEEE80211_HW_SOFTWARE_SEQUENCE has been set.

The question has been asked (by Jouni), but I didn't see a good answer (maybe I missed it).
Why is this a flag at all? The sequence counter is such a trivial thing that having an extra conditional is just _more_ overhead. Why not simply calculate the seq all the time and let hardware override it, if it has the capability to do so? Calculation of the seq is cheap. No need to bloat code.

net/mac80211/ieee80211.c +5 -0

+	sdata->sequence = (sdata->sequence + 0x10) & IEEE80211_SCTL_SEQ;
+}
+
 struct ieee80211_key_conf *
 ieee80211_key_data2conf(struct ieee80211_local *local,
 			const struct ieee80211_key *data)

@@ -445,6 +459,7 @@ ieee80211_tx_h_fragment(struct ieee80211_txrx_data *tx)
 	size_t hdrlen, per_fragm, num_fragm, payload_len, left;
 	struct sk_buff **frags, *first, *frag;
 	int i;
+	u16 seq;
 	u8 *pos;
 	int frag_threshold = tx->local->fragmentation_threshold;
 

@@ -463,6 +478,7 @@ ieee80211_tx_h_fragment(struct ieee80211_txrx_data *tx)
 		goto fail;
 
 	hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREFRAGS);
+	seq = le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_SEQ;
 	pos = first->data + hdrlen + per_fragm;
 	left = payload_len - per_fragm;
 	for (i = 0; i < num_fragm - 1; i++) {