On 11/30/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
On 2006-12-01 01:28, Guy Harris wrote:
> On Nov 30, 2006, at 1:08 PM, Aaron Turner wrote:
>> Unfortunately, I don't know where or how these pcap files were
>> generated, so I don't know what's causing this to happen or how
>> widespread it i
On 2006-12-01 01:28, Guy Harris wrote:
> On Nov 30, 2006, at 1:08 PM, Aaron Turner wrote:
>> Unfortunately, I don't know where or how these pcap files were
>> generated, so I don't know what's causing this to happen or how
>> widespread it is. Could this of been a bug in earlier versions of
>> lib
On 11/30/06, Guy Harris <[EMAIL PROTECTED]> wrote:
I'd suggest writing a small program to fix the snapshot length in
those captures. It could, for example, scan through the file, find
the maximum caplen, and then open the file for writing and write out
the maximum of the snaplen value and the m
On Nov 30, 2006, at 1:08 PM, Aaron Turner wrote:
I guess I can understand why libpcap takes the min of snaplen &
caplen, but it would be nice if libpcap returned the actual captured
data rather then truncating it.
Unfortunately, I don't know where or how these pcap files were
generated, so I d
Hi All,
I've seen this a few times where a pcap file header has a snaplen of
say 100 bytes, but then one or more packet headers say the caplen (and
actual packet data) is larger. When you read this file with libpcap,
it returns the lesser of the two values and truncates the data
accordingly.
I
Hello,
On 2006-11-28 20:02:24 GMT Guy Harris wrote:
> i.e., you're replacing
> bpf_u_int32 urb_type;
> with
> u_char transfer_type;
> u_char event_type;
> u_short bus_id;
> [... don't work...]
Thanks for precising it. If binary compatibility will be break in any
way, I'd b
