Page 1 of 2
v1.5.4 Bug Reports and Comments
Posted: Mon Aug 19, 2019 6:02 pm
by Stephen
1.5.4 wrote:FIXED/CHANGED
- Production requirements for testing forced this release- This version had to be pushed as a new production run has a new temp sensor as old was discontinued
- fixed issue with watchdog poe bounce that was not completely shutting off power depending on the delay time and offset's used
- fixed memory leak in NET-SNMP
ENHANCEMENTS- Modified Port Bounce option to read 'Port Bounce POE' and added 'Port Bounce Link' manual option for status and ports tab
- Option in discovery configuration now exists to disable the switch from broadcasting on discovery protocols while the discovery tab is enabled
- link bounce option exists for the watchdog as well as the POE bounce option.
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
Released 8/19/2019
Re: v1.5.4 Bug Reports and Comments
Posted: Thu Aug 22, 2019 5:36 pm
by bipbaep
What is the difference between 1.5.3 and 1.5.4?
We have rolled out 1.5.3 to A LOT of production switches, so it would be good to know...
Re: v1.5.4 Bug Reports and Comments
Posted: Thu Aug 22, 2019 6:46 pm
by Stephen
The highlighted text summarizes it. Honestly this was more of a manufacturing issue. All my work on the firmware has been frozen until this release because of needed changes for the factory. The coming rc release for this version will have change's you may want to wait for.
Re: v1.5.4 Bug Reports and Comments
Posted: Tue Aug 27, 2019 1:00 pm
by s7stem-abotbyl
With syslog, it seems the logging is done with an improper format (even with Log Name enabled (which really should be a default).
The current log is:
<140>Aug 27 11:55:01 UI: User 'admin' logged in from ::ffff:172.16.0.5.
but should ideally be
<140>Aug 27 11:55:01 $HostName: UI: User 's7admin' logged in from ::ffff:172.16.0.5.
This is messing up our logging application since it's not following a standard format.
Re: v1.5.4 Bug Reports and Comments
Posted: Tue Aug 27, 2019 3:44 pm
by Stephen
Are any of the other logs beside's the user logging in that cause this?
Re: v1.5.4 Bug Reports and Comments
Posted: Tue Sep 03, 2019 2:33 pm
by s7stem-abotbyl
Yes all logs are this format when remote syslogging.
Re: v1.5.4 Bug Reports and Comments
Posted: Mon Sep 16, 2019 4:04 pm
by TheNet
Hi,
ntp issue is not resolved in 1.5.4 for ws 12-250-dc and ws 8-150-dc after firmware upgrade it is still showing that you have not set time.
Tried NTP server in local network and public ,same result.
Re: v1.5.4 Bug Reports and Comments
Posted: Mon Sep 16, 2019 5:12 pm
by sirhc
TheNet wrote:Hi,
ntp issue is not resolved in 1.5.4 for ws 12-250-dc and ws 8-150-dc after firmware upgrade it is still showing that you have not set time.
Tried NTP server in local network and public ,same result.
NTP service would be the same regardless of the model as they are all basically the same hardware and firmware just different number of ports.
I am not aware of any bugs with NTP on our switches. If you are having issues getting time from an NTP server it has to be your configuration.
So I just upgraded the switch here in the office to v1.5.4 from v1.5.2 and NTP worked fine in v1.5.2
Now this switch is behind a NAT but I have other switches in my WISP and even 1 at a VALID IP and others on invalid 172.17.X.X addresses that are not rout able beyond my network edge but they do route and talk to an NTP server we setup in our NOC inside our network.
And as I said all our switches use the same firmware and all our switches use basically the exact same internal hardware and basic design so this is not model specific.
NTP works, if it does not work then you need to look into your network configuration.
Re: v1.5.4 Bug Reports and Comments
Posted: Tue Sep 17, 2019 6:43 pm
by Ludvik
You have not a central ticket management?
viewtopic.php?f=17&t=5443
Re: v1.5.4 Bug Reports and Comments
Posted: Wed Sep 18, 2019 6:59 am
by sirhc
OK so NTP not working with DHCP IP address, will test this and if broken will have fixed and put in next release as programers are here in PA this week.
I never test these issues with DHCP as I can never understand why people would want infrastructure like switches on a dynamic address but then again this is like Ford Chevy argument and I need to force myself to do so in the future.