On Sat, 2009-10-24 at 05:12 +0200, Björn Smedman wrote:
> >> diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
> >> compat-wireless-2009-10-21/net/mac80211/tx.c
> >> @@ -1445,7 +1445,7 @@
> >> if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
> >> continue;
> >> if (compare_ether_addr(tmp_sdata->dev->dev_addr,
> >> - hdr->addr2)) {
> >> + hdr->addr2) == 0) {
> >> dev_hold(tmp_sdata->dev);
> >> dev_put(sdata->dev);
> >> sdata = tmp_sdata;
> >
> > This does indeed look like a typo. Though, I'm not sure how this would
> > have caused a regression between compat-wireless-2009-06-02 and
> > compat-wireless-2.6.32-rc1. The incorrect compare_ether_addr() use seems
> > to be there in the original commit that added this code
> > (25d834e16294c8dfd923dae6bdb8a055391a99a5 from September 12, 2008)..
>
> Interesting puzzle. :) It looks like there was a complementary bug
> (the pointer hdr was set to point len_rthdr * sizeof(struct
> ieee80211_hdr) bytes into the skbuff) in that commit:
> ...
> + len_rthdr = ieee80211_get_radiotap_len(skb->data);
> + hdr = (struct ieee80211_hdr *)skb->data + len_rthdr;
> ...
> So the frame source address used to be compared with random data which
> was likely to result in inequality, causing the first ap interface to
> be "found" and the code to work as expected. I guess the pointer bug
> was fixed somewhere between 2006-06-02 and now "causing" the sequence
> number problem.
Heh, indeed, interesting. I remember somebody fixing that, but was
unaware of the second bug (obviously).
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
