Bug 455778 - kernel-2.6.25.10-86 iwl4965 can't transmit after association
kernel-2.6.25.10-86 iwl4965 can't transmit after association
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: John W. Linville
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-17 13:40 EDT by Dax Kelson
Modified: 2008-12-01 08:03 EST (History)
5 users (show)

See Also:
Fixed In Version: 2.6.25.11-97.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-31 10:20:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dax Kelson 2008-07-17 13:40:13 EDT
Description of problem:

Thinkpad T61p

kernel-2.6.25.9-76.fc9.x86_64 works normally
kernel-2.6.25.10-86.fc9.x86_64 NOT OK

Both at home and at work, when I try to use wireless with
kernel-2.6.25.10-86.fc9.x86_64:

1. It is able to associate, and
2. It can receive IP packets (using wireshark to sniff wlan0 I can see broadcast
and multicast packets), BUT
3. It CAN NOT send packets successfully. The DHCP DISCOVER packets are not seen
when sniff on the AP. When I statically configure an IP address on wlan0, the
ARP requests are not seen when sniffing on the AP.

The work AP is a Cisco 1130 an the home AP is a Dlink WG302.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Dax Kelson 2008-07-17 17:42:56 EDT
(In reply to comment #0)
> Description of problem:
> 
> Thinkpad T61p
> 
> kernel-2.6.25.9-76.fc9.x86_64 works normally
> kernel-2.6.25.10-86.fc9.x86_64 NOT OK
> 
> Both at home and at work, when I try to use wireless with
> kernel-2.6.25.10-86.fc9.x86_64:
> 
> 1. It is able to associate, and
> 2. It can receive IP packets (using wireshark to sniff wlan0 I can see broadcast
> and multicast packets), BUT
> 3. It CAN NOT send packets successfully. The DHCP DISCOVER packets are not seen
> when sniff on the AP. When I statically configure an IP address on wlan0, the
> ARP requests are not seen when sniffing on the AP.
> 
> The work AP is a Cisco 1130 an the home AP is a Dlink WG302.

I don't think it matters to this bug but the home AP is actually a DLink DIR655.
Comment 2 Johan Vromans 2008-07-18 17:30:08 EDT
I seem to have the same problem on i686 (Toshiba Satellite A200-237).

The same problem occurred with pre-2.6.25.6-55 kernels.
kernel 2.6.25.6-55 froze when the iwl4965 was used.
kernel 2.6.25.9-76 solved it.
kernel 2.6.25.10-86 problem re-appears.

I do not consider the urgency 'low'...
Comment 3 Matteo 2008-07-18 19:03:26 EDT
2.6.25.10-86 x86_64 kernel doesn't permit wi-fi to work.
I tryed it in an open network, without any encryption.

The same config is working with 2.6.25.9-76 kernel

dmesg is this:

ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: authenticate with AP $MAC_ADDRESS
wlan0: authenticated
wlan0: associate with AP $MAC_ADDRESS
wlan0: RX AssocResp from $MAC_ADDRESS (capab=0x401 status=0 aid=1)
wlan0: associated
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
wlan0: disassociating by local choice (reason=3)
wlan0: authenticate with AP $MAC_ADDRESS
wlan0: authenticate with AP $MAC_ADDRESS
wlan0: authenticated
wlan0: associate with AP $MAC_ADDRESS
wlan0: RX ReassocResp from $MAC_ADDRESS (capab=0x401 status=0 aid=1)
wlan0: associated
wlan0: no IPv6 routers present
wlan0: deauthenticated
wlan0: authenticate with AP $MAC_ADDRESS
wlan0: authenticate with AP $MAC_ADDRESS
wlan0: authenticate with AP $MAC_ADDRESS
wlan0: authentication with AP $MAC_ADDRESS timed out
Comment 4 Michael Ekstrand 2008-07-19 08:24:27 EDT
Similar problems: after upgrading to kernel-2.6.25.10-86.fc9, my iwl4965
wireless stopped working.

dmesg outputs the following:

wlan0: authenticate with AP 00:0b:85:5f:64:be
wlan0: authenticate with AP 00:0b:85:5f:64:be
wlan0: authenticate with AP 00:0b:85:5f:64:be
wlan0: authentication with AP 00:0b:85:5f:64:be timed out
iwl4965: Error sending TX power (-22)
iwl4965: Error sending TX power (-22)
iwl4965: Error sending TX power (-22)
iwl4965: Error sending TX power (-22)
iwl4965: Error sending TX power (-22)
iwl4965: Error sending TX power (-22)
<repeats of the above>
wlan0: authenticate with AP 00:0b:85:5f:71:2e
wlan0: authenticated
wlan0: associate with AP 00:0b:85:5f:71:2e
wlan0: RX ReassocResp from 00:0b:85:5f:71:2e (capab=0x431 status=0 aid=1)
wlan0: associated
wlan0: disassociating by local choice (reason=3)
wlan0: deauthenticated

Renders this kernel version unusable for me.
Comment 5 Mike Loseke 2008-07-21 12:01:15 EDT
I'm seeing the same issue using the iwl3945 on my T61 with
2.6.25.10-86.fc9.i686.  I had to go back to 2.6.25.6-55.fc9.i686 as that's the
most recent kernel that will allow me to associate to the WEP and WPA AP's I
need to use.  I don't have the dmesg output as above, but in messages, after it
associates and NM times out, I have these entries:

Jul 20 11:52:08 t61 kernel: iwl3945: No space for Tx
Jul 20 11:52:08 t61 kernel: iwl3945: Error sending REPLY_LEDS_CMD: iwl3945_enq
ueue_hcmd failed: -28
Comment 6 Matteo 2008-07-21 15:30:50 EDT
I think severity is more than LOW
Comment 7 John W. Linville 2008-07-24 21:29:14 EDT
On a hunch, please try the -87.fc9 kernel:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=55238

If that proves unsatisfactory, please try -93.fc9 or later:

   http://koji.fedoraproject.org/koji/buildinfo?buildID=56380

Do either (or both) of these kernels improve the situation?
Comment 8 Chuck Ebbert 2008-07-24 23:33:03 EDT
We have now released -97 to stable. I don't think it fixes this...
Comment 9 Johan Vromans 2008-07-25 05:18:31 EDT
Does that mean it's no use to try 87, 93 nor 97?
Comment 10 John W. Linville 2008-07-25 21:37:18 EDT
If you don't mind, I'd still like to know the results of trying -87.
Comment 11 Johan Vromans 2008-07-26 08:42:35 EDT
2.6.25.10-87.fc9.i686 seems to work occasionally. Associating is reliable, but
the address negociation frequently fails. If a connection is established, it
seems reliable. If not, the driver won't succeed anymore whatever you do. 
Comment 12 Gilboa Davara 2008-07-26 09:52:09 EDT
Hope I'm not abducting this BZ, but -87 doesn't work for me (Ad-hoc mode)

If I ping the T61/iwl4965 laptop from my rt61-equipped firewall, I can see the
firewall's arp requests hitting the T61 (and the T61's response) - but the
returning arp packets are never received by the rt61.

