Toshiba laptop wireless problems

[TheCrust]

This is kind of in relation to this thread: http://www.edugeek.net/forums/networks/85092-toshiba-laptop-dropping-wireless-connection-only-school.html

 

I thought I would start another as the two problems are not necessarily related. This is a bit convoluted, but please stay with me!

 

 

Background: PFI school with a managed Cisco wireless network using a mix of 1252 and 1121-series Aironet access points and two Cisco 4402-50 Wireless LAN Controllers configured in a mobility group. 600 Toshiba laptops on site - all Tecra models split between M9, M10 and M11 varients. All laptops work faultlessly on our wireless (when the students haven't mucked around with the wireless on/off switch anyway )

 

Over the summer we purchased 120 Tecra R840 laptops to replace the same number of aging Tecra M5s. They arrived, we imaged them as usual using SCCM, and deployed them into their lapsafes. Nothing unusual about that.

 

 

The problem: Within days of the start of the year, we started getting calls about the new laptops not working. When examined, it seems that while they connect to our WLAN fine, they either won't stay connected to it, or report such wildly varying signal strength as to be practically unusable. Network access will randomly drop away.

 

Referring this issue to the reseller's technical support who liaised with Toshiba on our behalf, the first suggestion was to update the WLAN card drivers - which we did (to no effect). We were then told to change the power management settings - which we did as far as we are able as they are set via GP (also to no effect). We even changed some of the lightweight access points with another model to eliminate them being the problem. We put Toshiba's 64-bit Windows 7 Professional recovery image back onto a handful in case there was an issue with our 32-bit image, or the 32-bit drivers we had off Toshiba's website. This made no difference - the laptops continued to perform poorly on our wireless network.

 

We then took a batch of laptops off to try them on another wireless network - we are lucky enough to have a working relationship with a local place that does large events and conferences, and they kindly let us test a few on their press wireless network. Every laptop tested misbehaved in exactly the same way, confirming that our WLAN at school is not necessarily to blame.

 

A quick trip through Google highlighted that previously there seemed to be a large number of Dell users who had had issues with the same Intel Advanced-N 6230 wireless card now used in the Tecra R840. We passed this on to the reseller, and Toshiba who were now involved directly themselves.

 

At this point, Toshiba sent one of their QA engineers out to see us. He bought with him his own R840, but with a different Intel WLAN card in it - an Intel 6300 I think it was. This also misbehaved on our wireless, and he went away "happy" that the fault was with our WLAN despite being told the fault was reproducable elsewhere.

 

 

Today we have taken delivery of a Toshiba Satellite Pro - this one fitted with an Atheros WLAN card. Having checked it behaved perfectly on our WLAN, I asked one of the techs to swap the WLAN card with that in the R840 to see what happened.

 

The Satellite Pro, now with the R840's Advanced-N 6230 card in it, continued to behave impeccably on the wireless network.

The R840, now with the Satellite Pro's Atheros card in it (which behaved fine in the Satellite Pro remember), behaves better - but still reports varying signal strength.

 

 

Can I ask at this point, what inference most people here would draw from that observation? I know what I'm thinking right now, but it will be interesting to see if anyone else comes to the same conclusion, has seen similar behaviour and can give some pointers, or can suggest anything we haven't tried yet.

 

 

Thanks in advance!

[synaesthesia]

Not much I can add really, it seems to be one of those intemitten problems which are a complete bugger to narrow down. However, before you mentioned the wireless card in use, there was only one type of wifi card I knew would cause that sort of grief which Toshiba like to use - Atheros, most of which is to be avoided in any way shape or form. They really don't play nicely with enterprise level wireless systems and some of the older ones don't even like things as menial as WPA2 security without having to use 3rd party and very unofficial drivers.

Were exactly the same drivers being used when the R840's card was installed? Driver versions can make a whole lot of difference. I'd have also suggested power saving, transmit power etc but that's already been covered.

 

Is there anything on Google regarding those cards and Aironet systems? There's always going to be someone out there with the same setup and may well have had the same issues, however I'd imagine from what you've gone through so far a google search was one of the first things done.

Definitely worth hunting for unofficial drivers though - I find the most reliable ones are often those that are designed to help people do "naughty" things - for instance - argh, what's it called, when you drive round trying to find/crack poorly secured WiFi networks. Wardriving? Something daft. But those drivers are usually optimised for performance and throughput and may help narrow down to a software fault over hardware/design issues. I still wouldn't rule hardware/design problems out though, I've never been a fan of anything with a Toshiba badge and a wireless card in.

[TheCrust]

Were exactly the same drivers being used when the R840's card was installed?

 

Thanks for the thoughts.

 

Yes, when we put the R840's card into the Sat Pro we used the same revision of drivers, but couldn't use the same architecture - we had to use the x64 drivers to suit the pre-loaded OS on the Satellite Pro whereas our R840s use a 32-bit image.

 

Similarly when the Atheros card went into the R840, we used the same revision of drivers - but 32-bit - off the Toshiba support site to suit our image. I am aware of Atheros' "somewhat patchy" history of compatibility having been caught out before

 

I was more interested in what you made of the fact that the laptop with the R840's card continued to behave impeccably, but the R840 itself continued to exhibit problems, despite it having had another network card. OK, I need to test further and do accept some of what we saw may be down to the fact the Atheros WLAN card is shi.... um.... less than perfect - but wouldn't that suggest that there is something in the laptop itself that is causing the issue, as opposed to the wireless card?

Edited November 16, 2011 by TheCrust
spellung!

[synaesthesia]

There's not a huge amount that can go wrong otherwise so I'm not sure. Two other things I've just thought you could try, perhaps a fresh build of Windows but before doing that, maybe seeing if using a live CD of Ubuntu or similar might help - just to make sure it behaves properly on the wireless for a day or so. If it does, then it's almost certainly software related rather than hardware compatibility. Trouble then is, sometimes Linux is less sensitive to such minor incompatibilities than Windows is Makes life tough for us!

[TheCrust]

Hmmm.

 

While last night it looked like the R840 itself was to blame, this morning I've got a lot more intensive testing done - two Tecra R840s (one with the Atheros card in it) side-by-side with the Satellite Pro that got the Intel Advanced-N 6230 card. I let them run for over an hour on battery, on mains, viewing streamed content, running a constant ping, that sort of stuff.

 

The R840 with the Atheros card in it, while it did experience some minor fluctuation of signal, behaved pretty well as it should and only dropped its WLAN connection after being stood idle for over an hour.

The R840 and Satellite Pro with the Intel Advanced-N card in them reported massive signal fluctuation, and fell off the WLAN repeatedly - at exactly the same time on some occasions.

 

So it is looking like the issue itself is with the Intel card, or some form of incompatibility between the card and the WLAN.

[ToyHeartsFan]

I know you said you changed the power management settings but it does sound like this:

 

Intel® WiFi Products — Power save polling (PSP) causes connection issues with access points

[TheCrust]

Yeah, we thought that too - but following the advice on Intel's site makes no difference whatsoever.

 

We've restored a few of the laptops to the factory image to remove any chance of our GPO power management settings being permanently tattoo'd onto OS, and made sure we're using the latest drivers but have had no joy on that one. Whatever power management settings are used, the laptops just don't remain reliably connected to the WLAN.

 

All our other, older, Toshiba Tecra laptops just don't have this problem - at all, in any shape or form - and we have a "fair few" on-site to have tested with

[HilcrRWise]

I am far from an expert in this but could it be something to do with the way the antennas are routed in the laptops causing it to pick up interference from the laptop itself? Do your laptops have bluetooth installed, if so have you tried disabling it?

[ToyHeartsFan]

All our other, older, Toshiba Tecra laptops just don't have this problem - at all, in any shape or form - and we have a "fair few" on-site to have tested with

 

Can you nick the wireless cards out of all your Tecras and use them as a short term fix or do you need both sets of laptops connecting wirelessly?

 

I think Intel know they have a problem or they wouldnt be saying this on the link I posted!

"If the slider is already at Highest / Maximum Performance, move the slider to another setting and then back to Highest / Maximum Performance."

[psydii]

We are also experiencing issues with the 'Intel Advanced-N 6230' card with Toshiba R840 and R850 laptops.

 

Disabling 'Allow Windows to turn off device' improved things a little for us. However a side effect was that re-association after resume from hibernate takes 30+ seconds and doesn't always happen automatically. Further research shows that the guidance from intel is out of date:

You may experience connectivity issues or performance issues when you connect a mobile PC that is running Windows Vista or Windows 7 to a wireless access point

 

It does seem to be worse on machines where we have the full (?we think - but maybe we've goofed the install) bluetooth drivers.

 

On a particularly troublesome machine after disabling all things bluetooth and Selecting the High Performance Power Profile, and re-enabling 'Allow windows to turn of device' we found connection stability considerably improved, though not perfect we have not yet collected enough data to be sure that the improvement is real.

 

Initially we had to disable IPv6 support - but this is probably a Meru specific trick. It remains disabled.

 

I also noticed that we didn't have a tracking devices in power saving mode (I paraphrase the language since it was vendor specific) enabled on our wireless controller. So I turned that on. It may be related to the improvements we've seen.

 

I'm not sure whether the issues are related to bugs in the intel software (which IMHO has mostly not worked properly since about 2005, with rare exceptions around the release of the 4965), or simply that they expect the wlan to support modern/advanced standards that they in fact (perhaps) don't.

 

I have a case open with Meru and after patching the controller to fix one issue found, it seems that they are escalating the problem to their engineering team.

 

I'm not near a machine to pick up the logs and post them for comparison, but I'll post the wlan-autoconfig event log when I get a chance. I must say at this point, having one's networked devices sync'd to the same GPS time source as the clients has proved most helpful in getting certain co-incident events recognised as such by various support agents.

 

Finally I should add that in an act of desperation last week (before I understood about the Vista/7 power saving controls) I updated a couple of laptops to BIOS V3.10. These are the laptops that are now best behaving. A laptop that has the exact same power profile **seems** to still be a little flakey, but again we have not collected enough data to be sure.

 

HTH and I look forward to others sharing their findings/experiences.

[psydii]

http://www.edugeek.net/forums/networks/84556-ruckus-ap-setup-options-samsung-intel-centrino-n-6230-cards.html

 

Inference - Something about the intel card/chipset/driver is causing issues. I'm hoping its that they are doing in standard advanced things, and the WLAN vendors can support them with minor (i.e. quick) patches to the controller code.

[kennysarmy]

I know you said you changed the power management settings but it does sound like this:

 

Intel® WiFi Products — Power save polling (PSP) causes connection issues with access points

 

We are having issues with the Intel Centrino Advanced N-6230 - we are on driver version 14.2.1.1 15/09/2011 and there is NO option in the advanced tab of the driver to change Power Management setting, uncheck Default / Auto, and move the slider to Highest / Maximum Performance

 

[psydii]

Try the advice regarding choosing the high performance power profile and leaving the 'allow the computer to turn off this device to save power' enabled.

 

Do your AP's support these: A guide to Wi-Fi power-save technologies - Feature - Techworld.com ?

 

I'm begining to suspect that there may be an issue with the 6230 and its implementation of PSMP given how these issues are seen spread across a range of WLAN vendors.

[psydii]

Further observations.

---------------------------

 

enabling on the clients:

'balance power plan'

computer to manage power saving

Roaming Agressiveness (least)

 

On the controller enabled:

Silent client polling

Broacast SSID until connect

 

 

These settings have resulted in much more stable connections on all Toshiba laptops tested so far (both BIOS2 and 3, and the tosh wifi driver release and the latest intel driver release)

 

However we were still seeing Database application throwing execptions. Tweaking keepalive settings in SQLand Windows does seem to have made a noticable improvement. Using Network trace to troubleshoot intermittent connectivity issues - Data Access Technologies - Site Home - MSDN Blogs

 

Unfortunately my experience here is mostly still based on user experience rather than detailed logs. However WLAN-autoconfig and traces on the controller do show a lot less drops and reassociations, and application crashes are now only occasional, but still a little too frequent so my users tell me.

[kennysarmy]

Update from me.

 

We have had very poor performance on our 16 samsungs with these 6230's.

 

We have put in a MERU controller/AP solution to test the laptops with another vendor of wireless.....SAME ISSUE!

The MERU guys were able to see that most of the time the laptops are not connecting at N rates but at G.

 

Tomorrow we have RUCKUS on-site to capture some stats. to see if they can get to the bottom of it....

 

Personally I just want to return the laptops and get some others - I've spent over 100 hours trying to get to the bottom of this....

[psydii]

Made two changes recently that appear to have dramatically improved things again.

 

1) A further undocumented config tweak by Meru support

2) Turning off band steering - basically we don't have quite enough coverage on the 5Ghz band. Previously clients would move to a band and then the controller would roam them in an attempt to get the best throughput - which changes as people move about the school.

 

Also I suspect that the MS DHCP via relay issue recently fixed by MS (but worked around by Meru in our case) may also yeild and improvement for people.