Created attachment 593978 [details] Log file showing how dhcpclient gets timed out Description of problem: I use a "TL-WN722N USB WLAN" stick to connect to a "FRITZ!WLAN Repeater N/G" which in turn connects to an "P1 DV230 WiMax modem". I used a DVD to upgrade from F16 to F17. After the first boot the WiFi connection still worked. It stopped working after "yum update". What happens is that the dhcp client gets timed out (see attachment). I suspected the linux-firmware package. I rolled back from the version in Fedora Updates to the one in the Fedora 17 repo. The problem still occured. Updating dhcpclient to the one in "Updates testing" didn't help. After searching the internet I found somebody on archlinux describing my problem: https://bbs.archlinux.org/viewtopic.php?id=143848 I confirmed that booting in the older kernel solves the problem while it comes back in the newer. It is interesting that it also seems to depend on device you connect to. With kernel 3.4.3 I cannot connect to the Fritz Repeater, but I can still establish a connection with the P1 modem. Version-Release number of selected component (if applicable): kernel 3.3.4-5 - works as expected. No problems. kernel 3.4.3-1 - problem occurs How reproducible: Always Steps to Reproduce: 1. Upgrade to Kernel 3.4.3 2. Try to connect to a Fritz Repeater using TL-WN722N Actual results: dhcpclient gets timed out. No WLAN connection can be established. Expected results: WLAN stick connects Additional info: WLAN stick:http://www.tp-link.com/en/products/details/?model=TL-WN722N WLAN stick lsusb info: Bus 001 Device 006: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n NW Manager Driver: ath9k_htc Repeater: http://www.avm.de/de/Produkte/FRITZ_WLAN/FRITZ_WLAN_Repeater_NG/index.php Modem with WiFi: http://www.avm.de/de/Produkte/FRITZ_WLAN/FRITZ_WLAN_Repeater_NG/index.php (check info on DV230)
The Arch bug report mentions doing (as root) "ifconfig wlan0 promisc" before the DHCP attempt. That suggests that there may be some sort of filtering problem. Have you tried that? Did it make things work for you?
No. I have not tried this solution. Unfortunately I cannot confirm if it would help, because I found the problem on my parents computer. They live in another town. I only visited them last weekend. Their computer is currently running well on the older 3.3.4 kernel.
I have seen a few reports over the last 24 hours of issues with ath9k.
Can confirm this behavior with: Bus 001 Device 003: ID 057c:8403 AVM GmbH Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x057c AVM GmbH idProduct 0x8403 bcdDevice 5.11 iManufacturer 16 AVM Berlin iProduct 32 FRITZ!WLAN N2.4 iSerial 48 42AB7 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 60 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 6 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Whats also confusing is that the LED blinks very strange. Under Windows there is a green LED wich blinks (think thats somehow an "OK" LED which is not blinking in F17) When i set the IP fixed i can connect but can not ping anything, even the AP not. wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.102 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::be05:43ff:fe04:2ab7 prefixlen 64 scopeid 0x20<link> ether bc:05:43:04:2a:b7 txqueuelen 1000 (Ethernet) RX packets 36 bytes 5076 (4.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 190 bytes 43000 (41.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Will now try another kernel which should work as suggested.
Not working for me in 3.3.4-5.fc17.x86_64.debug Will compile now 3.0.36
Oliver, you probably want to stick with the 3.3 branch.
recent ath9k_htc fix and relevant thread http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commitdiff;h=931cb03afed7b541392295f3afc4638da32f08a0 http://permalink.gmane.org/gmane.linux.kernel.wireless.general/93461
Dan Mashal, comment 3 doesn't sound like a question. What info do you need from me about it?
correction: 3.3.4-5 works since 3.4 i cannot find my AP, so i can not test #7
John, I saw you as the assignee for this bug so I was wondering if you could provide more insight. Obviously, Mr. Shafi has done so already. Maybe he should be assigned to this ticket, I think this is his department is it not?
(In reply to comment #10) > John, > > I saw you as the assignee for this bug so I was wondering if you could > provide more insight. Obviously, Mr. Shafi has done so already. Maybe he > should be assigned to this ticket, I think this is his department is it not? hi i would just check out tomorrow with an AP with the above mentioned chip. thanks!
(In reply to comment #11) > (In reply to comment #10) > > John, > > > > I saw you as the assignee for this bug so I was wondering if you could > > provide more insight. Obviously, Mr. Shafi has done so already. Maybe he > > should be assigned to this ticket, I think this is his department is it not? > > hi i would just check out tomorrow with an AP with the above mentioned chip. > thanks! oops just found, i need to borrow AR9271 and check itout, another ath9k_htc seems to be ok with wireless-testing
Shafi, I see kernel 3.5 rc4 being built on Koji.. how long will this take to make it in to stable? Other people are reporting unrelated hardware problems with 3.4.
We are talking about the same fix as in bug 828731, right? Dan and others, have you tried the f17 test kernels from here? http://koji.fedoraproject.org/koji/taskinfo?taskID=4194787 Please give them a try and post the results here...thanks!
I tried it with 3.4.4-1 but my problem is not solved when i do iwlist wlan0 scanning it even did not find my AP - i guess the connection is to evil/bad so it is not displayed, but on the previous kernel its working 1a (3.3.x).
With 3.3.x kernel series i find much more APs btw.
John/Shafi, Can you let us know what fixes for what cards are in the newer kernels? I do not actually use a WLAN card myself personally but I'm wondering if there are fixes for other cards such as broadcom. I did see there was an intel update last night and also an update to 3.4.4-3. Can we get an official support matrix up somewhere on a wiki for this? This is a borderline "commonbug". Oliver, can you let us know if 3.4.4-3 kernel fixes your issue? It is in the latest "yum update". Thanks, Dan
Yes its working again, thanks.
*** This bug has been marked as a duplicate of bug 828731 ***
(In reply to comment #18) > Yes its working again, thanks. thanks a lot for verifying, i am able to verify it was working with another ath9k_htc chipset.
(In reply to comment #17) > John/Shafi, > > Can you let us know what fixes for what cards are in the newer kernels? I do > not actually use a WLAN card myself personally but I'm wondering if there > are fixes for other cards such as broadcom. I did see there was an intel > update last night and also an update to 3.4.4-3. > > Can we get an official support matrix up somewhere on a wiki for this? This > is a borderline "commonbug". > > Oliver, can you let us know if 3.4.4-3 kernel fixes your issue? It is in the > latest "yum update". > > Thanks, > Dan Hi Dan, i am aware of this fix is for ath9k_htc. thanks!
Mr Shafi, Yes I see that.. I was wondering about other wireless cards and if we can create some type of wiki support matrix for various cards.
Dan, please realize that Shafi is a Qualcomm/Atheros employee and probably has little interest in supporting cards from Broadcom/Intel/whomever. Beyond that, feel free to create whatever wiki support matrix you like -- you can retrieve information about that from the Fedora kernel package changelog and the output of 'git log' from the upstream "stable" kernel that Fedora uses as a base. I think you will find that it is very difficult to keep that information up to date with every change, but you are welcome to try. In any case, I think that your time might be better spent on issues in which you actually have a personal interest and/or for which you can provide actual constructive feedback towards their resolution. That would be a lot more helpful than providing random, ill-definied requests for other people to do work of questional usefulness.
Thanks.