v1.3.9rc15+ - BETA/Release Candidate

[sirhc]

This thread is for posts regarding v1.3.9rcX BETA / RC

Issues fixed since v1.3.8
v1.3.9rc15 - Release 1/26/2015
- Delay I2C init in SMART DC power supply firmware to fix random RJ45 POE light on a cold boot - COSMETIC FIX ONLY
- Added HTTP watchdog - Customer can now create a watchdog event based on an HTTP URL
- Allow up to 253 character RADIUS secret - USER REQUESTED

v1.3.9rc14 - Release 1/15/2015
- Fixed SNMP using 100% CPU
- Fixed config revert not working
- Added enable/disable VLAN to CLI

v1.3.9rc13 - Released 1/7/2016
- fix for clearing log
- added "clear log" CLI command

v1.3.9rc12 - Released 1/4/2016
- Fixed per-port graphs that were broken if switch was up less than 1 hour
- Fixed condition where DC2DC power supply failed to wake up switch from hibernation mode
- Fixed where unresolvable hostname could hang syslog server
- Fixed DC power supply voltage range
- Added LLDP Discovery
- Now retains log if log daemon is restarted
- CLI no longer saves config unless something was changed

v1.3.9rc8 - Released 12/15/2015
- Fixed UBNT Discovery name
- Ping Watchdog now disabled if port is disabled
- Changing Safe Mode Timer and ability to disable Safe Mode
- Ability to reset counters per port instead of all
- Log file formatting
- UI Enhancement for MAC table
- Add clear stats command to CLI

v1.3.9rc7 - Released 12/10/2015
- Fixed UBNT Discovery - FINALLY
- Fixed Linux log

v1.3.9rc6 - Released 12/02/2015
- Fixed Loop protection log entry refers to wrong port number
- Fixed Broadcast storm when using LACP and RSTP [Discovered by Thomas]
- Fixed Unable to change RSTP path cost for LAGs

v1.3.9rc4 - Released 11/30/2015
- Changed from mini-snmpd to net-snmp, a more common and well tested snmp daemon.

v1.3.9rc2 - Released 11/24/2015
- Fixed MAC table eating up CPU time when you have hundreds and hundreds of MAC entries. [Discovered by Francisco]

[lligetfa]

Flashed both WS-6 and WS-24 without drama.

[sakita]

Upgraded one WS-12-250-AC with no difficulties. Longer RADIUS works as advertised.

Netonix is now probably one of the few products that actually meets the RFC length requirement.

Still need to do a site visit to power cycle it and see if that makes the "power should not be 0" log message go away (wattage on the Status tab is jumping between 0.0 and 0.5). Will probably have technician take a couple of different brand SFPs along to try if a simple power cycle doesn't make the error go away... won't get to this until at least tomorrow.

[sirhc]

Upgraded one WS-12-250-AC with no difficulties. Longer RADIUS works as advertised.

Netonix is now probably one of the few products that actually meets the RFC length requirement.

Still need to do a site visit to power cycle it and see if that makes the "power should not be 0" log message go away (wattage on the Status tab is jumping between 0.0 and 0.5). Will probably have technician take a couple of different brand SFPs along to try if a simple power cycle doesn't make the error go away... won't get to this until at least tomorrow.

You probably have a blow current sensor if your getting that error.

Read this post viewtopic.php?f=30&t=1429
Then re-read this post if you have read it before as it has been updated several times viewtopic.php?f=30&t=188

[sbyrd]

I am not sure if this is by design or a flaw, but I have the following issue.

If you put a new VLAN on the switch and assign it to a port. For example put vlan 99 on ports 1 and 2. If you then later delete the VLAN 99 from the switch it disables Ports 1 and 2, even though the GUI of the switch shows the Enabled check boxes checked for those ports.

I then disable the ports and then enable the ports and all is well until a reboot. After a switch reboot the ports become disabled again.

Anyway this has been an issue in previous FW as well. I just never got around to posting it.

