Bugzilla – Bug 1112
ipw3945 cannot ping in Ad-Hoc mode
Last modified: 2008-12-08 22:10:41
You need to log in before you can comment on or make changes to this bug.
Hi, I'm using this same setup in Windows successfully. I have an old Compaq laptop with ipw2100 which works perfect. Earlier I was using Ad-Hoc mode with ipw2100 and ipw2200 on another Dell laptop. With a new Dell laptop which has ipw3945, I've configured everything as I had done with earlier machines. But I'm not able to ping the machine. Under Windows, it works perfect. I searched and found that similar issues were seen earlier with ipw2200 also. I also used ethereal to see what was happening: The machine sends ARP request like, "Who has 192.168.1.1? Tell 192.168.1.2" And this is the only message in the entire log. Kernel: 2.6.17 (stock) No wireless security used. Thanks, Ritesh
Sorry, the error message I get is: Destination Host Unreachable.
Did iwconfig tell you that you have associated successfully? You have assigned IP address for both machines, right? Please attach the dmesg on the 3945 latop.
Yes, it did. That's why I filed a bug. If it didn't associate, it would be a different bug. In IBSSS mode, the Cell address for both laptops needs to be the same, and it was the same for both. Both had Network Settings configured properly. The problem is that it doesn't ping. I've attached the dmesg output. Note: Currently I'm using it at Office in Managed mode and it works perfect.
Created an attachment (id=908) [details] dmesg log
I'm not sure if ipw3945 is the only culprit. There might be chances that the userspace daemons might also be the reason. But in this case I doubt that because iwconfig reports that it is associated with the proper network in proper mode with proper essid. Mode: Ad-Hoc essid: Home But it doesn't ping. I feel it is related to ipw3945 because as per the bug database such issues were seen earlier also with ipw2200 drivers.
I wonder if you can provide info like: 1- type of the two machine you are using in the ad-hoc network and the OS on them 2- a step you did in both the machine until you get the no ping status. 3- the output if iwconfig on both machine. 4- ifconfig on both. 4- and please try to load the driver with debug=0x637ff then capture the dmesg log so we can have more detailed messgaes.
1- type of the two machine you are using in the ad-hoc network and the OS on them Machine-1 (which is the old machine): Compaq Presario 2203AL Pentium M 1.5 Ghz IPW2100 Debian GNU/Linux Linux - 2.6.17.8 Machine-2 (which is the new machine): Dell XPS M1210 Intel Dual Core 2.0Ghz IPW3945 Debian GNU/Linux Linux - 2.6.17.8 2- a step you did in both the machine until you get the no ping status. So Machine-1 has been working perfect with other laptops running Windows (both present XPS and earlier Latitude D600). Machine-1 also worked perfectly with Dell Latitude D600 under Linux which had IPW2200. The current machine (Machine-2) doesn't ping to Machine-1 under Ad-Hoc mode. I've configured Machine-2 to use Ad-Hoc mode. I've associated it to ESSID I use i.e. Home Machine-2's iwconfig shows everything correct. It shows that it as the Mode, ESSID and Cell# But doing a ping to Machine-1 from Machine-2 results in "Destination Host Unreachable" 3- the output if iwconfig on both machine. Machine-1: learner:~# iwconfig eth2 eth2 IEEE 802.11b ESSID:"Home" Nickname:"ipw2100" Mode:Ad-Hoc Frequency:2.422 GHz Cell: 02:0C:F1:39:C1:A8 Bit Rate=0 kb/s Tx-Power:16 dBm Retry min limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=97/100 Signal level=-36 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:10 Invalid misc:0 Missed beacon:0 Machine-2: xps:~# iwconfig eth2 eth2 IEEE 802.11b ESSID:"Home" Mode:Ad-Hoc Frequency:2.422 GHz Cell: 02:0C:F1:39:C1:A8 Bit Rate:11 Mb/s Tx-Power:13 dBm Retry limit:15 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=97/100 Signal level=-27 dBm Noise level=-28 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:82 Missed beacon:0 4- ifconfig on both. Machine-1: learner:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:C0:9F:49:61:A4 inet addr:210.18.182.33 Bcast:210.18.182.255 Mask:255.255.255.0 inet6 addr: fe80::2c0:9fff:fe49:61a4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:936546 errors:0 dropped:0 overruns:0 frame:0 TX packets:120753 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:105391858 (100.5 MiB) TX bytes:40774769 (38.8 MiB) Interrupt:10 Base address:0x3000 eth2 Link encap:Ethernet HWaddr 00:0C:F1:36:53:B0 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20c:f1ff:fe36:53b0/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:626 errors:0 dropped:0 overruns:0 frame:0 TX packets:1195 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:232355 (226.9 KiB) TX bytes:278667 (272.1 KiB) Interrupt:11 Base address:0x2000 Memory:e0204000-e0204fff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:21749 errors:0 dropped:0 overruns:0 frame:0 TX packets:21749 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:17701636 (16.8 MiB) TX bytes:17701636 (16.8 MiB) Machine-2: xps:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:15:C5:45:48:E8 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:177 eth2 Link encap:Ethernet HWaddr 00:13:02:B7:7A:7E inet addr:169.254.85.219 Bcast:169.254.255.255 Mask:255.255.0.0 inet6 addr: fe80::213:2ff:feb7:7a7e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:148 errors:0 dropped:82 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:702 (702.0 b) Interrupt:177 Base address:0x8000 Memory:dcfff000-dcffffff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Note: eth0 doesn't have an IP address because that interface is configured to use dhcp which works only when I use the laptop at office. 4- and please try to load the driver with debug=0x637ff then capture the dmesg log so we can have more detailed messgaes. Execute the following command. modprobe ipw3945 debug=0x637ff Dmesg last couple of lines output: Bluetooth: RFCOMM ver 1.7 NET: Registered protocol family 10 lo: Disabled Privacy Extensions ADDRCONF(NETDEV_UP): eth0: link is not ready ADDRCONF(NETDEV_UP): eth2: link is not ready IPv6 over IPv4 tunneling driver NET: Registered protocol family 4 NET: Registered protocol family 3 NET: Registered protocol family 5 ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready eth2: no IPv6 routers present ADDRCONF(NETDEV_UP): eth2: link is not ready ieee80211_crypt: unregistered algorithm 'NULL' ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, 1.1.13 ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com> ipw3945: Intel(R) PRO/Wireless 3945 Network Connection driver for Linux, 1.0.5dmp ipw3945: Copyright(c) 2003-2006 Intel Corporation ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 17 (level, low) -> IRQ 177 PCI: Setting latency timer of device 0000:0c:00.0 to 64 ipw3945: Detected Intel PRO/Wireless 3945ABG Network Connection ipw3945: Detected geography ABG (13 802.11bg channels, 4 802.11a channels) I don't think there should be a configuration issue with Machine-1 because the XPS machine when booted with Windows works perfect in Ad-Hoc mode. Thanks, Ritesh
Any update on whether you were able to reproduce the bug ?
The IP address of machine 1 is 192.168.1.1, while machine 2 is 169.254.85.219. They are not in the same segment. Furthermore please ping with "-I eth2", in case the default route is set to eth1 (wired network).
I wonder how that came. Probably it took up the office address. But if you notice in my first comment, I've given reports of ethereal also. At that test point, the network interface was properly configured. Anyway, here are more details: geeKISSexy:~/ipw# cat ifconfig eth2 Link encap:Ethernet HWaddr 00:13:02:B7:7A:7E inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::213:2ff:feb7:7a7e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:111 errors:0 dropped:3 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1542 (1.5 KiB) TX bytes:540 (540.0 b) Interrupt:177 Base address:0xa000 Memory:dcfff000-dcffffff lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:175 errors:0 dropped:0 overruns:0 frame:0 TX packets:175 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:14765 (14.4 KiB) TX bytes:14765 (14.4 KiB) geeKISSexy:~/ipw# cat ip-a 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:15:c5:45:48:e8 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ieee1394 35:4f:c0:00:22:26:c8:38 brd ff:ff:ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:13:02:b7:7a:7e brd ff:ff:ff:ff:ff:ff inet 192.168.1.2/24 brd 192.168.1.255 scope global eth2 inet6 fe80::213:2ff:feb7:7a7e/64 scope link valid_lft forever preferred_lft forever 5: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 geeKISSexy:~/ipw# cat iwconfig eth2 IEEE 802.11b ESSID:"Home" Mode:Ad-Hoc Frequency:2.422 GHz Cell: 02:0C:F1:39:10:8C Bit Rate:11 Mb/s Tx-Power:13 dBm Retry limit:15 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=93/100 Signal level=-37 dBm Noise level=-38 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:3 Missed beacon:0 geeKISSexy:~/ipw# cat ping-I geeKISSexy:~/ipw# ping -I eth2 192.168.1.1 PING 192.168.1.1 (192.168.1.1) from 192.168.1.2 eth2: 56(84) bytes of data. From 192.168.1.2 icmp_seq=2 Destination Host Unreachable From 192.168.1.2 icmp_seq=3 Destination Host Unreachable From 192.168.1.2 icmp_seq=4 Destination Host Unreachable From 192.168.1.2 icmp_seq=6 Destination Host Unreachable From 192.168.1.2 icmp_seq=7 Destination Host Unreachable From 192.168.1.2 icmp_seq=8 Destination Host Unreachable --- 192.168.1.1 ping statistics --- 8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6998ms , pipe 3 geeKISSexy:~/ipw# cat route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth2 geeKISSexy:~/ipw# tcpdump -i eth2 -v tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes 11:44:08.222569 arp who-has 192.168.1.1 tell 192.168.1.2 1 packets captured 28 packets received by filter 0 packets dropped by kernel Another friend of mine also owns the same machine (Dell XPS M1210) and has confirmed that he too sees the same problem. Have you tired it in your lab ? Is Ad-Hoc mode working for you with ipw3945 ?
Hi, Any updates ? Is there any additional information you want ?
Try this let ipw2100 machine first to create the adhoc network. then let 3945 machine join that network, make sure the adhoc network was created by 2100 machine and let us know if this will work. This not a solution ofcource.
I feel my setup is exactly the same as you're asking me to. My old laptop (which has ipw2100) is connected to a cable modem, hence it acts as the gateway. It is started first, and enables the Ad-Hoc mode network. Then I ifup my new laptop. It associates itself with the Ad-Hoc network but cannot ping. Just FYI, the Wireless Notification tool in KDE does show that both the wireless cards see each other, but they just don't ping each other. :-( Also, at workplace, ipw3945 works perfect in Managed mode. Is there something else you want me to try ?
(In reply to comment #13) > Is there something else you want me to try ? Does any of the Dell XPS M1210 has Windows installed? Can you try if the Windows driver works with ipw2100 or not?
(In reply to comment #14) > Does any of the Dell XPS M1210 has Windows installed? Can you try if the Windows > driver works with ipw2100 or not? Yes, it has Windows XP installed on it too. And under Windows it works perfect with the old laptop (which has ipw2100) in Ad-Hoc Mode. I've mentioned it in the earlier comments also.
Hi, Do you have any update on this bug ? At least, it'd be great if you could confirm whether you were able to reproduce the bug at your labs or not.
I've also noticed this problem on a few machines, perhaps I can offer some additional information that may help in debugging. I've tried establishing an ad-hoc connection between an ipw3945 machine and two ipw2100 machines (not simultaneously). The ipw3945 machine will not cooperate with either ipw2100 machines, but the two ipw2100 machines will link in an ad-hoc network just fine. Here's some details: The ad-hoc network _is_ being established just fine. The two machines associate with each other, iwconfig reports correctly. Secondly, if I run dhcpd on the ipw3945 machine I can reliably obtain an IP address on the ipw2100 machine. Specifically, the ipw3945 sees all DHCPREQUESTS to 255.255.255.255:67 whether from 0.0.0.0:68 or 172.16.0.35:68 (a previous lease). As well, ipw3945 reponds to all these requests just fine, hence why the ipw2100 machine is able to get a lease. However, if I run dhcpd on the ipw2100 machine I can't obtain an IP address on the ipw3945 machine. The ipw3945 machine does send out the DHCPREQUEST, and the ipw2100 does receive it and respond, however the ipw3945 machine never sees the response. So it repeats sending out requests (and the other machine keeps responding) until it times out. Third, arp who-has requests from the ipw3945 machine go out to the ipw2100 machine, and the ipw2100 machine does reply but again the ipw3945 machine doesn't see the reply. From the other direction, when the ipw2100 machine sends arp who-has requests the ipw3945 usually doesn't see them, however on rare occasion the ipw3945 machine does see the arp request and replies (which the ipw2100 machine receives). Fourth, pings from the ipw3945 machine are received by the ipw2100 machines and replied. The ipw3945 machine does not see any replies. Also, if a ping originates from the ipw2100 machine, the ipw3945 never sees the echo request. Fifth, broadcast pings from the ipw2100 machine to the network broadcast address (172.16.0.255) _are_ seen by the ipw3945 machine and responded too, and those responses are seen by the ipw2100 machine. This is working. Sixth, broadcast pings from the ipw3945 machine to the network broadcast address are seen by the ipw2100 machine and responded to, but the ipw3945 machine doesn't see the response. In summary: The ipw2100 sees all outgoing traffic from the ipw3945 machine and responds to it. The ipw3945 machine doesn't see any traffic from the ipw2100 machine except DHCPREQUESTS sent to 255.255.255.255:67, broadcast pings sent to 172.16.0.255, and in rare instances arp replies. So yeah, the obvious problem seems to be that the ipw3945 is not receiving any packets sent to it's IP address (172.16.0.1 in this case), but does receive packets sent to either broadcast address. Does this help, or can I do more debugging?
Created an attachment (id=923) [details] fix the avialable rate scale for ad-hoc Network please try against 1.1.0
We forgot to setup the rate scale availeble rates for AD-HOC network which might cause Tx in wrong rates. Please try out the patch and see if this fix the problem
The patch doesn't fix the issue. :-( I'm still suffering the same issue. I've attached the ethereal log. Probably that might be of some help.
Created an attachment (id=924) [details] ipw3945 ethereal log
Sorry for the late response. But yes, I'm also still having the same issues I saw previously. Also, the issue seems to be Rx related, possibly something related to address discrimination since I can see received packets, just not IP packets sent to non-network, non-broadcast addresses. Actually, I've just discovered that I can see echo requests sent to a non-broadcast address if I forge the broadcast address. That is, if the ipw2100 machine thinks that 172.16.0.5 is the broadcast address and I send pings to it, they're seen by the ipw3945 machine even if the broadcast address is actually set to 172.16.0.255. This doens't work if I send regular pings to 172.16.0.5. I haven't looked in detail, but there must be some difference in broadcast IP packets sent and regular packets that the ipw3945 machine is wrongly throwing away regular packets. Why this only affects the ipw3945 driver in ad-hoc mode, I have no idea.
Created an attachment (id=934) [details] set short slot please try this against 1.1.0
The second patch doesn't change any observed behavior. However, in further testing I discovered something of interest. It turns out that the ipw3945 card observes all packets sent to the broadcast MAC address (ff:ff:ff:ff:ff:ff) but fails to observe any packet sent to its specific MAC address (00:13:02:22:73:32). This is consistent with everything I've seen before. It responds to DHCP requests, arp who-has requests, and broadcast pings (all sent to ff:ff:ff:ff:ff:ff), but fails to see (or respond to) DHCP replies, arp repilies, and regular pings (all sent to 00:13:02:22:73:32). So somewhere it seems that the ipw3945 driver in ad-hoc mode fails to properly discriminate its own MAC address and blocks any ethernet frames sent to it. I believe that is the problem we're seeing. Hope this helps.
I've tried with the latest 2.6.18 kernel (ieee80211 git-1.1.13) and ipw3945 1.1.0 and it is still not fixed.
please try with both patch from comments #18 and #23.
Hong tried the patch from comment#18 and comment#23, the patches don't work. The problem is still there.
I have problems with dhcp and ipw3945 also in managed mode. The card sends the DHCP request but never sees the dhcp server reply. Sometimes it works, but it's random. I tried with 2.6.17-10-generic from ubuntu edgy with ieee80211 1.1.13 and ipw3945 1.1.0, and also with ieee80211 1.2.15. (In reply to comment #24) > The second patch doesn't change any observed behavior. > > However, in further testing I discovered something of interest. It turns out > that the ipw3945 card observes all packets sent to the broadcast MAC address > (ff:ff:ff:ff:ff:ff) but fails to observe any packet sent to its specific MAC > address (00:13:02:22:73:32). > > This is consistent with everything I've seen before. It responds to DHCP > requests, arp who-has requests, and broadcast pings (all sent to > ff:ff:ff:ff:ff:ff), but fails to see (or respond to) DHCP replies, arp > repilies, and regular pings (all sent to 00:13:02:22:73:32). > > So somewhere it seems that the ipw3945 driver in ad-hoc mode fails to properly > discriminate its own MAC address and blocks any ethernet frames sent to it. I > believe that is the problem we're seeing. > > Hope this helps.
(In reply to comment #29) > I have problems with dhcp and ipw3945 also in managed mode. The card sends the > DHCP request but never sees the dhcp server reply. Sometimes it works, but it's > random. > I tried with 2.6.17-10-generic from ubuntu edgy with ieee80211 1.1.13 and > ipw3945 1.1.0, and also with ieee80211 1.2.15. > No. You might be having configuration issues. I'm running ipw3945 in Managed mode with dhcp on a daily basis both at home and office. And it works good.
Created an attachment (id=949) [details] ipw3945 log (with one dhcp ack seen) this is the dump of packets seen on lan by ipw3945, please compare it to the other dump
Created an attachment (id=950) [details] dump of packets on lan this is the dump of packets seen on lan, compare to the other dump. Please notice that there are 3 dhcp acks sent. Ipw3945 see only the last ack.
I've attached a test done at home with a 3com router, wpa-psk encryption. The behaviour of ipw3945 is random. Sometimes the ipw3945 receive dhcp acks, but most of the time it don't see them. I tried also installing another distro (fedora core 5) on another partition. The behaviour is the same. It's not my router, at university (wep 128bit encryption) my network card don't get dhcp ack (only sometimes). It's not my card, using winxp it works flawlessy and gets dhcp configuration immediately both at home and the university. If you need to do some test please contact me, I could give you ssh access to my notebook. I forgot, my notebook is an HP Compaq nx7400.
Created an attachment (id=951) [details] packet dump @ university This is a packet dump done at university, with ipw3945, wep 128bit encryption. Output of dhclient: emi@portatile-emi: $ sudo ifup wlan Password: Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/wlan/00:13:02:41:0e:da Sending on LPF/wlan/00:13:02:41:0e:da Sending on Socket/fallback DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 12 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 10 DHCPOFFER from 192.168.42.6 DHCPREQUEST on wlan to 255.255.255.255 port 67 DHCPREQUEST on wlan to 255.255.255.255 port 67 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 3 DHCPOFFER from 192.168.42.6 DHCPREQUEST on wlan to 255.255.255.255 port 67 DHCPREQUEST on wlan to 255.255.255.255 port 67 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 18 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 18 DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 1 No DHCPOFFERS received. No working leases in persistent database - sleeping.
Is there any progress? I still have this problem with kernel 2.6.19-rc6+ ieee80211 1.2.15 and ipw3945 1.1.2. Should I have to open another bug with a different topic ("ipw3945 don't receive broadcast packets")? Is there anyone that has this problem? (In reply to comment #34) > Created an attachment (id=951) [edit] [details] > packet dump @ university > > This is a packet dump done at university, with ipw3945, wep 128bit encryption. > > Output of dhclient: > emi@portatile-emi: $ sudo ifup wlan > Password: > Internet Systems Consortium DHCP Client V3.0.4 > Copyright 2004-2006 Internet Systems Consortium. > All rights reserved. > For info, please visit http://www.isc.org/sw/dhcp/ > > Listening on LPF/wlan/00:13:02:41:0e:da > Sending on LPF/wlan/00:13:02:41:0e:da > Sending on Socket/fallback > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 4 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 13 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 12 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 10 > DHCPOFFER from 192.168.42.6 > DHCPREQUEST on wlan to 255.255.255.255 port 67 > DHCPREQUEST on wlan to 255.255.255.255 port 67 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 3 > DHCPOFFER from 192.168.42.6 > DHCPREQUEST on wlan to 255.255.255.255 port 67 > DHCPREQUEST on wlan to 255.255.255.255 port 67 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 5 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 10 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 18 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 18 > DHCPDISCOVER on wlan to 255.255.255.255 port 67 interval 1 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. >
Ping? I still have that problem, using kernel 2.6.19 + ieee80211 1.2.15 + ipw3945 1.1.3 It's not an smp related problem (I tried disabling dual core), it's not an hardware problem (when the card doesn't get dhcp, using windows it will function normally). Does anyone can help me? It's very annoying having to set manually the ip every time..
Hi James/Abbas/Jun, Do you have plans on fixing this ? This has been reported by many users again and again. Or do we expect users to buy an AP and forget this issue. ;-)
Has this been resolved meanwhile? I experience exactly this problem with version 1.2.2.
Not fixed the time I last checked it. But that was December 2006. As mentioned in Comment #37, I finally ended up buying a Wireless Router.
ipw3945 as a driver has been replaced by iwl3945 in official kernel for a long time. We suggest to use iwl3945 driver instead of the obsolete ipw3945 driver. If you have bug, please report it with product=iwlwifi and platform="Intel(R) Wifi Link 3945". Thanks so much!