If I lower iv_fragthreshold to IEEE80211_FRAG_MIN and then ping with a data size that makes net80211 frame larger than threshold the frame is never sent. Freebsd seems to be stuck somewhere cause the ping program never print anything, quiting ping does show that packets have been sent but that is not true. Ping without -s option works. After a while (not sure when or how) I get these print out on console: # ping -s8192 192.168.5.12 PING 192.168.5.12 (192.168.5.12): 8192 data bytes arge0: Failed to allocate buffer ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! I tried with -s1024 and -s193 no frame sent, -s192 works fine. Fix: unknown How-To-Repeat: change (ieee80211_var.h): #define IEEE80211_FRAG_DEFAULT IEEE80211_FRAG_MAX to: #define IEEE80211_FRAG_DEFAULT IEEE80211_FRAG_MIN Then you need two ath wifi setup as STA and AP. Then: # ping -c 1 192.168.5.12 PING 192.168.5.12 (192.168.5.12): 56 data bytes 64 bytes from 192.168.5.12: icmp_seq=0 ttl=64 time=61.260 ms --- 192.168.5.12 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 61.260/61.260/61.260/0.000 ms # # ping -s8192 192.168.5.12 PING 192.168.5.12 (192.168.5.12): 8192 data bytes ^C --- 192.168.5.12 ping statistics --- 134 packets transmitted, 0 packets received, 100.0% packet loss RSPRO-MESH-11# ping -s8192 192.168.5.12 PING 192.168.5.12 (192.168.5.12): 8192 data bytes <long/random time> arge0: Failed to allocate buffer ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf!
Responsible Changed From-To: freebsd-bugs->freebsd-wireless Punt
The problem is .. well, annoying: * ieee80211_fragment() creates a fragment list by chaining mbufs together using m->m_nextpkt; * IFQ_DEQUEUE() (well, _IF_DEQUEUE()) clears m->m_nextpkt when the mbuf is being returned; * ath_start() uses IFQ_DEQUEUE() to dequeue a frame; * .. since it notes its a fragment, it punts it to ath_txfrag_setup(); * .. and ath_txfrag_setup(), finding m->m_nextpkt to be NULL, bails out with an error (since the fragment list is empty.) * ath_start() tosses the initial frame, and nothing is sent. Now it looks like the rest of the frames in the list are also unceremoniously ignored (since m->m_nextpkt is completely blanked out); which is likely the mbuf leak you noticed. Adrian
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Initially fixed in base r251014 and later rechecked in base r287197.