Netonix Forums

NOTE: WE REMOVED v1.5.1 FROM CIRCULATION AS THERE IS A BAD BUG WITH STP INTERACTING WITH LAGS.
PLEASE USE V1.5.2rc4 OR NEWER. ALSO YOU MUST USE v1.5.2rc4 OR NEWER WITH ANY RECENTLY PURCHASED SWITCHES AS YOU NEED THIS FIRMWARE TO PROPERLY DRIVE THE NEW FANS.

Please post bug reports and comments on v1.5.1 ONLY in this thread.

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

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

Released 1/28/2019

Can you elaborate on this one?

- Fixed voltage input calibration for the WS-8-150-DC

I was at one of my towers just yesterday (yes, really) and was trying to calibrate my WS-8-150-DC to match what my multimeter was saying the voltage was, and I kept getting an error that said something like: "Voltage must be within 1.5v of measured values", but the Netonix and the Multimeter were disagreeing by about 2.2v so it wouldn't let me input the value that the multimeter was showing..

You should be able to change the calibration in steps.
So for example if the switch is reading 20.0V for the Power Supply Input Voltage, and your meter is reading 22.2V
Calibrate by first inputting the max change (+1.5) or 21.5,
then after everything update's,
You can enter 22.2 and shortly thereafter the Input Voltage and the meter should match.

I'll give that a try. Thank you.

Back to my original question, though, what was changed in the new firmware regarding voltage calibration?

Oh right duh, sorry got too focused on the second part of your question.

The WS-8-150-DC model was not applying the dc calibration value.
It was actually fixed in 1.5.1rc1

Sounds like a good reason to upgrade. Thanks for the follow-up!

Oh, one last question. Was this issue with the voltage calibration a regression? I'm wondering if I need to visit all of my tower locations, that use the DC-8, and redo the calibration after applying this new firmware.

No problem,

Not sure I'd call it a regression exactly since this was a new fix for the WS-8-150-DC.
The calibration value's you created would still be in memory. So if it was done right before it should be fine now.
But the issue with that is of course that since it was not correctly applying the calibration. I doubt that the calibration value currently in memory is correct on your other WS-8's.

I'd say follow up with at least one of them after the update to see if it needs adjusting.

OK, we have upgraded a bunch of Netonix Wispswitches last night.

We have been seeing what was once a rather subtle bug on previous fw (1.4.9 and/or 1.5.0, hard to tell) and barely had enough data about it to confirm it was not just coincidences. But since upgrade, we have caught same bug rather not-subtly twice in a day on 1.5.1. Hardware bug has presented on includes a WS-24-400A and a WS-12-400-AC as of today's testing.

Bug presents as follows: Wispswitch configured with some vlans (never more than 4 as it happens in our case, and seen with as few as management vlan + one more). Layer 3 traffic to one or more IP addresses on a single vlan that is not the management vlan (so far we've only caught this on one or more access ports at a time, that is to say vlan is set to "U" for this port) stops flowing. Some layer 2 traffic must be passing because the mac address table on the wisp switch (and on the router behind it) will rebuild for the problem IPs after you flush them. Needless to say, flushing mac cache does not make bug go away.

Problem start for IPs reachable through a given port appears to coincide with when that port hiccups, flaps, or renegotiates a different speed, per our device and SNMP logs.

"Some" IPs on a given vlan become unreachable, but not usually all. Affected IPs may be in any subnet, and other IPs in same subnet/vlan combo may continue to work just fine. In one instance this was on an AP and we had not diagnosed the problem as originating with the Wispswitch yet, so we tried rebooting the AP. The first time, only one client was affected but when AP came back online all clients were affected, while AP management interface was still reachable. After second reboot, even AP management interface stopped being reachable.

Bear in mind "reachable" is as measured from router behind any of these Wispswitches, or as measured from Wispswitch's management IP on a different vlan and a different subnet from the affected targets, so its traffic would have to leave the switch to the router and loop back.. making it no closer to the asset than the router itself.

So, our next diagnostic step is often to try creating a new IP in the same subnet as one of the troubled IPs, and applying that to the Wispswitch as an extra IP for that specific vlan. The thought is "if Wispswitch can ping asset while things behind it in same subnet/vlan cannot, perhaps our vlan forwarding settings are incorrect on either the switch or the router".

But, the instant the IP address gets added to the vlan (and then save/apply) where bug is being presented, bug instantly disappears and all affected clients can pass traffic once more.

Bear in mind that other settings that we save/apply do not appear to affect the bug at all.

Once bug is gone, new IP can be cleared out from Wispswitch's vlan with no further harm.

Please let us know if there is any kind of support dump we can download from the hardware during the bug's presentation, or if you have any other suggestions for us?

Thank you.

- - Jesse Thompson
Webformix, Bend OR

UPDATE: Disregard this post. Stupid user error. Move along. No problems here.


I just encountered some strange behavior when upgrading a WS-6-MINI (board Rev F according to Status page) to 1.5.1:

Basically it appears that in v1.5.1 the switch has reversed the port order internally. What I mean is that the switch now thinks that physical port 1 is port 6 & physical port 6 is port 1.

So for example, on the switch I upgraded, physical ports 2, 4 & 6 have devices connected. After upgrading to 1.5.1 the switch now shows ports 1, 3 & 5 as the active ports. (Ports 1, 3 & 5 now show an Active link & are counting traffic.)

Note that it did NOT change the port labels/descriptions so if you are using all 6 ports (or any ports that could get "reversed" like 1 & 6 or 2 & 5 etc) then it would be very hard to detect this problem since the same ports would appear active before & after the upgrade.

I didn't watch the upgrade process closely but everything seemed to proceed normally & as best I could tell there were no errors.

After I noticed the problem I rebooted the switch again but the problem remains. Since this switch is remote I'll have to investigate further later tonight. (Luckily I was smart & was testing the 1.5.1 upgrade on my non-production test switch.)

Can anyone else confirm?

@Netonix, if you want any more info just let me know.

KBrownConsulting wrote:I just encountered some strange behavior when upgrading a WS-6-MINI (board Rev F according to Status page) to 1.5.1:

Basically it appears that in v1.5.1 the switch has reversed the port order internally. What I mean is that the switch now thinks that physical port 1 is port 6 & physical port 6 is port 1.

So for example, on the switch I upgraded, physical ports 2, 4 & 6 have devices connected. After upgrading to 1.5.1 the switch now shows ports 1, 3 & 5 as the active ports. (Ports 1, 3 & 5 now show an Active link & are counting traffic.)

Note that it did NOT change the port labels/descriptions so if you are using all 6 ports (or any ports that could get "reversed" like 1 & 6 or 2 & 5 etc) then it would be very hard to detect this problem since the same ports would appear active before & after the upgrade.

I didn't watch the upgrade process closely but everything seemed to proceed normally & as best I could tell there were no errors.

After I noticed the problem I rebooted the switch again but the problem remains. Since this switch is remote I'll have to investigate further later tonight. (Luckily I was smart & was testing the 1.5.1 upgrade on my non-production test switch.)

Can anyone else confirm?

@Netonix, if you want any more info just let me know.

What firmware version was your switch before you upgraded to 1.5.1?

Also, try defaulting the switch with the cli command:

Code: Select all

reload defaults


and see if that corrects the issue.