| View previous topic :: View next topic |
| Author |
Message |
Tub
n00b
Joined: 08 Feb 2005
Posts: 21
|
 Posted: Tue Aug 23, 2011 2:20 pm Post subject: Wlan dies after 30 seconds of inactivity |
 |
|
Hi,
bought a Lenovo X121e, having trouble with my wlan.
I can start the wlan and use it just fine. But as soon as about 30 seconds pass without network activity, the connection dies in a weird way:
- ifconfig still shows an IP
- wpa_gui still claims to be associated
- the last line in dmesg is still "wlan0: associated"
but
- Network is down. Pinging anything results in a long wait, then "Destination Host Unreachable", while wget says "No route to host".
- my access point's interface stops listing the netbook as an associated client
Doing /etc/init.d/net.wlan0 restart will bring the connection back up, but that's only temporary.
| Code: | 01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
Linux tubbook 3.0.3-gentoo #9 SMP Mon Aug 22 22:01:48 CEST 2011 x86_64 AMD E-350 Processor AuthenticAMD GNU/Linux
[ebuild R ] net-wireless/wpa_supplicant-0.7.3-r2 USE="dbus qt4 readline ssl -debug -eap-sim -fasteap -gnutls -madwifi (-ps3) -wimax -wps" 0 kB
|
Using the in-kernel driver (RTL8192CE) with the proper firmware (rtlwifi/rtl8192xfw.bin).
wpa_supplicant.conf has been copied from my old notebook. Worked before, should work now.
I'm not sure if "-Dwext" or "-Dnl80211" is the correct parameter in /etc/conf.d/net. Either seems to work, either leads to the problems mentioned above.
Any ideas what might be causing this? Disconnects after inactivity sounds like some power management feature, but why doesn't it come back up again? Any hints for further debugging?
_________________
m00 |
|
| Back to top |
|
 |
