Michael Countermeasures tracing
ars at itconnection.ru
Fri Nov 18 05:07:17 EST 2005
I'm spending second week already trying to understand how should the
trace of source of MIC error in a buggy RF environment be performed,
hope to receive some advices here...
The DS is built on two D-Link DWL-2100AP, latest firmwares.
MS are either Intel PRO Wireless 2200BG or Ambit Microsystems 11b/g WNIC.
WPA-PSK with TKIP
Monitoring APs reports MIC errors in RX frames periodically. The report
on D-Link looks like "MIC error in RX frame at %integer", where %integer
is something that my Russian D-Link office could not explain ("too deep"
they said). I suppose it is a value from total frames passed DS->RF,
But what is certain: RX means that there's a buggy adapter - I doubt if
What I did first is started a syslog stats on roaming/associations from
a week period (I thought MICs can be caused by a panicly roamed MS that
calculated checksum for one DEST MAC, but sends frame to other DEST
MAC). Its examples are:
2005-11-02 13:37:40 User.Notice 192.168.0.125 Wireless STA connected
2005-11-02 13:37:43 User.Notice 192.168.0.124 Wireless STA connected
countermeasures followed on AP .124
2005-11-17 17:37:03 User.Notice 192.168.0.125 Wireless STA connected
2005-11-17 17:37:03 User.Notice 192.168.0.125 Last message repeated 10 times
countermeasures followed on .125
OR very funny one
2005-11-17 20:03:49 User.Notice 192.168.0.124 Wireless STA connected
2005-11-17 20:04:04 User.Notice 192.168.0.124 Last message repeated 509
countermeasures followed on .124
so you see, no system at all among those 15 MB of logs. So it's not the
poing of panic roaming - so I was wrong.
I started ethereal monitoring to catch any suspicious
authentication/association denicals or something just in few frames
before actual countermeasure starts on a given AP.
Found nothing suspicious - just Data and Acks...
I wonder how can I solve this problem with MIC errors leading to
e-mail: ars at itconnection.ru
phone: +7 812 320-9850
More information about the HostAP