> Your program is calling pcap_open_live() with a snapshot length of 1,
> meaning that it only wants the first byte of every packet, but the Linux
> libpcap doesn't correctly handle that when capturing on a device that
> uses "cooked mode", such as a PPP device - it just allocates a buffer
Michal Kepien wrote:
The whole `valgrind --leak-check=yes ./glibc_pcap_error' output can be found
here:
http://kempniu.no-ip.com/files/valgrind.log
Well, after seeing the Valgrind errors and asking why it was complaining
about a buffer of size 1, and then looking at the libpcap code to see
> Could you try running that version of tcpdump, or your application,
> under Valgrind, while capturing on a PPP link? If libpcap is
> overwriting a buffer, that might find the place where it happens.
The whole `valgrind --leak-check=yes ./glibc_pcap_error' output can be found
here:
http://kem
Michal Kepien wrote:
$ tcpdump -h
tcpdump version 3.9.2
libpcap version 0.9.2
I've compiled both libpcap and tcpdump from sources version 3.9.3 (yes, that's
a "3" at the end :))
Could you try running that version of tcpdump, or your application,
under Valgrind, while capturing on a PPP link?
> I'll have to check on a system where glibc was not updated since install.
I get the same errors on a Slackware box with an unupgraded libc version 2.3.4.
Best regards,
Michal
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
> What version of libpcap is in your version of Slackware? (What does
> "tcpdump -h" print?)
$ tcpdump -h
tcpdump version 3.9.2
libpcap version 0.9.2
I've compiled both libpcap and tcpdump from sources version 3.9.3 (yes, that's
a "3" at the end :))
Best regards,
Michal
-
This is the tcpdump-w
Michal Kepien wrote:
I don't know whether this is the right place to post, but unfortunately nobody
on the usenet was able to help me with this issue. I came across this while
I was writing a simple libpcap-based program. The problem is, after I call any
packet capturing function (pcap_next(), p
> maybe you could recompile libpcap with your current libc and make certain
> that gcc finds the new libpcap, i.e. set LD_LIBRARY_PATH, if necessary?
Well, actually it has been compiled with the current libc... I really don't get
it, I've skimmed through tcpdump sources and it also uses gmtime() (
> the program looks ok and it compiled and ran on my sparc debian printing
> "callback" on each packet (i had to use eth0 as the interface, but it
> should not matter).
Now that's odd, the program works fine if I use eth0 as the interface... While
with ppp0 it crashes... Any ideas?
Best regards,
Hi Michal,
the program looks ok and it compiled and ran on my sparc debian printing
"callback" on each packet (i had to use eth0 as the interface, but it
should not matter).
maybe you could recompile libpcap with your current libc and make certain
that gcc finds the new libpcap, i.e. set LD_LIBRAR
Hi all,
I don't know whether this is the right place to post, but unfortunately nobody
on the usenet was able to help me with this issue. I came across this while
I was writing a simple libpcap-based program. The problem is, after I call any
packet capturing function (pcap_next(), pcap_loop() etc.
11 matches
Mail list logo
