v1.5.1rcX Bug Reports and Comments

[CCIS]

Calibrate button on WS-12-250-DC problem with 1.5.0.
Batteries read 13.0 with my voltmeter.
Netonix said batteries voltage was 12.8
I used the calibrate button and entered 13, and the netonix rebooted all POE ports, and when the site came back up, the voltage now reads 12.6
rebooting all the POE equipment happens every time I try to calibrate.

Saw 1.5.1RC1 had a calibrate fix for WS-8-150-DC.
I upgraded my WS-12-250-DC to 1.5.1rc4 and now the calibrate works properly, and equipment didnt reboot.
All good now.

[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 )


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

[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

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

[wtm]

Interesting problem..... (to set the network layout) Location A: We have a Mikrotik CCR (10 gig fiber drop- 2 gig active), we had setup 4 Lags between the CCR and the WS-26-500-DC switch. Was running v1.5.0 for at least several weeks now, no problems. At Location B:Have a WS-26-500-DC switch, which was running 1.4.9 on it. Between them we have 2 UBNT AF11x links. Both the same stats, and setups. These both have been running for months now as single links, we turn on one and run it, and then switch to the other one to make sure they were both working well. No Problems.

We finally got the fiber company to provide us with our upgraded speeds last week, so we figured it was time to Bond the 2 AF11x links together.

Last night, I upgrade both switches to 1.5.1rc6 firmware. We setup the Lag on the 2 AF11x radios, and all ran well till today about noon.

At that time the system went down, I could get into the CCR, but the switch at location A was non-responsive. I then started turning off the Ports in the CCR that created the bonding, till I had one port on. It immediately came back up, and I was able to get into the switch.

After it stabilized, I started enabling the other Lag ports on the CCR, and as soon as I got past 2 ports, it started to fail again. Turn them off, and the traffic would pick up again as normal.

I rolled back the firmware to version 1.5.0 at Location A, and then re-enabled the other LAG ports on the CCR. All worked as original normal then.

The 2 Lag ports for the AF11x's going between Location A and B did not seem to be effected. Location B is still running version 1.5.1rc6 firmware in it.

Might something in the new firmware be limiting the amount of Lags that will work with each other?



P.S When will the new 10 Gig switches be available ?

[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

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

[astounding]

QUESTION: Will 1.5.1 fix the issue of DC Netonix switches sometimes rebooting when the WARNING voltage threshold is crossed but the HIBERNATE voltage has not even been closely approached yet? This happens sadly far too often on various Netonixes on my network. It may have been worse pre 1.5.0 as I haven't noticed it as often.

I've got a remote solar-powered mountain top site with a pair of DC Netonixes. Last time the DC input voltages dipped, #1 switch rebooted. I assumed it was some odd combo of hardware/firmware--but then noticed both switches are the same model WS-12-250-DC and board revision (F), and shared identical Power tab settings (WARN at 48.8, HIBERNATE at 46.0 or something). After that reboot incident, I changed switch #1 to warn at 48.2 instead, but left switch #2 at 48.8 (as it had remained online with no reboots). Then this morning, when voltage dipped below 48.8 at just before 5:00am, switch #2 decided it wanted to reboot AFTER sending the email warning message--but WITHOUT sending any sort of other email notice.

REQUEST: Finally a feature request: Could some ALARM states be added to Netonix firmware that can be checked both via SNMP and in the web CLI? For example, I would LOVE to see a "LOW INPUT VOLTAGE" alarm trigger at the Warning Voltage and REMAIN in that ALARM state until voltage returned ABOVE the Warning Voltage setting. I'd ALSO love to be able to set an ALARM email such that I could enable alarm states to be emailed periodically (i.e. #1 upon the alarm state triggering, #2 upon alarm-state resolving, and #3 at some configurable period of minutes, perhaps 30 minutes by default, if ANY alarms are active, summarizing all the alarm states).

Originally I assumed the Warning Voltage email was something like that, not realizing that email messages about the warning voltage were only sent upon crossing the threshold (i.e. only once). My mistake.

Thank you very much for all the hard work improving the Netonix platform!

-Aaron out.

[wtm]

+1 for that feature !

[sirhc]

QUESTION: Will 1.5.1 fix the issue of DC Netonix switches sometimes rebooting when the WARNING voltage threshold is crossed but the HIBERNATE voltage has not even been closely approached yet? This happens sadly far too often on various Netonixes on my network. It may have been worse pre 1.5.0 as I haven't noticed it as often.

This is not a known issue, what is known is if the switch detects a low voltage it will react. This is why we keep stressing the proper way to use the SMART units like the WS-12-250-DC is it to attach them DIRECTLY to the battery bank with an inline fuse or breaker and hook your charger unit to the battery bank separately.

When you hook the switch to the battery bank DIRECTLY the voltage swings are not so fast.

If you are going to power the switch with 48V from a power supply/charger you should use the WS-12-DC.

[astounding]

"This is not a known issue, what is known is if the switch detects a low voltage it will react. This is why we keep stressing the proper way to use the SMART units like the WS-12-250-DC is it to attach them DIRECTLY to the battery bank with an inline fuse or breaker and hook your charger unit to the battery bank separately."

This is exactly how these two in question are connected. And when the issue occurs, there is zero charging occurring. I have seen this happen at unpredictable times on various DC Netonix models at multiple sites over the course of more than a year. Yes, it's my fault for not filing reports so that this can become a KNOWN issue. But it IS an issue. And one I cannot consistently reproduce--it seems somewhat sporadic.

Were I to take a wild guess, I would suspect it's more likely to happen/trigger when voltage fluctuations cause multiple warning threshold crossings.

I do expect a reaction by the Netonix when the warning threshold is reached: An email warning. And that mostly happens (sometimes the device will reboot before it's able to send an email warning, but that might be due to other reasons). But I do NOT expect any rebooting. I expect the device to remain up and functioning until it reaches the hibernate voltage, at which time I expect another email, and then the device to hibernate (shut down). And I don't expect it to power up after hibernating until the wake voltage is reached. The problem is the sporadic reboots when the warning threshold is reached (and there are often multiple warning emails as the threshold voltage must waver just a bit, causing several threshold crossings sometimes, and not others).

One other power tab config. item of note: I have NOT configured individual port voltages for port shutdown/resume. I've left those empty. I have, however, set priorities on ports (i.e. my most important device with priority 12 on a 12-port DC Netonix, the least with priority 1).

Thanks!

-Aaron out.

[jpaine619]

Erm... I see we are up to 1.5.1rc7, but the last change log I can find is for RC4. Can anyone point me to the 5, 6, & 7 change logs?