WiFi dis(re)connection/dropout thread

[edboston]

I've been through the security settings a million times over. Changing the security settings has never helped. Wifi is the only persistent problem I have.

I'll try a clean install just for the heck of it, but even that has never helped in the past. The best is when I do a full wipe and install, and then wifi starts failing on the first boot .

Sounds like it could be bad hardware then.

 

[philburkhardt]

Sounds like it could be bad hardware then.

Haha, no it's not my hardware. My hardware has been problem free. So, everyone here having wifi issues has faulty hardware because changing the security settings didn't fix it?

Isn't this the wifi dis(re)connection/dropout thread? So should we all just give up and blame it on hardware?

EDIT: It looks like I lost my static IP settings somehow. I just re-entered them, and my wifi seems to be rock solid (at the moment). I actually just had the fastest download speeds I have ever had on my nook. I'm gonna keep my fingers crossed and hope it sticks.

 

[rhester72]

Lease issue is fixed: http://review.cyanogenmod.com/#change,6098

I don't want to pretend the problems _I_ was having with WiFi are necessary the same as others...but I can say that I've been happily listening to Pandora for more than an hour at work (where I couldn't stay connected longer than 5 minutes) without so much as a blip. Thank you!

Rodney

 

[edboston]

Isn't this the wifi dis(re)connection/dropout thread? So should we all just give up and blame it on hardware?

EDIT: It looks like I lost my static IP settings somehow.

well, if the software is setup correctly, which in your case it sounds like it wasn't, then that would only leave a hardware issue to explain it. I never said or implied we should just give up and blame the hardware. Only saying if all the software fixes don't address the problem, it *could* be a hardware problem.

 

[philburkhardt]

well, if the software is setup correctly, which in your case it sounds like it wasn't, then that would only leave a hardware issue to explain it. I never said or implied we should just give up and blame the hardware. Only saying if all the software fixes don't address the problem, it *could* be a hardware problem.

I wouldn't exactly say it wasn't set up correctly, I am sure the majority of nook color users are not using a Static IP. But, I will admit that using a static IP seemed to help.

One thing I notice in alogcat is that when my wifi drops the log reads:

E/wpa_supplicant(1108): Ongoing Scan action...
D/NetworkLocator(3179):null cell state delivered
D/NetworkLocator(3179):null cell state delivered
D/NetworkLocator(3179):null cell state delivered

This seems to continue on, and then I don't have wifi until I turn it off and back on. I don't know that this has anything to do with it, just something I noticed.

This hasn't happened yet today, since I entered the static ip settings. But, I don't believe static ips have helped everyone.

 

[muness]

Lease issue is fixed: http://review.cyanogenmod.com/#change,6098

Indeed. No more needless lease renewal requests. Definitely fixes my NookColor wifi issues on the router that sends 9 year DHCP leases.

 

[Expatriotex]

posting to report that my wifi issues have been resolved with the release commit in nightly 102.

huge thank you to dalingrin

 

[christoophat]

I am running n102 which has this included, and my wifi is just as bad. It has been especially bad in the last 24 hours.

As is mine, same nightly + 6/13 kernel. Having to refresh wifi any time I want to use Pandora or Netflix. Wifi icon stays green even when app report no connection.

 

[rhester72]

I'm afraid I may have spoken too soon on this one - or we had more than one issue.

It worked well for a few days, but now, even with the stock kernel and conservative governor (seems the safest choice for testing) on n103, if I run nothing but Pandora in the background and let it sit for 60 seconds until the screen turns itself off, Pandora cuts out at that exact instant. Turn the screen back on and the wifi icon shows green but no actual connectivity. Recycling wifi brings it back.

I've also re-encountered the nothing-shows-up-on-a-wifi-scan-unless-you-delete-every-remembered-entry problem.

Rodney

 

[paleh0rse]

I'm afraid I may have spoken too soon on this one - or we had more than one issue.

It worked well for a few days, but now, even with the stock kernel and conservative governor (seems the safest choice for testing) on n103, if I run nothing but Pandora in the background and let it sit for 60 seconds until the screen turns itself off, Pandora cuts out at that exact instant. Turn the screen back on and the wifi icon shows green but no actual connectivity. Recycling wifi brings it back.

I've also re-encountered the nothing-shows-up-on-a-wifi-scan-unless-you-delete-every-remembered-entry problem.

Rodney

Would Pandora normally override the wifi setting "turn off when screen is off"? Perhaps it requires you to set wifi to "always on"?

 

[rhester72]

Pandora keeps the screen awake on its own, but I've also set wifi to always on so I can test by keeping the CPU Spy screen up.

I'm getting a bit closer to understanding this, but there are so many variables...right now I'm working on an assumption that having more than one wifi connection defined causes trouble regardless of kernel, but there seems to be something specific to the 0616 test kernel even then (maybe related to governor)?

Lots of combinations to test through :/

Rodney

 

[rhester72]

OK, I have a somewhat-convoluted but reliable way to reproduce this, and it seems to be peripherally related to ondemand (see below):

1) Flash the 0616 test kernel
2) Reboot
3) Set governor to ondemand
4) Set wifi to always on (haven't had a SOD from this so far, thank God!)
5) Set the display timeout to 1 minute
6) Start up Pandora and let it begin streaming
7) Hit the n/home button
8) Let it sit on the home screen until the display shuts off
9) Wait patiently another 2-3 minutes and observe in wonder as the wifi goes away and the sound stops
10) Verify wifi is toast by trying to open the Market (without attempting to manually toggle wifi off/on) and see that despite the pretty green icon you have no connectivity

