v1.5.24 Bug Reports and Comments

[Stephen]

Latest WS Stable Release: v1.5.24


***NOTE:
WILL RESET PASSWORD BACK TO DEFAULT PASSWORD "admin" WHEN UPGRADING SO YOU MUST RESET PASSWORD AFTER UPGRADE IF UPGRADING FROM BELOW 1.5.17
(including 1.5.17rc2)


Personally we feel this is the most stable and best firmware since v1.4.8. (THIS IS CHRIS, I THINK BEST EVER)
We have been testing this intensely for weeks.


***NOTE:
Some people use a smart power strip that will reboot a switch if pings stop.
This upgrade process can take longer than normal due to a lot of house
keeping from the vast changes in code. So if the unit is power cycled
during the upgrade it is bricked. Make sure to disable this or increase
time missing pings till reboot 10 minutes or more.


***NOTE (Smart DC Switches):
On the original 1.5.17 release, it was noted that certain DC models could get bricked.
It appears that during firmware ugprade, sometimes it will also upgrade the firmware on the power supply which was being blocked by a failed semaphore init. This could easily have been corruption on download or possibly upload. But we have also added additional checks in an attempt to circumvent this issue should it appear again.
HOWEVER,
especially for smart DC models. We suggest you upgrade one that is easy for you to access in case anything goes wrong FIRST. Then continue
rollout if all goes well.




FIXED/CHANGED
- lighttpd upgraded - 1.5.17rc1
- Openssl upgraded - 1.5.17rc2
- Upgrade failure on very old WS models -1.5.17rc2
- Patched security holes to prevent hacking, however you should always use the Access Control List as good practice. - 1.5.17
- Removed PHP replaced with compiled binaries (approximately 60,000 lines of code needed re-written) - 1.5.17
- Greatly improved SFP compatibility and Stability where you saw SFPs not come up after upgrades and reboots - 1.5.17
- Fixed potential multi reboots due to certian configurations during warm boots and firmware upgrades - 1.5.17
- Fixed NTP - 1.5.17
- Fixed SNMP memory leak - 1.5.17
- Upgraded password hash (WILL RESET PASSWORD BACK TO DEFAULT "admin"
WHEN UPGRADING REQUIRES PASSWORD RESET AFTER UPGRADE IF PREVIOUS VERSION
IS BELOW 1.5.17) - 1.5.17
- Upgraded session hash algorithm - 1.5.17
- Fixed MAC table lookup and updated to latest vendor list - 1.5.17
- NTP scripts fixed - 1.5.18
- fixed special characters (aka !#@, etc) during login - 1.5.18
- checks added during boot for smart i2c supply BE CAUTIOUS WHEN UPGRADING SMART DC SWITCH'S (WS-12-250-DC, WS-8-150-DC, etc) - 1.5.18
- ssh login now only accepts correct password - 1.5.19
- VLAN's and other variable length conf items no longer limited - 1.5.20
- If greater than 30 VLAN they will now be applied correctly - 1.5.21
- Radius login fixed - NOTE, POSSIBLE SECURITY HOLE FOUND IN ORIGINAL IMPLEMENATION (pre-1.5.17) - 1.5.21
- Autobackup filenames fixed - 1.5.21
- DHCP fixed - 1.5.22
- web conf check command fixed - 1.5.22
- SMTP From Address now used when populated, otherwise defaults to switch ip - 1.5.22
- Ingress/Egress Throughput samples now account for delays lasting longer than a second, preventing weird spikes on port status - 1.5.22
- Memory corruption spikes on smart DC switch Input Voltage graphs looks fixed after 24 hour testing, please report if more are seen - 1.5.22
- NTP enable/disable will now trigger update immediately - 1.5.23
- SSH Key length extended to 1000 characters to accommodate common algorithms - 1.5.23
- WebUI Sessions can now expire, but will remain open with the webui - 1.5.23
- Multicast Configuration bug fix, this is potentially responsible for spontaneous issue's that have been reported with SFP's, PPPoE, OSPF, etc but due to testing complexity we cannot be certain, please let us know if you see any improvements if you have been experiencing these problems - 1.5.23
- SMTP will now handle from address more intuitively - 1.5.24
- NTP update bug causing failures on config changes and incorrectly triggering revert timer fixed - 1.5.24

ENHANCEMENTS
- UI works faster as it is binary verses PHP - 1.5.17

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

Released 12/20/2024

[KBrownConsulting]

Just a quick report on the SMTP fix:

Most importantly, I can confirm that the main issue is resolved. I am once again able to enter any email address into the "From Address" field and have the switch use that email address in the From header field of the email, as expected. Thanks for the quick fix!

One super minor issue to put on your list: If you leave the "From Address" field blank the switch allows you to save the config but then when you try to send a test email you get the following error:

ssmtp: No recipients supplied - mail will not be sent

That error is misleading as it's the "From Address", not the recipient that's missing. More importantly, I'm guessing leaving the From Address empty would result in emails not going out. Since it seems like you're treating the From Address as a required field I'd suggest handling it the same way you do the "Address" field. (Change box to red and prevent saving config if it's blank.)

