v1.5.22 Bug Reports and Comments

[mayheart]

One thing I've noticed, sessions don't seem to time out in the webui.

I was in a switch a few days ago, I opened the page back up this morning and it let me login without a login/password.

EDIT: I've looked into the VLANs I'm using for PPPoE, some of them have an IP on the VLAN and some don't. I'm still not expericing these issues. I wonder what's different in my setup compared to others...

[joeyr-stc]

Updated a WS-6-MINI from the Netonix Manager and it worked fine.
Now to work on 100+ more.

I want to second what mfwbooks said about accessing the login page using Netonix Manager globe button.
I don't know if I missed the conversation or not but why does the password get reset when updating?

[mayheart]

Updated a WS-6-MINI from the Netonix Manager and it worked fine.
Now to work on 100+ more.

I want to second what mfwbooks said about accessing the login page using Netonix Manager globe button.
I don't know if I missed the conversation or not but why does the password get reset when updating?

They switched to a more secure password hash.

[sirhc]

I really want to reach out to those trying to help debug the remaining issues. Taking their time, and risk to do so.

It is GREATLY appreciated.

[Stephen]

One thing I've noticed, sessions don't seem to time out in the webui.

I was in a switch a few days ago, I opened the page back up this morning and it let me login without a login/password.

EDIT: I've looked into the VLANs I'm using for PPPoE, some of them have an IP on the VLAN and some don't. I'm still not expericing these issues. I wonder what's different in my setup compared to others...

Thanks for the info, I will look closer into session's. What would be an ideal timeout for a session?

On the VLAN/PPPoE issue. Based on observations noted in the forum's so far it potentially has to do with LAG's and/or DHCP Snooping.
The observation reported by oeyre lead us to think that perhaps having an IP assigned to the VLAN or possibly the act of assigning it might clear the issue.
But based on what you've reported this is either just incidental or only loosely related somehow.
yahel was also experiencing what we think is a related issue and we're waiting to hear back if changing VLAN IP address's made any difference on OSPF multicast's in his case.


Are you using DHCP Snooping or LAG's on your switches?

[mayheart]

One thing I've noticed, sessions don't seem to time out in the webui.

I was in a switch a few days ago, I opened the page back up this morning and it let me login without a login/password.

EDIT: I've looked into the VLANs I'm using for PPPoE, some of them have an IP on the VLAN and some don't. I'm still not expericing these issues. I wonder what's different in my setup compared to others...

Thanks for the info, I will look closer into session's. What would be an ideal timeout for a session?

On the VLAN/PPPoE issue. Based on observations noted in the forum's so far it potentially has to do with LAG's and/or DHCP Snooping.
The observation reported by oeyre lead us to think that perhaps having an IP assigned to the VLAN or possibly the act of assigning it might clear the issue.
But based on what you've reported this is either just incidental or only loosely related somehow.
yahel was also experiencing what we think is a related issue and we're waiting to hear back if changing VLAN IP address's made any difference on OSPF multicast's in his case.


Are you using DHCP Snooping or LAG's on your switches?

Maybe an half an hour to an hour or so before the session gets closed?

I only use DHCP snopping facing access points on copper ports, not on the fiber uplinks.

Out of the 300 some Netonix devices we have deployed, we're only running LAG on one and that's facing an appliance that expects LAG and not normal ethernet. That is also running 1.5.22.

[RTGLW]

You know we never tested or even thought about the switches being polled by two snmp like servers. Wondering what happens if they both hit at same time?

And yes this is hitting it pretty often, more than we recommend obviously, worried about the small CPU in there which could be fine and something else.

As a test could you only query it from one and start at 2 minutes, then decrease to 1 min just for shits and giggles.


Not saying we won't investigate and or come up with a solution, but this would help.

My assumptions would be that the switch either processes both in parallel, queues the second request, or drops one or both entirely if it's resources are overcommitted? Theoretically, this should never occur. But just to clarify your request here, are you suspecting a high polling rate to be causing an issue with SNMP collection on first boot after 1.5.22 upgrade? I ask only because SNMP works fine at our current polling rate after a reboot/server toggle. We have a number of different hosts tied to the same prometheus snmp polling job, so I'd have to see what my systems team and I could do to test this if you believe that's directly affecting. Not sure if @Dawizman would have an easier time testing this?

On an unrelated note, I believe I've found an issue with how SSH keys are being stored (sorry, another for the list). We have 2 SSH keys added to the switch and the keys themselves have been truncated and put together on one line, rather than on two. I removed the keys and re-added them from both the CLI and webUI with the same results. The key looks to gets truncated even if only adding one.

How it is on our production hosts-

Code: Select all

 
root@<redacted>:/www# cat /etc/dropbear/authorized_keys
ssh-rsa <redacted full key>
ssh-rsa <redacted full key>


How it is on 1.5.22-

Code: Select all

root@<redacted>:/www# cat /etc/dropbear/authorized_keys
ssh-rsa <redacted truncated key>ssh-rsa <redacted truncated key>

[Stephen]

You know we never tested or even thought about the switches being polled by two snmp like servers. Wondering what happens if they both hit at same time?

And yes this is hitting it pretty often, more than we recommend obviously, worried about the small CPU in there which could be fine and something else.

As a test could you only query it from one and start at 2 minutes, then decrease to 1 min just for shits and giggles.


Not saying we won't investigate and or come up with a solution, but this would help.

My assumptions would be that the switch either processes both in parallel, queues the second request, or drops one or both entirely if it's resources are overcommitted? Theoretically, this should never occur. But just to clarify your request here, are you suspecting a high polling rate to be causing an issue with SNMP collection on first boot after 1.5.22 upgrade? I ask only because SNMP works fine at our current polling rate after a reboot/server toggle. We have a number of different hosts tied to the same prometheus snmp polling job, so I'd have to see what my systems team and I could do to test this if you believe that's directly affecting. Not sure if @Dawizman would have an easier time testing this?

On an unrelated note, I believe I've found an issue with how SSH keys are being stored (sorry, another for the list). We have 2 SSH keys added to the switch and the keys themselves have been truncated and put together on one line, rather than on two. I removed the keys and re-added them from both the CLI and webUI with the same results. The key looks to gets truncated even if only adding one.

How it is on our production hosts-

Code: Select all

 
root@<redacted>:/www# cat /etc/dropbear/authorized_keys
ssh-rsa <redacted full key>
ssh-rsa <redacted full key>


How it is on 1.5.22-

Code: Select all

root@<redacted>:/www# cat /etc/dropbear/authorized_keys
ssh-rsa <redacted truncated key>ssh-rsa <redacted truncated key>

Hi RTGLW,

Noted, how large are your key's? As in, what is the character count?

[RTGLW]

Should've added that, still waking up. One is 748 characters and the other 785. These got truncated down to 120 and 102 characters after upgrade, but when I added them manually I got a different truncated count again.

[Stephen]

Should've added that, still waking up. One is 748 characters and the other 785. These got truncated down to 120 and 102 characters after upgrade, but when I added them manually I got a different truncated count again.

No worries,

Fortunately this isn't a big deal to fix, I have a few knob's and dials I can turn to accommodate these sorts of things.

However, just in case it's helpful. You may want to consider moving from RSA to Ed25519 or ECDSA, it's my understanding that these key's are smaller and more secure.

Regardless, I will modify it to work with the larger key's.