So do you have an idea where the problem lies? A bug in my code? An
error in my design? An incorrect call to wireshark functions?
Here's some output from my program, printing info from pinfo before call
to tcp_dissect_pdus, in each get length call, and in each each dissector:
//before call to
Guy Harris wrote:
Andrew Schweitzer wrote:
Maybe I don't understand tcp_dissect_pdus.
If a user message overruns an ethernet frame, tcp_dissect_pdus is
supposed to allocate enough space to hold the entire user message, and
only call the user's dissector when the entire message has been
I'm writing a dissector for a proprietary protocol and using
tcp_dissect_pdus. Our packets can be 2k, and sometimes I seem to get
incorrectly parsed messages in the gui. I see the text in the gui
Packet size limited during capture.
I found this in packet-frame.c, and apparently I'm getting a
Andrew Schweitzer wrote:
I'm writing a dissector for a proprietary protocol and using
tcp_dissect_pdus. Our packets can be 2k, and sometimes I seem to get
incorrectly parsed messages in the gui. I see the text in the gui
Packet size limited during capture.
I found this in packet-frame.c,
Andrew Schweitzer wrote:
I'm writing a dissector for a proprietary protocol and using
tcp_dissect_pdus. Our packets can be 2k, and sometimes I seem to get
incorrectly parsed messages in the gui. I see the text in the gui
Packet size limited during capture.
I found this in packet-frame.c,
Guy Harris wrote:
Andrew Schweitzer wrote:
Thanks.
In a packet that gets a BoundsError, what are the captured length and
(actual) length in the Frame section of the packet detail pane?
hm it seemed like it captured a full ethernet packet.
1514, if I understand you:
Frame 1
Maybe I don't understand tcp_dissect_pdus.
If a user message overruns an ethernet frame, tcp_dissect_pdus is
supposed to allocate enough space to hold the entire user message, and
only call the user's dissector when the entire message has been
received... right?
So if we get a frame with user
