Date: Fri, 17 Feb 2012 00:53:12 -0800 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-net@freebsd.org Subject: net80211 - how the heck is M_FRAG (mbuf/net80211 fragments) supposed to work? Message-ID: <CAJ-Vmo=4vzSy5V8i0%2BVMXP8kT4XuoJkXYvwurnonmJjXRnNr=Q@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=4vzSy5V8i0%2BVMXP8kT4XuoJkXYvwurnonmJjXRnNr=Q>