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.

That isn't needed with the iwl3945 driver


Have you always been using the iwl3945 driver or have you accidentally switched from ipw3945. I think you need different firmware for the two drivers.

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 thrff Fragment thr=2352 B
Encryption keyff
Power Managementff
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 dptostgresql
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:

The "ACCEPT all from 10.0.0.0 anywhere" as well as the third "ACCEPT all" are redundant.

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.