v1.3.9 FINAL bug reports and comments

[mhoppes]

Chris,
Something absolutely changed in the 1.3.8 firmware.

I have rebooted the switches and it doesn't fix anything.

1.3.4 - Works Fine
1.3.8 - Broken - Packet Loss when Flow Control enabled on ports connected to airFiber24s
1.3.9 - Works Fine even with Flow Control enabled.

So what changed between 1.3.8 and 1.3.9 that might have corrected this? Literally, the issue is broken in 1.3.8 but works flawlessly in 1.3.4 and 1.3.9.

[sirhc]

Chris,
Something absolutely changed in the 1.3.8 firmware.

I have rebooted the switches and it doesn't fix anything.

1.3.4 - Works Fine
1.3.8 - Broken - Packet Loss when Flow Control enabled on ports connected to airFiber24s
1.3.9 - Works Fine even with Flow Control enabled.

So what changed between 1.3.8 and 1.3.9 that might have corrected this? Literally, the issue is broken in 1.3.8 but works flawlessly in 1.3.4 and 1.3.9.

I did not see the problem on my network with v1.3.8, not saying you do not, but you are saying it works fine in v1.3.9 which is the newest version?

Should we go back and try and fix v1.3.8 if v1.3.9 solves your issue?

[sirhc]

If v1.3.9 fixes your issue is it not solved?

However my guess as to possible reasons why you have an issue with v1.3.8 and I do not (my network is routed not flat) is highlighted in red below:

FIXED
- Fixed clear log
- Fixed SNMP using 100% CPU
- Fixed config revert not working
- Fixed per-port graphs that were broken if switch was up less than 1 hour
- Fixed condition where DC2DC power supply failed to wake up switch from hibernation mode
- Fixed where unresolvable hostname could hang syslog server
- Fixed DC power supply voltage range
- Fixed UBNT Discovery name
- Fixed Watchdog, now disabled if port is disabled
- Fixed so now retains log if log daemon is restarted
- Fixed so CLI no longer saves config unless something was changed
- Fixed Log file formatting
- Fixed UBNT Discovery - FINALLY
- Fixed Linux log
- Fixed Loop protection log entry refers to wrong port number
- Fixed Broadcast storm when using LACP and RSTP
- Fixed Unable to change RSTP path cost for LAGs
- Fixed MAC table eating up CPU time when you have hundreds and hundreds of MAC entries.
- Fixed SNMP, Changed from mini-snmpd to net-snmp, a more common and well tested snmp daemon.

ENHANCEMENTS
- Added enable/disable VLAN to CLI
- Added "clear log" CLI command
- Added LLDP Discovery
- Added changing of Safe Mode Timer and ability to disable Safe Mode
- Added ability to reset counters per port instead of all
- Added Enhancement for MAC table
- Added clear stats command to CLI
- Added HTTP watchdog - Customer can now create a watchdog event based on an HTTP URL
- Allow up to 253 character RADIUS secret - USER REQUESTED
- Delay I2C init in SMART DC power supply firmware to fix random RJ45 POE light on a cold boot - COSMETIC FIX ONLY

[mhoppes]

Yes, I guess that fixes it. I just don't know why 1.3.8 caused that to happen.

[sirhc]

Yes, I guess that fixes it. I just don't know why 1.3.8 caused that to happen.

Neither do I, but had you been keeping your switches up to date and discovered this issue while those versions were still being openly developed/fixed we could have fixed that bug sooner?

Obviously something we fixed for someone who reported a bug during the development of v1.3.9rcX (which was the time we were fixing bugs found in v1.3.8) also fixed your issue as well?

[mhoppes]

Can you or Eric elaborate on this?

- Fixed Broadcast storm when using LACP and RSTP

That's the only thing I even remotely see that looks like it could affect something on the switching fabric.

[sirhc]

Can you or Eric elaborate on this?

- Fixed Broadcast storm when using LACP and RSTP

That's the only thing I even remotely see that looks like it could affect something on the switching fabric.

You can do a search for it in the v1.3.9rcX threads and you can read about Thomas reporting the bug and then us fixing it.

I just did a quick search and here is where Thomas reports we fixed it:
viewtopic.php?f=17&t=1241&p=9364#p9364

[sbyrd]

I will give it a try off hours later tonight. So far I have 3 WS-Minis on 1.39 or 1.39rc15 and they all report uptimes of 429 days. I have another WS-MIni on 1.33 with a SNMP uptime of 117 days and GUI uptime of 118 days. My WS-12s and WS-8 (running much older FW) are reporting uptimes correctly.

I will work on upgrading all my switches to 1.39 (including my WS-12s and WS-8) and report back.

If it matters I am using The Dude for SNMP and pulled these values using SNMP walk.

OH, My bad I did not read your post correctly, I thought you were referring to the UI report of uptime.

Yes upgrade them to v1.3.9 and report back as there were MAJOR changes to SNMP in v1.3.9

There may be a bug on the SNMP reported up time so yes please upgrade and review the release notes.

Also note that you now must use our new MIB file located HERE

I upgraded a WS-8-AC from 1.2.0 to 1.3.9 and now it is reporting the uptime in SNMP as 430days. On 1.2.0 the uptime was reported correctly. So as of now i have 4 switches on 1.3.9 that all have uptimes of 400+ days.

netonix.PNG (11 KiB) Viewed 8101 times

[sirhc]

Eric confirmed SNMP reported uptime is a bug. We will release a fix in v1.4.0rc2 soon

[sirhc]

v1.4.0rc2 is released which fixes SNMP reported up time.

No core changes so if the up-time is what you want then it is a safe upgrade to get it.

Was that fast enough on the fix?