Bug 12044
Summary: | Connections to N-mode wireless AP not working with iwl4965 AGN driver: no data transferred | ||
---|---|---|---|
Product: | Drivers | Reporter: | Sjoerd Hardeman (sjoerd) |
Component: | network-wireless | Assignee: | networking_wireless (networking_wireless) |
Status: | RESOLVED UNREPRODUCIBLE | ||
Severity: | normal | CC: | reinette.chatre |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.28-rc4 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
Iwlwifi debugging output in syslog
tarred gzip of captured debugging info and tcpdump |
Description
Sjoerd Hardeman
2008-11-16 03:25:06 UTC
This appears to be a duplicate of http://bugzilla.kernel.org/show_bug.cgi?id=11596 ... from the commit log of patch "iwlagn: fix RX skb alignment"[1] this bug (11596) is fixed. Could you please check if this patch fixes the problem for you also? [1] commit e777fa4a467e0649929b28ee120510dc2bf87a29 in wireless-testing http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=e777fa4a467e0649929b28ee120510dc2bf87a29 I tried the wireless-testing kernel including the patches, but that doesn't solve the problem. You mention that the problem occurs in unencrypted tests also. Could you please repeat that test (without wpa_supplicant) with the driver loaded with the following debug parameter: debug=0x40841000 Of course I forgot to check if the device worked unencrypted with the new kernel. Well, I do get a ip address, even without the debug parameter, and am also able to send data over the line. Yet, the connection seems to be rather buggy, at one point not pinging my access point and filling the syslog with: Dec 9 22:27:57 laptop kernel: [ 815.699549] martian source 192.168.2.102 from 192.168.2.1, on dev wlan0 Dec 9 22:27:57 laptop kernel: [ 815.699555] ll header: ff:ff:ff:ff:ff:ff:00:1d:7e:ab:ac:66:08:06 In order to use the debug parameter, I did a "modprobe -v iwlagn debug=0x40841000". Is that what I am supposed to do? Furthermore, where can I find the additional debugging info? Anyway, thanks a lot for your time. Sjoerd My apologies for this double message, but to be sure I made myself clear: WPA and WPA2 still do not work. Sjoerd, Is this bug still open? To obtain the debugging the driver needs to be compiled with debugging enabled - you can check this in your logs - the driver will have a "d" in the version number if debugging is compiled in. With debugging enabled you can see debug output when you run "dmesg" - for this debugging it may be better if you configure syslog to send debug output to a file because it may generate a lot of data. If you still need to obtain debug information - could you please try to debug flags 0x41843fff instead? You can do this at runtime when you run: echo 0x41843fff > /sys/class/net/wlan0/device/debug_level John, Could this bug be closed? We have not heard from the reported in more than a month. Thanks Reinette Created attachment 20502 [details]
Iwlwifi debugging output in syslog
Hi Reinette,
I was away for some time, my apologies.
Anyway, here's a dump of the debugging info, done with the newest kernel (2.6.29-rc7-wl).
I connected using wpa_supplicant, tried to get a dhcp lease, and also manually set an address and tried to ping the router.
If you need me to check anything else, I am available again.
Sjoerd
Could you please check the setup of your AP? The log shows that the DHCPREQUEST go out successfully, but that the AP responds with a DHCPNAK. The source address used by the AP when it sends its response is also strange as it uses the broadcast address as its source. The networking code caught this as you can see from message: Mar 12 15:01:00 laptop kernel: [ 599.518745] martian source 255.255.255.255 from 192.168.2.1, on dev wlan0 Mar 12 15:01:00 laptop kernel: [ 599.518749] ll header: ff:ff:ff:ff:ff:ff:00:1d:7e:ab:ac:66:08:00 Strange, my AP is setup up as provided by linksys. I have tried a new firmware with similar results. I will check more thoroughly what going on next weekend. Anyway, it is thus probably not a bug in the kernel? Then I have to bug Linksys with this issue. Thanks a lot for your time. I do not see how this can be a problem with the driver. The problem is that you are not getting an IP address via dhcp. This is because the DHCP server (your AP) responds with a DHCPNAK when asked for an IP address. Also, the source IP address used by the AP when responding to the request is not correct. It can't be a DHCP problem, as setting the ip address manually also does not work. Sjoerd Were you able to check the AP's network setup? The fact that it sends a DHCPNAK and also that it uses a broadcast address as its source is a problem. When you do set an IP address manually, can you capture some network traffic for us to look at when you try to ping ? (something like "tcpdump -i wlan0 -n -s0 -w my.cap") Also, you provided the debugging for the DHCP case ... can you provide debugging for the case where you set IP manually? Created attachment 21000 [details]
tarred gzip of captured debugging info and tcpdump
The atatchment is a gzipped tar of the tcpdump and the captured debugging info. I connected with wpa_supplicant, set my ip to 192.168.2.151, bcast 192.168.2.255, netmask 255.255.255.0 (the AP is 192.168.2.1, so it should be reachable). and pinged 12 times. A similar setup with my eth card (of course) works, so it is not related to my AP not accepting addresses not set by dhcp or something similar.
Hopefully the information is useful. Thanks for your time.
Sjoerd
Just tested if I could still find the bug in the current kernel release, and the answer is no. So apparently it is fixed in 2.6.31. Sjoerd |