This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

I'm starting to dig into the details of some capture files and have been humbled by the gaps in my knowledge that have been exposed in this process. I am using a Lua dissector for a protocol (call it MYPROTO) that is conveyed via TCP. I was puzzled by some extremely large TCP segments in the capture, but now understand that multiple MYPROTO PDUs can be carried in a single TCP segment. However, the Lua dissector only shows one MYPROTO PDU. (I'm still puzzled by the underlying question of why some segments are extremely large while others are not, but I can put that aside while I look to solve the dissector problem.)

I have been reading about reassembly, which I understand to mean the process of reassembling higher-level PDUs that may cross multiple TCP segments. If I modify the dissector to support reassembly, will the same mechanism allow the dissector to discover multiple MYPROTO PDUs within a single TCP segment?

asked 07 Mar '14, 04:35

yotommy's gravatar image

yotommy
36227
accept rate: 0%

edited 07 Mar '14, 04:43


Not the last time I checked. I believe you have to write your dissector function with a loop internally, to handle the case of there being multiple of your protocol messages inside a single TCP segment. I could be wrong, but I don't believe wireshark will call your dissector function multiple times for the same TCP segment (or at least it didn't use to, though that may have changed). That should be easy enough for you to test though, and report back here with an answer. :)

Regardless, if your dissector doesn't use one of the two reassembly mechanisms/models, then wireshark has no idea how much of a segment(s) your protocol message consumed, since there's no inherent message framing inside TCP. So you at least have to use one of the reassembly models to handle the fact any given protocol message may cross one or more segment(s).

permanent link

answered 07 Mar '14, 05:10

Hadriel's gravatar image

Hadriel
2.7k2939
accept rate: 18%

1

For a C based "new" style dissector that returns the number of bytes it dissected, multiple PDU's per TCP segments are dissected. See the reassembly chapter in README.dissector.

I don't know if a Lua dissector can do this.

(07 Mar '14, 05:31) grahamb ♦
1

Yeah I was just about to correct myself, because it looks like there's a loop inside dissect_tcp() now. So it should work for Lua as well, if you use the new style of returning the number of bytes consumed. (or at least the Lua binding code does look for a number return value and passes that back in to wireshark, so the plumbing's there)

(07 Mar '14, 05:44) Hadriel
1

Large TCP sgements may be due to offloading, you can try to turn that off.

(07 Mar '14, 05:54) Anders ♦

This is great info, thanks. I will modify the dissector to return the number of bytes consumed. Using this mechanism, will the buffer passed into the dissector always point to the beginning of the to-be-dissected data, or do I need to check pinfo.desegment_offset?

(07 Mar '14, 06:01) yotommy

Modifying the Lua dissector to have it return the number of bytes consumed did not have an effect. So I created a loop inside the dissector to add a subtree when I have enough data and to request reassembly otherwise. This is working better, but the packet length shown in the display is that of the enclosing TCP segment rather than that of the MYPROTO PDU. Any tips for this?

(07 Mar '14, 09:53) yotommy

Can you post your code, or at least th relevant portions of it that weren't working with the number return model?

(07 Mar '14, 10:28) Hadriel

To demonstrate this, I modified the 'trivial' dissector provided on wireshark.org. The revised code is shown here: https://gist.github.com/yotommy/9418831 - sample capture file here: http://www.cloudshark.org/captures/ef2f1bb3e67a

(07 Mar '14, 12:04) yotommy

Excellent - thanks for uploading that. I just tried your script and was worried something else was broken because I kept getting a Lua error in the second packet's dissection pane, and putting a print statement showed wireshark was only giving your dissector a 2-byte tvb/buffer.

But then I looked at the second packet closely and saw the IP header length field is wrong, indicating it really does think the payload is 2 bytes long - you must have created this packet by hand, right? :)

Anyway, I'll go investigate why the first packet isn't getting chopped up.

(07 Mar '14, 13:15) Hadriel

Yes, created the pcap file with text2pcap. There are two bytes left over in the first packet that ideally will be combined with the two bytes from the second packet to make another 'trivial' PDU. Thanks for your help.

(07 Mar '14, 13:31) yotommy

Hmm... not only does it not work in 1.11, 1,10, nor 1.8, but I don't see how it ever worked. The loop I saw is in tcp_dissect_pdus(), and it's not exposed for Lua scripts to use, but it has to be used.

So returning a number is meaningless, even though the Lua binding C-code registers the dissector as a new type and passes back the number. The TCP dissector must have worked differently a long time ago, or else this behavior was never tested.

Looks like you'll have to write your own looping code in Lua, before returning from the dissector() function.

I'll submit a bug to track this, though I'll have to think about the best way to enable this to work. It's always a tricky balance of exposing too much of the internals and potentially breaking scripts if the internals change in the future, vs. exposing too little and making it not powerful enough and making the Lua script writer have to do more work.

(07 Mar '14, 14:17) Hadriel

Thanks for taking a careful look. One last (?) question: I've experimented with some looping code that adds multiple MYPROTO subtrees. Is there anyway to get Wireshark to display one row per MYPROTO PDU rather than having multiple PDUs grafted to a single TCP row?

(07 Mar '14, 14:22) yotommy

I'm not sure I follow you, but this should probably be a new question in a new topic. This ask.wireshark.org site follows a one-question/answer model, rather than a forum discussion model. Besides, that way I get paid more commission fees. ;)

(07 Mar '14, 14:32) Hadriel
showing 5 of 12 show 7 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×637
×431
×78

question asked: 07 Mar '14, 04:35

question was seen: 2,684 times

last updated: 07 Mar '14, 14:32

p​o​w​e​r​e​d by O​S​Q​A