Bug 455778

(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.

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'...

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

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.

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

I think severity is more than LOW

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?

We have now released -97 to stable. I don't think it fixes this...

Does that mean it's no use to try 87, 93 nor 97?

If you don't mind, I'd still like to know the results of trying -87.

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. 

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

P.S. 2.6.25-14 (stock F9) works just fine.

- Gilboa

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.

... 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 :))

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.

So are you saying that -97 works for you?  Can others confirm?

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

2.6.25.11-97.fc9.x86_64 working for me, although suspend seems less reliable
than under the .9-76 kernel.

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.

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.

This may be a false alarm. Please ignore unless someone else confirms.

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?