 | 1 | initial version |
You use Wireshark by observing the connection sequence, probably:
open authentication --> association --> 4-way EAPOL handshake for auth+keying
and then the tear down sequence, probably a single management frame, either
disassociate or deauth
This could be more about cutting the problem in half instead of the brass ring - know exact root cause. Anyway, sometimes we get lucky. Either side can choose to leave the association, so you would see who is issuing the leave, and there is a field that might contain a reason code. Hopefully it doesn't say 'unspecified'... this is the jumping off point. Whichever entity is leaving, you need to look there - why are they sending that frame? A real reason code is a great starting clue. Often, you will need logs as Wireshark only shows what happened, but does not always show why it happened.
Things like power save behavior, DHCP timeouts, and session timeouts are common reasons why a host might leave a wireless association.
| | 2 | No.2 Revision |
You use Wireshark by observing the connection sequence, probably:
open authentication --> association --> 4-way EAPOL handshake for auth+keying
and then the tear down sequence, probably a single management frame, either
disassociate or deauth
This could be more about cutting the problem in half instead of the brass ring - know exact root cause. Anyway, sometimes we get lucky. Either side can choose to leave the association, so you would see who is issuing the leave, and there is a field that might contain a reason code. Hopefully it doesn't say 'unspecified'... this is the jumping off point. Whichever entity is leaving, you need to look there - why are they sending that frame? A real reason code is a great starting clue. Often, you will need logs as Wireshark only shows what happened, but does not always show why it happened.
Things like power save behavior, DHCP timeouts, and session timeouts are common reasons why a host might leave a wireless association.
Wireless packet capture is hard but there is some guidance [here] (https://wiki.wireshark.org/CaptureSetup/WLAN). Often, special hardware is needed.
| | 3 | No.3 Revision |
You use Wireshark by observing the connection sequence, probably:
open authentication --> association --> 4-way EAPOL handshake for auth+keying
and then the tear down sequence, probably a single management frame, either
disassociate or deauth
This could be more about cutting the problem in half instead of the brass ring - know exact root cause. Anyway, sometimes we get lucky. Either side can choose to leave the association, so you would see who is issuing the leave, and there is a field that might contain a reason code. Hopefully it doesn't say 'unspecified'... this is the jumping off point. Whichever entity is leaving, you need to look there - why are they sending that frame? A real reason code is a great starting clue. Often, you will need logs as Wireshark only shows what happened, but does not always show why it happened.
Things like power save behavior, DHCP timeouts, and session timeouts are common reasons why a host might leave a wireless association.
Wireless packet capture is hard but there is some guidance [here] (https://wiki.wireshark.org/CaptureSetup/WLAN). here. Often, special hardware is needed.