Spurious disassociations in prismGT STA <-> prism2.5 AP setup

[Jouni Malinen]

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).

> 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.

> 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).

-- 
Jouni Malinen                                            PGP id EFC895FA