Bug 834850

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.