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"