v1.5.5rcX Bug Reports and Comments

[Omniflux]

Can you ping it?

No response to ping. It is still announcing itself via LLDP though.

[sirhc]

So also keep in mind that when a switch upgrades it does the process with the OLD firmware.

After the upgrade completes and reboots then the NEW firmware is running.

Not sure which version this switch was before the upgrade?

Also this could have been a one off mishap?

I know when I go and upgrade 1000+ UBNT radios I have quite a few units that we have to call the owner to power cycle and on very rare occasions we have to roll a truck and have to default and re-set up.

I know this is not something anyone wants to happen but on occasions it does happen.

But either way provide Stephen the config so he can confirm there is an issue or not but if he can not then this could be one of those times an upgrade goes bonkers.

Was this the FIRST upgrade to v1.5.5rc3?

If so is this the closest unit you could test with?

I guess we could consider putting in a ping watchdog option.....might have helped in this event if a power cycle fixes it.

[Omniflux]

Upgraded from 1.5.4.

I see the same thing with M5 radios. I don't think I've seen it with any of the AC radios.

No, it was not the closest unit. Bad choice on my part. I could have someone out there reboot it, but no one there can retrieve the log via the serial port.

I actually went looking for a watchdog option shortly after this happened, but the right type isn't there. Might be useful, but I'd rather have all the other things I've requested first :)

[sirhc]

If you use the Manager you would have a recent copy of the config on the Manager as it backs up after every change.

Or if you have TFTP auto backup.

That way provide Stephen the config and have it rebooted save the drive?

[Omniflux]

I sent him a backup from minutes before the change I made that caused it to stop responding. I just cannot get the log files.

I need to replace the switch anyway, it's one of the ones I'm having FCS errors with ( viewtopic.php?f=6&t=5701 ). I pulled an older unit with no issues and placed this new one in it's place as I still cannot figure out what is going on with them. The problem follows the new switches, and I've tried at multiple sites.

[Omniflux]

The problem is too many VLAN IP addresses. I expect you will be able to reproduce with the configuration I sent you as it occurs even when my notebook is the only device connected to the switch.

I did not narrow down the exact number, but 2 VLAN IP addresses works, and 13 does not. When there are too many, vtss_appl continuously restarts.

When there are 13 VLAN addresses and I try to remove any, the switch stops responding. I had to restore to default and reprogram without the VLAN addresses. Restoring to default and reprogramming with the VLAN addresses reproduces the problem.

When vtss_appl continuously restarts, the CPU runs at 100% utilization. After several hours, the packet loss each time vtss_appl restarts begins to increase. Eventually the switch stops passing traffic altogether.

[Stephen]

Thank you for the data, I am able to see it as well. Working on it as I type this.

[Stephen]

OmniFlux,

OK - you were correct, as it turns out, vitesse had hard-coded the limit of VLAN virtual interface's to 8.
I have increased this count to 100 (I can't imagine someone needing more than this and I'm not sure the OS itself could do anywhere near this many anyway). After loading a test firmware your configuration is working for me. However, I do not have all of your hardware or setup so this is the best I can do with it here and it is passing. I've sent you a link with a test firmware. If you can test it and get back to us here about your result's that would be extremely helpful.

Just FYI, as you've already figured out, default the switch first and upload the test firmware image. Then apply your configuration. Please be aware (if you are not already) that it will take some time for it to come back and you will likely have to refresh the browser to see it up again. The reason is because the OS itself (a variant of OpenWRT) has to create and add all of the virtual eth0 interfaces to the kernel and then to the firewall which takes a few minutes for this many. (A recent security patch means that it has no choice but to do this twice actually). I would suggest bringing up a cmd prompt and ping it continuously:

Code: Select all

ping <ip_address> -t


To see when it come's back.

If possible, it would also be helpful to watch the log file on the switch itself via an RS232 console cable. Once it has booted, Just get into the linux terminal and run these commands:

Code: Select all

cmd
tail -f /var/log/messages


Then you can watch to see when it has finished setting up.

Looking forward to hearing your results.

[Omniflux]

This resolves the issue on the same switch, sitting on my desk. I will test on site in a few days.

After upgrading, status page shows

Code: Select all

Power Supply Firmware Version Error
Power Supply Board Rev Error

Rebooting fixed it. Not sure if it's anything to look into.

Also,

Code: Select all

Z-120 PoE Switch# reload
cold Reload cold.
defaults Reload defaults without rebooting.

Z-120 PoE Switch# reload defaults
% Reloading defaults. Please stand by.
% Rebooting...

Z-120 PoE Switch# Terminated
Netonix Switch# Restarting system.

Seems the help description is slightly inaccurate.

[Stephen]

Seems the help description is slightly inaccurate.

Fortunately, that is an easy fix. Probably when that description was created it was true.

This resolves the issue on the same switch, sitting on my desk. I will test on site in a few days.

That's good to hear. I know we have a time limit before we need to get all these changes finalized for 1.5.5 because production is getting ready to create several new batches of these switches and we really don't want all the previous issue's to be present and force everyone buying in the future to go through the process of coming to the forum and upgrading manually. I will see if we can try to hold off until you can test this version on a site. If you could get back to us before Tuesday though that would be extremely helpful.

Rebooting fixed it. Not sure if it's anything to look into.

More than likely while vtss was busy working with the OS to add in the virtual LAN's it missed it's initial poll's to the MCU that control's the DC regulator for the smart DC switch. It poll's it at rather slow interval's so it's possible it would resolve itself. However, I'll keep an eye on it as I test this a bit more.