v1.2.3 and v1.2.4 FINAL bug reports and comments

[keefe007]

I still see this problem on 1.2.4

[sirhc]

Oops, I meant to say on 1.2.4 not 1.2.2.

Current Time7/23/2015, 11:49:33 AM
Uptime1 day 23:04:28
CPU Usage10%
Memory Usage29.70
MBMAC Addressec:13:b2:91:06:fc
IP Address
Firmware Version1.2.4Board RevB

Well can you please provide a LAB to demonstrate your false loop detection or at the very least post your config Tabs. The log does not help as it just says it is going on but what it causing it or how you are setting up your switch that causes the false loop detection is what we need.

It would be like your customer calling you up and saying their laptop or iPad loses wireless connectivity to their home AP and asks you to fix it and that is all they told you.

Most people have reported that their false loop detection stopped with v1.2.4 so we need to know a setup that can re-create it so we can address it.

[menacers]

I spontaneously starting getting false loop detections. I was running 1.2.0. It was happening every few minutes so I upgraded to 1.2.4 and the issue still persists. I have disabled the loop detection and the issue immediately stopped.

[sirhc]

I spontaneously starting getting false loop detections. I was running 1.2.0. It was happening every few minutes so I upgraded to 1.2.4 and the issue still persists. I have disabled the loop detection and the issue immediately stopped.

Please post screen captures of your config tabs (Ports, LAG, RSTP, VLAN, Device/Config) and "formatted" log file so we can see what might be going on.

Actually RSTP is a better solution under most situations but we should find the bug if we can.

[keefe007]

I have a very basic setup. No LAG, STP, or VLANs setup. Only VLAN trunking enabled on every port.

Only 2 ports in use. 1 - Backhaul to network and 1 - Access Point. On the access point I only have one customer. It should be noted that the customer is inside a VLAN (the CPE radio at the customer site is doing the VLAN tagging).

[sirhc]

I have a very basic setup. No LAG, STP, or VLANs setup. Only VLAN trunking enabled on every port.

Only 2 ports in use. 1 - Backhaul to network and 1 - Access Point. On the access point I only have one customer. It should be noted that the customer is inside a VLAN (the CPE radio at the customer site is doing the VLAN tagging).

Well you do know how Loop Protection works right?

Each port constantly sends out a special unique packet every second that is identified by the unique mac address of that port in the switch.

Now if that packet comes back to the same port that indicates a possible loop somewhere out past that port, maybe a loop on another switch that is plugged into that port.

OR

If the packet come back to another port the question is how and it is considered a possible loop.

False loop protections can be caused by other switches or devices leaking packets across their VLANS and such and may be the reason some people see them as we are unable to find fault "so far" in our code or reproduce it???

One option is to just disable Loop Protection, you can always use RSTP which is a more robust option.

[anvilcom]

Both 1.2.3 and 1.2.4 upgrades screwed me! WS-12-250-AC was accessible behind a mikrotik RB850G with 1.2.2. Upgrading killed all accessibility. I can access via serial console and the config is still there. I can ping the local IP via the serial console, but not the gateway. If I reconfigure a computer with the wisp switch's gateway, I can access it via the web gui.

I need to have 1.2.2 so I can downgrade, but I can't find that version on this site any longer.

Please help.

[anvilcom]

Rolling back to 1.2.2 solved my problem. I was lucky that I didn't deploy the wispswitch yet. Still testing. It does shake my confidence that a FW update renders the unit inaccessible.

I'm willing to help troubleshoot and see if we can isolate the issue and correct for future smooth FW updates.

[sirhc]

It has to be something with your config as MANY MANY people including me are using v1.2.4 with no issues.

The first thing you can do is post your config tabs and explain your issue in detail.

If you have another WISP Switch LAB it first before you deploy it. If my guys at my WISP installed any new gear without first LAB-ing it I would be very upset with them.

The BIGGEST thing some people are having issues with is Loop Protection disabling ports. The way Loop Protection works though it could be doing it's job correctly and another piece of gear on your network is not which causes a false Loop Detection.

I have spelled this out many times already but here it is again.

When Loop Protection is enabled under the Device/Configuration Tab the switch sends a special packet out each port every second with that port's unique MAC address. The special packet will propagate through switches and only stop at end points like routers or computers or such. If one of those special packets makes it back to the switch on the same port the switch is concerned that a loop exists somewhere out there and a packet storm will be coming so it disables the port for 90 seconds then tries again. If the packet come back on another port then it disables one of the ports assuming a loop is detected.

What I think is happening with Loop detection is that the packet comes back to the original port because of the way some people set up their network or a malfunctioning piece of equipment and the switch thinks there is a loop out there on that port and it disables it.

There were changes made to Loop Protection in v1.2.4 that was our fault with VLANs maybe that change is causing your issue.

Anyway did you even look in the log file to see why you lost connection? It maybe that Loop Protection was disabling the port.

Turn Loop Protection OFF and see what happens, but also check your logs. And post your config Tabs and describe your network architecture

[anvilcom]

No loop protection entries in the log. 1.2.3 seems to trigger the problem. Upgrading to 1.2.4 didn't solve it either. I disabled loop protection and still no entries in log re loops, and still not functioning / passing traffic.

Rolling back to 1.2.2 did fix it.

I'm at home now, but I'll follow up tomorrow.