NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
LLDP "Operational MAU type" (802.3 TLV) is zero for GS724Tv3
Versions Model Name Boot Version Software Version B5.1.1.1 5.4.2.19 I've enabled the optional LLDP TLVs on all my ports. When I receive the 802....
I forgot to say that the "autonegotiation support/status" field (0x03) is correct. 0x01 means that auto-negotiation is supported. 0x02 means that auto-negotiation is enabled. So together they make 0x03. Hurray! That's correct.
The G 2.2 PMD auto-negotiation advertised capability field looks wrong too. The value is 0x0001. So, looking again at RFC 3636 - this looks wrong. 0x0001 means that the only thing it is capable of is 1000 mbit full duplex. This one should have a bunch of bits turned on 10,100,1000 full and half duplex. That's 6 bits. 5 are missing ;-).
Maybe the implementers got confused. What they've done here is given the current speed and duplex, not the ones its capable of.
As you can see below - wireshark agrees with me. I should have used wireshark earlier ;-).
The upper red arrow is for the PMD Auto-Negotiation Advertised Capability. It is 0x0001 as my software printed it, and the meaning is clearly spelled out in wireshark. The switch is claiming it only connect at 1000BASE-T full duplex.
The lower red arrow makes the same complaint that I do -- 0x0000 is unknown or invalid.
I'm trying to use this in the Assimilation Suite - which maps host and network interconnections. Here's an example of how I'd like to use it:
If you look at this, I know the Duplex and MTU of the host-side of connections, but not the switch side. LLDP is supposed to provide this information from the switch side. Then I could validate the best practices here: http://assimilationsystems.com/2015/12/23/three-simple-network-best-practices/ For good measure, the MTU is not provided by this switch. The Maximum Frame Size TLV (Section G.5 in the spec) is not provided. I'd love to have both of these. The NICs are the red ovals. You can see that port eth0 is wired to port g6 on the switch. That is, the host's eth0 is plugged into the switch's g6 port.
It turns out that several of the LLDP-MED frames are also bogus.
Manufacturer: is "0xbc00" - should be "Netgear"
Hardware version is "0 0x0"
Firmware version is "rrr ttt"
Asset is "Asset 1717"
These are all ASCII (or perhaps UTF-8) strings.
They are all maximum length - with blanks filling out the length. The TLVs really ought to be the right length - although that's not a huge problem. Strangely enough, the hardware version string has the extra blanks after the "0" and before the "0x0".
On the plus side, the serial number, model and software version all look good.
I've now verified that three different switches that I own (including an 8-port model) have the same bugs.
I tried to attach a new picture like I did above, but something has changed in the interface, and I can't seem to do that any more.
I now see why I couldn't post the picture - my login had expired. Now that I'm logged in again, here' s the picture I wanted to put in the link above.
In my code, I stripped any trailing blanks, but not those extra blanks in the middle of the strings. Like before, this data agrees with the results from Wireshark.
If the bogus data was replaced by real data, then this would be pretty cool. Note that it picks up the port description and puts it on the "g6" port description. If they fixed the speed and duplex and added the MTU value (mentioned at the start of this chain), then we could detect duplex and MTU mismatches. This would be pretty cool.
Lots of things are right here. It would be good to get the broken things fixed too. I've put in a request to get them fixed.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
