Parsing LLDP exported to JSON (or XML) has problems

asked 2019-11-26 15:57:09 +0000

Leo_mac
1

updated 2019-11-26 17:22:46 +0000

grahamb

flag of United Kingdom of Great Britain and Northern Ireland

23790 ●4 ●950 ●227 https://www.wireshark.org

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

answered 2019-11-27 08:46:23 +0000

Guy Harris
19890 ●3 ●633 ●207

Why does Wireshark producse such a json structure?

Because it has a routine that puts "plain text" items into the protocol tree, with no field name associated with them, and because it has a JSON printer that, for those items, just prints out the text.

Can't it be fixed?

It can, but it would involve a change such as requiring that routine to specify a named field, so it'd show up as something such as

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

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

Please file a bug report on the Wireshark Bugzilla.

edit flag offensive delete link

Comments

Does this bring us back to bug 12958?

Jaap ( 2019-11-27 11:52:11 +0000 )edit

No, this is a separate issue - the problem is that the top-level item for the chassis ID is an FT_TEXT field and thus has no field name; that means there is nothing available from which to generate a JSON key, so it just falls back on using the display representation.

Guy Harris ( 2019-11-27 22:05:02 +0000 )edit

Note, by the way, that according to RFC 8259, a name for an object is a string - that's it. No restrictions on the contents of the string, so, whilst the JSON currently produced by Wireshark may not be convenient for some parsers, it is valid JSON.

So what exactly does "correctly built" mean here? Do you mean "all composite objects must have a name that is the same for all instances of that object"? If so, changing that for all protocols (this is NOT unique to LLDP!) would involve changing about 2,000 instances of code generating those composite objects (all calls to proto_tree_add_subtree_format()).

Guy Harris ( 2019-11-28 19:22:57 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Parsing LLDP exported to JSON (or XML) has problems

1 Answer

Comments

Your Answer

Question Tools

Stats

Parsing LLDP exported to JSON (or XML) has problems edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Parsing LLDP exported to JSON (or XML) has problems