v1.5.18 Bug Reports and Comments

[Stephen]

Latest WS Stable Release: v1.5.18


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


Personally we feel this is the most stable and best firmware since v1.4.8.

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
- Patched security holes to prevent hacking, however you should always use the Access Control List as good practice.
- Upgrade failure on very old WS models
- Openssl upgraded
- lighttpd upgraded
- Removed PHP replaced with compiled binaries (approximately 60,000 lines of code needed re-written)
- Greatly improved SFP compatibility and Stability where you saw SFPs not come up after upgrades and reboots
- Fixed potential multi reboots due to certian configurations during warm boots and firmware upgrades
- Fixed NTP
- Fixed SNMP memory leak
- 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)
- Upgraded session hash algorithm
- Fixed MAC table lookup and updated to latest vendor list
- NTP scripts fixed
- fixed special characters (aka !#@, etc) during login
- 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)


ENHANCEMENTS
- UI works faster as it is binary verses PHP

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

Released 11/16/2024

[marcbou]

Hey ssh keys are still not working properly. it seems a truncated version of the key is incorrectly written to /etc/dropbear/authorized_keys.

If I copy a proper authorized_keys from a switch with older firmware, then logging in with ssh key works fine on v1.5.18.

I saw an older thread where this same issue was reported but the answer was "we don't use ssh keys" and the thread was locked. This is not an appropriate response !

Can we please get a proper fix for this regression please ? ssh keys are very useful for automated secure remote command execution through scripting for network management.
Just because you don't use them isn't a valid reason not to fix this simple bug !

[Stephen]

Hey ssh keys are still not working properly. it seems a truncated version of the key is incorrectly written to /etc/dropbear/authorized_keys.

If I copy a proper authorized_keys from a switch with older firmware, then logging in with ssh key works fine on v1.5.18.

I saw an older thread where this same issue was reported but the answer was "we don't use ssh keys" and the thread was locked. This is not an appropriate response !

Can we please get a proper fix for this regression please ? ssh keys are very useful for automated secure remote command execution through scripting for network management.
Just because you don't use them isn't a valid reason not to fix this simple bug !

I'm not sure who said that, I use ssh key's on all my device's in my network, including our switches.

Can you explain in more detail the steps you take to add a key? I tested this a moment ago and it worked fine.

Here are the steps I took:
1. On your host laptop/desktop. Run the command

Code: Select all

ssh-keygen

and save to some file

For example

Code: Select all

/home/user/.ssh/new_key

Which also creates the public key file

Code: Select all

/home/user/.ssh/new_key.pub

2. Open web UI and go to Device->Configuration Tab and scroll down to third row to view the SSH Panel.
3. In the SSH Config Panel, click "keys"
4. Click "import"
5. From the file system, select the public key
Which, in this scenario, is

Code: Select all

/home/user/.ssh/new_key.pub

6. Close the dropdown menu and click Save/Apply
7. Finally, login with ssh using the private key

Code: Select all

 ssh -i /home/user/.ssh/new_key admin@<switch ip>


8. Login is successful.

But it sounds to me that you may be trying to use the private key when uploading to the switch. I believe our older firmware may have worked this way, but this was incorrect. Only the public key should be uploaded to the switch.

[Banana Jack]

Great to see a fast release of the new version 1.5.18; thank you. I'm happy to confirm that I can now include exclamation marks in the password and still be able to log on to the GUI.

I think it's weird that I can use ssh to access the device using literally any username and password; is this expected behaviour? Devices running 1.5.14 need a valid username and password to authenticate. Can anyone else replicate this problem?

Glenn

[sirhc]

Great to see a fast release of the new version 1.5.18; thank you. I'm happy to confirm that I can now include exclamation marks in the password and still be able to log on to the GUI.

I think it's weird that I can use ssh to access the device using literally any username and password; is this expected behaviour? Devices running 1.5.14 need a valid username and password to authenticate. Can anyone else replicate this problem?

Glenn

Umm no, investigating now.

We did test logging into SSH but did not try INVALID info and assumed we just typed it correctly. Verifying this now and will release NEW version very shortly like within an hour or so.

My guess is this broke when we upgraded to new more secure HASH encoding of password.

THIS IS REALLY STUPID ON OUR PART.

[Hightech]

We tryed to upgrade our WS-12-250-AC, but switches with more than 33 vlan in the vlan table fail and never come back after reboot!

I have tryed to type all configuration in manuel on a factory reset switch on v1.5.18 bui it fails to save configuration when vlan number 34 is typed in?

Any suggestion i can send config backup from switches that have fail with more than 33 vlan

Br.
Carsten

[Stephen]

We tryed to upgrade our WS-12-250-AC, but switches with more than 33 vlan in the vlan table fail and never come back after reboot!

I have tryed to type all configuration in manuel on a factory reset switch on v1.5.18 bui it fails to save configuration when vlan number 34 is typed in?

Any suggestion i can send config backup from switches that have fail with more than 33 vlan

Br.
Carsten

Please PM me your backup .ncfg file or the config.json

[Stephen]

We tryed to upgrade our WS-12-250-AC, but switches with more than 33 vlan in the vlan table fail and never come back after reboot!

I have tryed to type all configuration in manuel on a factory reset switch on v1.5.18 bui it fails to save configuration when vlan number 34 is typed in?

Any suggestion i can send config backup from switches that have fail with more than 33 vlan

Br.
Carsten

Hello Hightech, I have received your config and have been able to replicate the issue. We need to get a release out now to fix ssh so 1.5.19 is going live and this thread will be closed. However, in your case I would suggest that you wait to upgrade until you hear from me. It may take a bit more time to properly isolate the issue.

I suggest anyone going forward with more than say 20 VLANs may want to hold off upgrading briefly until this is resolved.