Hi.
We have an application that uses libpcap for many Linux versions and for Mac Os
X Leopard with an excellent outcome. When tested on Snow Leopard (10.6.2), it
stopped working. I googled a lot and found out about the BPF issues that you
mention on many posts like
http://www.mail-archive.com/
On Jan 31, 2010, at 1:07 AM, Marco De Angelis wrote:
> We have an application that uses libpcap for many Linux versions and for Mac
> Os X Leopard with an excellent outcome. When tested on Snow Leopard (10.6.2),
> it stopped working. I googled a lot and found out about the BPF issues that
> yo
On Jan 31, 2010, at 1:07 AM, Marco De Angelis wrote:
> I recompiled tcpdump 4.0.0 on my machine, and it works!
On which machine? The Snow Leopard machine? If so, does the tcpdump 4.0.0
that comes with Snow Leopard *not* work?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/
Hi Guy.
Thanks so much for replying.
> The issue described in that message is fixed in 10.6.2.
That is good to know. I have 10.6.2, but I still experience problems
> These are both BPF issues; libpcap 1.0.0 didn't *introduce* them -
I was just looking at my depedency, without being sure if I
Guy Harris alum.mit.edu> writes:
> The issue described in that message is fixed in 10.6.2.
Thanks so much for replying (Sorry if this reply arrives twice, I had problems
in subscribing). That is good to know. I have 10.6.2, but I still experience
problems (packets not dispatched).
> These are b
Gentle people,
I also am seeing similar behavior with libpcap-1.0.0 on Snow Leopard (10.6.2).
Seems that this just started very recently, possible with the upgrade to 10.6.2
but not sure about that.
In my application, which uses pcap_dispatch() in non-blocking mode, and uses
select() to be notifie
On Feb 1, 2010, at 1:08 AM, Marco De Angelis wrote:
> The problem is that the packets are not delivered to the application. More
> specifically,
> it seems that libpcap captures them, but the pcap_dispatch (and pcap_loop as
> well) does
> not deliver packets to the pcap_handler.
What do you
On Feb 1, 2010, at 8:44 AM, Carter Bullard wrote:
> Gentle people,
> I also am seeing similar behavior with libpcap-1.0.0 on Snow Leopard (10.6.2).
> Seems that this just started very recently, possible with the upgrade to
> 10.6.2
> but not sure about that.
>
> In my application, which uses pc
Guy Harris alum.mit.edu> writes:
> > it seems that libpcap captures them, but the pcap_dispatch (and pcap_loop as
well) does not deliver packets to the pcap_handler.
>
> What do you mean by "libpcap captures them"? Do you mean that libpcap reads
the packets into the userland
> buffer attached t
On Feb 3, 2010, at 5:03 AM, Marco De Angelis wrote:
> Guy Harris alum.mit.edu> writes:
>
>>> it seems that libpcap captures them, but the pcap_dispatch (and pcap_loop
>>> as well) does not deliver packets to the pcap_handler.
>>
>> What do you mean by "libpcap captures them"? Do you mean tha
Guy Harris alum.mit.edu> writes:
> > some printout I could add before calling pcap_dispatch to see what's in the
> > kernel buffer and what in the userland buffer?
>
> Yes, but you'd have to add it to libpcap.
>
> >> Is your program built as a 32-bit program or a 64-bit program?
> >
To summa
Guy Harris alum.mit.edu> writes:
> > Good question. Do you know how could I verify the buffer
> > they stay in? Is there
> > some printout I could add before calling pcap_dispatch to see
> > what's in the kernel buffer and what in the userland buffer?
>
> Yes, but you'd have to add it to libpc
Hey Marco,
This may help you if you are not doing it. It seemed to help me on Snow
Leopard.
Just after the call to pcap_open_live(), I set this ioctl. You may not need
the pcap_setnonblock() for
your application.
if ((pd = pcap_open_live(device->name, snaplen, !pflag, 100, errbuf)) !=
NUL
On Feb 9, 2010, at 9:41 AM, Carter Bullard wrote:
> Just after the call to pcap_open_live(), I set this ioctl. You may not need
> the pcap_setnonblock() for
> your application.
>
> if ((pd = pcap_open_live(device->name, snaplen, !pflag, 100, errbuf)) !=
> NULL) {
That's a sub-second timeou
On Feb 9, 2010, at 2:15 AM, Marco De Angelis wrote:
> I made an interesting test.
> By collecting pcap_stats() after every call to pcap_dispatch and
> printing the pcap_stat values out, I could verify that the packets
> are received.
> E.g. if I filter for ICMP packets, by launching "ping" com
Carter Bullard qosient.com> writes:
>
> Hey Marco,
> This may help you if you are not doing it. It seemed to help me on
> Snow Leopard.
Carter, thank you so much! It works nicely with this addition. I understand
that
BIOCIMMEDIATE changes the behaviour and avoids buffering, therefore I will
Guy Harris alum.mit.edu> writes:
> Your code snippet shows pcap_dispatch() being called at the
> beginning of a "loop forever" loop, so I presume you're not
> doing a select() to wait for packets to arrive (that has a problem
> in older versions of *BSD and still has a problem in OS X).
So the
On Feb 10, 2010, at 1:42 PM, Marco De Angelis wrote:
> So the call to pcap_dispatch not preceded by a select() could still
> cause problems in 10.6.2?
It *shouldn't* cause problems, but, from what you and Carter are reporting, it
*does* cause problems.
> This is the output on my machine:
>
>
Guy Harris alum.mit.edu> writes:
> Can you cut your application down to the smallest code
> snippet that shows the problem, and send that to me?
I managed to extrapolate the core. It's a little messy because
of the many tests I made recently and the 80-chars line
limitation, but it show the o
On Feb 12, 2010, at 11:02 AM, Marco De Angelis wrote:
> Guy Harris alum.mit.edu> writes:
>
>> Can you cut your application down to the smallest code
>> snippet that shows the problem, and send that to me?
>
> I managed to extrapolate the core. It's a little messy because
> of the many tests
On Feb 12, 2010, at 4:52 PM, Guy Harris wrote:
> If it shows up in FreeBSD, I'll look at submitting fixes for it and DragonFly
> BSD as well.
It shows up in FreeBSD 7.0 as well, as I suspected. I've submitted a FreeBSD
bug, kern/143855, and a DragonFly BSD bug.
-
This is the tcpdump-workers
Guy Harris alum.mit.edu> writes:
> ...and if I "#if 0" out the code that puts the pcap into
> non-blocking mode, packets don't get delivered
> immediately, but they *do* arrive, so it appears to be an
>issue with non-blocking mode.
Oh, I see.
I have set the non-blocking mode to 0, expecting
On Feb 15, 2010, at 3:55 PM, Marco De Angelis wrote:
> I have set the non-blocking mode to 0, expecting
> the call to pcap_dispatch to hang when packets are not
> collected. But instead, I can see many printouts (Read 0 packets)
> which indicate that the pcap_dispatch has exited when no
> packet
23 matches
Mail list logo
