Bug 834850 - kernel 3.4.3-1.fc17 causes a dhcp time out with ath9k_htc WLAN stick
Summary: kernel 3.4.3-1.fc17 causes a dhcp time out with ath9k_htc WLAN stick
Keywords:
Status: CLOSED DUPLICATE of bug 828731
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Dan Mashal
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-24 09:41 UTC by Matthias
Modified: 2012-07-02 14:57 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-02 13:33:37 UTC
Type: Bug


Attachments (Terms of Use)
Log file showing how dhcpclient gets timed out (6.55 KB, application/octet-stream)
2012-06-24 09:41 UTC, Matthias
no flags Details

Description Matthias 2012-06-24 09:41:44 UTC
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)

Comment 1 John W. Linville 2012-06-25 12:49:46 UTC
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?

Comment 2 Matthias 2012-06-25 13:27:08 UTC
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.

Comment 3 Dan Mashal 2012-06-25 14:03:35 UTC
I have seen a few reports over the last 24 hours of issues with ath9k.

Comment 4 bugzilla 2012-06-25 14:04:37 UTC
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.

Comment 5 bugzilla 2012-06-25 14:19:11 UTC
Not working for me in 3.3.4-5.fc17.x86_64.debug
Will compile now 3.0.36

Comment 6 Dan Mashal 2012-06-25 14:20:08 UTC
Oliver, you probably want to stick with the 3.3 branch.

Comment 8 John W. Linville 2012-06-25 15:10:41 UTC
Dan Mashal, comment 3 doesn't sound like a question.  What info do you need from me about it?

Comment 9 bugzilla 2012-06-25 15:59:30 UTC
correction: 3.3.4-5 works

since 3.4 i cannot find my AP, so i can not test #7

Comment 10 Dan Mashal 2012-06-25 16:03:12 UTC
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?

Comment 11 Mohammed Shafi 2012-06-25 16:13:56 UTC
(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!

Comment 12 Mohammed Shafi 2012-06-26 15:38:21 UTC
(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

Comment 13 Dan Mashal 2012-06-26 15:40:26 UTC
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.

Comment 14 John W. Linville 2012-06-26 16:19:22 UTC
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!

Comment 15 bugzilla 2012-06-26 19:19:54 UTC
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).

Comment 16 bugzilla 2012-06-26 19:22:32 UTC
With 3.3.x kernel series i find much more APs btw.

Comment 17 Dan Mashal 2012-07-01 19:57:52 UTC
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

Comment 18 bugzilla 2012-07-01 20:56:20 UTC
Yes its working again, thanks.

Comment 19 John W. Linville 2012-07-02 13:33:37 UTC

*** This bug has been marked as a duplicate of bug 828731 ***

Comment 20 Mohammed Shafi 2012-07-02 13:37:20 UTC
(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.

Comment 21 Mohammed Shafi 2012-07-02 13:45:12 UTC
(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!

Comment 22 Dan Mashal 2012-07-02 13:58:31 UTC
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.

Comment 23 John W. Linville 2012-07-02 14:33:38 UTC
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.

Comment 24 Dan Mashal 2012-07-02 14:57:35 UTC
Thanks.


Note You need to log in before you can comment on or make changes to this bug.