Other devices that use the same ad-hoc connection seem to work just fine.

- Gilboa
Comment 13 Gilboa Davara 2008-07-26 10:09:38 EDT
P.S. 2.6.25-14 (stock F9) works just fine.

- Gilboa
Comment 14 Johan Vromans 2008-07-26 10:11:31 EDT
With -87, I get often get good results when connecting manually:

  kill NetworkManager and nm-applet
  modprobe -r iwl4965
  wait some seconds
  modprobe iwl4965
  ifup wlan0

(Connection is to a WEP protected AP)

I get virtually never a successful connection when using the
NetworkManager/nm-applet combo.
Comment 15 Gilboa Davara 2008-07-26 10:16:27 EDT
... While filling the kernel log with:
wlan0: Configured IBSS beacon template
phy1: Adding new IBSS station XX:XX:XX:XX:XX:XX (dev=wlan0)

(Ending spam now :))
Comment 16 Kyrre Ness Sjøbæk 2008-07-30 15:58:20 EDT
I am also experiencing this - with kernel 2.6.25.11-97.fc9.x86_64 iwl seems to
work fine, but under kernel 2.6.25-14.fc9.x86_64 I can only connect to
unencrypted networks, and only unreliably. In NetworkManager, it fails waiting
for DHCP.

Also notable, is that it reports normal AP's as ad-hock, and unencrypted as
encrypted etc. in NM-applet. However it seems correct in "iwlist scanning", so
that *may* just be a bug in NetworkManager.

You should probably search component kernel/fedora9 for iwl3945, there seems to
be lots and lots of dupes in bugzilla.

dax: why is this bug set to needinfo - what info do you miss?

Machine is a Dell Lattitude D520.
Comment 17 John W. Linville 2008-07-30 16:45:58 EDT
So are you saying that -97 works for you?  Can others confirm?
Comment 18 Mike Loseke 2008-07-30 17:36:24 EDT
2.6.25.11-97.fc9.i686 is working for me, for both WEP and WPA networks that I
was seeing issues with.  This is on my T61 and iwl3945
Comment 19 Michael Ekstrand 2008-07-30 20:05:37 EDT
2.6.25.11-97.fc9.x86_64 working for me, although suspend seems less reliable
than under the .9-76 kernel.
Comment 20 Johan Vromans 2008-07-31 06:06:35 EDT
2.6.25.11-97.fc9.i686 WiFi seems to work for me. I use the cubbi tuxonice
kernel, and hibernate/resume seems slightly less (but not significantly)
reliable in combination with the iwl4965 module. Adding this module to the
blacklist may help.
Comment 21 Johan Vromans 2008-09-19 06:01:02 EDT
The problem is back again in kernel-2.6.26.3-29.fc9.i686.

After a hibernate/resume cycle, the iwl4965 cannot connect anymore but keeps emitting messages:
kernel: iwl4965: Error sending TX power (-22)

A module unload/reload helps.
Comment 22 Johan Vromans 2008-09-20 15:15:45 EDT
This may be a false alarm. Please ignore unless someone else confirms.
Comment 23 Francois-Xavier 'FiX' KOWALSKI 2008-12-01 08:03:57 EST
I confirm this issue.  I happens after every suspend/resume cycle (I did not try s2ram or d2disk), but also after a few minutes of working transmission.

I am running fc8/x86_64, on an HP 8510w.

kernel-2.6.25.14-69.fc8:
- iwl4965 works simply great, but...
- the SD/MMC reader does not work when the radio is activated (rf_kill switch turned on)

kernel-2.6.26.6-49.fc8:
- fixes the SD/MMC problem, but...
- fails on "kernel: iwl4965: Error sending TX power (-22)" after a few minutes of operation, or always after a suspend/resume cycle.

I have faced non-working iwl4965 since 2.6.26* was out on fc8.  I have been upgrading regularly at each kernel update to see whether this problem was fixed, with no luck so far.  Any trace I can activate to help trouble-shooting this?

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