All, I have a customer running MC55s BSP35 (i.e. Win Mobile 6.1) and Fusion 3.00.1.0-003B. They have units that will be running fine then it will go to sleep after an inactivity time. When they then switch the unit back on we have found on a couple of occassions the wireless doesn't come back up properly. Looking into the log I see
15:01:17 Radio is resetting.
15:01:18 Radio reset complete.
15:01:19 Cannot use profile: Till 18
15:01:19 Profile does not match regulatory settings.
And the Fusion icon shows the card with a red cross through it. Rebooting the unit clears the problem. The wireless profile is fine and works 99% of the time. The partner's application has a check at startup that checks whether the wireless is enabled and if not it switches it on. Its a very simple script with a couple of Fusion API calls ... is there any chance this could be causing the wireless driver to stall if the check happens before the wireless powered? Any thoughts would really help. IJ
5 Replies
First, one golden rule about Fusion (from its early days): never ever try to "access" wifi communications at level 3 (or higher) until Fusion status is steady. This might (well, actually will very likely) make Fusion go unstable. This especially happens after a suspend/resume cycle has happened. Typical case of checking connectivity is pinging some address. Or even worse, opening a dummy web service. I first noticed on old MC70 and it seems to me this feature has not been properly fixed yet. I actually raised a couple of SPR/CASPs about... but eventually I had to write a wrapper to get rid of this (partner was not skilled at all). Now I advice all my partners to first check Fusion status by inspecting both the BSSID and RSSI using our APIs. If they both are OK, then yes they can then ping, open web services, etcetera. On the other hand, 802.11d setting is very important for Fusion and may provoke unstability or wrong behaviour. This often makes Fusion profile show a devilish yellow triangle. If 802.11d is set (ticked) on terminals and APs' beacons do NOT "publish" the expected information, then regardless Options and/or Profile country settings, Fusion may or may not connect. This is obvious and of course somewhat expectable. However, if 802.11d is not set and APs' do send country information, after a suspend/resume cycle you might get this yellow triangle about regulatory settings. So, my second golden rule is: if you are 100% sure APs transmit 100% compatible 802.11d information (which is Motorola's case by the way), set this option and leave all the according settings to "Allow any country". If not, untick it and set both Options and Profile settings to the country APs are set to. I hope this helps.
It means that MC55 connects only to the AP on channel 48, not to the APs on channels 60 and 116? If so, could you open the registry path [HKEY_LOCAL_MACHINE\Comm\JEDI10_1\Parms] and check whether any value with the name containing "ChannelMask" is set?
Perhaps could be a DFS issue, that Aruba is not giving the information in the beacons, that they did the radar check and the new fusion version is waiting for this information. Is the ESSID hidden in the beacons? Fusion is not doing active scans on DFS channels to find an AP with hiden ESSID as far as I know, so starting with passive scans. How long did You wait for a connect? 10 minutes or more?
Fusion 3.00.2.0.020R has the fix for the radio reset problem. This version of Fusion is available in Support central.
Thanks for that, One issue around 3.00.2.0-020R though, when I upgraded to that version my MC55s suddenly wouldn't connect to any AP that wasn't using channels 36, 40, 44 or 48 in the 802.11a band. The customer had 3 APs, 1 on channel 48, 1 on 60 and 1 on 116!! Any thoughts? The network is Aruba (AP105s) IJ