Lather, rinse, repeat with conservative in step 3 and see that it will not fail/disconnect. I did my testing on n103.

Rodney

UPDATE: OK, so it happens on conservative (with the OC kernel) as well, but seems to take a lot longer to trigger (it went for more than 15 minutes before wifi died). Will retest all with stock.

UPDATE 2: With n103 stock and ondemand (and wifi again set to always on), you lose wifi the _instant_ the screen shuts off...you can literally watch it happen in perfect synchronicity (at least the OC kernel had the good graces to wait a minute or two to kill off wifi). Testing stock conservative now.

UPDATE 3: n103 stock and conservative stubbornly refuses to fail after 40+ minutes. It would seem that's the only combination thus far that hasn't failed. This seems to suggest that a) there's a definite issue with ondemand, and b) there's something else about the OC kernel outside of the scheduler that causes a behaviorally similar problem.

UPDATE 4: stock+conservative finally died as well, more than two hours later. The difference is that the wifi icon actually turned white instead of remaining green, so at least you know you have no connectivity. Cycling wifi made it come back, but it's still a mystery to me why we lose it anyway, and why it seems sensitive to both kernel and scheduler (obviously that means it's not a DHCP thing).

 

[bonald]

Samething here, wifi drops especialy when downloading large files.
Using OC kernel with 102 NL.

Sent from my NookColor using Tapatalk

 

[rhester72]

Testing completed, see all updates at the bottom of the post 2 above this one.

Stock kernel + conservative appears to be the only way to fly at the moment for full stability.

Rodney

 

[mr_fosi]

My wifi has suddenly started acting hinky.

I haven't seen any descriptions of my problem and this seemed like the place to bring it up so, here it is.

I have had problems seeing the WRT54G WEP-secured network at my work for some time. It has been a problem since the n86+ releases. The AP was active, other device's connections were fine, but the NC wouldn't see it. If I left it on with the wifi connected, after 5-15 min it often would suddenly see the WEP and connect to it. Once connected it would keep it for as long as I left it.

I am currently on EMMC n105 with the 06/13 kernel and the ONDEMAND gov, but the behavior I am about to describe was also in force when I use the stock n105 and n102 kernels as well.

Not having installed anything new, my formerly rock solid wifi will now not connect to APs (any APs!) about 80% of the time.

- It doesn't matter if an AP is secured or not, doesn't matter if it's remembered or not.

- I will turn the wifi on in wireless settings and I will watch for my list of remembered APs to pop up. 50% of the time, no list pops up, though it says it's scanning. It will never pop up, nor connect to anything if I let it go.

- If I cycle the wifi sometimes the remembered AP list shows up but often it will not list any in range even though several of them are well within range.

- If I cycle the wifi several times while crossing my fingers and standing on my head while singing Kumbaya, sometimes the list of remembered APs will pop up along with some non-remembered ones and I am able to connect to an AP.

I've wiped caches and flashed new releases and the behavior has been consistent.

 

[rhester72]

If you do a wifi scan and see nothing but remembered devices, try removing _all_ remembered devices (yeah, I know, it's a PITA), then toggle wifi off and back on.

This is proving to be as hard to get to the bottom of as the SOD.

On a positive note, my reports above seem to be faulty, because it appears Pandora is _not_ the best test vehicle for connectivity. =) A simple terminal ping test exonerated the kernel and scheduler - I've been rocking solid WPA2/AES connectivity to the AP I've had the worst experience with for more than 2 hours (a new record!).

Now, as for why Pandora suddenly decides to crap itself and take wifi with it, that's another matter...

Rodney

 

[rhester72]

Oh, I forgot to mention...if you run a constant ping in the background (or presumably any other two-way communication with a transmit period less than the screen timeout), Pandora will seemingly run forever without problems or disconnects. That kinda suggests that wifi almost _needs_ outbound traffic periodically to prevent a problem.

Come to think of it - some modern PCI NICs will put themselves into hybrid sleep if there are no outbound packets for X minutes. Is it possible that (some of) the wifi disconnects are the radio itself going to sleep, independent of the CPU/OS?

Rodney

 

[rhester72]

One more data point...

Eventually, Pandora crapped out even with the background ping running. That's not the interesting part.

The interesting part is the following from pings after the wifi dropped (though the icon still shows green):

ping: sendmsg: No buffer space available

No buffer space available? Hrm...

Rodney

 

[quai]

I was having the problem of being connected and wifi would stop working after about 2 minutes. The connection never dropped I just had no internet. I would have to disable then enable the wifi every 2 minutes. Now none of this started happening till I changed my router to a netgear. I went in to my settings and noticed that the ip address was different from what my old d-link router was, which I had to change on that due to a conflict with my dsl modem. So I changed my new netgear router to the same ip as the old d-link and fixed my issue completely. No wifi disconnects or problems whatsoever! Something to try or consider.

 

[EnTg888]

It appears that Nightly 106 solved this problem, probably due to the wifi driver update. it's been going good for at least an hour or so now, whereas before it wouldn't last more than 2 min before dying.