[KBrownConsulting]

A few more email related bugs I've found:

1. Link Change alerts aren't being sent.
The log shows the switch is detecting the link change event taking place, but no email is ever sent. I tried disabling & enabling the "Link Change" email alert option and it didn't help. Honestly, I'm not sure if any of the other optional SMTP alerts are being sent because they are not as easy to trigger as a Link Change event so they should probably be checked as well! I can confirm that Watchdog alerts are being sent though. (See next item.)

2. Latitude & Longitude values are messed up in email subject
Here's an example of how the email subject is arriving:
Watchdog 'Port 1' failure checking 192.168.0.100, watchdog triggered on port 1 (Port 1), action is Bounce Link switch latitude: @zI, longitude: àsI - from Netonix Switch (192.168.0.25)

3. Email events in log don't reflect the new From Address fix.
Here's an example of how email events are showing up in the log:
Sent mail for admin@[smtp-host-domain] (221 2.0.0 [redacted] closing connection) uid=0 username=admin outbytes=773

I realize the "admin" in the log is probably coming from the account name used to log into the switch, but personally I'd find the above log entry more helpful if it showed the following values instead:

Sent mail for [smtp-from-address] (221 2.0.0 [redacted] closing connection) uid=0 username=[smtp-username] outbytes=773


With that said, #3 isn't going to impact my day but #1 is something I do use so hope it can be addressed.


I haven't done much additional testing (wanted to test and give feedback on the SMTP fix as soon as possible since I was one of the people who reported the bug) but I can say that the WS-8-150-AC I'm using to test v1.5.24 updated from v1.5.22 just fine.

[yahel]

Quick update.
Last night, we upgraded about 40 additional switches to 1.5.23 (and a couple to 1.5.24).
For the most part, everything went smoothly.
We intentionally avoided upgrades to switches that uses SFP ports.
That said, we unintentionally upgraded at least two that used SFP ports, and fortunately it was uneventful -- OSPF works via these ports.
Then we started to focus on switches that do use SFP ports, and the first that we've upgraded (intentionally) had the same issue.
Seems to not pass Multicast traffic on BOTH SFP ports (trunks and LAG members).
This is exactly the same as that other switch in which one of the SFP ports has this problem (but not the other).
Tomorrow, I'll try to replace the SFP modules and see if that helps (it didn't help in the previous switch when I replaced a mm-fiber with an AOC cable).
In the case of the switch that is failing as of last night, one of the SFP modules is a DAC cable, and the other is an SFP-to-RJ45 converter (which is working with 1.5.23 elsewhere).

More tomorrow -- I can't seem to nail what is the problem, but we'll keep trying...

[sirhc]

Quick update.
Last night, we upgraded about 40 additional switches to 1.5.23 (and a couple to 1.5.24).
For the most part, everything went smoothly.
We intentionally avoided upgrades to switches that uses SFP ports.

