Hi,

So ray@ pointed out that fragment handling in net80211 is broken. Yes,
802.11 fragments, not IP fragments. This is specific to ath, but any
driver using IFQ_ENQUEUE/IFQ_DEQUEUE is likely broken.

The 30 second summary goes something like this:

* frame ends up at ieee80211_start()
* .. this ends up at ieee80211_encap()
* .. this ends up being fragmented via ieee80211_fragment() into
multiple fragments.
* these are chained together via m->m_nextpkt, with them being marked as M_FRAG.

Now, comes the annoying bit:

* The parent if->if_transmit is called()
* .. which for ath is default, so it gets onto the ifnet send queue
via IFQ_ENQUEUE()
* .. and that macro clears m->m_nextpkt, totally dropping the rest of
the fragments. Yes, they leak.

Now even if you fix this, a similar problem in ath_start() exists:

* ath_start() uses IFQ_DEQUEUE() to grab a frame;
* this clears m->m_nextpkt before returning it;
* so.. the ath fragment processing function finds there's not enough
fragments (as the rest have been dropped) and it drops it.

So my question is - how the heck did this ever work? The behvaiour of
clearing m->m_nextpkt in IFQ_ENQUEUE/IFQ_DEQUEUE seems to have been
around since forever. What am I missing?

I'd really like to repair the fragment behaviour in net80211 so we can
TX/RX fragments again. Monthadar has a need for it for supporting
802.11s mesh (legacy) environments so I'd like to give that to him.

Thanks!



Adrian
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Reply via email to