iwl3945 no dhcpoffers received
I searched and googled for an answer to this, but I'm stumped. The system is an HP Pavilion dv6000 running Debian and wireless was working fine until a few weeks ago. There was an update for hal a few weeks ago is all I can think of. I recently updated the kernel to 2.6.27.2. thinking maybe it was a buggy driver, but still the same problem. The networks I'm trying to connect to have worked fine for months. I have checked the hardware kill switch and it isn't on.
Here is dmesg output: iwl3945 0000:02:00.0: PCI INT A disabled iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26ks iwl3945: Copyright(c) 2003-2008 Intel Corporation iwl3945 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 iwl3945 0000:02:00.0: setting latency timer to 64 iwl3945: Detected Intel Wireless WiFi Link 3945ABG iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels phy1: Selected rate control algorithm 'iwl-3945-rs' lsmod shows this: iwl3945 75032 0 rfkill 7000 2 iwl3945 mac80211 128088 1 iwl3945 led_class 3268 1 iwl3945 cfg80211 19848 2 iwl3945,mac80211 ifup wlan0 shows this (everything is usual): Internet Systems Consortium DHCP Client V3.1.1 Copyright 2004-2008 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ wmaster0: unknown hardware address type 801 wmaster0: unknown hardware address type 801 Listening on LPF/wlan0/00:0f:f7:4b:8b:c9 Sending on LPF/wlan0/00:0f:f7:4b:8b:c9 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 16 No DHCPOFFERS received. No working leases in persistent database - sleeping. from tcpdump: 10:45:43.863065 IP6 fe80::20f:f7ff:fe4b:8bc9 > ip6-allrouters: ICMP6, router solicitation, length 16 10:45:44.526024 IP6 fe80::20f:f7ff:fe4b:8bc9 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 10:45:45.000438 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0f:f7:4b:8b:c9 (oui Unknown), length 300 10:45:47.863022 IP6 fe80::20f:f7ff:fe4b:8bc9 > ip6-allrouters: ICMP6, router solicitation, length 16 10:45:48.000397 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0f:f7:4b:8b:c9 (oui Unknown), length 300 10:45:51.863023 IP6 fe80::20f:f7ff:fe4b:8bc9 > ip6-allrouters: ICMP6, router solicitation, length 16 10:45:53.000367 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0f:f7:4b:8b:c9 (oui Unknown), length 300 10:46:05.000212 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0f:f7:4b:8b:c9 (oui Unknown), length 300 10:46:19.000216 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0f:f7:4b:8b:c9 (oui Unknown), length 300 10:46:39.000085 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0f:f7:4b:8b:c9 (oui Unknown), length 300 I have gkrellm, so I can see the link meter go up when I do ifup, but I never get an IP This system is also dual-boot with Vista and wireless works fine there. Any help is appreciated. Thanks. |
Check that ipw3945d is running. On my system it occasionally fails to run (or maybe it quits unexpectedly) but the result is that the system can't actually negotiate a connection. The essid, channel, and so on will be set and you can even scan the available networks, but if you use 'iwconfig' you will see a "connection quality" of 0/100.
|
Quote:
Quote:
|
I've been using iwl3945 all along (as listed with lsmod in my previous post). I can see that it is associating with an access point, but no ip is ever received. I might suspect the firewall (iptables), but I haven't made any changes to it in a long time and wireless was working fine before. I don't think I have IPv6 support for iptables compiled in the kernel, so I could suspect something was changed with one network I connect to that way, but not both at the same time. These are both open networks BTW. I'm thinking it must be something in the kernel that I didn't create (because it got moved, etc.) or perhaps a package that was upgraded (although I've gone back and tried to add back packages I thought were relevant, etc). Thanks for the responses.
|
Can you post the output of:
iwconfig eth1 (or whatever your wireless device is called) Also post your iptables rules: iptables -L If it were an iptables problem, what usually happens is that you get an IP address and everything, but the rules prevent any routing. As for the radio, you can set all the parameters except for frequency and 'iwconfig' will show access points and everything, but the message "unassociated" will appear somewhere and you'll also have a "signal quality: 0/100". The other thing to check is that you have the correct firmware; I still use the 'ipw' driver and the daemon, but Intel has put all the necessary functions into the firmware and eliminated the ipw daemon. |
# iwconfig wlan0
wlan0 IEEE 802.11abg ESSID:"NETGEAR" Mode:Managed Frequency:2.412 GHz Access Point: 00:1F:33:23:8E:0A Bit Rate=54 Mb/s Tx-Power=15 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Power Management:off Link Quality=45/100 Signal level:-82 dBm Noise level=-127 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 iptables -L Chain INPUT (policy DROP) target prot opt source destination DROP all -- anywhere anywhere state INVALID ACCEPT all -- anywhere anywhere LOG all -- loopback/8 anywhere LOG level warning DROP all -- loopback/8 anywhere ACCEPT all -- 10.0.0.0 anywhere check_blocked all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU ACCEPT all -- anywhere anywhere TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU ACCEPT all -- anywhere anywhere Chain check_blocked (1 references) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED check_tcp tcp -- anywhere anywhere check_udp udp -- anywhere anywhere check_icmp icmp -- anywhere anywhere Chain check_icmp (1 references) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp fragmentation-needed Chain check_tcp (1 references) target prot opt source destination DROP tcp -- anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN ACCEPT tcp -- anywhere anywhere tcp dpt:postgresql ACCEPT tcp -- anywhere anywhere tcp spt:www ACCEPT tcp -- anywhere anywhere tcp spt:bootpc Chain check_udp (1 references) target prot opt source destination DROP udp -- anywhere anywhere udp dpts:loc-srv:netbios-ssn ACCEPT udp -- anywhere anywhere ACCEPT udp -- anywhere anywhere udp spt:domain The firmware is the latest in Debian testing and is the same that I used before. |
Well, the radio is up and running (and even associated) but DHCP is failing.
Your iptables rules look whacky - have they been changed lately? For example, in the INPUT side: Quote:
Anyway, try dropping the iptables rules and then sending a dhcp request: iptables -F dhclient wlan0 If that works then you need to work on your iptables rules. |
iptables -F didn't do anything for me (still no dhcpoffers). I also changed the default policy of the INPUT and OUTPUT chains to ACCEPT. I didn't think it would be the firewall because it was working before, but thanks for the tip. I even tried dpkg-reconfigure firmware-iwlwifi but that didn't do any good either. I might have to try another kernel ,maybe 2.6.26 something to get this to work. I think maybe before I had accidently bumped the kill switch or something was the reason it stopped working.
|
Using kernel 2.6.26.5 fixes the problem, so I'll live with it for now. I haven't been able to find a reason why the newer kernel doesn't work. Thanks for the help.
|
Well, it's good it works with the earlier kernel. See if you can find any bug reports filed against the other kernel. I don't know if Intel maintain the driver, but you can check the website for the driver and see if anyone has asked about the driver working in 2.6.X but not in 2.6.Y.
If you happen to have the sources for both, a 'diff' between the good driver and the bad one might help (unless the changes were in other parts like the 802.11 stack). |
The newest stable kernel 2.6.28 (released 12/24/08) works fine also.
|
All times are GMT -5. The time now is 06:08 PM. |