v1.5.16 Bug Reports and Comments

[Stephen]

FIXED/CHANGED
- Fixed SNMP init error (causing memory leaks)
- Fixed kernel page-cache failure
- Fixed watchdog memory leak
- Fixed leak in net-snmp causing "No MemShared" error in logs
- Fixed SFP port link flapping on config change
- Stability issue discovered from internal caching in vtss_appl fixed
- i2c corruption that bricked smart dc switches (only in 1.5.15)
- snmp corruption

ENHANCEMENTS

KNOWN ISSUES
- WEB UI issues when not at 100% Zoom on browser especially on VLAN TAB
- Some language templates need help

Released 5/16/2024

[coreinput]

Upgraded from 1.5.14 on WS-12-250-AC (Board Rev F) and everything went smooth, thanks!

[Flo]

@Stephen Is the v1.5.16 build identical with v1.5.15rc3?

[fictitiousexistence]

Hi I noticed a few issues.

"no stp" does not turn off stp on ports.
Ex:

Code: Select all

config t
interface port 8
no stp
end

STP will show enabled still in gui and state does not change.
Show config shows

"STP": "false"

.
When unchecking from gui the config shows

Code: Select all

 "STP": false

(without quotes around false)

Running the opposite of "no stp" aka "stp" is invalid and you need to run either "stp priority" or "stp path_cost" commands to re-enable.



When adding Access Control entries, ex:

Code: Select all

configure terminal
accesscontrol 2
ip 192.168.1.5
end

I get this output (but it does still save):
% Applying configuration...
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number
sh: bad number

Cannot find an option to disable an access control entry via cli, seems like you can only delete them.

Cli lets you save invalid access control rules,
ex:

Code: Select all

config t
accesscontrol 2
end

saves with blank ip

Code: Select all

config t
accesscontrol2
ip "192.168.2.5"
end

saves with " "192.168.2.5" " as the ip.
The gui does warn "Invalid Fields" though.

End / exit will auto save. Can't find an option to end and discard any changes.

The revert time message in the cli will always say "If you do not hit enter within 60 seconds...." even if Switch_Revert_Timer value was changes.
The message in the gui says the right value though


Thanks.

[bipbaep]

Yeah, so a bug:
Two switches with two uplink ports between them (one AF24 connected to one port, and one AF60-LR connected to the other port), no STP, LAG etc. One port is disabled manually. When disabling the active port, and enabling the disabled port on near side switch, no traffic passes the port that is enabled. This worked flawless with only one ping dropped on 1.5.14.

Also, the SFP ports are not showing any SFP info anymore.

[mayheart]

Yeah, so a bug:
Two switches with two uplink ports between them (one AF24 connected to one port, and one AF60-LR connected to the other port), no STP, LAG etc. One port is disabled manually. When disabling the active port, and enabling the disabled port on near side switch, no traffic passes the port that is enabled. This worked flawless with only one ping dropped on 1.5.14.

I've reported this before, been broken for some time.

What I've noticed, when you shut down one port and bring up the other, all traffic gets sent with vlan tagging removed. I see a massive influx on the other side of MACs all on the untagged vlan. Only way to fix it is to reboot the switch after making that change.

The various spanning tree modes or having it disabled doesn't help.

[bipbaep]

"been broken for some time", does this mean from the release of 1.5.15rcX?
We did not experience this issue with 1.5.14.

[mayheart]

The switch that I have this problem on is still running 1.5.11.

Another similar setups has 1.5.14 and 1.5.15rc3, same issue.

Edit: here's my report in the 1.5.14 thread, others are having the same issue viewtopic.php?f=17&t=7423&p=37400#p37400

[bipbaep]

@Stephen - Is this something you can check out and hopefully get a fix for? This is a big issue for us.

[Stephen]

@bipbaep,

Yeah, this among other issue's reported on this thread are under investigation.
For the issue you reported, current suspicion is that tags being stripped as mayheart mentioned might be the same issue. As potential verification, is the port that was disabled-> enabled using a tag?