Image of the packet trace -> http://postimage.org/image/984jj38/ This is also happens with Auth packets the client -> AP packet has a timestamp which occurs after the AP -> client Auth packet Does anyone know whats going on? is it a bug in the driver? asked 16 Oct '11, 11:08  ddayan edited 16 Oct '11, 13:21 |
One Answer:
--- from comment to answer --- If this happens multiple times, your capture setup might irritate you. Buffered frames waiting to be delivered to your analyzer may change their original order - happens more often when capturing your own, local machine during its own association. In that case, just ignore is. I would always recommend capturing wireless traffic with a second "capture only" device. answered 18 Oct '11, 09:33  Landi |
Do the frames contain the same Association ID?
http://www.wildpackets.com/resources/compendium/wireless_lan/wlan_packet_types/printable
http://www.wi-fiplanet.com/tutorials/article.php/1447501
If this happens multiple times, your capture setup might irritate you. Buffered frames waiting to be delivered to your analyzer may change their original order - happens more often when capturing your own, local machine during its own association. In that case, just ignore is.
I would always recommend capturing wireless traffic with a second "capture only" device.
@ Joke, Association ID is assigned by the AP - NOT requested by the client. It's just a number for the wireless client to remember in case the AP later on tells e.g. "buffered packets for Assoc ID 2".
@Landi
You are absolutely right. Thank you.
@ddayan
Sorry for the noise.
@Landi
I think you are right. I did captured on the same machine. Where can i get more info about the way buffered frames are delivered? I would like to know more about why the original order is changed.
Good question - if you find something give me the link ;) No, honestly - that's stack internals as far as i figured that out plus the way the driver handles stuff... no idea - sorry