ZyXEL unknown TLV support

[grawity]

I just noticed the GS1920's send a few custom TLVs containing mostly text data (with length byte) – model name, etc. (pcap attached)

Interface:    eth0, via: LLDP, RID: 40, Time: 0 day, 00:02:21
  Chassis:     
    ChassisID:    mac 4c:9e:ff:87:0b:5e
    SysName:      sw-m7-klases
    SysDescr:     V4.30(AAOB.0) | 09/16/2015
    MgmtIP:       192.168.30.2
    Capability:   Bridge, on
  Port:        
    PortID:       local 13
    PMD autoneg:  supported: yes, enabled: yes
      Adv:          10Base-T, HD: yes, FD: yes
      Adv:          100Base-TX, HD: yes, FD: yes
      Adv:          1000Base-T, HD: no, FD: yes
      MAU oper type: 1000BaseTFD - Four-pair Category 5 UTP, full duplex mode
  VLAN:         1, pvid: yes
  UnknownTLVs: 
    TLV:          OUI: 00,A0,C5, SubType: 2, Len: 10 09,47,53,31,39,32,30,2D,32,34
    TLV:          OUI: 00,A0,C5, SubType: 3, Len: 27 1A,56,34,2E,33,30,28,41,41,4F,42,2E,30,29,20,7C,20,30,39,2F,31,36,2F,32,30,31,35
    TLV:          OUI: 00,A0,C5, SubType: 4, Len: 18 11,34,63,2D,39,65,2D,66,66,2D,38,37,2D,30,62,2D,35,65
    TLV:          OUI: 00,A0,C5, SubType: 5, Len: 21 14,68,74,74,70,3A,2F,2F,31,39,32,2E,31,36,38,2E,33,30,2E,32,2F
    TLV:          OUI: 00,A0,C5, SubType: 7, Len: 11 0A,4D,61,69,72,6F,6E,69,6F,20,37

All of them seem to have length byte + ASCII text:

• subtype 2: GS1920-24, model name
• subtype 3: V4.30(AAOB.0) | 09/16/2015, firmware version
• subtype 4: 4c-9e-ff-87-0b-5e, seems to be the MAC address in ASCII form
• subtype 5: http://192.168.30.2/, management URL
• subtype 6: physical location

(I tried entering Unicode in the "system location" field, and it only stored HTML-style { escapes.)

[vincentbernat]

Something that would be easy to do is to display the ASCII string if we detect this is length + ASCII string (something that Net-SNMP already does). Another easy task would be to let lldpcli do the decoding of those unknown TLV. What would be inconvenient is to implement the decoding into lldpd since it would add a bunch of code just for that (more code, more bugs).

[vincentbernat]

cc @commodo for comments (this could be done in the lib for other "users" to get the information as well)

[grawity]

Generic ASCII (or UTF-8) detection sounds useful. It probably should also detect values without a length byte though? (After all the TLV already has a length field of its own, so I don't know why ZyXEL added a redundant one in the value itself...)

[commodo]

I would maybe go for a DB-type/convention/format file (maybe not the best terminology here). So, have some sort file (json or something other) that describes TLVs.

In JSON it would look like. zyxel.tlv

{
    "oui": "00,A0,C5",
    "subtype": {
        "0" : {
              "type": "ascii",     # other values could include "binary", "utf-8"
              "max_len": 10,   # dunno, could be optional
         }
    }
}

Maybe (later) we could merge a few common attribute types in other functions. One example (only valid for exemplification) is "type": "ipv4" , and then this would take binary data and print the valid IPv4 addr.

[vincentbernat]

Since JSON dependency is optional, I wouldn't go with JSON, but I get the idea. Adding a name for OUI and a name for each subtype would help too. So, in llpdcli, "unknown TLV" would be split between "additional TLV" and "unknown TLV".

[commodo]

Yeah. We use JSON for a lot of stuff on OpenWRT ; it's kind of a habit for me.

[pyropeter]

OUI: 00,90,69, SubType: 1, Len: 12 43,57,30,30,30,30,30,30,30,30,30,30

Juniper EX2200. Serial number as ASCII.

(I changed each digit to '0' for anonymity)