Guy Harris [EMAIL PROTECTED] writes:
On Sep 19, 2008, at 6:02 PM, John R. Hogerhuis wrote:
Libpcap doesn't support Linux USB, period, yet, if by yet you mean
in any release that tcpdump.org has put out.
Understood, but yeah I just meant in the sense might work, not a supported
OK, more resolution on the problem:
I updated the libpcap from cvs, and wireshark from svn today. Rebuilt, installed
libpcap. Rebuilt wireshark.
I added some debug print statements to pcap-usb-linux.c . It is definitely
successful in opening the plain binary interface. It doesn't use the fast
Hi,
I've been using the USB support in Wireshark/libpcap. I get lots of truncated
messages which makes it hard to make use of.
I have a recent Linux kernel 2.6.24-19, which I believe supports the binary data
format for the kernel usbmon support. Further, my understanding is that through
the
Jeff Morriss [EMAIL PROTECTED] writes:
Paul Dietrich wrote:
I saw a dissector for LLRP submitted a few months back. Does anyone
know the status? There are several vendors out with LLRP devices that
could really benefit from wireshark support.
Looks like the request is still
Jaap Keuter [EMAIL PROTECTED] writes:
Hi John,
I've been looking at this submission from the start, and frankly I don't like
it. It is like Ronnie says in
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1957#c4, this code is very
hard to read, let alone maintain.
I don't want to
Guy Harris [EMAIL PROTECTED] writes:
Merlin Hooze wrote:
For a disector plugin, if the fixed length part of the message is
split across tcp segments, can wireshark reassemble it?
It should be able to do so. If not, that's a bug. (That's why the size
of the fixed-length part of the
On 1/30/07, Guy Harris [EMAIL PROTECTED] wrote:
On Jan 30, 2007, at 11:07 AM, John R. wrote:
Sequence, iteration, algorithms,
etc. are more naturally handled in code than XML document (that didn't
stop the abomination that is XSLT though ;-) ).
Nor did it stop NetPDL:
Another
On 1/30/07, Mark H. Wood [EMAIL PROTECTED] wrote:
ASN.1 was designed specifically for that sort of thing.
Not really. ASN.1 is a standard description format for new protocols.
It is not designed to, nor is it capable of describing arbitrary
existing protocols. If a new encoding were arrived at,
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
If you get a lot of PDUs spanning tcp segments you may run into this too:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124
-- John.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
I would find it bizarre in the extreme to classify this bug as an
enhancement request.
It is a corner case, yes, but it is still a severe bug under
demonstrable conditions. It cost me about 3 man-weeks of time to
troubleshoot the problem and find a work-around. Basically, wireshark
was unusable
Still looking at the problem of minimal headers split across tcp segments...
Given a minimum header length of L, we only get L - k bytes of the
header at the end of the first packet. So we record in the reassembly
data structures that we need k more bytes. They come in the next
packet, and I
Using tcp_dissect_pdus I have been having issues with improper
dissection of application level protocol PDUs with my proprietary
protocol.
So that this problem can be efficiently debugged, I have reproduced
the issue against a BitTorrent peer.
Problem:
tcp_dissect_pdus is used by many
I have filed this report in bugzilla as
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1124
Thanks,
-- John.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
On Thu, 2006-09-07 at 03:22 -0700, Guy Harris wrote:
John R. wrote:
I have an issue with desegmentation of packets: if the minimal
header
required to judge length is broken across TCP segments A and B, at
segment A it decides properly to return expecting the remainder of
the
minimal
OK, so I'm digging into desegment_tcp.
What I find is that when segment B comes it looks for the most recent
prior PDU which it calls msp. It calculates an offset and length for
the last snippet of Segment A. The length is 4, which is the length of
data at the end of Segment A. It uses this info
16 matches
Mail list logo
