Re: 0.9.6 - this week.. we hit the 6 month part 2 weeks back... so
I'm going to start writing all the ChangeLog/Notes, and get it shipped.
Ken
On 2-Apr-07, at 1:35 AM, Aaron Turner wrote:
On 4/1/07, Guy Harris <[EMAIL PROTECTED]> wrote:
I've checked into the main and x.9 branches a chan
On 4/1/07, Guy Harris <[EMAIL PROTECTED]> wrote:
I've checked into the main and x.9 branches a change that sets the
pcap_t's snaplen value to 14 more than the value from the file header if
the capture was an Ethernet capture with the modified libpcap (based on
the magic number). This isn't idea
Aaron Turner wrote:
Honestly, I can't imagine why the snaplen is interesting other then
for properly sizing the packet data buffer,
It might be useful to use as evidence if somebody asks why a capture has
only partial packets in it.
Well the real issue IMHO is the buggy RH hacked libpcap.
Oops... pcap.h moved to pcap/pcap.h since 0.9.5... This patch
properly handles that.
--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix
On 3/20/07, Aaron Turner <[EMAIL PROTECTED]> wrote:
Well here's a quick patch (against CVS:HEAD) implemen
Well here's a quick patch (against CVS:HEAD) implementing
pcap_snapshot_override(). I did a quick test and it solves my
specific problem. If you accept it, let me know if you decide to keep
the function name, so that I can make sure my code is forwards
compatible. If there's anything you don't
On 3/20/07, Guy Harris <[EMAIL PROTECTED]> wrote:
[snip]
> One fix that would work w/o breaking backwards compatibility is to
> emulate Ethereal/Wireshark for pcap_open_offline(). Basically ignore
> the header snaplen, allocate the max size buffer and have
> pcap_snapshot() always return 65535
Aaron Turner wrote:
Not sure I follow the above. What value are you talking about here...
the file snaplen?
Yes.
Not sure what errors you're talking about here.
People should always compare the packet caplen/len to determine if the
packet was truncated, not the file snaplen.
It's not a qu
On 3/20/07, Guy Harris <[EMAIL PROTECTED]> wrote:
Aaron Turner wrote:
> That's an excellent question. The original pcap file is over 3 years
> old, and honestly I don't remember. My guess is that the packets were
> most likely captured using tcpdump using the default snaplen on a
> RedHat Linu
Aaron Turner wrote:
That's an excellent question. The original pcap file is over 3 years
old, and honestly I don't remember. My guess is that the packets were
most likely captured using tcpdump using the default snaplen on a
RedHat Linux box since that was my main development environment at th
Inline...
On 3/20/07, Guy Harris <[EMAIL PROTECTED]> wrote:
Aaron Turner wrote:
> notice the addtional 14 byes in the wireshark decode: "G SRC='http://";
When you say "same packet", do you mean that you ran "tcpdump -XX" on a
capture file, and ran Wireshark on the same capture file, and got th
Aaron Turner wrote:
notice the addtional 14 byes in the wireshark decode: "G SRC='http://";
When you say "same packet", do you mean that you ran "tcpdump -XX" on a
capture file, and ran Wireshark on the same capture file, and got the
"packet dump example from tcpdump -XX" output from tcpdump
So I'm very confused. Basically I have a loop:
while ((pktdata = pcap_next(pin, pkthdr_ptr)) != NULL) {
packetnum++;
dbgx(2, "packet " COUNTER_SPEC " caplen %d", packetnum, pkthdr.caplen);
}
But when pkthdr.caplen != pkthdr.len for the original packet (as
viewed by
12 matches
Mail list logo
