802.11d setting

I cannot get the "802.11d  disable" fusion option to work with MSP3.0/Object builder. Therefore clients still fail to connect to the WLAN after RD unless I manually uncheck 802.11d.

Has anybody else seen this or am I doing something wrong?
Allan Herrod
You are doing nothing wrong.

You are doing nothing wrong.
MSP supports configuring the Fusion Options through an API that is, unfortunately, not supported by all (actually most) versions of Fusion at present.

At present, the only devices with a version of Fusion (2.53) that supports the required API are the CA50 and MC17.
Fusion 2.5.49R, which is the most recent version for most devices, does not support the required API.

There is nothing that MSP can do about it until Fusion supports the required API.
We believed that this would be a serious inconvenience for the field, so we tried to push for the inclusion of the required API in an earlier version of Fusion, with no success.
So, if you are unhappy, please let the product team for Fusion and/or the device know the pain that this has caused.
Perhaps this will help them to make a better decision in a similar situation in the future.

We built the FusionPublic plug-in to use the API if it exists and to NOT report an error if the API does not exist, but instead to proceed.
If the API does not exist, then if Fusion option has been manually set correctly before running RD, then it will work as expected, otherwise, it will fail, as you have seen, without reporting any error.

Perhaps this was a mistake, but our thinking was that the SAME settings object could then be used on devices with version of Fusion that did and did not support the API.
On devices with older Fusion versions that do not support the API, the 802.11d Option would have to be turned off by hand BEFORE using RD.
On devices with newer versions of Fusion that support the API, the plug-in would, as requested, configure the option automatically.

If we had instead reported an error, then it would have been necessary to have two different versions of the settings object, one with and one without the Fusion option, in order to deal with a mixed population of devices where some have and some do not have the support for the API.
When staging a device, it would have been necessary to apply a different staging profile to devices that DID support the API as opposed to those that did not.
And it STILL would have been necessary to manually configure the Fusion option before running RD on devices that did not support the API.
Would that have been better?  It did not seem so to us.

As for when the rest of the devices will have a Fusion version that supports the API, that is a question best directed at the Fusion team and/or device teams.
I hope that the TNT 1.5 devices coming out this month will have the API, but frankly, tracking Fusion versions would be a full time job.
Nonetheless, MSP 3.0 is ready to use the API without ANY change on our part, just as soon as devices ship with a version of Fusion that provides the feature.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Richard Hector
Alan, I also ran into this

Alan, I also ran into this issue and called the support center for help, they were unaware of the reason / resolution.  I checked the Release Notes and as far as I can tell, there was no mention of this 'gotcha'.  If possible, it would be helpful to include this type of information in the documentation.
As you'd imagine, the ability to 'remotely' disable 802.11d is a very compelling feature.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Anonymous (not verified)
Ditto.  I spent a few hours

Ditto.  I spent a few hours tracking down this problem last week.  If you use the RD Client for MSP 3 and try to scan a Staging Profile barcode sheet to set the 802.11d option, the client says "ERROR Applying Network settings".

I also ran into problems configuring GPRS settings on an MC7094 with a Staging Profile.  When I scan the staging barcodes with the MSP 3 RD Client, it gives a bunch of errors (see attached).  If I scan the barcode sheet a second time, it works.  Could this also require a newer OS component to work properly?
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


William Perryman
Richard,I have a customer who

Richard,

I have a customer who expierenced this and also the re introduction of HEX key entries into the Fusion Software as you may know it was available in Mobile Companion and not in Fusion.  That being said here is what I have been told in relation to the 802.11d default configuration and Fusion support of the MSP API to change it.


802.11d must be enabled by default to “out of box – from MOT manufacturing” to meet FCC regulatory requirements; end-users not Motorola must physically disable it via the GUI, API or Provisioning a Fusion Device Options File.



The API access to Fusion Device Options (where the 802.11d setting lives) was implemented as part of Fusion 2.53 release (Jedi radio on UCA and A4); this “new” 2.53 feature was merged in the Fusion 2.55 release and will be available in all releases moving forward. To set the record straight, Public API access to the Device Options was planned for the Fusion 2.40 release but was later deferred due release schedule pressure, but up until Fusion 2.53 the MSP team always had a “backdoor” via Motorola private methods to control Fusion Device Options. That said, once we have released Fusion 2.53 (and 2.55) rev A, the MSP team and our customer will be able to use the newly exposed “Public API” for control of Fusion Device Options. MSP will not have access to the “back door private” mechanism.

Bill Perryman


SE Central

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
The request to have this

The request to have this limitation covered in the release notes is certainly a reasonable one and we will endeavor to do so for the upcoming MSP 3.0.2 bug fix release.  In the mean time, this thread on DevCentral should help to explain the situation and why it is the way it is.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
If you are having issues with

If you are having issues with GPRS, it would be best to discuss them in a separate thread than those for Fusion.  Also, have you opened as case and SPR if you believe there is an issue?  Note that DevCentral is a forum for exchanging information, NOT a substiture for the SPR system.  Issues reported on DevCentral will NOT receive prioritization for engineering unless followed up with a case and SPR.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
To really "set the record

To really "set the record straight", while it IS true that "until Fusion 2.53 the MSP team always had a 'backdoor' via Motorola private methods to control Fusion Device Options", this is NOT the whole story.

The MSP team asked the Fusion team if they would formally support a solution that used the Fusion Public API to do EVERYTHING except configure Fusion Options and the Fusion Private API to configure Fusion Options.  The response was that the Fusion Private API was ALWAYS UNSUPPORTED and they could make no specific claims for its support.  Further, they stated that concurrent use of both APIs by the SAME application could potentially generate issues and no specific claims could be made for the viability of such a solution.

On the basis of the above, and since the Fusion Public API to configure Fusion Options was delayed, the MSP Team had no recourse but to do what we did.  And we made it 100% clear to the Fusion team that MSP 3.0 would thus be UNABLE to support configuring Fusion Options, including 802.11d and that this fact would likely be unsatisfactory to the field.  The decision to leave a SUPPORTED method to set Fusion Options out of Fusion 2.5 was made nonetheless, with the current situation as its DIRECT RESULT.

MSP 3.0 supports setting Fusion Options on Fusion 2.53 on the Jedi radio.  And MSP 3.0 is ready to support setting Fusion Options on all future versions of Fusion that support the Fusion Public API to do so.  No changes to any MSP software will be required to support this feature once a device has been updated to a suitable new version of Fusion.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Sean Wheatley
When can we expect Fusion 2.5

When can we expect Fusion 2.5.3.x. to make it into other mobile devices such as the 9090? As far as I know BSP38/39 is out in the next month with fusion 2.5.2.x. It looks like we missed an opportunity to include the required level of fusion in order to get the 802.11d feature we need in the field.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Sean Wheatley
Something else to add, is

Something else to add, is there any reason why we cannot simply ship units with the default setting 802.11d disabled?
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
I recommend that you pose

I recommend that you pose questions about the availability of Fusion features in device releases in one of the MCD forums related to Fusion and/or the devices in question.  We in MSD have no control over and limited visibility into what they put in Fusion and when, or what Fusion version they put in any given device and when.  If the lack of this Fusion feature in certain devices is causing pain due to its impact on MSP functionality, please make sure that you communicate this fact to the device teams and/or Fusion team so they can better understand the impact on the field of the decisions they are making.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


William Perryman
Sean, I was told it is an

Sean,

I was told it is an FCC regulation.

Bill Perryman
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
I had the same question for

I had the same question for Mark Orlassino almost a year ago.  My position was that having BOTH the 802.11d and Auto Time Config Fusions Options enabled by default was a poor choice.

This was based on the fact that both caused the new devices to behave differently than the older Mobile Companion devices, especially when used with older Symbol wireless infrastructure that did not support or was not configured properly to support these new features.  Not only did the defaults chosen for these options make them different, the difference made them appear BROKEN.  In the case of 802.11d, the device would not get on older networks unless the options was MANUALLY turned off.  In the case of Auto Time Config, the device would periodically set the clock back to an invalid value, even if it was MANUALLY set to the correct value.

Mark's position was that it was a regulatory requirement to have 802.11d turned on by default and nothing could be done about it.  I assume he knows what he is talking about, but it does not lessen the pain it causes in the field.  With regard to Auto Time Config, Mark's position was that it should be on since the correct time and date was required to do certificate-based authentication.  While true, since such authentication is NOT the default, I failed to see why Auto Time Config should be the default.  If the user configures certificate-based authentication they could be told to ALSO configure Auto Time Config or to MANUALLY set the time and date.  Since Auto Time Config won't work unless the network is set up to support it (and many older networks are NOT), then it seems odd for it to be the default.  But I lost that argument.

So, again, if these decisions by the Fusion team are causing pain in the field, please let THEM know, not US.  We made the best case we could for the needs of the field and the Fusion team concluded that the arguments were not sufficient to change their approach.  While it may be too late for those decisions to be changed, understanding the impact on the field of their prior decisions may help them to make better decisions in the future.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Has anyone figured out a

Has anyone figured out a "magical" way of disabling the 802.11d option?  MSP Staging via RF can't be used unless this option is first manually disabled. 

I'm discouraging customers from using Staging and suggesting they build a golden image that includes a front end configuration application that runs at first boot up to prompt the user for their location.  Based on that input, the configuration app will configure the wireless settings (including disabling 802.11d), the MSP site name, MSP Relay Server IP, and then connect to the Relay Server so MSP Provisioning can take over to get everything loaded on the device.  SymScript or a custom application can be used for this.  Who needs RD when you have SymScript!

Ken
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Richard Hector
Ken, sounds like you've

Ken, sounds like you've discovered a "magial method...".
Tell me more about this 'front-end configuration application" you speak of.
Also, what method are they using to install this application?
Finally, I assume you are talking about staging devices that are 'MSP 3x ready?'
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
Ken; That's all well and

Ken;

That's all well and good, but how do you get your "front end configuration application" into the device.  If you are OK ActiveSync'ing it in one device at a time, then fine.  But otherwise, you still have a Staging issue.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
The customer has to be sold

The customer has to be sold on the value of having either Motorola (McAllen team) or a partner load the golden image on the device before delivery.  This would also need to be done when a device is sent in for repair by either us (El Paso Depot Express) or a partner reloading the image after service.

As for the device being MSP3x ready, because we're building a golden image, we control which MSP agent is loaded on the device.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
Ken; OK, so even in that

Ken;

OK, so even in that scenario, the gold image wouldf need to be prepared so it can be supplied to Motorola to pre-load into the device.  I believe that MSP has a potential role to play in BOTH preparing that Gold Image (or suitable alternate) AND in deploying it, wherever that deployment is done (e.g. in the Motorola factory or configuration center).

Perhaps having the customer use their OWN MSP (or an account on OURS) to create staging profiles and package and distribute them to a Motorola Relay Server might be the way to go.  Then when the devices are staged at Motorola, they can be prepared as required by the customer.  And the customer can change what will be staged at any time.  Since the staging will be done on Motorola's WLAN, it circumvents any issues with 802.11d, AES, etc. that might have occured if the staging were done on the customer's WLAN.

This is a great discusssion.  Lets keep it going...

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Allan Herrod
Ken; OK, so even in that

Ken;

OK, so even in that scenario, the gold image wouldf need to be prepared so it can be supplied to Motorola to pre-load into the device.  I believe that MSP has a potential role to play in BOTH preparing that Gold Image (or suitable alternate) AND in deploying it, wherever that deployment is done (e.g. in the Motorola factory or configuration center).

Perhaps having the customer use their OWN MSP (or an account on OURS) to create staging profiles and package and distribute them to a Motorola Relay Server might be the way to go.  Then when the devices are staged at Motorola, they can be prepared as required by the customer.  And the customer can change what will be staged at any time.  Since the staging will be done on Motorola's WLAN, it circumvents any issues with 802.11d, AES, etc. that might have occured if the staging were done on the customer's WLAN.

This is a great discusssion.  Lets keep it going...

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anonymous (not verified)
Allan,We've been doing sort

Allan,

We've been doing sort of what you described for both United Airlines and Cardinal Health in El Paso/Depot Express for a few months now.  Depot Express has an FTP/AirBeam server that we use for both of these accounts, plus I'm sure many more.  I provide them with the golden image that needs to get loaded on the customer's units along with an RD barcode sheet.  The RD sheet gets the device on the network in El Paso and points to the proper OS Update/golden image package on the FTP server there.  Prior to using RD, Depot Express had to ActiveSync REG files to each device to configure the Mobile Companion and AirBeam settings to do this.

In United's case, they have a combination of 32 MB and 64 MB MC9060 units, so there are two golden images and two RD barcode sheets.  The Depot Express tech needs to make sure they scan the proper RD sheet for the correct device.  This is something that I wouldn't want each United site doing...they would screw it up, big time!  The need to make sure you are scanning the correct RD barcode sheet for the correct device is a limitation with MSP3 Staging.  We can only define the device type that a particular staging profile applies to.  We can't go into further detail to say that a particular staging profile applies to an MC9060-G with CE and 32 MB RAM for example.  We can't get to this level of granularity until we get to MSP Provision.

Due to corporate network security concerns, the FTP/AirBeam server in Depot Express is not on the Moto network, so I can't update it remotely with a new golden image.  I have to e-mail golden image updates to someone in El Paso so they can update the server.  It would be nice in the future if this server (i.e. Relay Server) could be set up so that it was visible/accessible to United's and Cardinal's MSP server.  They would be able to update the golden image that we load on their devices themselves.  They would also have visibility to all of their devices that we have in Depot Express since the devices down there would be checking in with the Depot Express Relay Server.  This would help out the Depot Express folks too since they wouldn't need to provide inventory reports on the spare pool to customers.  Each customer's MSP system would know where all devices are located within their environment and our facility.

Ken
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments