ipw3945 doesn't reassociate after suspend

Bug #56421 reported by Ross Burton
14
Affects Status Importance Assigned to Milestone
Baltix
Invalid
Undecided
Unassigned
linux-source-2.6.17 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

On my old laptop (ThinkPad T40p, ipw2100) if I had the following in /etc/network/interfaces then after a suspend/resume cycle the network card had re-associated with the AP and network was usable again:

auto eth0
iface eth0 inet dhcp
        name home
        wireless-essid Burton
        wireless-key [snip]

However my new laptop (ThinkPad X60, ipw3945) with an identical configuration doesn't do this. After resume it's unassociated:

$ iwconfig eth0
eth0 unassociated ESSID:off/any
          Mode:Managed Frequency=nan kHz Access Point: Not-Associated
          Bit Rate:0 kb/s Tx-Power:16 dBm
          Retry limit:15 RTS thr:off Fragment thr:off
          Power Management:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

sudo ifdown eth0 && sudo ifup eth0 brings the network back, but I'd prefer not to have to do this every time I resume.

Note: the original reporter indicated the bug was in package 'linux-image-2.6.15-26-686'; however, that package was not published in Baltix.

Revision history for this message
Ross Burton (ross) wrote :

Damn, I forgot to change the distribution. Can the Baltix distribution be removed? (I suggest launchpad shouldn't pre-fill that field)

Revision history for this message
Dennis Kaarsemaker (dennis) wrote :

Rejecting accidental baltix task

Revision history for this message
apelete (apelete) wrote :

I have exactly the same bug running Ubuntu 6.06 on a Thinkpad X60.
After applying some changes in /etc/default/acpi-support (according to this page: https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadX60s), I was finally able to get suspend work (didn't work out of the box).

But when resuming from suspend, the laptop is unable to reconnect to the network using wifi (Intel 3945 wifi card).
I did not try to manually reassociate the laptop with my access point, but I shouldn't be forced to, it should work automatically after resume...

Revision history for this message
apelete (apelete) wrote :

Don't know if it is relevant to this bug report, but Suspend/Hibernate should work out of the box on 6.06 too.
Hoping some improvements in 6.06.2 maybe ?

Revision history for this message
merc (merc) wrote :

Hiya,

I am not sure this is gonna help.
However, I found that ifdown/ifup doesn't actually do the trick.

What you _actually_ need to do is this:

#!/bin/bash

#echo Killing the DHCP client...
killall dhclient3
rm /var/run/dhclient.eth1.pid

#echo Restarting the DHCP client...
dhclient3 -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp3/dhclient.eth1.leases eth1

This actually does the trick quite nicely.

I have no idea why this is. I know that dhclient3 is killed when the computer goes to sleep. But I don't understand what wakes it up, nor why it won't work "normally" as soon as the interface is up. Please note that it doesn't just take extra time - it will never connect.

If you want me to run more tests, all you have to do is ask!

Bye,

Merc.

Revision history for this message
merc (merc) wrote :

Hi,

Sorry, I should have said...

You should save the script as:

/etc/acpi/resume.d/99-tony.sh

And remember to set it as executable (chmod 755)

Merc.

Revision history for this message
Ben Collins (ben-collins) wrote : Re: [Bug 56421] Re: ipw3945 doesn't reassociate after suspend

On Sat, 2006-12-16 at 17:51 +0000, merc wrote:
> Hiya,
>
> I am not sure this is gonna help.
> However, I found that ifdown/ifup doesn't actually do the trick.
>
> What you _actually_ need to do is this:
>
>
> #!/bin/bash
>
> #echo Killing the DHCP client...
> killall dhclient3
> rm /var/run/dhclient.eth1.pid
>
> #echo Restarting the DHCP client...
> dhclient3 -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp3/dhclient.eth1.leases eth1

Then this is surely a userspace problem.

description: updated
Revision history for this message
merc (merc) wrote :

> Then this is surely a userspace problem.

...is anybody dealing with this?
My script now reads:

#!/bin/bash

echo Killing dhclient3 and ipw3945d
killall dhclient3
killall /sbin/ipw3945d-2.6.19-7-generic

echo Wait 2 secs...
sleep 2

echo Taking the modules out
rmmod ipw3945
rmmod ieee80211

echo Deleting the PIDs
rm -f /var/run/ipw3945d.pid
rm -f /var/run/dhclient.eth1.pid

echo Wait 1 sec...
sleep 1

echo Inserting the ipw3945 module
modprobe ipw3945

echo Wait 1 sec...
sleep 1

echo Running the dhclient
dhclient3 -pf /var/run/dhclient.eth1.pid -lf /var/lib/dhcp3/dhclient.eth1.leases eth1

It took a lot of trial-and-error. I *suspect* it's the interaction with the ipw3945d daemon that makes everything go bananas...

Merc.

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Please review bug #63418 - it may match your problems, and there is a new ipw3945 coming for Feisty (and Edgy). If the new ipw3945 addresses the problems in this bug, please mark it as a dupe. Otherwise, well, we'll burn that bridge when we get there...!

Changed in linux-source-2.6.15:
status: Unconfirmed → Needs Info
Revision history for this message
Matthew Whitworth (mwhitworth) wrote :

I can report the same thing happening with my Acer Aspire 5610 laptop. The ipw3945 driver fails to reconnect after resuming, even after switching the wireless off and on again.

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Matthew, what Ubuntu release are you running? Would it be possible for you to test with Feisty? (Warning - development release, please be sure to backup all valuable data before testing.)

Revision history for this message
Matthew Whitworth (mwhitworth) wrote :

I'm currently running a fully-updated Edgy. Unfortunately, it's not
possible to test with Feisty at the moment. How else could I help?

On 2/13/07, Peter Whittaker <email address hidden> wrote:
> Matthew, what Ubuntu release are you running? Would it be possible for
> you to test with Feisty? (Warning - development release, please be sure
> to backup all valuable data before testing.)
>
> --
> ipw3945 doesn't reassociate after suspend
> https://launchpad.net/bugs/56421
>

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Matthew, there are a couple of possible paths. For maximum risk avoidance, wait for the new ipw3945 to be include in Edgy; if you feel like living on the Edge, upgrade your kernel outside of the normal channels (refer to bug #63418 for more information on both cases).

I lean toward the "wait" path, myself, if the system is otherwise stable and working (and the lack of ipw3945 after suspend isn't a show stopper).

Changed in linux-source-2.6.15:
status: Needs Info → Confirmed
Revision history for this message
Matthew Whitworth (mwhitworth) wrote :

Ok - any indications on how long until a new ipw3945 driver arrives?

On 2/13/07, Peter Whittaker <email address hidden> wrote:
> Matthew, there are a couple of possible paths. For maximum risk
> avoidance, wait for the new ipw3945 to be include in Edgy; if you feel
> like living on the Edge, upgrade your kernel outside of the normal
> channels (refer to bug #63418 for more information on both cases).
>
> I lean toward the "wait" path, myself, if the system is otherwise stable
> and working (and the lack of ipw3945 after suspend isn't a show
> stopper).
>
> ** Changed in: linux-source-2.6.15 (Ubuntu)
> Sourcepackagename: linux-source-2.6.15 => linux-source-2.6.17
> Status: Needs Info => Confirmed
>
> --
> ipw3945 doesn't reassociate after suspend
> https://launchpad.net/bugs/56421
>

Revision history for this message
Peter Whittaker (pwwnow) wrote :

On Tue, 2007-02-13 at 17:57 +0000, Matthew Whitworth wrote:
> any indications how long until a new ipw3945 driver arrives?

I think the best we can say is "it's in the queue", and the best we can
do is adopt patience as our byword...! (Crossing fingers and wishing
good karma on the kernel devs probably won't hurt either....)

Revision history for this message
ThomasDahlmann (tdd-lnxgeek) wrote :

Been working with this issue for some time now and the fix seems to be the ipw3945 daemon not running.

On my T60 wireless stops working after a couple of suspends/hipernations (never counted how many times though). Not until I read this bug did I see the connection between the daemon not running and the wireless problem. I've tried running the script provided by Merc and it seems to work out just fine. Will test it out for some time.

Revision history for this message
ThomasDahlmann (tdd-lnxgeek) wrote :

just added a simple change to the script to make it more flexible.

Instead of:
echo Killing dhclient3 and ipw3945d
killall dhclient3
killall /sbin/ipw3945d-2.6.19-7-generic

I made it:
echo Killing dhclient3 and ipw3945d
killall dhclient3
killall /sbin/ipw3945d-`uname -r`

Revision history for this message
merc (merc) wrote :

I just would like to be known that after the latest-est feisty update, my card has been reassociating completely fine - no need for the script.
Can everybody else confirm this?

Merc.

Revision history for this message
merc (merc) wrote :

Hi,

Also, this bug seems to be a duplicate of:

https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/83235

If so, it would be better to mark it as a duplicate - even better, aduplicate where the "main" one is apparently fixed!

Merc.

Revision history for this message
Jeremy Teale (jteale) wrote :

I can confirm that re-associating with an AP post suspend is now working again on Feisty.

Revision history for this message
Peter Whittaker (pwwnow) wrote :

Closing as fix released based on most recent comments.

Changed in linux-source-2.6.17:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.