Hi, I've written a LUA dissector for a custom protocol which is working great, but I've encountered an issue where if a packet is detected as a retransmission by Wireshark the dissector is not called, so these packets are not decoded and therefore missed when filtering for my protocol - despite the fact that they have been transmitted. All the packets which are not decoded say "Retransmitted TCP segment data (## bytes)" in the packet details pane, I'm assuming that this means they're retransmissions. At the moment I'm adding my dissector to the dissector tables for "tcp.port" and "udp.port", is there another table I need to add to in order to support dissection on retransmitted packets? That doesn't seem right to me, as these retransmitted packets are still coming in on the same port. Does anyone know what I might be doing wrong? Unfortunately I'm not at liberty to share the source, but I will provide as much additional information as I can on request if more is required! :) TIA, RB Edit: After further investigation when using the "Analyze TCP Sequence Numbers" option, packets which have "[TCP Retransmission]" in the packet info column do react to the "Do not call subdissectors for error packets" setting. The packets which are not dissected are the ones which do not have an error notification in the "Info" column in the UI, but instead say "Retransmitted TCP segment data (# bytes)" in the packet details tree view. Interestingly, if I tick "Analyse TCP Sequence Numbers" and "Do not call subdissectors for error packets", these packets do decode! (But packets marked with "[TCP ZeroWindow]", "[TCP Out-Of-Order]" and "[TCP Retransmission]" in the "Info" column do not, which is a step back again). It does seem related to some combination of preferences but I can't seem to find one which lets me decode everything, all the time. :( asked 26 Nov '13, 01:18  rstb edited 28 Nov '13, 03:05 |
3 Answers:
I was experiencing this exact situation, and I tried several different combinations of TCP settings before landing one that was satisfactory. From the default settings, I unchecked "Allow subdissector to reassemble TCP stream", and it seems to have worked in my specific situation. After unchecking the aforementioned, the "Do not call subdissectors for error packets" works like I expect: Checked-doesn't call LUA, Unchecked-does call LUA. I would post a picture of my settings, but unfortunately, I don't have enough karma points... :( answered 28 Apr '16, 08:53  J_Turner |
Do you have the TCP preference "Do not call subdissectors for error packets" set (yes retransmissions count as "errors")? If so, this would be normal behavior. answered 26 Nov '13, 06:28  JeffMorriss ♦ That option is unchecked in the TCP Preferences. I tried to toggle it on and off to see if it was lying to me, but that did not resolve it. (26 Nov '13, 06:36) rstb is it possible to post parts of your Lua code here? (26 Nov '13, 07:01) Kurt Knochner ♦ Which parts would be of use? I can strip out any sensitive parts and post it. The dissector function itself isn't called at all when the problem occurs, which I've verified by calling the "debug()" function right at the start of it and trying to print a message to the debug console so I suppose that code is not useful. Very little code is run before that though. Before adding my custom dissector to the TCP and UDP tables I do the following:
My custom dissector is then registered as follows, where the tcp_port_range and udp_port_range variables are arrays of port range integers retrieved from the preferences registered above. This registers about 10 UDP ports and 1 TCP port. (26 Nov ‘13, 07:26) rstb |
did you try to disable the following TCP preference
What changes is you enable/disable that option (probably in conjunction with other preferences)? Regards answered 28 Nov '13, 07:47  Kurt Knochner ♦ edited 28 Nov '13, 07:48 I tried that in conjunction with the other two TCP preferences that change the behaviour, but it seems to have no effect. Could this be a bug in Wireshark where the code path which prints only to the tree view and not the info column is not obeying the "tcp.no_subdissector_on_error" preference? (29 Nov '13, 00:19) rstb
Maybe. Is it possible to post the whole Lua code and a sample capture file somewhere (google drive, dropbox, mega.co.nz), so interested people can check it? You can also file a bug report at https://bugs.wireshark.org and attach everything there, plus an update here with the bug ID. If you don't want to post everything publicly, you can send it to me via e-mail (see my profile - click on my name). I'm interested in this problem and will have a look. However, no promises about results and time required to check ;-) (29 Nov '13, 05:54) Kurt Knochner ♦ The LUA sample dissectors from the wiki would probably work given the right port number, but I'm afraid I'm not able to share the capture which seems to be the important thing here. It seems in my case, the capture isn't generated by Wireshark and therefore is missing quite a lot of information from the TCP and IP packet layers (timestamp resolution is awful, sequence numbers are fudged etc). I think this isn't actually a Wireshark problem though, I need to find out what tool generated this file instead - apologies for having wasted your time! (04 Dec '13, 01:03) rstb never mind. If you ever find the reason for the problem (related to Wireshark or not), please update here. Thanks! (04 Dec '13, 02:41) Kurt Knochner ♦ |
Hi, I was running into the same issue. Apparently unchecking the "Allow subdissector to reassemble TCP stream" and "Do not call subdissectors for error packets" worked for me. If I uncheck both of them in the Edit >> Preferences >> Protocols >> TCP, the re-transmission packets are dissected. If however, any of these two is checked, the packets are not dissected. Thanks.