Gerard Robin wrote:
when my laptop starts, the connection wifi works fine, after that my laptop has hibernated, when I restart, all works fine except the connection wifi.
Depends what's wrong.Problem Level 1: Can you get the network working again by simply "dhclient eth1" (or whichever interface you're using for wifi)? If so, then all you need to do is to trigger a DHCP request upon wake-up.
Problem Level 2: If that doesn't fix it, try an "if-down eth1" and "if-up eth1" to see if physically bringing the interface down and up can get it going.
Problem Level 3: If *that* doesn't work, then your interface might have gone catatonic. I've had this happen to my machine a couple of times (in all fairness, it happens just as often with Windows, too), and the only thing that fixed it was turning off the wireless features of my laptop entirely (for my Dell, it's Fn-F2) and then turning it back on.
I've been experimenting with the hibernate tool, myself (you *did* say "hibernate", so I'm assuming that you're using the hibernate package, and not just "echo disk > /sys/power/state"). If you look through the hibernate conf file, you should come across a section that says:
### network # DownInterfaces eth0 # UpInterfaces autoI uncommented these (and changed eth0 to be the interface of my wifi) and things worked fine. This should work to fix problem types #1 and #2.
If your problem was #1 (like with me), there's probably a slicker way to do this than to just yank the interface off and on, incidentally. For example, in my case, I've got ifplugd watching my wired (eth0) interface and also the wifi (eth1). Ifplugd was originally made for wired ethernet and would watch for the link-beat from plugging in a network cable and would automatically trigger an if-up for the interface... and an if-down when the cable was pulled out. Since there's no cable that can be plugged in for wifi, ifplugd didn't used to work with it, but wpasupplicant (and maybe waproamd, but I haven't used it in a while) now simulates the link-beat of a cable insertion when it finds an access-point that it can talk to.
So... I can probably achieve what I want by telling wpasupplicant to re-associate:
wpa_cli -i eth1 reassociateI'm figuring that this would cause wpasupplicant to send an "unplugged" (and, if a suitable AP was found, a "plugged") message to be sent to ifplugd, which would probably trigger a new DHCP request. If I couldn't get wpasupplicant to fake unplug/replug event with a reassociate, then there's probably still a way to force ifplugd to run through the unplug/replug process *anyway*. I'm thinking that there are a couple of reasons why you might want to pursue this method anyway. 1) I imagine that it's possible that you could hibernate your laptop and then restart it at the same location. Wpasupplicant, even when forced to reassociate, might realize that it reassociated with the AP that it was just associated with... and not bother sending an unplug/replug to ifplugd... even when you might need to run a DHCP request. 2) You probably need to do things this way for *wired* interfaces. If you have your machine plugged into a wired port at home, then hibernate, and then plug it in at work and wake it up, I figure that ifplugd will never notice that the plug was ever messed with... when, in reality, you need to issue a DHCP request again.
Now, if your problem is #3... you might be screwed and be stuck toggling your laptop's wireless mode by hand.
I hope this helps. Let me know if you get any further with it. - Joe
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature