On Wed, Nov 10, 2004 at 10:14:27AM -0800, Sam Leffler wrote:
> On Wednesday 10 November 2004 08:24 am, David Young wrote:
> > On Wed, Nov 10, 2004 at 09:30:56AM -0500, David Hudak wrote:
> > > Hi,
> > >
> > > Question for the group:  I am using NetBSD 2.0 with an Atheros 5212
> > > radio.  I put the radio in monitor mode and do tcpdump -D IEEE802_11...
> > > I have seen the following...
> > > 1.  beacons
> > > 2.  probe requests, probe responses
> > > 3.  auth requests, auth responses
> > > 4.  association requests, association responses
> > > 5.  data frames
> > >
> > > But, I have not seen any 802.11 ACKs.  Is this expected behavior?  I
> > > know that they are there, since a sniff with KisMAC using an original
> > > Apple Airport (i.e., Orinoco) card shows them.
> >
> > That's a bug.  There are a few problems, beginning with this check
> > in ath_rx_proc,
> >
> >                 len = ds->ds_rxstat.rs_datalen;
> >                 if (len < IEEE80211_MIN_LEN) {
> >                         DPRINTF(ATH_DEBUG_RECV, ("%s: short packet %d\n",
> >                                 __func__, len));
> >                         sc->sc_stats.ast_rx_tooshort++;
> >                         goto rx_next;
> >                 }
> >
> > It looks to me like that check can be postponed until a few lines later
> > when the WEP header is stripped.  These days, it's ok to pass a short
> > frame to net80211, which taps the IEEE802_11 DLT.
> >
> > (Now that I am looking at ath_rx_proc, I'd sure like to revamp its
> > radiotap section.)
> 
> This all works on Linux and/or my freebsd p4 tree.  If you're not in 
> promiscuous mode be sure to also enable rx of control frames.  But presumably 
> you did this already if you're handling PSPOLL frames.

Is your FreeBSD p4 tree publically available somewhere?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933