That said, we unintentionally upgraded at least two that used SFP ports, and fortunately it was uneventful -- OSPF works via these ports.
~~SAME AS ME OSPF WORKS WITH SFP PORTS~~

Then we started to focus on switches that do use SFP ports, and the first that we've upgraded (intentionally) had the same issue.
Seems to not pass Multicast traffic on BOTH SFP ports (trunks and LAG members).
This is exactly the same as that other switch in which one of the SFP ports has this problem (but not the other).
Tomorrow, I'll try to replace the SFP modules and see if that helps (it didn't help in the previous switch when I replaced a mm-fiber with an AOC cable).
In the case of the switch that is failing as of last night, one of the SFP modules is a DAC cable, and the other is an SFP-to-RJ45 converter (which is working with 1.5.23 elsewhere).

More tomorrow -- I can't seem to nail what is the problem, but we'll keep trying...

I just really caught this. - (trunks and LAG members)

Please define what you call a trunk. (Show list of allowed VLANs or if blank)

Please post up pictures of your Ports, LAG, and VLANs Tabs of a switch which has the issue. It can be with the older firmware so its working.

I'm "thinking" now this has nothing to do with SFP brand but rather something we missed in the PHP to binary conversion related to Trunks. But I have been wrong before, just ask Robert (AF5 50MHz wide channels), which ruined our friendship.

Please remember to use the link below called upload attachment don't link to a third party site that way the pictures will remain or the post becomes useless later.

The link is right below the BLUE Preview button. You can then put your cursor inside the post and click the grey button below the uploaded file name Place inline to position the picture within the post where you want it. (This is more of a reminder to all users)

[yahel]

Ok - I just got back from replacing SFP modules and cables -- nothing changes...
Still no OSPF peering via the SFP ports, no matter what modules, fiber (DAC, AOC, etc)...
I'll provide the pictures of the setup of the switch with the issues that started after yesterday's upgrade below.
However, on the other switch where this issue started after last week's upgrade, we have done work to isolate the problem and the port in question (SFP P14) is no longer a trunk (just has a single U on a single VLAN), and is no longer a LAG member - yet the OSPF still isn't working over it (I wrote about it in detail -- multiple posts -- but I guess it's hard to follow many public forum posts).

Anyways here goes - two LAGs, two members in each:

LAGs

VLANs (allowed VLANs in the Trunked ports are all of them 0-4095).

VLANs

Added "Ports" tab.

Ports

Since solving this takes a while, I plan to experiment with getting OSPF to work without Multicast over these ports -- I think NBMA setting should do it, but I don't really remember my OSPF deeply enough.



Finally - as if there aren't enough problems, with 1.5.24, the web-GUI occasionally shows the message that the switch was rebooted and need to reload page to match the configuration in my browser. However, the switch had NOT rebooted (thank god) -- so something else is going on related to the GUI.


Thanks,

Yahel.

[sirhc]

...

Edit above post - add Ports Tab please, important

Also specify Trunk ports with VLAN list or if blank

As I said screen shots can be from v1.5.14 or what ever version works for you

[sirhc]

@yahel BUMP

[KBrownConsulting]

the web-GUI occasionally shows the message that the switch was rebooted and need to reload page to match the configuration in my browser. However, the switch had NOT rebooted (thank god) -- so something else is going on related to the GUI.

I have experienced this more than once as well. So far haven't been able to identify what triggers it.


Also, another minor bug: The "Resolve IPs" checkbox on the Traceroute page is not respected. (It ALWAYS resolves the IPs even when unchecked.)

[mayheart]

the web-GUI occasionally shows the message that the switch was rebooted and need to reload page to match the configuration in my browser. However, the switch had NOT rebooted (thank god) -- so something else is going on related to the GUI.

I have experienced this more than once as well. So far haven't been able to identify what triggers it.


Also, another minor bug: The "Resolve IPs" checkbox on the Traceroute page is not respected. (It ALWAYS resolves the IPs even when unchecked.)

I'm pretty sure its the idle auto logout that's causing it. Seen it a few times that I left the UI open and came back to "Switch has rebooted"