Ask Your Question

How to write to previous packet pinfo?

asked 2018-01-22 14:04:11 +0000

jzhvymetal gravatar image

updated 2018-01-22 14:20:42 +0000

I'm trying to write a postdissector that will detect missed response from ModbusRTU serial which is half duplex and should always have matching Query and Response. For some reason my code will not work on all the packets. Also is there a way to write to the previous packet pinfo? I want to put in the info that there was "No Response" to the packet.

-- MB_INFO postdissector
-- declare some Fields to be read
local ws_expert_message_f ="")
-- declare our (pseudo) protocol
MB_INFO_proto = Proto("MB_INFO","Modbus Info")
-- declare previous Query state
local isPrevousQuery

function MB_INFO_proto.init()

function MB_INFO_proto.dissector(buffer,pinfo,tree)
  local ws_expert_message = ws_expert_message_f()
  local ws_expert_message_str = tostring(ws_expert_message)

  local pinfo_str=tostring(

  if not pinfo.visited then" NEVER WORKS ALAWAYS VISTED")

local isQuery=pinfo_str:find("Query")
if isPrevousQuery and isQuery then
   -- Needs to be written to previous packet" (No Response Message)")

  local isBadSize=pinfo_str:find("[Packet size limited during capture]")>1

  if (ws_expert_message_str ~= "nil" and not isBadSize) then" (")")")

-- register our protocol as a postdissector

Here is image of a Modbus Trace

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-01-22 22:26:50 +0000

sindy gravatar image

updated 2018-01-22 22:27:20 +0000

The dissector code has no access to pinfo of any other packet than the one currently dissected.

If some transaction ID exists in modbus which allows you to match requests and responses, you may use two global tables indexed by this transaction ID and store the frame.number of the currently dissected packet to the appropriate table (request{transactionId} or response{transactionId}) during the first pass of the dissector (after loading the file, all packets are dissected in sequence). Whenever you click a packet in the packet list, it is dissected again so that the dissectoon tree could be displayed in the dissection pane; whenever you change the display filter, the packets are dissected in sequence again to be able to match the dissected fields to the filter conditions. So while dissecting a response, you may check whether a matching request exists in the capture by looking to request{transactionId}, and vice versa.

Have a look here to see how to render that information into the dissection tree nicely.

edit flag offensive delete link more


My original code works but when capturing live it does not update unless I apply any filter. Is there any way to turn on 2 pass analysis on live capturing?

jzhvymetal gravatar imagejzhvymetal ( 2018-01-23 02:38:08 +0000 )edit

Until some core developer sheds light to that: I've tried to ping a remote device and live capture in parallel and I've noticed that some echo requests indicate "no response found" in the packet comment in the packet list pane although the response did actually arrive and the cross-reference links in the dissection trees are there, while others show the "response in" value.

So I'd expect some extra magic behind use of the frametype.REQUEST / frametype.RESPONSE fields, causing either the referred-to packet to be redissected and redrawn into the packet list once you assign its frame.number into the frametype.REQUEST of another frame dissected later, or automatic re-dissection of already dissected packets after a short amount of time before publishing them in the packet list, meaning that by the time of this second dissection the cross-reference informaton is already available. The delay cannot be too ...(more)

sindy gravatar imagesindy ( 2018-01-23 14:41:11 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-01-22 14:04:11 +0000

Seen: 45 times

Last updated: Jan 22