v1.4.2 Bug Reports and Comments

[Eric Stern]

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

1. Those numbers come from different counters that come from the switch core. Apparently it doesn't consider one of those values to be an "error" when calculating the other counter.

2. Apparently whatever problem you are having with that port is causing both of those issues to occur.

3. I would guess Excessive Collisions and Late Collisions are just being lumped into Tx Collisions. These are the values that come from the switch core and it is just displaying the information it gets.

[sirhc]

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?

LOL - So your one of the ones hounding me for the kits...Small world

As far as the ISO Beam and our kit they perform the same. If your buying my 5 Pack it is a lot cheaper and cheaper to ship as 5 ship for the same price as 1 and with the ISO the boxes only hold 1. But it is cheaper yet I think to buy the ones with the ISO BEam pre attached (non removable).

We do now use a much more expensive white material that will no longer fade and dry out, manufacturer of material claims 10 years in HIGH UV conditions.

So about the missing bolts, there are 4 hex head bolts that hold the sectors to the mounts, the 2 bottom bolts UBNT gives you will have to be exchanged with the new bolts we provide as theirs is 3/4 " long thread and will hit the Radio cover box so we provide (2) replacement bolts that are roughly 1/2" long and will not hit the box.

Some advice on the airPRISIM radios vs say the AC Lite.

I suggest you people put up an airPRISIM sector and an AC Lite sector (both with shield kits) and compare the performance difference. I do not see any improvement. Now airPRISIM without shield kits will perform better than AC Lite but airPRISIM does not work so good without shielding so sort of a catch 22.

The only thing that is cool about the airPRISIM is the ability to scan while active.

Also where as I love the AC radios for PTP links I am not a fan yet in PTMP especially if the spectrum is noisy in your area or your links are over 3 miles.

And of course the GPS still does not work if you need to do channel re-use.

I warned people years ago about Titanium and most did not listen and spent a ton of money and got no gain in performance over Legacy Rockets but paid a dear price not even including the high failure rates.

[givemesam]

yes, with your kits, i was able to get 90mbps down on a 20mhz wide rocketm5. Across all channels pretty much, when a powerbeam m5 25dbi was listening also on your shield kits, 1 mile range.

with AC we are looking for the support of DFS, yes, the ISO has DFS! Not sure if the prism does yet....

And overall flexibility with more speed per mhz (although its minor), when we have high SNRs

we may try mimosas crazy A5-18dbi, but i just cant see their c5 working without a kit like yours.... any plans?

TLDR: your kits make or break things, so we will not deploy a Prism without it. Our logic was that maybe the prisms will eventually get the entire use of the band since they are made 'better?' vs the lites? a boy can dream.

[slowe]

I have the Cisco check boxed checked in the discovery tab, but when I plug in my LinkRunner the Switch Name/IP/Port is not returned. It did work in 1.4.0 although the port was eth0 and not the actual port.

[Eric Stern]

I have the Cisco check boxed checked in the discovery tab, but when I plug in my LinkRunner the Switch Name/IP/Port is not returned. It did work in 1.4.0 although the port was eth0 and not the actual port.

What port is the LinkRunner plugged in to?

[slowe]

What port is the LinkRunner plugged in to?

1.4.0 always returned eth0 on any port. And 1.4.2 never works on any port

[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.

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.

Took a while but we lab tested this. LLDP is not being sent on SFP ports.

Netonix <- copper -> Ruggedcom = works correctly on both sides.
Netonix <- fiber -> Ruggedcom = Netonix sees Ruggedcom. Ruggedcom never receives LLDP packets from Netonix.

Verified with both 100Mb and Gigabit SFPs. Used port mirroring and Wireshark = no LLDP packets from Netonix on fiber port.

The LLDP settings are baked into the binary so only see LLDP on / off in command line or web GUI so no way for me to verify why only copper ports work.

Any changes to LLDP in the 1.4.3rc?

[Eric Stern]

Any changes to LLDP in the 1.4.3rc?

Yes. I'll fix this in the next release.

[brian@speednetscotland.net]

Hi Wondering if you could HELP,

I have just purchased the WS-24-400-A switch which seems great.

I recieved a note within the packaging telling me to upgrade the firmware as soon as I can.

However trying to upgrade to wispswitch-1.4.2 and it stops half way through and stops doing the upgrade.

What firmware would you recommend for this switch?

Thanks in advance

[sirhc]

Hi Wondering if you could HELP,

I have just purchased the WS-24-400-A switch which seems great.

I recieved a note within the packaging telling me to upgrade the firmware as soon as I can.

However trying to upgrade to wispswitch-1.4.2 and it stops half way through and stops doing the upgrade.

What firmware would you recommend for this switch?

Thanks in advance

This should not happen. All Netonix WISP Switches use the same firmware so I recommend either v1.4.2 or v1.4.3rcX

Maybe it's your browser, what browser are you using?

If you not using Chrome try Chrome.