Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 455778 - kernel-2.6.25.10-86 iwl4965 can't transmit after association
Summary: kernel-2.6.25.10-86 iwl4965 can't transmit after association
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-17 17:40 UTC by Dax Kelson
Modified: 2008-12-01 13:03 UTC (History)
5 users (show)

Fixed In Version: 2.6.25.11-97.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-31 14:20:59 UTC


Attachments (Terms of Use)

Description Dax Kelson 2008-07-17 17:40:13 UTC
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 21:42:56 UTC
(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 21:30:08 UTC
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 23:03:26 UTC
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 12:24:27 UTC
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 16:01:15 UTC
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 19:30:50 UTC
I think severity is more than LOW

Comment 7 John W. Linville 2008-07-25 01:29:14 UTC
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-25 03:33:03 UTC
We have now released -97 to stable. I don't think it fixes this...

Comment 9 Johan Vromans 2008-07-25 09:18:31 UTC
Does that mean it's no use to try 87, 93 nor 97?

Comment 10 John W. Linville 2008-07-26 01:37:18 UTC
If you don't mind, I'd still like to know the results of trying -87.

Comment 11 Johan Vromans 2008-07-26 12:42:35 UTC
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 13:52:09 UTC
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 14:09:38 UTC
P.S. 2.6.25-14 (stock F9) works just fine.

- Gilboa

Comment 14 Johan Vromans 2008-07-26 14:11:31 UTC
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 14:16:27 UTC
... 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 19:58:20 UTC
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 20:45:58 UTC
So are you saying that -97 works for you?  Can others confirm?

Comment 18 Mike Loseke 2008-07-30 21:36:24 UTC
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-31 00:05:37 UTC
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 10:06:35 UTC
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 10:01:02 UTC
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 19:15:45 UTC
This may be a false alarm. Please ignore unless someone else confirms.

Comment 23 Francois-Xavier 'FiX' KOWALSKI 2008-12-01 13:03:57 UTC
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.