v1.4.2 Bug Reports and Comments

[sirhc]

well i just upgraded to 1.4.2 again tonight a had the same result... rolling back to 1.3.8 now...... any thoughts???

Not really?

Create a new post/thread and post up screen grabs of all your config tabs.

Since our code just runs the UI, CLI, SNMP, Daemons and configures the switch core which we do not write the code for the core and packet switching and the switch core code is the exact same between all versions from v1.0.0 to now it does not make sense?

The only thing I can think is if your using SFP modules you may need to manually set the SFP port speed?

[jtaylor901]

Very basic config..... 2 vlans tagged on two ports.... one going to my backhaul and the other going to my router.... no fiber and the ports are hard coded for 100meg.... i have another switch just the same that does not produce the issues... and it is fully loaded with 6 APs and a back haul.... i'll start another thread as suggested

[sirhc]

Very basic config..... 2 vlans tagged on two ports.... one going to my backhaul and the other going to my router.... no fiber and the ports are hard coded for 100meg.... i have another switch just the same that does not produce the issues... and it is fully loaded with 6 APs and a back haul.... i'll start another thread as suggested

Try not hard coding ports which is not a great idea.

[sakita]

Is the switch supposed to send LLDP messages when LLDP is enabled on the Device Configuration page?

For example, a WS-12-250-AC running 1.4.2 doesn't appear to be sending LLDP messages even though the LLDP checkbox is checked under Discovery on the Device Configuration page.

In this case, the neighbor switches, Ruggedcom RSG2100 and RS900, both are seen by the Netonix switch using the Tools Discovery page but neither Ruggedcom switch sees any LLDPDUs from the Netonix.

[Eric Stern]

Is the switch supposed to send LLDP messages when LLDP is enabled on the Device Configuration page?

For example, a WS-12-250-AC running 1.4.2 doesn't appear to be sending LLDP messages even though the LLDP checkbox is checked under Discovery on the Device Configuration page.

In this case, the neighbor switches, Ruggedcom RSG2100 and RS900, both are seen by the Netonix switch using the Tools Discovery page but neither Ruggedcom switch sees any LLDPDUs from the Netonix.

Yes it does. Maybe there is something about the LLDP packets that the Ruggedcom doesn't like. If you can do a wireshark capture of the LLDP packets coming from the Ruggedcom I can try and figure out what it doesn't like.

[tonym]

exit on the command line doesn't work anymore.

Code: Select all

 
manson# exit
% Quitting
manson# quit
% Invalid command
manson# exit
% Quitting
manson#


It just dumps me back to the command line, this is breaking my automatic backup script (oxidized).

I actually had to use 'pkill -n dropbear' to disconnect from the switch! I couldn't get out any other way.

[Eric Stern]

exit on the command line doesn't work anymore.

Code: Select all

 

manson# exit
% Quitting
manson# quit
% Invalid command
manson# exit
% Quitting
manson#


It just dumps me back to the command line, this is breaking my automatic backup script (oxidized).

I'll fix this in the next release.

[mike@triadwireless.net]

Can anyone verify if the STP issues are cleared up with 1.4.2 Final?

[sirhc]

Can anyone verify if the STP issues are cleared up with 1.4.2 Final?

We believe so?

The STP issue was with large flat network and the Discovery Tab and or the UBNT Discovery protocol which you can disable if you run into a problem.

We think we fixed it but the problem is people are all too willing to come post when they have a problem but not so much when things are working?

[givemesam]

So, we have some Metrolinq's and for some reason from time to time we see all traffic get blocked but we can still get to the radios interfaces.
This makes me thing something somewhere is blocking VLAN traffic, but not the native vlan.

Does this sound like something that could be this switch bug? (the metrolinq have their share of bugs and things, but this one is weird, as we can still get to the interfaces, but all VLAN traffic is stopped for a period of 30 seconds to a minute. But it may actually be all traffic AFTER the slave radio is stopped as we do loose access to some things downstream on native vlan. We sometimes reboot the radio to awaken the path, not sure that is actually helping, as the last time, we had traffic stop, then we rebooted radio, it was still stopped, then started after about 30 seconds of the interface of both ends of the radios coming up.

nothing interesting in the logs of the SW other than some DHCP and ports going up and down when we reboot.

We are running 1.4.2rc6 WS-12-250-AC Rev D

do we need to switch off the discovery tab? here is the setup: