v1.5.1rcX Bug Reports and Comments

[sirhc]

For what ever reason, when we had 1.5.1 rc in it, and we tried to change "anything" on switch B, it would become inaccesible, and we had to go into the switch A, on the remote end, un-lag our backhauls, then switch B would come back up and be accessible again. Then we could re-establish the lags.

Don't have that problem on 1.5.0

Not sure what changed between the 2 firmwares?

This Started in v1.5.1rc2 - WE ARE ON IT

Are you by chance using SFP modules in your LAG?

[Stephen]

FIXED/CHANGED
- Fixed voltage input calibration for the WS-8-150-DC - RC1
- Fixed services running on IPv6 - RC2
- Fixed being able to bypass console login by hitting CTRL-C - RC2
- Fixed MSTP setting instance forwarding state - RC2
- Fixed UI on ERPS tab to prevent footer from from being mangled - RC3
- Fixed ERPS MEPs issue that triggered a Signal Fail on a ring when port not in the ring is disconnected/disabled - RC3
- Fixed ERPS issue that prevented access to Management VLAN when added to the protected VLAN list - RC3
- Fixed ERPS protected VLANs would not forward packets outside of the ring - RC3
- Fixed SNMP (Broken in v1.5.1rc3) - RC4
- Fixed Access Controls for a confirmed security vulnerability - RC5 (for more details check this thread: viewtopic.php?f=12&t=4103 )
- Fixed UI bug in Access Control List - RC6
- Fixed DHCP failure when switch has a static ip assigned to a vlan - RC7
- Increased time buffer for warning voltage email trigger - RC7
- MAC Table search works using colons and dashes - RC8
- update for new fans - RC9/RC10/RC11
- fixes for PoE sensor balloon performance issue and data display - RC12
- fix for LACP LAG breaking during config changes - RC12

ENHANCEMENTS

KNOWN ISSUES
- WEB UI issues when not at 100% Zoom on browser especially on VLAN TAB
- Some language templates need help - please private message Eric Stern to help
- IGMP snooping over VLANS, MSTP, and ERPS are still being developed

RC1 Released 6/20/2018
RC2 Released 7/10/2018
RC3 Released 8/2/2018
RC4 Released 8/11/2018
RC5 Released 9/17/2018
RC6 Released 9/19/2018
RC7 Released 10/1/2018
RC8 Released 11/5/2018
RC9 Released 12/23/2018
RC10 Released 12/25/2018
RC11 Released 12/27/2018
RC12 Released 1/17/2019

[Stephen]

For what ever reason, when we had 1.5.1 rc in it, and we tried to change "anything" on switch B, it would become inaccesible, and we had to go into the switch A, on the remote end, un-lag our backhauls, then switch B would come back up and be accessible again. Then we could re-establish the lags.

Don't have that problem on 1.5.0

Not sure what changed between the 2 firmwares?

wtm, try out 1.5.1rc12 - we were able to replicate and fix the issue in our labs and I've just submitted the patch. Let us know here how it works out for you - thanks.

[wtm]

Thank you !

I know it sounds weird that it may be doing that, and maybe even be a random thing. It was just we went into the switch and changed the name on a port, then hit the apply, and the system went down. After that it was totally non-responsive trying to use anyway to get into it. I then went the the switch that was at the other end , feeding it the LAGed backhaul, and once I turned the LAG off, everything immediately came back up and I could get into the other switch again.

Then I turned the LAG back on, and it was fine!

Just weird....

Downgraded to 1.5.0 and we don't seem to have the "touchiness" on the issue.

[Stephen]

What you're describing is actually expected now that we found the bug that started with v1.5.1rc2 through v1.5.1rc11

We think we have it fixed in v1.5.1rc12
Keep in mind, all switches that are part of the LAG will need to be upgraded to 1.5.1rc12 for this fix to take effect. So while you're upgrading them, if you can it would be easier to disable the LAG until both switches are running rc12, then once that is finished - re-establish the LAG and try making a configuration change.

If it's working the way it did in our experiments then now you shouldn't notice this issue anymore.

Let us know - we would like to resolve this as we want to close out v1.5.1rcX

[jakematic]

Upgraded to 1.5.1rc12 this morning and seeing some inconsistent fan behaviour.
Typically I can tell the seasons by the way the fans run on these indoor units, which is almost never in the winter and especially when it is this cold.

Currently: (lab = office/ws12)

Code: Select all

root@ubu:/Fedora# temps
----------------------------
Wed Jan 23 09:16:49 EST 2019
Wind : 0.2 m/s, 1.7 m/s max
Rain : 0.0 mm, 0.0 /hr; 0.0 mm/hr at 12:00:02
Baro : 1026 trending v
Outdoor : 3.4 67%
----------------------------
Archive : 22.1
Lab : 19.8 28%
Lounge : 19.5 24%
Garage : 6.4 43%
root@ubu:/Fedora#


Attaching screenshots for engineering.
These units are over a year old. Let me know if you need anything additional. Thanks-Jake

[sirhc]

Fan controls changed, explained here: viewtopic.php?f=17&t=3914&p=27564&hilit=+fan+sunon#p27564

The release notes also tell you we had to change the fan controls.

[jakematic]

Fan controls changed, explained here: viewtopic.php?f=17&t=3914&p=27564&hilit=+fan+sunon#p27564

The release notes also tell you we had to change the fan controls.

Oh I know, I read every post on the forum daily :)

Just wanted to let the guys know that some are running constantly now at 1/2 throttle while other warmer boards are at zero RPM.
May be nothing, but as an engineer I notice these things.

[sirhc]

Board temp has to drop to 35C for fan to turn off, always was 35C that has not changed.

The fan used to kick on at 40C board temp and now waits till 45C which was a compromise as we had to change low speed from 3K+/- to 4K+/- due to the NEW fan specs.

There are other things that can cause the fans to turn on but they cause the fan to go to HIGH speed of 8K+ regardless such as CPU/PHY/DC power supply sensors