[Prism54-devel] Re: Spurious disassociations in prismGT STA <-> prism2.5 AP setup

Sun Feb 8 09:53:11 PST 2004

On Sunday 08 February 2004 18:22, Jouni Malinen wrote:
> On Sun, Feb 08, 2004 at 01:29:45PM +0200, vda at port.imtp.ilyichevsk.odessa.ua wrote:
> > I setup another prism54 card in monitor mode.
> > To my joy, both tcpdump and wlansniff (it's
> > coming with hostap) were able to capture traffic.
> > I have evidence in the form of tcpdump logs
> > that it's prism54 to blame. It sends disassociation
> > requests. You may find log below sig.
>
> It would be useful to get the transmit rate of the packets from the
> prism54 station. I haven't used it in monitor mode, but I would assume
> this information would be available somehow. ?If any of the frames it
> sends is using ERP rates (i.e., rates not included in IEEE 802.11b),
> Prism2.5 is not going to see them..
>
> In addition, it would be useful to increase the snap length of the
> sniffer (e.g., add -s 2000 on the tcpdump command line).

In newer tcpdumps, -s0 means "snap entire packet". I use that.
But my tcpdump was too old :(

> > NB: 0:4:e2:64:15:e5 is MAC addr of the STA
> >
> > 12:14:39.548175 DA:0:5:5d:fa:58:45 SA:0:4:e2:64:15:e5
> > BSSID:0:5:5d:fa:58:45 [|llc] 12:14:39.548485 RA:0:4:e2:64:15:e5 [|802.11]
>
> This might be normal unicast data frame followed by ACK from the AP.
>
> > 12:14:39.563854 BSSID:ff:ff:ff:ff:ff:ff DA:ff:ff:ff:ff:ff:ff
> > SA:0:4:e2:64:15:e5 [|802.11] 12:14:39.595005 BSSID:ff:ff:ff:ff:ff:ff
> > DA:ff:ff:ff:ff:ff:ff SA:0:4:e2:64:15:e5 [|802.11]
>
> I would guess these are broadcast Probe Requests, but without seeing the
> full frame (larger snap length) it is a bit difficult to know for sure.

That was tcpdump-3.7.1. It was buggy wrt 802.11
I'm compiling tcpdump-3.8.1....

> > 12:14:39.625551 DA:0:5:5d:fa:58:45 SA:0:4:e2:64:15:e5
> > BSSID:0:5:5d:fa:58:45 [|llc] 12:14:39.625863 RA:0:4:e2:64:15:e5 [|802.11]
>
> Another data frame + ACK
>
> > 12:14:41.711844 BSSID:0:5:5d:fa:58:45 DA:0:5:5d:fa:58:45
> > SA:0:4:e2:64:15:e5 Disassociation: Disassociated because sending station
> > is leaving (or has left) BSS
>
> Disassociation by the STA. Note that this happened about two seconds
> after the possible Probe Requests. I didn't see anything that would be a
> Probe Response from the AP to the STA. If this was indeed the case, STA
> firmware might have assumed that the AP is out of range. I don't know
> why it would disassociate in that case, but that may be possible.
>
> It would be useful to get the TX rate of the frames I assumed were Probe
> Request. In addition, the full contents of those frames would be useful.
> Maybe writing a dump file with tcpdump (-s 2000 -w filename) and making
> it available would be easiest way of doing this. If you cannot get
> transmit rates with Prism54 driver to the sniffer log, you could try
> running another Prism2/2.5/3 card in monitor mode and verify whether it
> sees those Probe Request like frames.
>
> > 12:14:41.718756 BSSID:ff:ff:ff:ff:ff:ff DA:ff:ff:ff:ff:ff:ff
> > SA:0:4:e2:64:15:e5 [|802.11] 12:14:41.719232 BSSID:0:5:5d:fa:58:45
> > DA:0:4:e2:64:15:e5 SA:0:5:5d:fa:58:45 [|802.11]
>
> This here might actually be Probe Request & Probe Response (again,
> larger snap length would be required). I would also need to get full
> sniffer log, not just filtered one, to verify that ACK frame was sent
> for the Probe Response.
>
> > 12:14:42.638426 BSSID:ff:ff:ff:ff:ff:ff DA:ff:ff:ff:ff:ff:ff
> > SA:0:4:e2:64:15:e5 [|802.11] 12:14:42.712153 BSSID:ff:ff:ff:ff:ff:ff
> > DA:ff:ff:ff:ff:ff:ff SA:0:4:e2:64:15:e5 [|802.11] 12:14:42.740828
> > BSSID:ff:ff:ff:ff:ff:ff DA:ff:ff:ff:ff:ff:ff SA:0:4:e2:64:15:e5 [|802.11]
> > 12:14:42.771550 BSSID:ff:ff:ff:ff:ff:ff DA:ff:ff:ff:ff:ff:ff
> > SA:0:4:e2:64:15:e5 [|802.11] 12:14:42.802271 BSSID:ff:ff:ff:ff:ff:ff
> > DA:ff:ff:ff:ff:ff:ff SA:0:4:e2:64:15:e5 [|802.11] 12:14:42.833013
> > BSSID:ff:ff:ff:ff:ff:ff DA:ff:ff:ff:ff:ff:ff SA:0:4:e2:64:15:e5 [|802.11]
> > 12:14:42.833621 BSSID:0:5:5d:fa:58:45 DA:0:4:e2:64:15:e5
> > SA:0:5:5d:fa:58:45 [|802.11] 12:14:42.835219 BSSID:0:5:5d:fa:58:45
> > DA:0:4:e2:64:15:e5 SA:0:5:5d:fa:58:45 [|802.11]
>
> It looks like there could be some issues in low-level frame
> sending/receiving. This could be sequence of many Probe Requests and
> then Probe Response with one retry (or response to anothe request; not
> enough data to figure that out).

Thank you for your analysis.

I made a couple of logs with new tcpdump-3.8.1 and sent them to you.
Got a bounce from list due to excess size. Sorry. Resending
gzipped.

t.raw:
# tcpdump -nleieth1 -s2000 -vvv -w t.raw ether host 0:4:e2:64:15:e5

t.log:
# tcpdump -nleieth1 -s0 -vvv 2>&1 | grep '0*0:0*4:e2:64:15:e5' >t.log
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.log.gz
Type: application/x-gzip
Size: 5331 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20040208/700fa565/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.raw.gz
Type: application/x-gzip
Size: 6004 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20040208/700fa565/attachment-0001.bin 