Upgrade to 1.3.5 XU disables bridge randomly

[Julien Berthelot]

Hi!

We run about 600 bridged SPA122s on version 1.3.3 for quite a while now. 

I upgraded 50 of them to 1.3.5 XU to test it and I was glad I didn't upgraded all 600 of them. 

It randomly disabled the bridge functionality on half of them. 

The option was still set to 'Bridge' but no packets were allowed through it. 

The result was 25 clients with a phone line without Internet access.

I then tried to downgrade one of them to 1.3.3 but it had no effect: still no bridge.

We found a 'solution' and it was to log in to each ATA and put them into NAT mode, then but them back into Bridge mode. 

I suspect an internal script is run when switching mode and it was not executed during the upgrade. 

You can understand I am not going to upgrade our remaining SPA122 until this issue is fixed.

I can provide configurations if needed.

Thank you !

Julien Berthelot

[Dan Lukes]

It may be caused either by 1.3.5 version or by XU flavor of the image. You may try to use non-XU version of 1.3.5 image to decide.

It will not help you to recover units broken already, of course.

[Julien Berthelot]

Hi Dan.

Our first upgrade was with the non-XU images and we had the same issue 

We then upgraded to the XU image since it was the most recent image and I though it was a silent update.

There is no changelog in the XU firmware, can you tell me what is the difference?

Thank you for that clarification!

[Dan Lukes]

XU and non-XU image of the same version (1.3.5 here) is compiled from the same source code.

Just some crypto-related features (SRTP) are omitted from XU compilation. It's not so correct to claim the 1.3.5-XU is newer firmware than raw 1.3.5.

Read Lance Harper's comment here.

See also Version-style conditional expressions broken on XU image.

My personal recommendation is not to use XU flavor of image unless you are enforced by law to do it.

OK, but back to your issue. Another idea.

The problem you are facing may not be related to 1.3.5 as is. Saved configuration may be corrupted during upgrade process. Upgrade device to 1.3.5. Reset it to factory default, then reconfigure it from scratch.

If it will not be affected by issue, you discovered the workaround.

[Julien Berthelot]

Hi Dan,

Thank you for the clarification about the XU image, I'll stick with the regular firmware.

You are right, it may not be related to 1.3.5 and it could be an upgrade problem. 

I cannot factory default 550 units remotely since we use VLANs in the configs and we'll lose connectivity to the provisioning server.

I am really concerned about the quality of firmwares from Cisco.

Don't get me wrong, I love the products but I think there should be more tests done before official release. I am willing to be a beta tester if they need more people to test them. 

This is the second time we struggle with a buggy update and I have to convince my boss not to switch product over this kind of issue. 

[Dan Lukes]

I cannot factory default 550 units remotely

I didn't expected you will test it on 550+ units ;-)

Well, I'm surprised that you have hundreds of units with no zero-touch configuration ready. Of course, I know nothing about your network.

I have 1000+ units in seven countries around and I can't imagine the world with no zero-touch configuration working.

I am really concerned about the quality of firmwares from Cisco.

We didn't deployed SPA1x2 as we considered they are not ready for production deployment yet. Fortunately, we still have PAP2T in stock.

But you need to be careful during the update of any Cisco's device. You should never update tenths of devices as a test. You should start with ONE device.