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.

 Sam