I'm starting out creating a wireshark dissector (in lua) for my game-in-development's multiplayer protocol to help with debugging, and have so far been dissapointed by the lack of good documentation on the subject. This protocol runs on top of TCP because I can't be bothered to implement a real solution, and TCP is good enough for me. I've found dissector.lua, which seems to be a very valuable resource, but this leaves me wondering:
I'd love to have my dissector be a loop running in a coroutine that can call something like "stream.read(16)" to read 16 bits and that would do a coroutine.yield until I receive more data, and then once I get all my data I can just post some of it to the network dump file like so:
Unfortunately, I don't believe that Wireshark works like this. asked 08 Jan '15, 23:25 Xenotoad |
One Answer:
Potentially multiple times:
The
See the "TCP reassembly" section of http://wiki.wireshark.org/Lua/Dissectors. There is indeed a lack of documentation for TCP-based dissection, but if you ask your questions here (in new topics, not in this topic), then we can use that to help build some documentation for the wiki.
Right - a Lua plugin doesn't "drive" Wireshark... Wireshark controls everything and just invokes Lua callbacks. There is an open bug in this area (bug 9851), and when that gets addressed there may be something to make TCP dissection easier, but only if your protocol has a length field somewhere early in its message format. If, on the other hand, your protocol is more like HTTP where you don't know the length of the message until you're done with it, then the answered 09 Jan '15, 09:34 Hadriel edited 09 Jan '15, 09:36 |
I can read the first few bytes of the message to calculate the total length of the message. Thanks for the great answer, it's pretty close to what I was looking for!
If I return DESEGMENT_ONE_MORE_SEGMENT, will the next call's tvb argument still contain the data from the last call?
Example:
Call #1 Buffer: {0, 0, 5, 6, 7} --Returns DESEGMENT_ONE_MORE_SEGMENT
Will Call #2's buffer be {0, 0, 5, 6, 7, 3 , 5} or {3, 5}?
I believe it depends on what you set
pinfo.desegment_offset
to: if you leave it at 0, and setpinfo.desegment_len
toDESEGMENT_ONE_MORE_SEGMENT
, then yes you'll get all the previous Tvb bytes as well as the new ones on the next call todissect()
- i.e., you'll get{0, 0, 5, 6, 7, 3, 5}
. If you setpinfo.desegment_offset
to 1, then you'll get{0, 5, 6, 7, 3, 5}
, and so on.