Tub
n00b
Joined: 08 Feb 2005
Posts: 21
|
| Posted: Wed Aug 24, 2011 8:31 pm Post subject: |
|
|
This is weird.
I've disabled wlan power management in the kernel, no changes.
I noticed that the wlan sometimes dies, even with activity. I can be fairly certain it dies once it's inactive, but have no guarantee that it'll stay up when active. Which rules out the basic 'ping $router' workaround as a long-term solution. Darn.
And the one that confuses me most: I'm currently connected to my AP, can access the net just fine, but the AP doesn't list my netbook as connected. I'm beginning to suspect that the AP isn't as innocent as it appears, so I'll try the netbook on a different AP as soon as I get a chance - but that won't be for a while.
Meanwhile, any helpful suggestions are appreciated!
_________________
m00 |
|
| Back to top |
|
|
robdd
Tux's lil' helper
Joined: 02 Jan 2005
Posts: 142
Location: Sydney Australia
|
| Posted: Mon Jul 23, 2012 1:20 pm Post subject: |
|
|
Tub,
I know your posts are nearly a year old, but if you're still having issues maybe the solution I found would help. Not sure if they're related:
https://forums.gentoo.org/viewtopic-p-7095916.html#7095916
Or if you did find a solution maybe you'd like to tell us about it ? I'm still not sure how reliable my WLAN connection will be after prolonged use, and if I'm going to have ongoing problems.
Regards, Rob.
_________________
Rob Diamond
Gentoo Hack, hack, hacker
Sydney, Australia |
|
| Back to top |
|
|
Tub
n00b
Joined: 08 Feb 2005
Posts: 21
|
| Posted: Mon Jul 23, 2012 3:29 pm Post subject: |
|
|
Wow, unexpected reply from the past. Thank you so much for taking the time!
My wlan is still quirky. I've started running a "ping $router" on a VT, the constant traffic seems to alleviate the problems. Each time I forget to run the ping after a reboot, the wlan disconnects after a while.
It's still not perfect, but was enough to to use the machine over the last.. oh, has is been a year already? I think the problem got better with subsequent kernel upgrades, but then again I may be imagining things. The wlan will only fail when I carry my laptop out of the access point's reach; often it won't pick up the signal again when reentering. /etc/init.d/net.wlan0 restart usually fixes this, but sometimes a complete reboot of my notebook or access point or even both is in order.
I've checked your download link, but the firmware included within is identical to the one from linux-firmware, at least the cfw ones.
| Code: | /lib/firmware/rtlwifi> md5sum updated/firmware/rtlwifi/*cfw*.bin *cfw*.bin | sort
660d5d7e1e1fd985261fb20b2ac283f6 rtl8192cfwU.bin
660d5d7e1e1fd985261fb20b2ac283f6 updated/firmware/rtlwifi/rtl8192cfwU.bin
748944fbffd3b08b5b1929bb6c7fc537 rtl8192cfw.bin
748944fbffd3b08b5b1929bb6c7fc537 updated/firmware/rtlwifi/rtl8192cfw.bin
dd371739aa401ea1d615436b24598bc4 rtl8192cfwU_B.bin
dd371739aa401ea1d615436b24598bc4 updated/firmware/rtlwifi/rtl8192cfwU_B.bin
~> emerge -pv linux-firmware
[ebuild R ~] sys-kernel/linux-firmware-20120708 USE="savedconfig" 0 kB
|
Just to be clear: are you suggesting renaming rtl8192cfwU_B.bin to rtl8192cfw.bin? Is there a reason why you expect these to be compatible, or were you just toying around and noticed that it works better that way?
I'm a bit reluctant to do such hacks, but if you report success, then I may try it out later this week.
Hmm.. I'd be really interested to see which firmware the windows drivers are using.
_________________
m00 |
|
| Back to top |
|
|
Thistled
Guru
Joined: 06 Jan 2011
Posts: 572
Location: Scotland
|
| Posted: Mon Jul 23, 2012 6:59 pm Post subject: |
|
|
Could it possibly have something to do with the type of wireless encryption?
I had a similar problem with a local network file server the other year, and the problem was resolved by changing the encryption to wpa2.
Weird, but it seemed to fix the problem.
_________________
Whatever you do, do it properly! |
|
| Back to top |
|
|
robdd
Tux's lil' helper
Joined: 02 Jan 2005
Posts: 142
Location: Sydney Australia
|
| Posted: Tue Jul 24, 2012 2:46 am Post subject: |
|
|
Hi Tub,
| Quote: | | Just to be clear: are you suggesting renaming rtl8192cfwU_B.bin to rtl8192cfw.bin? Is there a reason why you expect these to be compatible, or were you just toying around and noticed that it works better that way? |
I have no idea what the Realtek driver does when looking for firmware files - does it do a wildcard search for rtl8192cfw*.bin or something ? How does it know what is old and what is new ? My assumption was that it's pretty dumb, and just loads the file called "rtl8192cfw.bin", ignoring any other files. So I thought I'd try overwriting the old firmware file of that name with what *looked* like a newer version. Not very scientific maybe, but I'm an impatient old hacker. All I can say is that it worked for me - the WLAN driver seemed to load and use the changed file with the same old name.
If you had a bit of time you could experiment by deleting all the firmware files from the rtlwifi directory - the driver should fail to load anything. Then copy in the rtl8192cfwU_B.bin file ONLY, reboot and see if the driver can find firmware in a file of that name. And then.. you get the idea.
Anyway - best of luck, and Happy Gentoo'ing.
Regards, Rob.
_________________
Rob Diamond
Gentoo Hack, hack, hacker
Sydney, Australia |
|
| Back to top |
|
|
Tub
n00b
Joined: 08 Feb 2005
Posts: 21
|
| Posted: Wed Jul 25, 2012 11:29 am Post subject: |
|
|
| Thistled wrote: | | Could it possibly have something to do with the type of wireless encryption? |
Very doubtful. I've encountered these problems with any AP I've used over the past year. I'm already using WPA2 on most of them, and I value my network's integrity way too much to go back to WEP.
| robdd wrote: | | I have no idea what the Realtek driver does when looking for firmware files - does it do a wildcard search for rtl8192cfw*.bin or something ? |
I'm pretty sure it can't do that. The driver doesn't access the file system, it's using the kernel's firmware loader, and I'd be surprised if that supported wildcard matching.
Anyway, see drivers/net/wireless/rtlwifi/rtl8192ce/sw.c - it's the only file that turns up when grepping rtl8192cfw.
The default is rtl8192cfw.bin, which may be changed by this code:
| Code: | /* request fw */
if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
!IS_92C_SERIAL(rtlhal->version))
rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cfwU.bin";
else if (IS_81xxC_VENDOR_UMC_B_CUT(rtlhal->version))
rtlpriv->cfg->fw_name = "rtlwifi/rtl8192cfwU_B.bin";
|
So apparently they're not newer files of each other, but adjusted firmwares for slightly different versions of the hardware.
In other words, I don't think anything good will come out of messing with this.
_________________
m00 |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
