hello,
On 02/02/2008 11:38 PM, Guy Harris wrote:
> Guy Harris wrote:
>> *However*, unless I'm missing something, a pointer to the payload
>> after the SLL header is being passed to the callback;
>
> ...
>
>> I'll try it out on my Ubuntu "machine"
>
> That appears to have been the problem;
On 02/02/2008 11:38 PM, Guy Harris wrote:
Guy Harris wrote:
*However*, unless I'm missing something, a pointer to the payload
after the SLL header is being passed to the callback;
...
I'll try it out on my Ubuntu "machine"
That appears to have been the problem; I checked in a fix that
Guy Harris wrote:
*However*, unless I'm missing something, a pointer to the payload after
the SLL header is being passed to the callback;
...
I'll try it out on my Ubuntu "machine"
That appears to have been the problem; I checked in a fix that made it
work, at least in my test.
-
Alexander 'Leo' Bergolth wrote:
Hi!
On 01/31/2008 02:39 PM, Abeni Paolo wrote:
on Thu 1/31/2008 10:37 AM Alexander 'Leo' Bergolth wrote:
I just gave your new linux mmap patch a try
thanks for the review :-)
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately
Alexander 'Leo' Bergolth wrote:
Sorry, I wasn't aware of the ambiguity...
It's an obscure ambiguity, but I just wanted to make sure.
I've checked your typo fix in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Abeni Paolo wrote:
*) If pcap_loop is called with cnt=0 (ngrep erroneously does that), it
will busy-loop forever. pcap_read_linux_mmap doesn't handle that case,
it returns 0, which is asymmetric to pcap_read_linux's behavior, which
reads one packet.
I think there is a little confusion about th
On 02/02/2008 08:42 PM, Guy Harris wrote:
Alexander 'Leo' Bergolth wrote:
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately, the same patch seems to cause some displacement of the
frames, starting with the first captured frame, when using the "any"
interface.
Alexander 'Leo' Bergolth wrote:
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately, the same patch seems to cause some displacement of the
frames, starting with the first captured frame, when using the "any"
interface.
So by "the same patch" are you referring
Hi!
On 01/31/2008 02:39 PM, Abeni Paolo wrote:
on Thu 1/31/2008 10:37 AM Alexander 'Leo' Bergolth wrote:
I just gave your new linux mmap patch a try
thanks for the review :-)
Bad news...
I've also tested it on debian etch (kernel 2.6.22-2-686).
Unfortunately, the same patch seems to cause s
hello,
on Thu 1/31/2008 10:37 AM Alexander 'Leo' Bergolth wrote:
> I just gave your new linux mmap patch a try
thanks for the review :-)
> *) There is a typo in the macro RING_GET_FRAME(h) (handle instead of h).
> The attached patch fixes that.
Your patch looks good to me. I hope that Guy Harri
Hi!
I just gave your new linux mmap patch a try, that was committed to svn
a few weeks ago.
The code works fine, except for two issues:
*) There is a typo in the macro RING_GET_FRAME(h) (handle instead of h).
The attached patch fixes that.
*) If pcap_loop is called with cnt=0 (ngrep erroneously
11 matches
Mail list logo
