VC5090 OSUpdate with BSP35

// Expert user has replied.
Y Yanis Dalabiras 3 years 6 months ago
7 7 0

Has anyone run into problems doing an over the air OSUpdate when using BSP35 on the VC5090?  I have an OSUpdate package set up to use the -n option so the Fusion radio is powered off during partition updates.  This works fine when the VC5090 has BSP30 on it.  If I don't use the -n option, then the device will sometimes hang during the update (IP address problem) and I will need to suspend and resume the device to get it back on the network for the OSUpdate to continue.  When the VC5090 is on BSP35, the -n option seems to be causing a problem.  When the radio is powered off to update the first partition, it fails to turn back on afterwards (the Comm light never starts blinking again).  A suspend/resume will not bring the radio back to life.  I need to cold boot to recover.  If I remove the -n option, then the OSUpdate goes through fine. It looks like I need to have two different OSUpdate packages.  One with the -n option for BSP30 devices and another without the -n option for BSP35 devices.  Has anyone run into this? Thanks, Ken

Please Register or Login to post a reply

7 Replies

Y Yanis Dalabiras

3.2.1

W William Honig

Ken, I see within the AirBEAM OSupdate package builder PRG it states the -n option is only MC3000 and MC9000 CE 5.0...
-n

 

Enables logic to cycle power to the 802.11 radio after each partition update.

 

This option is only supported for the MC3000 and MC9090 CE 5.0.

 

This option was implemented to workaround an intermittent timeout issue with the Fusion 2.0 radio. 

 

This feature is supported in osupdate client version 0.36n, and later.

Y Yanis Dalabiras

Bill, I know the documentation says -n is only needed on the MC3000 and MC9090, but I found that it's also required on both the WT4090 and VC5090.  If the option isn't used, the radio will normally fail to pull down all of the OS partitions.  This is what occurs when running BSP 30 and lower on the VC5090.  When using BSP 35, using the -n option causes the opposite effect.

Y Yanis Dalabiras

Chris, Thanks for the reply.  I opened up a case with the Support Center.  Glen Sobel wasn't able to duplicate the problem though.  One difference with his scenario is that he was using Open authentication and he wasn't using MSP to configure the wireless profile settings.  I am using MSP Stage with a WPA-PSK profile.  Are you also using MSP with WPA-PSK? Thanks, Ken

C Chris Matheson

I am using WPA2-Enterprise PEAP w/MSCHAPv2 and AES. Customer had a lab VC5090 so I can't say for sure if it was originally staged with MSP or manually...likely MSP as that is what they use

M Mario Di Pasquo

Hi Ken, What ver of MSP are you using ? 3.2.0 ?   3.2.1 ?  2.9 ?

C Chris Matheson

Yes I saw this last week as well. I had to update BSP30 to 35 and could not get it to work via OSUpdate package over RF. It would just hang at "Waiting for IP Address" and never recover. I ended up just doing it via USB key as I was rushed but after reading your post, sounds the same.I was using -n option as I have always done in the past.

CONTACT
Can’t find what you’re looking for?