John R. wrote:
Insofar as I have a workaround, I described it in the bug report.
hm didn't seem to work in my case. I still lose two packets
maybe I screwed something up.
I made these changes:
packet-tcp.c
tcp_dissect_pdus()
//COMMENTED OUT:
// pinfo-desegment_len
Andrew Schweitzer wrote:
John R. wrote:
Insofar as I have a workaround, I described it in the bug report.
hm didn't seem to work in my case. I still lose two packets
maybe I screwed something up.
Hey it works if I use 100 rather than -1!
Cool.
I made these changes:
I'll check it against my code on Monday. It's not accessible from where I'm at.
-- John.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
Andrew Schweitzer wrote:
Andrew Schweitzer wrote:
John R. wrote:
Insofar as I have a workaround, I described it in the bug report.
hm didn't seem to work in my case. I still lose two packets
maybe I screwed something up.
Hey it works if I use 100 rather than -1!
hm... now
I reduced my header length to 2 and turned off tcp checksum validation,
and things seem to be working much better.
At the moment... no problems! :)
Thanks
Andy
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
I'm having problems using tcp_disscet_pdus with a proprietary protocol.
Wireshark appears to be losing packets (not parsing them with
application level dissector) in cases where relatively large amounts of
packets are sent from one end.
I believe this is similar to the problems reported here:
