From nobody@FreeBSD.org  Tue Feb 14 19:17:17 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 7D1F01065677
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Feb 2012 19:17:17 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 6C39C8FC24
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Feb 2012 19:17:17 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q1EJHH6e089582
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 14 Feb 2012 19:17:17 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q1EJHHN3089581;
	Tue, 14 Feb 2012 19:17:17 GMT
	(envelope-from nobody)
Message-Id: <201202141917.q1EJHHN3089581@red.freebsd.org>
Date: Tue, 14 Feb 2012 19:17:17 GMT
From: Monthadar <monthadar@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [ath][net80211] Ping with data length more than iv_fragthreshold
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         165149
>Category:       kern
>Synopsis:       [ath] [net80211] Ping with data length more than iv_fragthreshold
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-wireless
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 14 19:20:12 UTC 2012
>Closed-Date:    
>Last-Modified:  Wed Feb 15 06:20:10 UTC 2012
>Originator:     Monthadar
>Release:        Current
>Organization:
>Environment:
mips:mipseb
>Description:
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.
>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!
>Fix:
unknown

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless 
Responsible-Changed-By: adrian 
Responsible-Changed-When: Wed Feb 15 06:13:29 UTC 2012 
Responsible-Changed-Why:  
Punt 


http://www.freebsd.org/cgi/query-pr.cgi?pr=165149 

From: Adrian Chadd <adrian@freebsd.org>
To: bug-followup@FreeBSD.org, monthadar@gmail.com
Cc:  
Subject: Re: kern/165149: [ath] [net80211] Ping with data length more than iv_fragthreshold
Date: Tue, 14 Feb 2012 22:16:31 -0800

 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
>Unformatted:
