Ask Your Question

Revision history [back]

Parsing LLDP exported to JSON (or XML) has problems

Hi, In the JSON file of a captured LLDP packet, theh Chassis id and the Port id (also the TTL, but I don't need that one) are exported in a structure like

"Chassis Subtype = MAC address, Id: 00:0a:25:3a:6c:ee": { "lldp.tlv.type": "1", "lldp.tlv.len": "7", "lldp.chassis.subtype": "4", "lldp.chassis.id.mac": "00:0a:25:3a:6c:ee" },

"Port Subtype = MAC address, Id: 00:0a:25:3a:6c:f1": { "lldp.tlv.type": "2", "lldp.tlv.len": "7", "lldp.port.subtype": "3", "lldp.port.id.mac": "00:0a:25:3a:6c:f1" }

If I try to use an lldp ibrary e.g. in Python, the fact that the key "Chassis Subtype = MAC address, Id: 00:0a:25:3a:6c:ee" also contains the values /subtype and actual id) makes the json not correctly parseable - I cannot know the key value beforehand, and use it to access the TLV contents.

I could use a line-by-line text search, but it's not a clean solution, I need a correctly built dictionary (e.g. in Python) to be able to interact with it using the standard json libraries, not ad-hoc text search and parse mechanisms.

Why does Wireshark producse such a json structure? /xml has an analogous problem).

Can't it be fixed? Is there some other way around (apart from doing text processing instead of using standard json libraries)?

Thanks

Leo

Parsing LLDP exported to JSON (or XML) has problems

Hi, In the JSON file of a captured LLDP packet, theh Chassis id and the Port id (also the TTL, but I don't need that one) are exported in a structure like

"Chassis Subtype = MAC address, Id: 00:0a:25:3a:6c:ee": {
    "lldp.tlv.type": "1",
    "lldp.tlv.len": "7",
    "lldp.chassis.subtype": "4",
    "lldp.chassis.id.mac": "00:0a:25:3a:6c:ee"
},

}, "Port Subtype = MAC address, Id: 00:0a:25:3a:6c:f1": { "lldp.tlv.type": "2", "lldp.tlv.len": "7", "lldp.port.subtype": "3", "lldp.port.id.mac": "00:0a:25:3a:6c:f1" }

}

If I try to use an lldp ibrary e.g. in Python, the fact that the key "Chassis Subtype = MAC address, Id: 00:0a:25:3a:6c:ee" also contains the values /subtype and actual id) makes the json not correctly parseable - I cannot know the key value beforehand, and use it to access the TLV contents.

I could use a line-by-line text search, but it's not a clean solution, I need a correctly built dictionary (e.g. in Python) to be able to interact with it using the standard json libraries, not ad-hoc text search and parse mechanisms.

Why does Wireshark producse such a json structure? /xml has an analogous problem).

Can't it be fixed? Is there some other way around (apart from doing text processing instead of using standard json libraries)?

Thanks

Leo