Also I forgot to mention you must have ports 1 and 2 Excluded from the Management VLAN for this to occur.

I just tested it again and the error happens if you just Exclude ports 1 and 2 from the Management VLAN and then reboot the switch. Upon reboot ports 1 and 2 are disabled.

[sirhc]

I am not sure if this is by design or a flaw, but I have the following issue.

If you put a new VLAN on the switch and assign it to a port. For example put vlan 99 on ports 1 and 2. If you then later delete the VLAN 99 from the switch it disables Ports 1 and 2, even though the GUI of the switch shows the Enabled check boxes checked for those ports.

I then disable the ports and then enable the ports and all is well until a reboot. After a switch reboot the ports become disabled again.

Anyway this has been an issue in previous FW as well. I just never got around to posting it.

Also I forgot to mention you must have ports 1 and 2 Excluded from the Management VLAN for this to occur.

I just tested it again and the error happens if you just Exclude ports 1 and 2 from the Management VLAN and then reboot the switch. Upon reboot ports 1 and 2 are disabled.

If a port does not belong to a VLAN it should have an "X" in the Christmas tree (Header) and should be essentially disabled as the ports do not belong to any VLAN.

Now the real bug might bee that if you say you can un-check Port Enable on the Port Tab hit Save/Apply then re-check Enable Port and hit Save/Apply and they starts passing traffic without first being put into a VLAN that would be a bug?

Are you saying you can get them to pass traffic "without" being in a VLAN?

[sbyrd]

I am not sure if this is by design or a flaw, but I have the following issue.

If you put a new VLAN on the switch and assign it to a port. For example put vlan 99 on ports 1 and 2. If you then later delete the VLAN 99 from the switch it disables Ports 1 and 2, even though the GUI of the switch shows the Enabled check boxes checked for those ports.

I then disable the ports and then enable the ports and all is well until a reboot. After a switch reboot the ports become disabled again.

Anyway this has been an issue in previous FW as well. I just never got around to posting it.

Also I forgot to mention you must have ports 1 and 2 Excluded from the Management VLAN for this to occur.

I just tested it again and the error happens if you just Exclude ports 1 and 2 from the Management VLAN and then reboot the switch. Upon reboot ports 1 and 2 are disabled.

If a port does not belong to a VLAN it should have an "X" in the Christmas tree (Header) and should be essentially disabled as the ports do not belong to any VLAN.

Now the real bug might bee that if you say you can un-check Port Enable on the Port Tab hit Save/Apply then re-check Enable Port and hit Save/Apply and they starts passing traffic without first being put into a VLAN that would be a bug?

Are you saying you can get them to pass traffic "without" being in a VLAN?

Ok I understand what you are saying. However, to answer your last question I can get them to pass traffic if I disable/enable the port in the gui. This will work until you reboot the switch. Then the port will be disabled again.

[sirhc]

OK so the bug is you can get around them not being in a VLAN and make them pass traffic which they should not do.

Thanks

[sbyrd]

OK so the bug is you can get around them not being in a VLAN and make them pass traffic which they should not do.

Thanks

Yes after you explained it to me better, the above is a correct statement of the bug.

[sirhc]

A few people have reported HIGH CPU utilization with their WISP Switch.


For the record the CPU is a utility CPU and is only there to do things like the following:
Run the UI/CLI
Gather Stats
Control some functions such as LACP, RSTP, and so on with Daemons.
Also runs some daemons for SNMP, SMTP, watchdog, and so on.
The more users that log into a switch UI/CLI at the same time will increase the CPU utilization for each user accessing the UI/CLI
Why some traffic for some people is causing this CPU utilization to be high is something we are investigating but it has no bearing on the switching capacity as all packet switching is done in the core by dedicated processors and the packets do not touch the CPU (MIP24K) which is simply a utility CPU to do the types of functions mentioned above.
If you have a switch that is exhibiting the higher CPU utilization and you want to help please by allowing us access to the switch via TeamViewer or similar means please send me a PM with your cell number.