v1.4.2 Bug Reports and Comments

[david.sovereen@mercury.net]

I have a port that is showing errors. When I tried to look at the "Port Detail" to find our what kind of error is being generated, I get an error that the port detail cannot be displayed. There is no error in the switch or linux log.

Dave

[sirhc]

Well there are 2 possible options:
1) The unit is messed up and needs rebooted, I would try a warm reboot from the UI if that does not work I would try a cold power cycle.

2) There is a damaged or failed PHY which you can test once you remove the unit from service.

Here is how you can test the port:
After you remove the unit from service factory default it and do a cable diagnostics on that port with no cable attached and you should get OPEN on all 4 pairs.

If all report OPEN with no cable then try and connect your laptop to it and see if you get a 1G connection.

Now if it failed we will fix it for free and if it is damaged we can fix it for a fee.
Either way the next step would be to RMA it.

[WirelessRudy]

1.4.2 FAIL!
Upgrade 2 x WS-12-250-DC units from 1.4.0 to 1.4.2 and both stopped passing traffic! 80% of my network down!
One unit still accessible but no more access to any units behind it.
Second unit became in accessible. Still passes traffic over some ports, other ports are not passing any more traffic.

First unit put 1.4.0 back and all working again...
Second unit in accessible and now need to drive over there to see if I can downgrade locally with laptop....

[david.sovereen@mercury.net]

Issue with "error loading port detail" seems to be some sort of loss of session or authentication issue. A colleague was able to open it (using Chrome). I was on Safari. After logging in again, I am able to view it. I should note that I normally use Safari and have never had an issue looking at port detail in the past so this is not a persistent browser issue with Safari.

Next issue:

In the background (status tab, greyed area on right), it shows 1043595 errors on this port.

In the foreground (port detail), it shows 2087090 errors (cumulative total of all errors, both transmit and receive).

I'm guessing that the "errors" we are seeing are "Tx Collisions", as we have temporarily forced the device on this port to 100-H as there seems to be a cable problem.

My questions and comments are:

1. If there are a total of 2087090 errors on the port, shouldn't the status tab report 2087090 errors and not 1043595?

2. It seems as though Rx Fragments and Tx Collisions are incrementing at almost the exact same rate, as though there is a bug causing a single value behind the scenes to be reported as both on the web page.

3. Tx Collisions are a normal operating condition of CSMA/CD Ethernet networks. I don't think they should be counted as an error on the status page, and I think it is a little confusing to put them in the Error Counters section. If it were my decision, I'd probably move it to the Total section on top. That said, Excessive Collisions (frames dropped due to congestion) and Late Collisions (typically caused by duplex mismatch) are errors that should be counted and reported in the Error Counters section, but I don't see them there. Is the Tx Collisions reporting Excessive Collisions or Late Collisions and perhaps not labelled clearly?

Thanks!
Dave

[givemesam]

just moved 4 12 port AC's from 4.2.rc6 to 4.2-stable
then disabled discovery tab and all other discovery checkboxes. not sure what purpose that really serves

so far so good.

hoping to see a weird blocking issue go away.

[sirhc]

just moved 4 12 port AC's from 4.2.rc6 to 4.2-stable
then disabled discovery tab and all other discovery checkboxes. not sure what purpose that really serves

so far so good.

hoping to see a weird blocking issue go away.

As I said before I do not believe your issue is with the switch I think it is one of two thing:
1) The Metrolink firmware - but I doubt it if your just using it as a bridge and did not configure any VLANs inside it or change from the defaults

2) Your MTU need to be set to a proper size to allow VLANs as you said you were passing VLANs and you had the MTU on several devices set to 1500 WHICH IS NOT GOING TO WORK!

Maybe you should do a little reading on Wikipedia about MTU sizes and what is required to pass VLANs. The fact that you were trying to pass VLANs of any kind and had any MTU set to 1500 should be a big red flag that it will not work.

Do some reading of posts like this all over the web: https://learningnetwork.cisco.com/thread/39098

You need to understand that a standard packet are 1500 and when you add a single VLAN then you need the MTU set to at least 1522 but depending on what else you have going on 1528 is a more safe setting.

If you change your standard MTU away from 1500 which you should NOT do in an internet environment then you have to account for that and then add 22 bytes to that larger MTU size.

[givemesam]

my so far so good was saying the firmware update went well. As for the quirkyness of our metrolinqs that was adopted when we went netonix, that is still to be decided. The issue could be with metrolinq, its settings, or something in the RC6 build.

in conjunction with this switch update we also:

- set L2 MTU on metrolinqs to 1528 (metrolinq firmware had some weird things going on with their gui in earlier firmwares, and we didn't touch it initially as it was working well with flow control off on toughswitches. We were under the impression it was a L3 mtu for the radio, not the L2 bridge, things were working well for months, then things got weird when we went netonix from toughswitch + updating our metrolinq firmware)

- turned on flow control on AirFiber24s (within their gui)

- disabled discovery tab on wispsw

we did this at our main tower site and 3 relay sites served with a mix of AF24 and Metrolinq 60ghz

[Eric Stern]

1.4.2 FAIL!
Upgrade 2 x WS-12-250-DC units from 1.4.0 to 1.4.2 and both stopped passing traffic! 80% of my network down!
One unit still accessible but no more access to any units behind it.
Second unit became in accessible. Still passes traffic over some ports, other ports are not passing any more traffic.

First unit put 1.4.0 back and all working again...
Second unit in accessible and now need to drive over there to see if I can downgrade locally with laptop....

Try 1.4.3rc3. It fixed a bug that might have caused this.

firmware/wispswitch-1.4.3rc3.bin

[sirhc]

my so far so good was saying the firmware update went well. As for the quirkyness of our metrolinqs that was adopted when we went netonix, that is still to be decided. The issue could be with metrolinq, its settings, or something in the RC6 build.

in conjunction with this switch update we also:

- set L2 MTU on metrolinqs to 1528 (metrolinq firmware had some weird things going on with their gui in earlier firmwares, and we didn't touch it initially as it was working well with flow control off on toughswitches. We were under the impression it was a L3 mtu for the radio, not the L2 bridge, things were working well for months, then things got weird when we went netonix from toughswitch + updating our metrolinq firmware)

- turned on flow control on AirFiber24s (within their gui)

- disabled discovery tab on wispsw

we did this at our main tower site and 3 relay sites served with a mix of AF24 and Metrolinq 60ghz

Sorry if I seem gruff, it has been a HORRIBLE day for me.

Some with Netonix Stuff and a lot with RF Armor stuff. Still waiting on a stupid bolt needed for the new RF Armor sector kits which people are screaming at me where is their order and we have been waiting for days only to have this single bolt and the bolt people come to us today and say "sorry they sent the wrong one to us from the factory" and to get the one you want will be a long wait so I am scrambling to find a substitute air shipped in for tomorrow. Not what I want for final but will have to do.

[givemesam]

no problem. i should be been less vague since contextually i was reporting other weirdness too. We just went to the 1.4.2. Any reason to jump to an RC at this point on Rev D and Rev E boards?

lets be clear. WE WANT THAT BOLT! i have a box of PRISMS that need a home behind a little 90 or 120 sector kit.

also, i know this isn't the right place for it, but what do you think of the PB-ISO 400mm performance vs the 25 dbi kit for a non-iso?