v1.2.0 FINAL bug reports and comments

[sirhc]

It has to be something specific to peoples networks that see it as I and most people do not see this behavior?

We would love to figure it out but we need to find someone willing to assist in in the process that is having the issue and can recreate it to demonstrate the behavior.

We can not fix something we can not recreate or we have to have access to someone's PC connected to a switch when the issue is being recreated.

If a "few" people experience it occasionally it makes it hard to figure out why, but do not get me wrong, even if just 1 person has an issue we want to figure out why but a little assistance will be required.

What we need to resolve this issue:
1) Access to the computer connected to the switch via Team Viewer
2) The ability to recreate it when we access your computer

Or if someone can figure out a LAB that will recreate it for us so we can set it up and see it happen.

[sethjt33]

So far there is only one or 2 other people that have reported this issue and we have offered to use something like Teamviewer to come in and look at their issue but they are not that concerned as they are busy.

Maybe you could provide some information to help with this?

What firmware version is on the switch?

What browser and version are you using?

Is your computer in the same subnet as the switch?

I have over 20 of these switches deployed at my WISP and do not see this issue in fact I have the UI open to all of them for days at a time.
There are over 1,000 of these switches deployed and only 2 people have reported this issue so it has to be something specific that causes it.

So if you are willing to set this up and demonstrate this with Team Viewer we may be able to help.

Are you positive there is not an IP conflict on your network as this would definitely cause this issue as the devices would fight over the ARP entry basically knocking down communications to the switch then randomly the switch would get the ARP entry and then the other and so on. An easy check would be to find an IP address you know is vacant then change the switch IP and see if that has an effect.

I have three switches on two different subnets and always on different subnets than the computer trying to access them. only tried the latest chrome. all version 1.2

all three do the same thing.

[sirhc]

Well we would be happy to look at this for you but you will need to setup Teamviewer on a computer that we can come in to so you can demonstrate what is going on. Eric would call you then connect to your computer and you could show him what is going on and we can try and see what is going on.

Also you will have to demonstrate this so please explain what is happening exactly, are you connected for a short period of time and this happens, or is it random?

Have you tried doing a constant ping to the switch from the computer accessing the UI to see if you are losing packets?

Please provide as much detail as you think might be useful.

Also I will tell you that if you use Chrome and you are logged into Chrome and another computer is also logged into Chrome also accessing the switch WITH THE SAME LOGIN CREDENTIALS it will kick each other out as Chrome shares security certificates. This behavior took me by surprise as I would be logged into the switches at my office then go home and log into the switches and I would get kicked out because I am also logged into Chrome/Google with the same account at home.

[AdamB]

I have recently discovered a bug in 1.2 related to VLAN. If I add a VLAN to a switch and then remove it later the switch will no longer trunk that VLAN. It explicitly denies trunking the deleted vlan but continues trunking all other VLANs as normal.

This could become a big problem as people might temporarily setup access ports to do testing and then remove them--and break their trunking of that vlan.

Keefe

Keefe, do you know off hand if this bug is new to 1.2.0, or if it existed in 1.1.8? I'm not currently trunking, but I could absolutely see myself adding trunks and I'd hate to have someone forget about this issue and get burned. If this is not known, I can probably test this in the lab by Monday, but I'm not planning to be at the office this weekend.

-Adam

[sirhc]

I have a v1.2.1 with that fixed I just have not released it yet

[telcom]

Any update on 1.2.1

I have been testing new vlans on some switches that are awaiting deployment and would like not to run into this vlan bug

Thanks

[sirhc]

Any update on 1.2.1

I have been testing new vlans on some switches that are awaiting deployment and would like not to run into this vlan bug

Thanks

I will post v1.2.2 later today

[Eric Stern]

I have recently discovered a bug in 1.2 related to VLAN. If I add a VLAN to a switch and then remove it later the switch will no longer trunk that VLAN. It explicitly denies trunking the deleted vlan but continues trunking all other VLANs as normal.

This could become a big problem as people might temporarily setup access ports to do testing and then remove them--and break their trunking of that vlan.

Keefe

I was unable to duplicate this bug in the lab today with 1.2.1.

I have a device on Port 4 using VLAN ID 100. Port 1 is hooked up to another switch which has another device that is also on VLAN 100. I have an explicit VLAN configured for this. The two devices can ping each other.

vlan1.png (27.42 KiB) Viewed 6423 times

I then removed the explicit VLAN and trunked Port 4. After doing this the two devices can still ping each other.

vlan2.png (25.51 KiB) Viewed 6423 times

If you can figure out how to reproduce this and give me steps I will look into it further.