v1.4.6 Bug reports and Comments

[tma]

On the ToughSwitches, if using STP and VLANs together, I found that I must enable "VLAN Trunking" too on the port that expects STP packets. These TSes were connected to DLINK switches, though - i.e. it may or may not help in your case. The VLAN Trunking feature appeared in TS firmware 3.0.

This is probably because STP BPDUs need to be transmitted untagged, or else it would be MSTP or some other VLAN-enabled-STP. While some switches accept untagged BPDUs even if the port is tagged-only, the TSes need to be explicitly configured to also accept untagged packets. So its either setting VLAN 1 to "U" (I haven't tried that but it may work) or setting the port to VLAN trunking.

After doing so, I haven't had any STP problems with TSes, and we still have some out there - always together with DLINKs. Because we replace the TSes with Netonix, we won't see a Netonix-TS combination ... can't help with this, sorry.

[bearm]

Do you have any test beds where ToughSwitches are interop tested?

I do not have any ToughSwitches in my network, sorry.

Here is one post about TS RSTP issue:
http://forum.netonix.com/viewtopic.php? ... oken#p4066

Thanks for the reply.

I figured you might not have ToughSwitches.

RSTP issue post: The ports in question are not trunk ports, they're untagged/access ports.

Interestingly enough, I haven't seen issues with ToughSwitch to Cisco Catalyst ... but that's not all telling (haven't isolated the true underlying cause other than something potentially related to STP). Back to troubleshooting.

[bearm]

On the ToughSwitches, if using STP and VLANs together, I found that I must enable "VLAN Trunking" too on the port that expects STP packets. These TSes were connected to DLINK switches, though - i.e. it may or may not help in your case. The VLAN Trunking feature appeared in TS firmware 3.0.

This is probably because STP BPDUs need to be transmitted untagged, or else it would be MSTP or some other VLAN-enabled-STP. While some switches accept untagged BPDUs even if the port is tagged-only, the TSes need to be explicitly configured to also accept untagged packets. So its either setting VLAN 1 to "U" (I haven't tried that but it may work) or setting the port to VLAN trunking.

After doing so, I haven't had any STP problems with TSes, and we still have some out there - always together with DLINKs. Because we replace the TSes with Netonix, we won't see a Netonix-TS combination ... can't help with this, sorry.

Both ports on either switch (Netonix and ToughSwitch) are access ports, no VLAN trunking going on across them.
I tried your suggestion and made the ToughSwitch port (to the station) a Trunk (click the checkbox) and re-enabled STP on the port (to the AP) on the Netonix. Unfortunately the same problems continued after the change.

Instead of TS firmware 3.0, do you mean 1.3.0 and later?
I'm running 1.3.2 (and the latest out [now] is 1.3.3) on the ToughSwitch in question.

I'm not sure what the magic configuration is supposed to be.
Thanks for the suggestions and guidance everyone.

[tma]

Yeah, sorry, I meant to say "the VLAN trunking feature appeared first in firmware 1.3.0".

Basically, I was describing the same thing that was mentioned in the post Chris referred you to: When STP and VLANs are active on a TS port, the port must accept untagged packets for one of its VLANs. That can be done by enabling VLAN trunking or - as the other post says - having one VLAN on the port in U (untagged) mode. I'd assume this could also be a VLAN that is defined only for that purpose, if you want to filter out untagged packets other than STP BPDUs.

I'm not sure whether our scenario is compatible to yours. We connect TSes (and now Netonixes) to DLINKs on a port that is tagging all VLANs, while all ports going to PTMP and PTP wireless devices are set to untagging one VLAN. So we are simply extending the DLINK switch with a PoE supplying switch. From your description it seems to me you are kind of doing the opposite, i.e. VLAN tagging towards a PTMP device and no VLANs between the switches. In any case, you need to make sure that a TS accepts STP packets - which it does only, because they are always arrive untagged even on otherwise tagged links, if it is configured to accept untagged packets on the STP-enabled port in its own peculiar way. If STP works across untagged ports only, there shouldn't be a problem.

[bearm]

Yeah, sorry, I meant to say "the VLAN trunking feature appeared first in firmware 1.3.0".

Basically, I was describing the same thing that was mentioned in the post Chris referred you to: When STP and VLANs are active on a TS port, the port must accept untagged packets for one of its VLANs. That can be done by enabling VLAN trunking or - as the other post says - having one VLAN on the port in U (untagged) mode. I'd assume this could also be a VLAN that is defined only for that purpose, if you want to filter out untagged packets other than STP BPDUs.

I'm not sure whether our scenario is compatible to yours. We connect TSes (and now Netonixes) to DLINKs on a port that is tagging all VLANs, while all ports going to PTMP and PTP wireless devices are set to untagging one VLAN. So we are simply extending the DLINK switch with a PoE supplying switch. From your description it seems to me you are kind of doing the opposite, i.e. VLAN tagging towards a PTMP device and no VLANs between the switches. In any case, you need to make sure that a TS accepts STP packets - which it does only, because they are always arrive untagged even on otherwise tagged links, if it is configured to accept untagged packets on the STP-enabled port in its own peculiar way. If STP works across untagged ports only, there shouldn't be a problem.

Thanks for clarifying.

I definitely have a VLAN untagged on the port going to the Station radio.
And definitely have a VLAN untagged on the Netonix going to the AP radio.

My VLAN trunking stops at the Netonix when ports go to each of the APs or backhaul links.
Correct, from what you've said my situation is the opposite of yours.

I am uplinking/feeding the Netonix with tagged traffic from a Cisco Catalyst switch, but that's working well.

[qlex]

I'm having a strange issue with the web UI and being able to authenticate. We upgraded four Netonix switches from various firmwares of v1.3.3 and higher to v1.4.6. Within 24 hours of doing so, the web UI no longer allows us to login -- however, I can login via SSH. The password is longer than 8 characters, but I have tried logging into the web UI with the same password that the switch has always had (which is the same one that works on SSH still), and using only the first 8 characters, but am having no luck.

What's the best way to fix this?
TIA

[sirhc]

I'm having a strange issue with the web UI and being able to authenticate.

I can login via SSH.

What's the best way to fix this?

Login via SSH and reset the password to a new password.

You can then login via UI and set password back to what you want.

There have been many bug fixes regarding passwords *see release notes*

It is always a good idea to read all the release notes.

Also I would use v1.4.7rc10 as that has all the bugs found so far in v1.4.6

[qlex]

Thanks, Chris. This is the first password issue we've encountered and have been with Netonix since at least v1.3.2, sorry I missed the notes. I have logged into the Netonix via SSH, dropped to cmdline, and issued 'passwd <new password>' , but the web UI is still not allowing me to login. Am I doing something wrong? Apologies, and TIA.

[Julian]

passwd is the SSH password, not sure if it carries to the web UI.

What you're looking for is:

<Netonix Switch>config t
<Netonix Switch(config)> cred pass (your password here)
<Netonix Switch(config)>

At this point, you need to pass control Z to the terminal session (might just work, depends on your SSH config i think)
and then hit enter to retain changes after the message pops up, at this point you should be okay to log in with your new password via the web UI.

[qlex]

Thank you Julian! This worked perfectly.