Comment # 4
on bug 10760
from Hadriel Kaplan
Thanks for the uploads - makes life a lot easier. :)
So the "C stack overflow" is a bit misleading - the failing function is
g:call(), and that calls the giop dissector, which is failing to parse the tvb,
and throwing an error type that the code isn't catching. So since the code
doesn't catch the thrown error, it raises up to a point that the Lua engine
sees as a stack overflow.
So I changed the code to catch the error, and it appears the goop dissector
isn't happy about the payload - in particular, for example in packet #1: it
correctly parses a GIOP Reply message after your "MyProt" header, starting at
hex bytes 0x47494f50 (the ascii chars "GIOP"), which is a GIOP message of 47
bytes long. But there are actually 48 bytes (an extra 0x00 at the end), so the
GIOP dissector completes dissecting the 47-byte Reply message, and then tries
to parse the extra 0x00 byte as a new GIOP message.
The reason it does that is the GIOP dissector you're grabbing with
"Dissector.get("goop")" and then calling is a GIOP-over-*TCP* dissector. Being
a TCP-based dissector, it tries to dissect the whole stream, so your single
"g:call()" actually causes it to dissect the first GIOP message and then what
it thinks is the second one.
So... if *all* of your packets will have that extra byte at the end, then when
you do "g:call()", you could give it a Tvb that doesn't have the extra byte.
Like this:
--------
local myEthType = 0x89ab
local p_myProto = Proto("myProto", "MyProt")
local g = Dissector.get("giop")
function p_myProto.dissector(buffer, pkt, root)
root:add(p_myProto, buffer(0, 36))
local giop_len = (buffer:len() - 36) - 1
g:call(buffer(36, giop_len):tvb(), pkt, root)
end
-- Register our dissector
DissectorTable.get("ethertype"):add(myEthType, p_myProto)
You are receiving this mail because:
- You are watching all bug changes.