v1.5.14 Bug Reports and Comments

[sirhc]

FIXED/CHANGED
- Fixed SSH login with RADIUS

ENHANCEMENTS

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

Released 4/26/2022

[jpmoller]

I can't see a release for 1.5.13. Was the issue with QinQ and Double tagging fixed with this release? Nothing in the list of fixed issues.

[sirhc]

I can't see a release for 1.5.13. Was the issue with QinQ and Double tagging fixed with this release? Nothing in the list of fixed issues.

I skipped 13. like 13th floor missing on most hotels

VLAN issue is under investigation.

[jpaine619]

Any chance you'll address the SMTP bug I reported two years ago?

I'm still having issues with the way a Netonix switch forges it's HELO string when connecting to a SMTP server. You already have the hostname field, all the switch has to do is USE it.

I provided the relevant RFCs and have been more than patient to get this fixed. It's a bug, it's a violation of the SMTP RFCs, you have the functionality in place, all you have to do it fix it. I shouldn't have to do a work-around every time I install a Netonix and I shouldn't have to disabled the most basic SPAM check an SMTP can do, which is see if the HELO string is forged. Every single Netonix I have does EXACTLY that.

The Netonix connects and says HELO x.x.x.x (where xxx is the IP of the MAIL SERVER). My mail server knows that's a lie because it's aware of it's own IP address. The only people who do that in the real world are spammers. My professional grade network switches should NOT be doing that. Either HELO x.x.x.x (where X is the Netonix's IP address or whatever I have put in the HOSTNAME field that you have ALREADY PROVIDED).

The HELO string is how the machine CONNECTING (The Netonix is our case) ANNOUNCES ITSELF. Why the hell would it HELO and then tell my SMTP server it's own address? My servers are not idiots, they know who they are. They want to know who the NETONIX is.

C'mon... Two years...

[jpmoller]

In response to a potential memory issue I raised in the thread for v1.5.12, I was asked to disable discovery options on the switch to see if it had an impact on the memory usage on the router
Original post -> https://forum.netonix.com/viewtopic.php?f=17&t=7371&start=20#p36648


Below is a graph showing the available memory still trending downwards after discovery was disabled and host rebooted 7 days ago

WS-8-150-DC memory usage

Comparing it over the last 90 days, you can see the trend over the last 7 days matches what the trend was before disabling discovery

90 day trend

Here is the configuration of the switch for discovery

Discovery settings

Screen Shot 2022-05-02 at 10.38.13 AM.png (11.59 KiB) Viewed 50220 times

What is the next thing I can test?

[dfusselmanTurnkey]

The old faithful of disable SNMP > Save > Enable SNMP and see if you free memory comes back =)

In response to a potential memory issue I raised in the thread for v1.5.12, I was asked to disable discovery options on the switch to see if it had an impact on the memory usage on the router
Original post -> https://forum.netonix.com/viewtopic.php?f=17&t=7371&start=20#p36648


What is the next thing I can test?

[jpmoller]

I thought this was a joke, but toggling SNMP has restored available memory to the same level as when it reboots after available memory runs out. What even? We don't collect a lot of data from the switches via SNMP. And if that is what is causing the issue, I would expect it to be happening on all of our switches.

I'll monitor this over the next week to see if the available memory is still decreasing. While this allows us to pre-emptively avoid a switch reboot at peak times, we shouldn't have to do that.

Is there any other testing I can conduct to try and figure out what is going on? We are not comfortable moving on from v1.5.8 until we see stability on the current platform.

Current firmwares that we do/do not see the issue on

v1.5.0 - Observed on all switches: 14
v1.5.4 - Observed on all switches: 14
v1.5.5 - Observed on 2 of the 47 switches, but the time period for degradation is much longer than the other versions mentioned
v1.5.5rc - Observed on 1 of the 6 switches, but the time period for degradation is much longer than the other versions mentioned
v1.5.6 - Observed on 3 of the 35 switches on this firmware
v1.5.8 - Observed on 1 of the 37 switches, but the time period for degradation is much longer than the other versions mentioned
v1.5.11 - Observed on 3 of 3 switches on this firmware


The only custom thing we do during provisioning on these switches is adding an ssh key with a command bound to it to output the switch configuration for remote config backup via ssh. I have removed the key from one of the switches on 1.5.11 to see if that has any impact. Otherwise, every other piece of configuration is what the web UI allows.

[jpmoller]

This has made no difference. Memory still decreasing at a constant rate.

Memory leaks was a major issue in this thread
https://forum.netonix.com/viewtopic.php?f=17&t=4788&hilit=Memory+Bug&start=80

I cannot see any resolution coming from this. Not a single release from 1.5.5 mentions patches to known memory leaks

I'm happy to assist in any troubleshooting to get to a solution. Please let me know what else I can do to narrow down the scope of the issue.

[KBrownConsulting]

This has made no difference. Memory still decreasing at a constant rate.

Memory leaks was a major issue in this thread
https://forum.netonix.com/viewtopic.php?f=17&t=4788&hilit=Memory+Bug&start=80

I cannot see any resolution coming from this. Not a single release from 1.5.5 mentions patches to known memory leaks

I'm happy to assist in any troubleshooting to get to a solution. Please let me know what else I can do to narrow down the scope of the issue.

If toggling SNMP off & back on restored available memory, it would seem there's a good chance the memory leak is SNMP. Do you have a switch with the problem that you can try disabling SNMP on and see if the memory leak goes away? Obviously that's not a solution if you need SNMP, but if you're interested in narrowing down the scope of the issue like you said then that's an easy way to confirm the problem is in SNMP.

[IntL-Daniel]

Any chance to fix reported SFP issue?
here viewtopic.php?f=17&t=7469&p=36804
and here viewtopic.php?f=17&t=7268