Parsing LLDP exported to JSON (or XML) has problems

retag add tags

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

Leo_mac

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

23.8k

grahamb

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

edit flag offensive 0 remove flag close merge delete

Comments

add a comment see more comments

1 Answer

Sort by

oldest

newest

most voted

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.

19.9k

Guy Harris

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

edit flag offensive 0 remove flag 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 see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer

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

Comments

1 Answer

Comments