hi, i've seen a few questions here implying it, but i've never saw an actual answer.. assume i have an xml string coming at a pre-specified port like so: 00:00:00:3a:3c:48:65:61:72:74:42:65:61:74:3e:3c:4f:70:43:6f:64:65:3e:36:33:3c:2f:4f:70:43:6f:64:65:3e:3c:4d:73:67:49:44:3e:30:3c:2f:4d:73:67:49:44:3e:3c:2f:48:65:61:72:74:42:65:61:74:3e not the xml begins 4 bytes ahead, how do i sent the entire data string from that point to the xml dissector? asked 13 Mar '16, 07:29  EXM1110b showing 5 of 11 show 6 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Do you mean programatically, i.e. C or Lua, or by using the UI?
UI is preferable, LUA is 2nd, not in C.
i've tried doing this in a short lua script (but i don't know how to skip chars all the way to the end), but if there was a way to do it in UI , that'd be great.
local aes_pro = Proto("AES","AES"); local data_dis = Dissector.get("data") local xml_dis = Dissector.get("xml")
function aes_pro.dissector(buf,pkt,root)
data_dis:call(buf,pkt,root)
xml_dis:call(buf,pkt,root)
return true end
local tcp_encap_table = DissectorTable.get("tcp.port") tcp_encap_table:add(1411,aes_pro)
What about
?
thanks, i came to that conclusion :), however it would seem i may have bigger difficulties because in large xml's the data is cut.
What exactly do you mean by that? That the individual tcp packets captured are cut short or (as I assume) that the xml "record" spans over several packets? If so, I'd speculate that the first four bytes could indicate the length of the xml part. In such case, your AES_pro dissector would have to behave similarly like other dissector handling multi-packet PDUs do, i.e. to make use of the length indication to collect the PDU data until they are complete, and display them in the last packet of the PDU.
yes, i believe it is the length, do you have any samples on such multi-pdu's?
So far I've been lucky enough not to need that, but you're not alone, so I'd recommend you to make use of @Hadriel's sample code as suggested in hist last but one comment to this question (sorry, direct links to comments are not supported here).
As TCP behaves more like a continuous stream of bytes than a sequence of messages, you often cannot rely on each PDU to start at the beginning of a new packet, so don't miss Hadriel's recommendations related to that. Plus, if the
aes_proPDU really consists only of the length and the xml data, you may have a tough time to synchronize your dissector if your capture does not contain the first packet. If you are really lucky, you can catch up on zero bytes. "Really lucky" would mean here that the xml part would never contain zero bytes and that the indicated length would never exceed 0xffffff.Or just look at the "TCP reassembly" part at the Wireshark Lua wiki - the magic seems to be the use of
pinfo.desegment_offsetandpinfo.desegment_len.thanks, i'll try that, btw, that's the use of the LUA console and evaluator menu options? at first i thought the console would at least show me print messsages i write in the dissector for debugging , but it does not. currently i have to change the script, close wireshark, and beging it again, on each change:(
I'm afraid no one else will find this individual question here, deep in the chain of comments, so you might get a more useful info if you'd ask it as a new Question.
I've also never understood what the Lua console is good for except trying self-sufficient pieces of Lua code, as the Lua script you use to add a dissector consists of parts which must be executed at different phases of Wireshark/tshark run, so you cannot run (or re-run) them at the "wrong" time.
So myself I do it the way you don't like - I prepare a short capture with just a couple of relevant packets (using
File -> Export Specified Packets) and then click that file to start Wireshark after each change of my Lua code, see the result, and close Wireshark again.oh i thought everyone knew this except me, i believe they are a new feature of wireshark 2.0