Ask Your Question
0

Parsing LLDP exported to JSON (or XML) has problems

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

Leo_mac gravatar image

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

grahamb gravatar image

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

edit retag flag offensive close merge delete
add a comment

1 Answer

Sort by ยป oldest newest most voted
0

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

Guy Harris gravatar image

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 more

Comments

Does this bring us back to bug 12958?

Jaap gravatar imageJaap ( 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 gravatar imageGuy 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 gravatar imageGuy 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.

Add Answer

Question Tools

subscribe to rss feed

Stats

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

Seen: 307 times

Last updated: Nov 27 '19