Hi,
Please copy the mailing list, I've done that now.
> My log files are filling up with these messages:
>
> [ 8722.198929] wlan0: RX non-WEP frame, but expected encryption
> [ 8726.506345] __ratelimit: 14 messages suppressed
> ./rx.c: printk(KERN_DEBUG "%s: RX non-WEP frame, but expected "
> It seems that others who are using Netgear WPN824 access points are
> also seeing these messages in their logs.
> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1614
> http://ubuntuforums.org/showthread.php?t=637084
>
> I am wondering whether this indicates a problem situation with the
> access point that really needs to be reported. Is this being reported
> because it is a security risk? Is this a condition that really needs
> to be reported by wireless drivers?
Hm. You shouldn't actually be getting this when your AP is configured to
use encryption. It either points to somebody trying to invade your
network (unlikely) or an AP bug.
Can you use 'iw' to add a new monitor interface and capture some of the
unencrypted packets with that? Use
$ git clone http://git.sipsolutions.net/iw.git/
$ cd iw
$ make
# ./iw dev wmaster0 interface add moni0 type monitor
and then wireshark/tcpdump on it, you can also send me the dump in
private mail if you cannot identify the problem. If you *disable* hw
crypto I won't even be able to read your actual traffic :)
johannes
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
09:30:35.980274 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:36.081393 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:36.180136 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:36.280104 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:36.382604 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:40.477051 IP whirligig.local.44350 > 209.62.187.17.www: F
81705605:81705605(0) ack 1667952741 win 137 <nop,nop,timestamp 1348464
2231439000>
09:30:40.478620 IP whirligig.local.38429 > 192.168.1.1.domain: 2736+
PTR? 17.187.62.209.in-addr.arpa. (44)
09:30:40.648999 IP 192.168.1.1.domain > whirligig.local.38429: 2736
ServFail 0/0/0 (44)
09:30:40.649195 IP whirligig.local.54273 > 192.168.1.1.domain: 2736+
PTR? 17.187.62.209.in-addr.arpa. (44)
09:30:40.819286 IP 192.168.1.1.domain > whirligig.local.54273: 2736
ServFail 0/0/0 (44)
09:30:40.920439 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 17.187.62.209.in-addr.arpa. (44)
09:30:41.581722 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:41.679830 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:41.780129 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:41.879732 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:41.930458 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 17.187.62.209.in-addr.arpa. (44)
09:30:41.979930 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:43.937126 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 17.187.62.209.in-addr.arpa. (44)
09:30:45.477026 arp who-has 192.168.1.1 tell whirligig.local
09:30:45.478080 arp reply 192.168.1.1 is-at 00:1b:2f:0e:ed:ba (oui Unknown)
09:30:45.827487 IP whirligig.local.39281 > 192.168.1.1.domain: 15918+
PTR? 4.1.168.192.in-addr.arpa. (42)
09:30:45.846455 IP 192.168.1.1.domain > whirligig.local.39281: 15918
NXDomain* 0/1/0 (119)
09:30:45.947112 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 4.1.168.192.in-addr.arpa. (42)
09:30:45.947394 IP whirligig.local.mdns > 224.0.0.251.mdns: 0*- [0q]
1/0/0 (Cache flush) PTR[|domain]
09:30:45.948047 IP whirligig.local.52755 > 192.168.1.1.domain: 48865+
PTR? 1.1.168.192.in-addr.arpa. (42)
09:30:45.971305 IP 192.168.1.1.domain > whirligig.local.52755: 48865
NXDomain* 0/1/0 (119)
09:30:46.077145 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 1.1.168.192.in-addr.arpa. (42)
09:30:47.079560 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:47.080486 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 1.1.168.192.in-addr.arpa. (42)
09:30:47.179546 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:47.279504 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:47.379457 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:47.479501 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:49.087131 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 1.1.168.192.in-addr.arpa. (42)
09:30:50.974318 IP whirligig.local.42959 > 192.168.1.1.domain: 24260+
PTR? 251.0.0.224.in-addr.arpa. (42)
09:30:50.984892 IP 192.168.1.1.domain > whirligig.local.42959: 24260
NXDomain* 0/1/0 (100)
09:30:51.087143 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 251.0.0.224.in-addr.arpa. (42)
09:30:52.093804 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 251.0.0.224.in-addr.arpa. (42)
09:30:52.579226 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:52.679164 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:52.779124 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:52.879144 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:52.981707 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:54.100452 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 251.0.0.224.in-addr.arpa. (42)
09:30:58.078895 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:58.178802 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:58.278847 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:58.378796 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:30:58.478831 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:01.982902 NBF Packet: Datagram
09:31:02.009004 IP 192.168.1.5.netbios-dgm >
192.168.1.255.netbios-dgm: NBT UDP PACKET(138)
09:31:02.009387 IP whirligig.local.34590 > 192.168.1.1.domain: 64044+
PTR? 255.1.168.192.in-addr.arpa. (44)
09:31:02.020810 IP 192.168.1.1.domain > whirligig.local.34590: 64044
NXDomain* 0/1/0 (121)
09:31:02.123826 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 255.1.168.192.in-addr.arpa. (44)
09:31:03.127127 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 255.1.168.192.in-addr.arpa. (44)
09:31:03.578567 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:03.678505 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:03.778535 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:03.878491 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:03.978710 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:05.133799 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 255.1.168.192.in-addr.arpa. (44)
09:31:07.027476 IP whirligig.local.55385 > 192.168.1.1.domain: 62170+
PTR? 5.1.168.192.in-addr.arpa. (42)
09:31:07.044743 IP 192.168.1.1.domain > whirligig.local.55385: 62170
NXDomain* 0/1/0 (119)
09:31:07.147146 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 5.1.168.192.in-addr.arpa. (42)
09:31:08.153794 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 5.1.168.192.in-addr.arpa. (42)
09:31:09.078235 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:09.178166 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:09.278163 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:09.378198 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:09.480568 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:09.917028 IP whirligig.local.44350 > 209.62.187.17.www: F 0:0(0)
ack 1 win 137 <nop,nop,timestamp 1357296 2231439000>
09:31:10.160503 IP whirligig.local.mdns > 224.0.0.251.mdns: 0 PTR
(QM)? 5.1.168.192.in-addr.arpa. (42)
09:31:14.577879 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:14.677855 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:14.777888 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:14.877836 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:14.920341 arp who-has 192.168.1.1 tell whirligig.local
09:31:14.921375 arp reply 192.168.1.1 is-at 00:1b:2f:0e:ed:ba (oui Unknown)
09:31:14.978027 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:20.077620 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:20.177513 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:20.277570 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:20.377530 AT 255.89.1.zip > 0.0.zip: at-#6 8
09:31:20.477569 AT 255.89.1.zip > 0.0.zip: at-#6 8
On Thu, 2008-04-03 at 14:45 +0200, Johannes Berg wrote:
> Hi,
>
> Please copy the mailing list, I've done that now.
>
> > My log files are filling up with these messages:
> >
> > [ 8722.198929] wlan0: RX non-WEP frame, but expected encryption
> > [ 8726.506345] __ratelimit: 14 messages suppressed
> > It seems that others who are using Netgear WPN824 access points are
> > also seeing these messages in their logs.
> > http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1614
> > http://ubuntuforums.org/showthread.php?t=637084
Ok, I got packets from Miles, and this is what I found:
IEEE 802.11 Data, Flags: ......F.
Type/Subtype: Data (0x20)
Frame Control: 0x0208 (Normal)
Version: 0
Type: Data frame (2)
Subtype: 0
Flags: 0x2
DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x02)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 44
Destination address: <his STA MAC>
BSS Id: <his Netgear AP>
Source address: <his Netgear AP>
Fragment number: 0
Sequence number: 3874
Logical-Link Control
DSAP: NULL LSAP (0x00)
IG Bit: Individual
SSAP: NULL LSAP (0x00)
CR Bit: Command
Control field: I, N(R)=0, N(S)=0 (0x0000)
0000 000. .... .... = N(R): 0
.... .... 0000 000. = N(S): 0
.... .... .... ...0 = Frame type: Information frame (0x0000)
Data (1472 bytes)
0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* all zeroes
05b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Data: 000000000000000000000000000000000000000000000000...
Note how the LLC header is also all-zeroes. Also note how the duration
field is totally bogus. The sequence number is actually correct.
Does anybody have an explanation for that except that the AP software is
messing it up?
In any case, I suppose the message in question isn't actually necessary.
I'll make it depend on verbose debugging maybe.
johannes
T24gVGh1LCBBcHIgMywgMjAwOCBhdCAxMjo1MiBQTSwgSm91bmkgTWFsaW5lbiA8akB3MS5maT4g
d3JvdGU6Cj4gT24gVGh1LCBBcHIgMDMsIDIwMDggYXQgMDQ6MDE6NTNQTSArMDIwMCwgSm9oYW5u
ZXMgQmVyZyB3cm90ZToKPgo+ICA+ID4gPiBNeSBsb2cgZmlsZXMgYXJlIGZpbGxpbmcgdXAgd2l0
aCB0aGVzZSBtZXNzYWdlczoKPiAgPiA+ID4gICAgICAgIFsgODcyMi4xOTg5MjldIHdsYW4wOiBS
WCBub24tV0VQIGZyYW1lLCBidXQgZXhwZWN0ZWQgZW5jcnlwdGlvbgo+ICA+ID4gPiAgICAgICAg
WyA4NzI2LjUwNjM0NV0gX19yYXRlbGltaXQ6IDE0IG1lc3NhZ2VzIHN1cHByZXNzZWQKPgo+ICBJ
cyB0aGUgbmV0d29yayB1c2luZyBXRVAgb3IgVEtJUC9DQ01QPwoKV1BBMiAvIEFFUwoKPiAgPiBP
aywgSSBnb3QgcGFja2V0cyBmcm9tIE1pbGVzLCBhbmQgdGhpcyBpcyB3aGF0IEkgZm91bmQ6Cj4g
ID4KPiAgPiBJRUVFIDgwMi4xMSBEYXRhLCBGbGFnczogLi4uLi4uRi4KPiAgPiAgICAgVHlwZS9T
dWJ0eXBlOiBEYXRhICgweDIwKQo+ICA+ICAgICBGcmFtZSBDb250cm9sOiAweDAyMDggKE5vcm1h
bCkKPgo+ID4gICAgIER1cmF0aW9uOiA0NAo+ICA+ICAgICBEZXN0aW5hdGlvbiBhZGRyZXNzOiA8
aGlzIFNUQSBNQUM+Cj4gID4gICAgIEJTUyBJZDogPGhpcyBOZXRnZWFyIEFQPgo+ICA+ICAgICBT
b3VyY2UgYWRkcmVzczogPGhpcyBOZXRnZWFyIEFQPgo+ICA+ICAgICBGcmFnbWVudCBudW1iZXI6
IDAKPiAgPiAgICAgU2VxdWVuY2UgbnVtYmVyOiAzODc0Cj4gID4gTG9naWNhbC1MaW5rIENvbnRy
b2wKPiAgPiAgICAgRFNBUDogTlVMTCBMU0FQICgweDAwKQo+Cj4gPiBEYXRhICgxNDcyIGJ5dGVz
KQo+ICA+IDAwMDAgIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw
IDAwICAgLi4uLi4uLi4uLi4uLi4uLgo+ICA+ICogYWxsIHplcm9lcwo+Cj4KPiA+IE5vdGUgaG93
IHRoZSBMTEMgaGVhZGVyIGlzIGFsc28gYWxsLXplcm9lcy4g77u/QWxzbyBub3RlIGhvdyB0aGUg
ZHVyYXRpb24KPiAgPiBmaWVsZCBpcyB0b3RhbGx5IGJvZ3VzLiBUaGUgc2VxdWVuY2UgbnVtYmVy
IGlzIGFjdHVhbGx5IGNvcnJlY3QuCj4KPiAgV2hhdCdzIHdyb25nIHdpdGggdGhlIGR1cmF0aW9u
IGZpZWxkIHZhbHVlPyBUaGUgZHVtcCBoZXJlIGRvZXMgbm90Cj4gIGluZGljYXRlIHdoaWNoIHRy
YW5zbWl0IHJhdGUgd2FzIHVzZWQsIHNvIEkgZG9uJ3Qga25vdyB3aGF0IFRYIHJhdGUgdGhlCj4g
IEFDSyB3b3VsZCB1c2UsIGJ1dCA0NCBzb3VuZHMgbGlrZSBhIHJlYXNvbmFibGUgZHVyYXRpb24g
dmFsdWUgZm9yCj4gIDgwMi4xMWcgcmF0ZXMuLgoKVGhlIEFQIGlzIHNldCB1cCB0byBvbmx5IHVz
ZSA4MDIuMTFnLgoKPiAgPiBEb2VzIGFueWJvZHkgaGF2ZSBhbiBleHBsYW5hdGlvbiBmb3IgdGhh
dCBleGNlcHQgdGhhdCB0aGUgQVAgc29mdHdhcmUgaXMKPiAgPiBtZXNzaW5nIGl0IHVwPwo+Cj4g
IExvb2tzIGxpa2UgYW4gaW50ZXJlc3RpbmcgQVAgYmVoYXZpb3IgdG8gbWUuLgo+Cj4gID4gSW4g
YW55IGNhc2UsIEkgc3VwcG9zZSB0aGUgbWVzc2FnZSBpbiBxdWVzdGlvbiBpc24ndCBhY3R1YWxs
eSBuZWNlc3NhcnkuCj4gID4gSSdsbCBtYWtlIGl0IGRlcGVuZCBvbiB2ZXJib3NlIGRlYnVnZ2lu
ZyBtYXliZS4KPgo+ICBZZXMsIHRoYXQgc291bmRzIHJlYXNvbmFibGUuIFRoZSBBUCBzaG91bGQg
bm90IGJlIHNlbmRpbmcgdGhpcyBraW5kIG9mCj4gIGNyYXAsIGJ1dCB3ZWxsLCB3aGF0IGNhbiB5
b3UgZG8gaWYgaXQgZG9lcy4uIEluIHRoZW9yeSwgdGhpcyBjb3VsZCBhbHNvCj4gIGJlIHNob3dp
bmcgdXAgaW4gbXVsdGktU1NJRCBjb25maWd1cmF0aW9uIHdoZW4gYW5vdGhlciBTU0lEIGlzCj4g
IGNvbmZpZ3VyZWQgdG8gdXNlIHVuZW5jcnlwdGVkIGZyYW1lcyAodGhvdWdoLCB0aGF0IHdvdWxk
IGNhdXNlIGludGVyb3AKPiAgaXNzdWVzIGluIGFzc29jaWF0aW9uIGZvciBudW1iZXIgb2YgY2xp
ZW50cy4uKS4KClRoZSBsaW5rIHNlZW1zIHRvIHdvcmsgd2VsbC4gIElmIHlvdSBjYW4gbmFpbCBk
b3duIGEgcHJvYmxlbSB3aXRoCnRoZWlyIEFQIHNvZnR3YXJlLCBJIHdpbGwgc3VibWl0IGEgYnVn
IHJlcG9ydCB0byBOZXRHZWFyLgoKQ2hlZXJzLAogICAgICBNaWxlcwo=
On Thu, Apr 3, 2008 at 8:45 AM, Johannes Berg <[email protected]> wrote:
> Hi,
>
> Please copy the mailing list, I've done that now.
>
>
> > My log files are filling up with these messages:
> >
> > [ 8722.198929] wlan0: RX non-WEP frame, but expected encryption
> > [ 8726.506345] __ratelimit: 14 messages suppressed
>
>
> > ./rx.c: printk(KERN_DEBUG "%s: RX non-WEP frame, but expected "
>
>
>
> > It seems that others who are using Netgear WPN824 access points are
> > also seeing these messages in their logs.
> > http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1614
> > http://ubuntuforums.org/showthread.php?t=637084
> >
> > I am wondering whether this indicates a problem situation with the
> > access point that really needs to be reported. Is this being reported
> > because it is a security risk? Is this a condition that really needs
> > to be reported by wireless drivers?
>
> Hm. You shouldn't actually be getting this when your AP is configured to
> use encryption. It either points to somebody trying to invade your
> network (unlikely) or an AP bug.
>
> Can you use 'iw' to add a new monitor interface and capture some of the
> unencrypted packets with that? Use
>
> $ git clone http://git.sipsolutions.net/iw.git/
> $ cd iw
> $ make
>
> # ./iw dev wmaster0 interface add moni0 type monitor
>
> and then wireshark/tcpdump on it, you can also send me the dump in
> private mail if you cannot identify the problem. If you *disable* hw
> crypto I won't even be able to read your actual traffic :)
Thanks Johannes,
I tried to build iw, but got an error:
# make
CC iw.o
/bin/sh: cgcc: not found
make[1]: *** [iw.o] Error 127
make: *** [check] Error 2
After poking around, I found
http://ftp.idilis.ro/mirrors/ftp.kernel.org/pub/software/devel/sparse/news.html
which seems to be where I can find the tool.
I compiled, and (after setting $HOME to /usr) installed it.
Now, when I try to compile iw, I get:
# make
CC iw.o
iw.c:9:11: error: unable to open 'netlink/genl/genl.h'
iw.c:9:31: error: netlink/genl/genl.h: No such file or directory
iw.c:10:33: error: netlink/genl/family.h: No such file or directory
iw.c:11:33: error: netlink/genl/ctrl.h: No such file or directory
iw.c:12:25: error: netlink/msg.h: No such file or directory
iw.c:13:26: error: netlink/attr.h: No such file or directory
iw.c: In function 'nl80211_init':
iw.c:23: error: implicit declaration of function 'nl_handle_alloc'
iw.c:23: warning: assignment makes pointer from integer without a cast
iw.c:29: error: implicit declaration of function 'genl_connect'
iw.c:35: error: implicit declaration of function 'genl_ctrl_alloc_cache'
iw.c:35: warning: assignment makes pointer from integer without a cast
iw.c:42: error: implicit declaration of function 'genl_ctrl_search_by_name'
iw.c:42: warning: assignment makes pointer from integer without a cast
iw.c:52: error: implicit declaration of function 'nl_cache_free'
iw.c:54: error: implicit declaration of function 'nl_handle_destroy'
iw.c: In function 'nl80211_cleanup':
iw.c:60: error: implicit declaration of function 'genl_family_put'
iw.c: In function 'get_phy_or_dev':
iw.c:83: error: implicit declaration of function 'strcmp'
make[1]: *** [iw.o] Error 1
Help?
Miles
On Thu, 2008-04-03 at 09:32 -0400, Miles Lane wrote:
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
> 09:30:35.980274 AT 255.89.1.zip > 0.0.zip: at-#6 8
I can't read much from that, can you make it write it to a file and send
me that file (preferably in private mail I guess to not clutter the list
with it)?
johannes
On Thu, Apr 03, 2008 at 04:01:53PM +0200, Johannes Berg wrote:
> > > My log files are filling up with these messages:
> > > [ 8722.198929] wlan0: RX non-WEP frame, but expected encry=
ption
> > > [ 8726.506345] __ratelimit: 14 messages suppressed
Is the network using WEP or TKIP/CCMP?
> Ok, I got packets from Miles, and this is what I found:
>=20
> IEEE 802.11 Data, Flags: ......F.
> Type/Subtype: Data (0x20)
> Frame Control: 0x0208 (Normal)
> Duration: 44
> Destination address: <his STA MAC>
> BSS Id: <his Netgear AP>
> Source address: <his Netgear AP>
> Fragment number: 0
> Sequence number: 3874
> Logical-Link Control
> DSAP: NULL LSAP (0x00)
> Data (1472 bytes)
> 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .............=
=2E..
> * all zeroes
> Note how the LLC header is also all-zeroes. =EF=BB=BFAlso note how th=
e duration
> field is totally bogus. The sequence number is actually correct.
What's wrong with the duration field value? The dump here does not
indicate which transmit rate was used, so I don't know what TX rate the
ACK would use, but 44 sounds like a reasonable duration value for
802.11g rates..
> Does anybody have an explanation for that except that the AP software=
is
> messing it up?
Looks like an interesting AP behavior to me..
> In any case, I suppose the message in question isn't actually necessa=
ry.
> I'll make it depend on verbose debugging maybe.
Yes, that sounds reasonable. The AP should not be sending this kind of
crap, but well, what can you do if it does.. In theory, this could also
be showing up in multi-SSID configuration when another SSID is
configured to use unencrypted frames (though, that would cause interop
issues in association for number of clients..).
--=20
Jouni Malinen PGP id EFC895F=
A
Thanks. I think I have a working build, but can you confirm that the
linker messages are benign?
I will get to work now on getting the log for you.
Now I get:
# make
CC iw.o
cc: -lnl: linker input file unused because linking not done
CC interface.o
interface.c: In function 'handle_interface':
interface.c:64: warning: 'err' may be used uninitialized in this function
interface.c:64: note: 'err' was declared here
interface.c:138: warning: 'err' may be used uninitialized in this function
interface.c:138: note: 'err' was declared here
cc: -lnl: linker input file unused because linking not done
CC info.o
cc: -lnl: linker input file unused because linking not done
CC station.o
cc: -lnl: linker input file unused because linking not done
CC util.o
cc: -lnl: linker input file unused because linking not done
CC mpath.o
cc: -lnl: linker input file unused because linking not done
CC iw
> > Duration: 44
> What's wrong with the duration field value? The dump here does not
> indicate which transmit rate was used, so I don't know what TX rate the
> ACK would use, but 44 sounds like a reasonable duration value for
> 802.11g rates..
Yes, you're perfectly right, my rough estimate was totally off, I
miscalculated.
> > Does anybody have an explanation for that except that the AP software is
> > messing it up?
>
> Looks like an interesting AP behavior to me..
For some values of interesting... :)
> > In any case, I suppose the message in question isn't actually necessary.
> > I'll make it depend on verbose debugging maybe.
>
> Yes, that sounds reasonable. The AP should not be sending this kind of
> crap, but well, what can you do if it does.. In theory, this could also
> be showing up in multi-SSID configuration when another SSID is
> configured to use unencrypted frames (though, that would cause interop
> issues in association for number of clients..).
That would be ... interesting. But yeah, the message doesn't have much
value, it just tells you your peer might be buggy...
johannes
On Thu, 2008-04-03 at 09:32 -0400, Miles Lane wrote:
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes
> 09:30:40.477051 IP whirligig.local.44350 > 209.62.187.17.www: F
> 81705605:81705605(0) ack 1667952741 win 137 <nop,nop,timestamp 1348464
> 2231439000>
Uh wait, I shouldn't be seeing this if the network is encrypted. Is this
really a dump from the monitor interface?
johannes
On Thu, 2008-04-03 at 09:24 -0400, Miles Lane wrote:
> Thanks. I think I have a working build, but can you confirm that the
> linker messages are benign?
Yeah, seems ok, as long as it runs :)
> I will get to work now on getting the log for you.
I'm about to go offline now, I'll look at it tomorrow. You should be
able to identify the packet that caused the problem in wireshark by
adding a display filter like "wlan.fc.protected == 0"
> CC iw.o
> cc: -lnl: linker input file unused because linking not done
Hrm. Yes, my mistake, I suppose. I don't like Makefile hacking :) Maybe
I should just go back to the built-in rules.
> interface.c: In function 'handle_interface':
> interface.c:64: warning: 'err' may be used uninitialized in this function
> interface.c:64: note: 'err' was declared here
> interface.c:138: warning: 'err' may be used uninitialized in this function
> interface.c:138: note: 'err' was declared here
Strange. I don't get those, and I don't know how the compiler arrives at
that conclusion.
johannes
> I tried to build iw, but got an error:
>
> # make
> CC iw.o
> /bin/sh: cgcc: not found
> make[1]: *** [iw.o] Error 127
> make: *** [check] Error 2
>
> After poking around, I found
> http://ftp.idilis.ro/mirrors/ftp.kernel.org/pub/software/devel/sparse/news.html
> which seems to be where I can find the tool.
> I compiled, and (after setting $HOME to /usr) installed it.
> Now, when I try to compile iw, I get:
Doh. I thought I hacked the makefile to not require cgcc. Will remove
that hack and just mandate that people run 'make check' instead of
'make' or 'make all'.
> iw.c:9:11: error: unable to open 'netlink/genl/genl.h'
You need to install libnl development headers, your distro should ship
libnl-dev (debian's package for example) or similar, or you need libnl
from source: http://people.suug.ch/~tgr/libnl/ At least version -pre8 is
required.
johannes