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 m
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
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 binar
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
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 i
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
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
> > minim
