Bugzilla – Bug 1446
No connectivity unless tcpdump -p is running on wireless interface
Last modified: 2008-12-15 18:46:36
You need to log in before you can comment on or make changes to this bug.
I've got an Intel 4965 wireless adapter in a Dell Inspiron 1520. I'm running the iwl4965 module from iwlwifi 0.1.12 connecting to a Dlink 802.11g AP with WPA2 via wpa_supplicant. It associates fine, authenticates fine, grabs a dhcp address fine, however, I get no TCP/IP traffic. nmap can probe ports across it fine but a simple ping to the AP fails as does any other TCP traffic. However, if I run 'tcpdump -i wlan0 -p' everything works fine. Due to that last little tidbit, I'm at a loss as to where to go next. uname -a: Linux bonsai 2.6.22-gentoo-r5 #3 SMP Sun Aug 26 16:49:06 MDT 2007 i686 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux dmesg output with the wmaster0 lines like this filtered out: wmaster0: TX to low-level driver (len=51) FC=0x0040 DUR=0x013a A1=00:0f:3d:07:e5:23 A2=00:13:e8:6e:9e:47 A3=00:0f:3d:07:e5:23 ACPI: PCI interrupt for device 0000:0c:00.0 disabled iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 0.1.12ds iwl4965: Copyright(c) 2003-2007 Intel Corporation ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 18 PCI: Setting latency timer of device 0000:0c:00.0 to 64 iwl4965: Detected Intel Wireless WiFi Link 4965AGN iwl4965: Tunable channels: 11 802.11bg, 13 802.11a channels wmaster0: Selected rate control algorithm 'iwl-4965-rs' HW CONFIG: channel=1 freq=2412 phymode=3 ADDRCONF(NETDEV_UP): wlan0: link is not ready HW CONFIG: channel=1 freq=2412 phymode=3 HW CONFIG: channel=11 freq=2462 phymode=3 wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:0f:3d:07:e5:23 wlan0: RX authentication from 00:0f:3d:07:e5:23 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:0f:3d:07:e5:23 wlan0: invalid aid value 0; bits 15:14 not set wlan0: RX AssocResp from 00:0f:3d:07:e5:23 (capab=0x431 status=43 aid=0) wlan0: AP denied association (code=43) wlan0: associate with AP 00:0f:3d:07:e5:23 wlan0: RX AssocResp from 00:0f:3d:07:e5:23 (capab=0x431 status=0 aid=2) wlan0: associated wmaster0: Added STA 00:0f:3d:07:e5:23 wlan0: WMM queue=2 aci=0 acm=0 aifs=3 cWmin=15 cWmax=1023 burst=0 ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: WMM queue=3 aci=1 acm=0 aifs=7 cWmin=15 cWmax=1023 burst=0 wlan0: WMM queue=1 aci=2 acm=0 aifs=2 cWmin=7 cWmax=15 burst=30 wlan0: WMM queue=0 aci=3 acm=0 aifs=2 cWmin=3 cWmax=7 burst=15 wlan0: CTS protection enabled (BSSID=00:0f:3d:07:e5:23) wlan0: no IPv6 routers present
A little more info, I've tracked the issue down to this point in the libpcap module: socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) I don't seem to be getting any arp packets until a socket connects to the interface to start grabbing packets in ETH_P_ALL mode.
Reclassifying this as a mac80211 bug as the following code is all that is required to make things work. I'm guessing that since this works without touching the actual wlan device that it is a problem above the driver. #include <stdio.h> #include <unistd.h> #include <sys/socket.h> #include <linux/if_ether.h> int main(int argc, char **argv) { int sock_fd; sock_fd = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); while(1) { sleep(600); } return(0); }
did you configure anything like iptable or selinux?
(In reply to comment #3) > did you configure anything like iptable or selinux? No neither. Running the code snippet above fixes things. Stopping it causes packets to be missed again. I can't say for certain that arp is the only thing not making it through but the fact that arp replies don't make it back to the machine is what causes the lack of connectivity. I realize this isn't enough to go on to make this reproducible. I'm willing to try any suggestions to collect more data to get there. I have run with full mac80211 and iwlwifi debugging turned on and can not see a toggle between passing and failing modes. I'm at a loss as to where to go next.
Could you please try with latest driver?
Yes! It works now with 2.6.24. I had completely forgotten about this as I automated the workaround. Thank you.
Thanks.