Converted from SourceForge issue 1001240, submitted by cozmic

Hello, I just set up my routing box with gentoo linux,
installed ppp 2.4.1 and libpcap 0.8.3 and compiled ppp
with the active filter option.
I did some testing of the active_filter and found out
that it did not work. So I inserted debug output in
pppd and the kernel and finally found out that the
problem originates from the returned ruleset of
pcap_compile.

The filter is 'tcp', optimization is on.

pcap_compile 0.8.3 returns:
(000) code[k]: 0020 [0x00000000], jt: 0, jf: 0
(001) code[k]: 0015 [0x02000000], jt: 0, jf: 3
(002) code[k]: 0030 [0x0000000d], jt: 0, jf: 0
(003) code[k]: 0015 [0x00000006], jt: 0, jf: 1
(004) code[k]: 0006 [0x00000009], jt: 0, jf: 0
(005) code[k]: 0006 [0x00000000], jt: 0, jf: 0

pcap_compile 0.7.2 returns:
(000) code[k]: 0028 [0x00000002], jt: 0, jf: 0
(001) code[k]: 0015 [0x00000021], jt: 0, jf: 3
(002) code[k]: 0030 [0x0000000d], jt: 0, jf: 0
(003) code[k]: 0015 [0x00000006], jt: 0, jf: 1
(004) code[k]: 0006 [0x00000004], jt: 0, jf: 0
(005) code[k]: 0006 [0x00000000], jt: 0, jf: 0

These rulesets are passed to the kernel by pppd, 0.7.2
works, 0.8.3 does not.

For reference the ruleset of tcpdump -d 'tcp' (the same
for both versions)
(000) ldh 12 jeq #0x800 jt 2 jf 5
(002) ldb 23 jeq #0x6 jt 4 jf 5
(004) ret #96
(005) ret #0

Converted from SourceForge issue 599847, submitted by donhatch

All strncpys in libpcap should be changed to strlcpy.
Also, there is this strange thing in pcap-snit.c:
strncpy(ifr.ifr_name, device,
sizeof(ifr.ifr_name));
ifr.ifr_name[sizeof(ifr.ifr_name) - 1] = ' ';
I don't understand why the space character is used
here; it seems to me
that it should be '\0'
(which will of course be unecessary when this strncpy
is changed to strlcpy).

Converted from SourceForge issue 605903, submitted by jrifkin

I believe this is a libpcap problem, but I need to use
tcpdump as an
example.

When reading network traffic that consists of vlan packets
the packet filter get confused? For example

tcpdump port 80

will not show port 80 packets that are also vlan, you
must use

tcpdump vlan and port 80

to see them. But this will not work if reading
'normal' packets.

It would make my app (ipaudit/ipstrings) easier to use
if 'port 80' applied to both 'vlan' and 'normal' (ip)
packets. Is the necessity to use
'vlan' a feature or a bug? If the latter, I would be
willing to invest the
time to fix it if that would help.

Thanks for your time.

Jon Rifkin, [email protected]

Converted from SourceForge issue 709394, submitted by nobody

static int
count_blocks(p)
struct block *p;
{
if (p == 0 || isMarked(p))
return 0;
Mark(p);
return count_blocks(JT(p)) + count_blocks(JF
(p)) + 1;
}

when the tree is depth enough, some recursion
functions will "eat up" the stack.

for example:

tcpdump not host 192.168.0.1 and ... and not host
192.168.0.254 and not host 192.168.1.1 and ... and not
hsot 192.168.10.254

tcpdump is coredump.

Converted from SourceForge issue 668545, submitted by nobody

I am using the pcap filter 'tr protocol ip' to get only
ip traffic encapsulated within token ring. I am using
aix 4.3 and libpcap 0.7.1. I get a parse error when I
try to use it. Why doesn't the tr keyword work? Is
there another way to filter ip addresses etc under
token ring device (i am using device tr0).

Thanks
Andrew

Converted from SourceForge issue 624566, submitted by sugyo

coredump when tcpdump -D on NetBSD1.6 w/ INET6

Converted from SourceForge issue 776730, submitted by nobody

I got this error while linking with libpcap.so
ver 0.7.2

ld: fatal: file /usr/lib/libc.so: version `SUNW_1.19' does
not exist:
required by file ./lib/libpcap.so

Then I have used the libpcap.a to link with, then I got
the following error.

Undefined first referenced
symbol in file
strlcpy ./lib/libpcap.a(pcap-dlpi.o)
ld: fatal: Symbol referencing errors.

OS version is : SunOS 5.7 Generic_106541-21 sun4u
sparc SUNW,Ultra-5_10

ps:Same perfectly got compiled on 5.8 OS.

Converted from SourceForge issue 908743, submitted by djkwesseling

The DLPI version of pcap_read does not test for
EAGAIN/EWOULDBLOCK if non-blocking mode is active.
cf. pcap-bpf.c which returns 0 in this case.

Converted from SourceForge issue 766013, submitted by mszeredi

Latest libpcap seems to mis-optimize the following.

The false jump in 5,7,9 are erronous: if the second
part of the first IP address does not match then it
ignores the second IP address.

The un-optimized version seems OK, so it seems to be an
optimization bug.

bcica:/tcpdump-3.7.2# ./tcpdump -d "( dst host
1234:5678:9abc:def0:feed:babe:dead:beef or dst host
1111:2222:3333:4444:5555:6666:7777:8888 )"
(000) ldh 12 jeq #0x86dd jt 2 jf 18
(002) ld 38 jeq #0x12345678 jt 4 jf 10
(004) ld 42 jeq #0x9abcdef0 jt 6 jf 18
(006) ld 46 jeq #0xfeedbabe jt 8 jf 18
(008) ld 50 jeq #0xdeadbeef jt 17 jf 18
(010) jeq #0x11112222 jt 11 jf 18
(011) ld 42 jeq #0x33334444 jt 13 jf 18
(013) ld 46 jeq #0x55556666 jt 15 jf 18
(015) ld 50 jeq #0x77778888 jt 17 jf 18
(017) ret #96
(018) ret #0
bcica:/tcpdump-3.7.2# ./tcpdump -d -O "( dst host
1234:5678:9abc:def0:feed:babe:dead:beef or dst host
1111:2222:3333:4444:5555:6666:7777:8888 )"
(000) ldh 12 jeq #0x86dd jt 2 jf 10
(002) ld 38 jeq #0x12345678 jt 4 jf 10
(004) ld 42 jeq #0x9abcdef0 jt 6 jf 10
(006) ld 46 jeq #0xfeedbabe jt 8 jf 10
(008) ld 50 jeq #0xdeadbeef jt 20 jf 10
(010) ldh 12 jeq #0x86dd jt 12 jf 21
(012) ld 38 jeq #0x11112222 jt 14 jf 21
(014) ld 42 jeq #0x33334444 jt 16 jf 21
(016) ld 46 jeq #0x55556666 jt 18 jf 21
(018) ld 50 jeq #0x77778888 jt 20 jf 21
(020) ret #96
(021) ret #0
bcica:~/tcpdump-3.7.2# ./tcpdump -V
tcpdump version 3.7.2
libpcap version 0.7.2

Converted from SourceForge issue 814702, submitted by kyle3y3

The example program is attached (pcap_example.c), and
works perfectly on a OpenBSD 3.3 i386.

Please let me know if my lack of understanding
libpcap is to blame.

Synopsis:
On a Redhat 9.0 using libpcap 0.7.2 or
libpcap-2003.09.28.tar.gz,
pcap_next() will return a pointer with random data in
the first 6 bytes.

Steps to recreate on a Redhat 9.0 i386:

1. Compile libpcap 0.7.2 or libpcap-2003.09.28
2. Compile pcap_example.c (gcc pcap_example.c -o
   pcap_example /usr/local/lib/libpcap.a)
   or (gcc pcap_example.c -o pcap_example
   /usr/lib/libpcap.a).
3. Execute pcap_example (./pcap_example )
4. Generate some network traffic. (i.e. surf the web,
   ping something, etc...)
5. pcap_example will return "random" data for the
   next six bytes,
   and not the Layer 2 ethernet destination MAC address.

Converted from SourceForge issue 1055940, submitted by dgaudet

struct sockaddr_ll is longer than struct sockaddr... so get_sa_len needs to know about it, otherwise pcap_findalldevs and such can't return the AF_PACKET addresses.

patch is attached.

Converted from SourceForge issue 693263, submitted by fenner

Eli Dart reported very strange libpcap/bpf behavior,
e.g. "(tcp[13] & 3 != 0) or (tcp[4:4] < 3000)" returns
packets with large sequence numbers. Vern followed up
with the example "tcp[4:4] == 0 and tcp[4:4] > 0"
returning true if the sequence number is == 0. The bpf
code for the latter case is

(007) ld x + 18 jeq #0x0 jt 9 jf 11
(009) jgt #0x80000000 jt 11 jf 10
(010) ret #96
(011) ret #0

This 0x80000000 thing is generated by cooperation
between the code generator and the optimizer. It is an
attempt to handle signed math, e.g. if x - N is
negative than X < n, but it doesn't work in
(some|many|most) cases.

I spent some time debugging this, quite a while ago,
and got more or less nowhere. My general idea is to at
least optimize comparisons with a constant to the
actual compare-with-constant operator. Comparison with
another variable is harder, maybe impossible, to get
right efficiently (it's possible to load into X and
compare directly, but that is quite an expensive
operation).

Eli reminded me today of this problem, and so I am
recording it in the bug database so that I don't forget.

Converted from SourceForge issue 735533, submitted by nobody

Can Libpcap and tcpdump be compiled under CYGWIN?
I am getting this error in ./configure:

configure:1491: case label does not reduce to an integer constant
configure: failed program was:
#line 1477 "configure"
#include "confdefs.h"
/*
                 * This generates a "duplicate case value" when fixincludes
                 * has not be run.
                 */
#               include <sys/types.h>
#               include <sys/time.h>
#               include <sys/ioctl.h>
#               ifdef HAVE_SYS_IOCCOM_H
#               include <sys/ioccom.h>
#               endif
int main() {
switch (0) {
                    case _IO('A', 1):;
                    case _IO('B', 1):;
                    }
; return 0; }

(END)

Converted from SourceForge issue 1037666, submitted by poltuiu

Hello, sorry if I have wrong but ;

in grammar.y we can see :

ifndef YYBISON

int yyparse(void);

int
pcap_parse()
{
return (yyparse());
}

endif

=> pcap_parse is defined if YYBISON is not defined

BUT in gencode.c, we have (line 342)
lex_init(buf ? buf : "");
init_linktype(pcap_datalink(p));
(void)pcap_parse();

AND in gencode.h (line 299)
struct bpf_insn *icode_to_fcode(struct block *, int *);
int pcap_parse(void);
void lex_init(char *);
void lex_cleanup(void);

=> pcap_parse if used without any test case !!
Result is a libpcap wrong if YYBISON is defined
(unedefined fonction pcap_parse)

Where is my error ???

Converted from SourceForge issue 744020, submitted by gangam

Latest CVS compilation fails.

[akshay@vriksha libpcap]$ make
gcc -O2 -I. -DHAVE_CONFIG_H -c ./pcap.c
pcap.c:143: conflicting types for pcap_next_ex' pcap.h:180: previous declaration ofpcap_next_ex'
pcap.c: In function `pcap_next_ex':
pcap.c:147: warning: assignment from incompatible
pointer type
make: *** [pcap.o] Error 1

Tracked the change, to a possible typo ?

RCS file: /tcpdump/master/libpcap/pcap.c,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53

int
pcap_next_ex(pcap_t _p, struct pcap_pkthdr *_pkt_header,

• const u_char **pkt_data)
• u_char **pkt_data)
  <=======================
  {
  struct pkt_for_fakecallback s;

The diff for the correction are :

[akshay@vriksha libpcap]$ diff pcap.c pcap-new.c
142c142

< u_char **pkt_data)

> const u_char **pkt_data)

Thanks
Akshay
gvakshay at yahoo dot com

Converted from SourceForge issue 1051449, submitted by cwrl

It would be useful for me to be able to write dump
files to another file descriptor (a pipe, in fact).
I've attached a patch against the most recent snapshot
(public CVS didn't work for me).

Converted from SourceForge issue 709338, submitted by nobody

static int
count_blocks(p)
struct block *p;
{
    if (p == 0 || isMarked(p))
        return 0;
    Mark(p);
    return count_blocks(JT(p)) + count_blocks(JF(p)) + 1;
}

when the tree is depth enough, some recursion functions will "eat up" the stack.

for example:

tcpdump not host 192.168.0.1 and ... and not host 192.168.0.254 and not host 192.168.1.1 and ... and not host 192.168.10.254

tcpdump is coredump.

Converted from SourceForge issue 656324, submitted by tbearden

I am using cisco 340 AP's and 340 and 350 wireless
adapters. I am sniffing with different cards, but when
I have the correct wep key on the card, all the IV's
show 0x03aaaa. If the card doesn't have the wep key
then it shows random IV's as expected.

Converted from SourceForge issue 918681, submitted by chjapes

Hi,

when I was compiling a program on FreeBSD 5.1 which
uses the libpcap 0.8.1 the program doesn't work as
expected. When compiling against 0.7.2 everzthing
works fine.
The crucial point seems to be the call to
pcap_open_live(). The returned structure doesn't
contain a valid pointer to a buffer as you can see in
the following output of gdb:

$1 = {fd = 8, snapshot = 8, linktype = 100,
tzoff = 1, offset = 0,
sf = {
rfile = 0x0, swapped = 0, hdrsize = 0,
version_major = 0,
version_minor = 0, base = 0x0},
md = {stat =
{ps_recv = 0, ps_drop = 0,
ps_ifdrop = 0},
use_bpf = 0, TotPkts = 0,
TotAccepted = 0, TotDrops = 0,
TotMissed = 0, OrigMissed = 0},
bufsize = 0, buffer = 0x0, bp = 0x0,
cc = 32768, pkt = 0x8079000 "",
fcode = {
bf_len = 0, bf_insns = 0x0},
errbuf = "\0\0\0\00Ã\004\bhÊ\004\b\004Ë\004\b
\0Ð\004\bxÐ\004\bÀÂ\004\b?Ä\004\b", '\0' <repeats 223
times>,
dlt_count = 0, dlt_list = 0x0}

Hope this helps and isn't based on a stupid error on
my side. ;-)

Converted from SourceForge issue 586764, submitted by nbarclay

When trying to use libpcap to capture large (24,000
byte) UDP packets split into fragments, I got a mismatch
between caplen and len on the fragments. This was
using an SGI Irix 6.5 system which uses pcap-snoop.c.
Specifically, the len field came back as 1514 bytes, while
caplen was only 1500 bytes.

Digging into the pcap-snoop.c code, the problem
appears to result from how some of the size check code
fits together in pcap_open_live. At present, the routine's
logic is:

1. Check whether snaplen is greater than the MTU and,
   if so, reduce it to the MTU.
2. Set snooplen to snaplen minus the link-layer header
   length.
3. Pass snooplen to the SIOCSNOOPLEN ioctl.

Thus, the snooplen passed to the ioctl ends up being
several bytes smaller than the MTU rather than being
equal to the MTU. If I understand the implications of
caplen < len correctly, this results in some data loss with
maximum-size fragments, and I'm guessing it would
cause similar problems with maximum-size non-
fragmented packets.

At first appearance, it looks like the problem can be
solved by moving the line "snoop_len = snap_len -
ll_hdrlen" up above the check against ifr.ifr_mtu and
changing the ifr.ifr_mtu check to check snoop_len
instead of snap_len. But that means snap_len itself
doesn't get checked against the MTU, and I don't know
the code enough to be sure whether it ought to be
checked against the MTU for some other reason. I
should also note that I'm working with an Ethernet
interface and can't say for sure how similar problems
would affect other interfaces.

Converted from SourceForge issue 573101, submitted by saturn_de

/*
 * Each packet in the dump file is prepended with this generic header.
 * This gets around the problem of different headers for different
 * packet interfaces.
 */
struct pcap_pkthdr {
    struct timeval ts;/* time stamp */
    bpf_u_int32 caplen;/* length of portion present */
    bpf_u_int32 len;/* length this packet (off wire) */
};

"struct timeval ts" could lead to machine dependant header sizes.

Harald Hoyer, Software Developer
Red Hat GmbH
Hauptstaetterstr. 58 Email:
[email protected]
D-70178 Stuttgart Web :
http://www.redhat.de/

Converted from SourceForge issue 671914, submitted by nobody

I am unable to compile a C++ application that uses
libpcap. The error is

In file included from sniff.cpp:5:
/usr/include/net/bpf.h:369: previous declaration of
u_int bpf_filter(bpf_insn *, u_char *, unsigned int, unsigned int)' with C++ linkage /usr/include/pcap.h:169: conflicts with new declaration with C linkage /usr/include/net/bpf.h:368: previous declaration of int bpf_validate(bpf_insn *, int)' with C++ linkage
/usr/include/pcap.h:170: conflicts with new declaration
with C linkage

This is the header of the bpf.h file:

•  @(#)bpf.h       7.1 (Berkeley) 5/7/91
  

  • @(#) $Header:
    /tcpdump/master/libpcap/bpf/net/bpf.h,v 1.44 2000/12/21
    10:29:24 guy Exp $ (LBL)

This is the header of the pcap.h file:

• @(#) $Header: /tcpdump/master/libpcap/pcap.h,v 1.31
  2000/10/28 00:01:31 guy Exp $ (LBL)

I see that the latest libpcap also has the same
problem. There is a XXX next to the offending
statements in pcap.h.

OS is RH 8.0 Linux.

The compilation command is:
g++ -Wall -I ../../extras/libpcap -o sniff sniff.cpp -L
../../extras/libpcap/ -lpcap

Converted from SourceForge issue 964350, submitted by rdeker

in pcap-bpf.c line 724 seemed a little broken. Rather
than checking each DLT returned by the BIOCGDLTLIST, it
was comparing against the pointer to the array returned
by malloc(). Patch attached.

Converted from SourceForge issue 668578, submitted by nobody

I am using the pcap filter 'tr protocol ip' to get only
ip traffic encapsulated within token ring. I am using
aix 4.3 and libpcap 0.7.1. I get a parse error when I
try to use it. Why doesn't the tr keyword work? Is
there another way to filter ip addresses etc under
token ring device (i am using device tr0).

Thanks
Andrew

Converted from SourceForge issue 673958, submitted by nobody

With network throughput of more than 10-20Mbits/sec,
dropped packets are rarely reported.

I think the reason is this:
The SB_NO_DROPS flag set in pcap_open_live causes
the dlpi module (not the bufmod module) to drop packets
in the STREAMS queues, I think in the upward direction
to bufmod.

When I removed the setting of this flag, I started
recieving drop reports from pcap_stats.
Now I needed two things to get no drops at all:

1. set the SBIOCSCHUNK to 65536 (this is the
   apparently the maximum; higher values caused bad
   behaviour but returned on error from ioctl)
2. run my process at real-time priority.

Converted from SourceForge issue 570998, submitted by nobody

Hello,
I'm using version 0.7.1 of libpcap under linux. If I try to
include pcap.h in a c++-File I get errors because the bpf-
functions are defined in pcap.h and net/bpf.h and
net/bpf.h is included in pcap.h.
Please remove the bpf_* functions from pcap.h. You
have a comment XXX this guy lives .... before the
functions.

Best regards
Bernd Tinkl

Converted from SourceForge issue 686170, submitted by ronnocol

When using the filter "ether host 01:00:0c:cc:cc:cc"
libpcap generates a bus error on the arm processor
(tested on a Sharp Zaurus SL-5500 rom 2.38) The
complete filter that I use is "ether host
01:00:0c:cc:cc:cc and ether[20:2] = 0x2000" which
is the CDP multicast address, and the CDP
identifier.

That multicast mac address is the one used by
Cisco for CDP and HSRP packets. The bus error
occurs in the code that I wrote (cdpr) as well as
when using tcpdump.

I've tried the current version of libpcap 0.7.1, as
well as the CVS daily 2003-02-12, and get the
same results. The workaround is to use the
following filter "ether multicast and ether[20:2] =
0x2000"

Converted from SourceForge issue 933195, submitted by jtalkington

When capturing on a MacOS X 10.2.8 host, all of the TCP
packets that originate from that host display a bad
checksum. However, if I capture the same packets on
the origin server, the packets have the correct checksum.

I thought it may be due to the version supplied with
Macos, so I tried the fink version, then finally
compiled 0.8.3 myself. It happens with all versions.

Converted from SourceForge issue 599857, submitted by donhatch

On Redhat Linux 7.3 with:

• kernel-2.4.18-10
• ethereal-0.9.4-0.7.3.0
• tcpdump-3.6.2-12
• libpcap-0.6.2-12

(and the same behavior observed also with tcpdump-3.7.1/libpcap-0.7.1).
The interface in question, eth1, is a Linksys WMP11 wireless PCI card, using the orinoco_pci driver.
The default route is to a Cisco 340 wireless accesspoint.

I have two problems:

1. While tracing using tcpdump or ethereal (regardless of whether in promiscuous mode or not), pings through the router fail with ICMP "Destination Host Unreachable" (apperently from the local host, not the router)
2. After the trace is finished, if the trace did not use promiscuous mode, pings through the router still fail.

To get the interface out of the bad state of (2), I do either of the following:

ifconfig eth1 promisc; ifconfig eth1 -promisc

or:

tcpdump -n -i eth1

(and then end it, with ^C)

(note that starting and ending "tcpdump -p -n -i eth1" does not fix it).

Running the debugger on tcpdump, I found out that the call in libpcap which causes the pings through the router to stop working is:

    setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP,
               &{ mr_ifindex = device_id, mr_type = promisc ? 
                          PACKET_MR_PROMISC  : PACKET_MR_ALLMULTI })

and there seems to be a third problem here:

1. this PACKET_MR_ALLMULTI call does not cause allmulti to show up in ifconfig. (It should show up, right?)

Here is the state machine, from what I can see.
(Hopefully I didn't make any mistakes...)
The states are: GOOD, BAD, A, P, AP.

The states are: GOOD, BAD, A, P, AP.

State GOOD:
        ifconfig reports no allmulti nor promisc
        ping through router succeeds
            ifconfig promisc -> P
            ifconfig -promisc -> GOOD
            ifconfig allmulti -> A
            ifconfig -allmulti -> GOOD
            start "tcpdump -n -i eth1" -> P
            start "tcpdump -p -n -i eth1" -> BAD
State BAD:
        ifconfig reports no allmulti nor promisc
        ping through router fails
            ifconfig promisc -> P (part way to fix)
            ifconfig -promisc -> BAD
            ifconfig allmulti -> A
            ifconfig -allmulti -> BAD
            start "tcpdump -n -i eth1" -> P
            start "tcpdump -p -n -i eth1" -> BAD
            end "tcpdump -p -n -i eth1" -> BAD
State A:
        ifconfig reports allmulti
        ping through router fails
            ifconfig promisc -> AP
            ifconfig -promisc -> A
            ifconfig allmulti -> A
            ifconfig -allmulti -> BAD (!)
            start "tcpdump -n -i eth1" -> AP
            start "tcpdump -p -n -i eth1" -> A
            end "tcpdump -p -n -i eth1" -> A
State P:
        ifconfig reports promisc
        ping through router fails
            ifconfig promisc -> P
            ifconfig -promisc -> GOOD (fixes the

problem)
ifconfig allmulti -> AP
ifconfig -allmulti -> P
start "tcpdump -n -i eth1" -> P
end "tcpdump -n -i eth1" -> P or GOOD
depending on whether promisc was on or not before
tcpdump was started
start "tcpdump -p -n -i eth1" -> P
end "tcpdump -p -n -i eth1" -> P
State AP:
ifconfig reports allmulti and promisc
ping through router fails
ifconfig promisc -> AP
ifconfig -promisc -> A
ifconfig allmulti -> AP
ifconfig -allmulti -> P
start "tcpdump -n -i eth1" -> AP
end "tcpdump -n -i eth1" -> AP or A
depending on whether promisc was on or not before
tcpdump was started
start "tcpdump -p -n -i eth1" -> AP
end "tcpdump -p -n -i eth1" -> AP

As a workaround, I hacked my libpcap source so that PACKET_MR_ALLMULTI is never used under any circumstances; i.e. it's either PACKET_MR_PROMISC or nothing. (So now I can at least get traces in non-promiscuous
mode!)

Even if none of this is libpcap's fault, I would suggest that libpcap never use PACKET_MR_ALLMULTI when not promiscuous, since it's closer to promiscuous than not, and seems to have similar drawbacks / triggers similar bugs.

Converted from SourceForge issue 1021526, submitted by voigty

ARPHRD_IRDA causes a libpcap-0.8.3 make error in
RedHat 7.1 (stop laughing). I resolved this by
commenting out as follows from libpcap-0.8.3/pcap-
linux.c:

/* case ARPHRD_IRDA:
handle->linktype = DLT_LINUX_IRDA;
//handle->md.cooked = 1;
break;
*/

Perhaps this was caused because my kernel does not
have any IrDA support. In any event, I thought it be
worth noting.

Red Hat Linux release 7.1 (Seawolf)
Kernel 2.4.21-custom on an i586

[user@linuxPC libpcap-0.8.3]# ./configure --
prefix=/usr/local/lib/libpcap083 --ena
ble-ipv6
checking build system type... i586-pc-linux-gnu
checking host system type... i586-pc-linux-gnu
checking target system type... i586-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking gcc version... 2
checking for inline... inline
checking for attribute... yes
checking for u_int8_t using gcc... yes
checking for u_int16_t using gcc... yes
checking for u_int32_t using gcc... yes
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking sys/ioccom.h usability... no
checking sys/ioccom.h presence... no
checking for sys/ioccom.h... no
checking sys/sockio.h usability... no
checking sys/sockio.h presence... no
checking for sys/sockio.h... no
checking ifaddrs.h usability... no
checking ifaddrs.h presence... no
checking for ifaddrs.h... no
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking for netinet/if_ether.h... yes
checking for ANSI ioctl definitions... yes
checking for ether_hostton... yes
checking for strerror... yes
checking for strlcpy... no
checking for vsnprintf... yes
checking for snprintf... yes
checking if --disable-protochain option is specified...
enabled
checking packet capture type... linux
checking for getifaddrs... no
checking if --enable-ipv6 option is specified... yes
checking whether to build optimizer debugging code... no
checking whether to build parser debugging code... no
checking Linux kernel version... 2
checking if if_packet.h has tpacket_stats defined... yes
checking whether we have /proc/net/dev... yes
checking whether we have DAG API... no
checking for flex... flex
checking for flex 2.4 or higher... yes
checking for bison... bison
checking for ranlib... ranlib
checking if sockaddr struct has sa_len member... no
checking if sockaddr_storage struct exists... yes
checking if dl_hp_ppa_info_t struct has dl_module_id_1
member... no
checking if unaligned accesses fail... no
checking for a BSD-compatible install... /usr/bin/install -c
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
[root@tb119 libpcap-0.8.3]# make
gcc -O2 -I. -DHAVE_CONFIG_H -D_U_="attribute
((unused))" -c ./pcap-linux.c
./pcap-linux.c: In function map_arphrd_to_dlt': ./pcap-linux.c:1166:ARPHRD_IRDA' undeclared (first
use in this function)
./pcap-linux.c:1166: (Each undeclared identifier is
reported only once
./pcap-linux.c:1166: for each function it appears in.)
make: *** [pcap-linux.o] Error 1
[root@tb119 libpcap-0.8.3]#

Converted from SourceForge issue 659407, submitted by nobody

I have been simulating a traditional switch. I use libpcap
to capture packet and use libnet to send packet.
But when i send a packet from a VLAN to anther VLAN
libpcap can't capture it(i set in promicuous mode).
Please solve this problem.

Converted from SourceForge issue 747111, submitted by nobody

hi

i have a compil error on freesbd with the last snapshot :

napoleon# make
gcc -O2 -I. -DHAVE_CONFIG_H -c ./pcap-bpf.c
gcc -O2 -I. -DHAVE_CONFIG_H -c ./fad-getad.c
sed -e 's/./static const char pcap_version_string[] =
"libpcap version &";/' ./VERSION > version.h
gcc -O2 -I. -DHAVE_CONFIG_H -c ./pcap.c
pcap.c:143: conflicting types for pcap_next_ex' pcap.h:180: previous declaration ofpcap_next_ex'
pcap.c: In function `pcap_next_ex':
pcap.c:147: warning: assignment from incompatible
pointer type
** Error code 1

i have fix the problem by changing the pcap_next_ex
declaration in pcap.c :

int
pcap_next_ex(pcap_t _p, struct pcap_pkthdr *_pkt_header,
u_char **pkt_data)
{

by

int
pcap_next_ex(pcap_t _p, struct pcap_pkthdr *_pkt_header,
const u_char **pkt_data)
{

hope it help you

Converted from SourceForge issue 769124, submitted by nobody

Using pcap_findalldevs on RH 9 last patched and then
looking for dev->addresses->addr, seems to return
always the value "2".

I have try this simple program:

http://xenion.antifork.org/misc/iip.c

but i cannot get my eth0 address:

[root@pct hopfake]# ./iip eth0
device: eth0 address: 2.0.0.0
[root@pct hopfake]#

bye
Rick.
[email protected]

Converted from SourceForge issue 681857, submitted by nobody

In libpcap/pcap-linux.c, line 496, the variable "struct
sock_fprog" is declared, but in some cases (at least on
a Linux 2.2 kernel), it is not initialized before being
passed to setsockopt(). As a result, programs
calling pcap_open_live() may randomly crash during that
call.

Solution :

line 497, add :
bzero(&fcode, sizeof(fcode));

and this will solve the problem.

Converted from SourceForge issue 654222, submitted by guy_harris

The filter parser and code generator needs a "pppoe"
keyword that works similarly to "vlan", in that it
causes other filter expressions to assume PPPoE
traffic, and check the PPP header for the packet type
and assume that network-layer headers are preceded by
the PPPoE and PPP headers rather than the LAN header.

Converted from SourceForge issue 940212, submitted by guy_harris

tcp[0:2]>=79 and tcp[0:2]<=81

generates bad code in 0.8.3:

(000) ldh 12 jeq #0x800 jt 2 jf 12
(002) ldb 23 jeq #0x6 jt 4 jf 12
(004) ldh 20 jset #0x1fff jt 12 jf 6
(006) ldxb 4*([14]&0xf)
(007) ldh x + 14 ldx #0x4f
(009) jge x jt 10 jf 12
(010) jgt x jt 12 jf 11
(011) ret #68
(012) ret #0

but not in 0.4:

(000) ldh 12 jeq #0x800 jt 2 jf 11
(002) ldb 23 jeq #0x6 jt 4 jf 11
(004) ldh 20 jset #0x1fff jt 11 jf 6
(006) ldxb 4*([14]&0xf)
(007) ldh x + 14 jge #0x4f jt 9 jf 11
(009) jgt #0x51 jt 11 jf 10
(010) ret #68
(011) ret #0

If you turn the optimizer off, the code is still different, but 0.8.3's
code is correct.

Converted from SourceForge issue 724171, submitted by mhwood

I was happy to see detached signatures for libpcap
0.7.2 and tcpdump 3.7.2 at www.tcpdump.org. However,
the signature files are empty! Now I'm not so happy.

Converted from SourceForge issue 793201, submitted by nobody

Hi, this is on a 4 CPU SMP Tru64 UNIX machine.

uname -a
OSF1 cfs0 V5.1 2650 alpha

I downloaded the following:

bison-1.875.tar.gz libpcap-0.7.2.tar.gz m4-1.4.tar.gz
tcpdump-3.7.2.tar.gz flex-2.5.4a.tar.gz

And set my root path as:

echo $PATH

/usr/local/bin:/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/bin/X11:/usr/local

I compiled/installed flex,m4,bison with:

./configure --prefix=/usr/local
make
make install

I then configured libpcap (./configure
--prefix=/usr/local) -- no problem so far.

But ... when I went to build libpcap with:

make

I got the following:

make

cc -O -std1 -g3 -I. -I/usr/local/include
-DHAVE_CONFIG_H -c ./pcap-pf.c
cc -O -std1 -g3 -I. -I/usr/local/include
-DHAVE_CONFIG_H -c ./pcap.c
cc -O -std1 -g3 -I. -I/usr/local/include
-DHAVE_CONFIG_H -c ./inet.c
cc -O -std1 -g3 -I. -I/usr/local/include
-DHAVE_CONFIG_H -c ./gencode.c
cc: Error: ./gencode.c, line 131: Missing ";". (nosemi)
static inline struct block new_block(int z);
--------------^
cc: Info: ./gencode.c, line 131: "inline" is a keyword
in the C99 revision of the C standard. Using it as an
identifier will prevent your program from conforming to
that standard. (futurekeywd2)
static inline struct block *new_block(int z);
-------^
cc: Error: ./gencode.c, line 132: Missing ";". (nosemi)
static inline struct slist *new_stmt(int);
--------------^
cc: Error: ./gencode.c, line 134: Missing ";". (nosemi)
static inline void syntax(void);
--------------^
cc: Error: ./gencode.c, line 143: Missing ";". (nosemi)
static inline struct block *gen_true(void);
--------------^
cc: Error: ./gencode.c, line 144: Missing ";". (nosemi)
static inline struct block *gen_false(void);
--------------^
cc: Error: ./gencode.c, line 239: Missing ";". (nosemi)
static inline struct block *
--------------^
cc: Error: ./gencode.c, line 804: Missing ";". (nosemi)
static inline struct block *
--------------^
cc: Error: ./gencode.c, line 810: Missing ";". (nosemi)
static inline struct block *
--------------^
cc: Warning: ./gencode.c, line 458: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_ABS|size);
--------^
cc: Warning: ./gencode.c, line 461: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(BPF_JEQ));
--------^
cc: Warning: ./gencode.c, line 476: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_ABS|size);
--------^
cc: Warning: ./gencode.c, line 479: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(BPF_JGT));
--------^
cc: Warning: ./gencode.c, line 496: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_ALU|BPF_AND|BPF_K);
----------------^
cc: Warning: ./gencode.c, line 796: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_IMM);
--------^
cc: Warning: ./gencode.c, line 798: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(BPF_JEQ));
--------^
cc: Warning: ./gencode.c, line 1260: In this statement,
"gen_true(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
return gen_true();
/ always true /
-------------------------------^
cc: Warning: ./gencode.c, line 1263: In this statement,
"gen_false(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
return gen_false();
/ always false /
-------------------------------^
cc: Warning: ./gencode.c, line 1409: In this statement,
"gen_false(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
return gen_false();
-------------------------------^
cc: Warning: ./gencode.c, line 1439: In this statement,
"gen_false(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
return gen_false();
-------------------------------^
cc: Warning: ./gencode.c, line 1469: In this statement,
"gen_true(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
return gen_true();
-------------------------------^
cc: Warning: ./gencode.c, line 1471: In this statement,
"gen_false(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
return gen_false();
-------------------------------^
cc: Warning: ./gencode.c, line 2284: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_H|BPF_ABS);
--------^
cc: Warning: ./gencode.c, line 2286: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(BPF_JSET));
--------^
cc: Warning: ./gencode.c, line 2302: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LDX|BPF_MSH|BPF_B);
--------^
cc: Warning: ./gencode.c, line 2305: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s->next = new_stmt(BPF_LD|BPF_IND|BPF_H);
--------^
cc: Warning: ./gencode.c, line 2308: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(BPF_JEQ));
--------^
cc: Warning: ./gencode.c, line 2566: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(0); /dummy/
--------^
cc: Warning: ./gencode.c, line 2574: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_LD|BPF_ABS|BPF_B);
----------------^
cc: Warning: ./gencode.c, line 2578: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_LDX|BPF_MSH|BPF_B);
----------------^
cc: Warning: ./gencode.c, line 2603: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_JMP|BPF_JEQ|BPF_K);
--------^
cc: Warning: ./gencode.c, line 2614: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_JMP|BPF_JEQ|BPF_K);
--------^
cc: Warning: ./gencode.c, line 2717: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_ALU|BPF_ADD|BPF_K);
----------------^
cc: Warning: ./gencode.c, line 2726: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_JMP|BPF_JEQ|BPF_K);
--------^
cc: Warning: ./gencode.c, line 2741: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i - 1]->s.jt = s[i] = new_stmt(BPF_MISC|BPF_TXA);
-------------------------^
cc: Warning: ./gencode.c, line 2744: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_LD|BPF_IND|BPF_B);
--------^
cc: Warning: ./gencode.c, line 2748: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_ST);
--------^
cc: Warning: ./gencode.c, line 2752: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i - 1]->s.jt = s[i] = new_stmt(BPF_MISC|BPF_TXA);
-------------------------^
cc: Warning: ./gencode.c, line 2755: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_ALU|BPF_ADD|BPF_K);
--------^
cc: Warning: ./gencode.c, line 2759: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_MISC|BPF_TAX);
--------^
cc: Warning: ./gencode.c, line 2762: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_LD|BPF_IND|BPF_B);
--------^
cc: Warning: ./gencode.c, line 2766: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_ALU|BPF_ADD|BPF_K);
--------^
cc: Warning: ./gencode.c, line 2770: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_ALU|BPF_MUL|BPF_K);
--------^
cc: Warning: ./gencode.c, line 2774: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_MISC|BPF_TAX);
--------^
cc: Warning: ./gencode.c, line 2777: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_LD|BPF_MEM);
--------^
cc: Warning: ./gencode.c, line 2782: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_JMP|BPF_JA);
--------^
cc: Warning: ./gencode.c, line 2788: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s[i] = new_stmt(BPF_ALU|BPF_ADD|BPF_K);
--------^
cc: Warning: ./gencode.c, line 2806: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(BPF_JEQ));
--------^
cc: Warning: ./gencode.c, line 3412: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LDX|BPF_MEM);
--------^
cc: Warning: ./gencode.c, line 3423: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_MEM);
--------^
cc: Warning: ./gencode.c, line 3462: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
tmp = new_stmt(BPF_LD|BPF_IND|size);
----------------^
cc: Warning: ./gencode.c, line 3481: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
tmp = new_stmt(BPF_LD|BPF_IND|size);
----------------^
cc: Warning: ./gencode.c, line 3500: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LDX|BPF_MSH|BPF_B);
----------------^
cc: Warning: ./gencode.c, line 3503: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
sappend(s,
new_stmt(BPF_ALU|BPF_ADD|BPF_X));
---------------------------^
cc: Warning: ./gencode.c, line 3504: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
sappend(s, new_stmt(BPF_MISC|BPF_TAX));
---------------------------^
cc: Warning: ./gencode.c, line 3505: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
sappend(s, tmp =
new_stmt(BPF_LD|BPF_IND|size));
---------------------------^
cc: Warning: ./gencode.c, line 3524: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_ST);
--------^
cc: Warning: ./gencode.c, line 3542: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s2 = new_stmt(BPF_ALU|BPF_SUB|BPF_X);
--------^
cc: Warning: ./gencode.c, line 3543: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(code));
--------^
cc: Warning: ./gencode.c, line 3584: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_LEN);
--------^
cc: Warning: ./gencode.c, line 3585: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s->next = new_stmt(BPF_ST);
--------^
cc: Warning: ./gencode.c, line 3605: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_IMM);
--------^
cc: Warning: ./gencode.c, line 3607: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s->next = new_stmt(BPF_ST);
--------^
cc: Warning: ./gencode.c, line 3623: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_ALU|BPF_NEG);
--------^
cc: Warning: ./gencode.c, line 3626: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_ST);
--------^
cc: Warning: ./gencode.c, line 3642: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s2 = new_stmt(BPF_ALU|BPF_X|code);
--------^
cc: Warning: ./gencode.c, line 3651: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s0 = new_stmt(BPF_ST);
--------^
cc: Warning: ./gencode.c, line 3703: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_LEN);
--------^
cc: Warning: ./gencode.c, line 3704: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(jmp));
--------^
cc: Warning: ./gencode.c, line 3759: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_ALU|BPF_OR|BPF_K);
----------------^
cc: Warning: ./gencode.c, line 3763: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_ALU|BPF_AND|BPF_K);
----------------^
cc: Warning: ./gencode.c, line 3767: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b = new_block(JMP(BPF_JEQ));
--------^
cc: Warning: ./gencode.c, line 3829: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_B|BPF_ABS);
------------------------^
cc: Warning: ./gencode.c, line 3831: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b0 = new_block(JMP(BPF_JSET));
------------------------^
cc: Warning: ./gencode.c, line 3840: In this statement,
"new_stmt(...)" of type "int", is being converted to
"pointer to struct slist". (cvtdiftypes)
s = new_stmt(BPF_LD|BPF_B|BPF_ABS);
------------------------^
cc: Warning: ./gencode.c, line 3842: In this statement,
"new_block(...)" of type "int", is being converted to
"pointer to struct block". (cvtdiftypes)
b0 = new_block(JMP(BPF_JSET));
------------------------^
cc: Error: ./gencode.c, line 133: The function
"gen_retblk" has internal linkage, occurs in a context
that requires its definition, and has no definition.
(missingfunc)
static struct block *gen_retblk(int);
---------------------^
** Exit 1
Stop.

I got around this by changing the CC flags:

diff -c Makefile Makefile.new

*** Makefile Fri Aug 22 13:57:57 2003
--- Makefile.new Fri Aug 22 13:57:48 2003

*** 42,48 ****

CC = cc
! CCOPT = -O -std1 -g3
INCLS = -I. -I/usr/local/include
DEFS = -DHAVE_CONFIG_H

--- 42,48 ----

CC = cc
! CCOPT = -O -g3
INCLS = -I. -I/usr/local/include
DEFS = -DHAVE_CONFIG_H

It compiles ok now...

make

cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
./gencode.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
./optimize.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
./nametoaddr.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
./etherent.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
./savefile.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
bpf_filter.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
./bpf_image.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
./bpf_dump.c
flex -Ppcap_ -t scanner.l > $$.scanner.c; mv
$$.scanner.c scanner.c
bison -y -p pcap_ -d grammar.y
mv y.tab.c grammar.c
mv y.tab.h tokdefs.h
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
scanner.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H
-Dyylval=pcap_lval -c grammar.c
sed -e 's/.*/char pcap_version[] = "&";/' ./VERSION >
version.c
cc -O -g3 -I. -I/usr/local/include -DHAVE_CONFIG_H -c
version.c
ar rc libpcap.a pcap-pf.o pcap.o inet.o gencode.o
optimize.o nametoaddr.o etherent.o savefile.o
bpf_filter.o bpf_image.o bpf_dump.o scanner.o grammar.o
version.o
ranlib libpcap.a

But it would be really nice to have it work first time!!!

The configure output (in case its helpful) is:

./configure --prefix=/usr/local

checking for a BSD-compatible install...
config/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for gcc... no
checking for cc... cc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc accepts -g... yes
checking for cc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of cc... tru64
checking for strerror in -lcposix... no
checking how to run the C preprocessor... cc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... no
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking for cc option to accept ANSI C... none needed
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for bison... no
checking for byacc... no
checking for ranlib... ranlib
checking for gm4... no
checking for gnum4... no
checking for m4... /usr/local/bin/m4
checking whether m4 supports frozen files... yes
checking for ANSI C header files... (cached) yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for memory.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking for stdbool.h that conforms to C99... no
checking for inline... inline
checking for uintptr_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for obstacks... no
checking for error_at_line... no
checking for working strnlen... no
checking for setlocale... yes
checking whether free is declared... yes
checking whether getenv is declared... yes
checking whether getopt is declared... yes
checking whether stpcpy is declared... no
checking whether strchr is declared... yes
checking whether strspn is declared... yes
checking whether strnlen is declared... no
checking whether malloc is declared... yes
checking whether memchr is declared... yes
checking whether memrchr is declared... no
checking for memchr... yes
checking for memrchr... no
checking for strchr... yes
checking for stpcpy... no
checking for strrchr... yes
checking for strspn... yes
checking for strtol... yes
checking for strtoul... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... no
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking for isascii... yes
checking for iswcntrl... yes
checking for iswprint... yes
checking for mbsinit... yes
checking for wcwidth... yes
checking whether mbrtowc and mbstate_t are properly
declared... yes
checking whether wcwidth is declared... yes
checking for mbstate_t... yes
checking for working memcmp... yes
checking for isascii... (cached) yes
checking for iswprint... (cached) yes
checking whether mbrtowc and mbstate_t are properly
declared... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for wchar.h... (cached) yes
checking for wctype.h... (cached) yes
checking for ANSI C header files... (cached) yes
checking whether backslash-a works in strings... yes
checking for mbstate_t... (cached) yes
checking for function prototypes... yes
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for strcasecmp... yes
checking for strncasecmp... yes
checking for strerror... yes
checking for vprintf... yes
checking for doprnt... no
checking whether strerror is declared... yes
checking whether strerror_r is declared... no
checking for strerror_r... yes
checking whether strerror_r returns char *... no
checking for ANSI C header files... (cached) yes
checking if malloc debugging is wanted... no
checking for pid_t... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking for sys/wait.h that is POSIX.1 compatible...
(cached) yes
checking for dup2... yes
checking for waitpid... yes
checking for unistd.h... (cached) yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/times.h usability... yes
checking sys/times.h presence... yes
checking for sys/times.h... yes
checking for times... yes
checking whether getrusage is declared... yes
checking whether times is declared... yes
checking whether clock is declared... yes
checking whether sysconf is declared... yes
checking for clock_t... yes
checking for struct tms... yes
checking for msgfmt... no
checking for gmsgfmt... :
checking for xgettext... no
checking for msgmerge... no
checking build system type... alphaev68-dec-osf5.1
checking host system type... alphaev68-dec-osf5.1
checking for non-GNU ld... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for shared library run path origin... done
checking whether NLS is requested... yes
checking for GNU gettext in libc... no
checking for iconv... yes
checking how to link with libiconv... -liconv
checking for GNU gettext in libintl... no
checking for valgrind... no
checking for g++... no
configure: creating ./config.status
config.status: creating tests/Makefile
config.status: creating tests/atlocal
config.status: creating tests/bison
config.status: creating Makefile
config.status: creating config/Makefile
config.status: creating po/Makefile.in
config.status: creating data/Makefile
config.status: creating lib/Makefile
config.status: creating src/Makefile
config.status: creating doc/Makefile
config.status: creating m4/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing tests/atconfig commands

Converted from SourceForge issue 941924, submitted by wiml

On (at least) OpenBSD 3.4, getifaddrs() can return an
address with
sa_family==0 and sa_len==0. This leads to a segfault
(more below...).

The specific case I'm seeing is that with gif0
configured as an
ipv6-over-ipv4 tunnel, the second set of addresses
returned for gif0
has a 'dstaddr' which is non-NULL but with zero
length.

This is passed to dup_sockaddr() in inet.c, which
reasonably calls
malloc(0) and then copies 0 bytes of sockaddr into
the resulting
buffer. So far so good. Unfortunately the resulting
pointer is
unusable --- malloc(0) happily returns a pointer to 0
bytes of
dereferencable memory. So any attempt to examine this
pointer results
in a segfault. Even if it did not segfault, of
course, it would not
have an accurate sa_family or sa_len, since those
didn't get copied by
dup_sockaddr(). And on systems where malloc(0)
returns NULL, this
would be interpreted as an error by
add_addr_to_iflist(), causing the
whole pcap_findalldevs() call to fail.

On my system I've worked around this by checking for
a zero sa_len in
add_addr_to_iflist() and zeroing out the dstaddr
pointer in that case.
A better solution would be to check for some minimum
length of a valid
sockaddr, long enough to hold sa_family and sa_len
(if sa_len exists
on that platform), and discard too-short sockaddrs as
unusable.

I've checked this in pcap-0.7.2, pcap-0.8.3, and the
current CVS
version, all of which have the same problem.

Converted from SourceForge issue 603580, submitted by nobody

I downloaded the latest libpcap from libpcap-0.7.1.tar.gz
but it fails to compile on my RedHat Linux box version
7.2 with kernel 2.4.17. I have searched in all the include
files I can find but I still cannot locate some #defines
and structs.
Where should the following structures be defined
sockaddr_raw, snoopfilter, RS_SNOOP, RS_DRAIN
and rawstats?

Also what are the values for the following defines
SIOCRAWSTATS,SIOCADDSNOOP,
SIOCSNOOPING, SIOCSNOOPLEN?

tia
Dympna

Converted from SourceForge issue 697594, submitted by cross

I am trying to get libpcap 0.7.2 to compile on a
BSD/OS 5.0 host. There are many DLT_ symbols used in
the code, that are documented to come from only one OS
(OpenBSD, NetBSD, Linux, etc). But, these are not
generally protected with an #ifdef. How is this? Do
all OS's tend to define these symbols to something,
even in the case that they came up from only one OS
originally? Is there some magic that needs to occur
during the build process to NULL out the other ones
that aren't valid for your host OS?

Thanks. Could very much use support/clarification
here...

Converted from SourceForge issue 599849, submitted by donhatch

The implementation of yy_flex_strncpy is:
static void yy_flex_strncpy( s1, s2, n )
{
register int i;
for ( i = 0; i < n; ++i )
s1[i] = s2[i];
}
This is bad since it can read past the end of the s2
buffer,
potentially into unmapped memory addresses
which would cause a SEGV.
Something like the following would be better:
static void yy_flex_strncpy( s1, s2, n )
{
register int i;
for ( i = 0; i < n; ++i )
if ((s1[i] = s2[i]) == '\0')
break;
}

Converted from SourceForge issue 573119, submitted by saturn_de

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=63125

Harald Hoyer <[email protected]>

Converted from SourceForge issue 612342, submitted by bkosbab

If I set the snaplength parameter to a value that is > 600, libpcap does not capture all packets. The problem grows worse as the snaplength value increases. However, if I set the value to a small value such as 64 libpcap gets 100% of the packets.

Platform is 500Mhz Sun Blade 100 with Solaris 8.2, 64-bit kernel.

Converted from SourceForge issue 686105, submitted by ronnocol

When using the filter "ether host 01:00:0c:cc:cc:cc" libpcap generates a bus error on the arm processor (tested on a Sharp Zaurus SL-5500 rom 2.38) The complete filter that I use is "ether host 01:00:0c:cc:cc:cc and ether[20:2] = 0x2000" which is the CDP multicast address, and the CDP identifier.

That multicast mac address is the one used by Cisco for CDP and HSRP packets. The bus error occurs in the code that I wrote (cdpr) as well as when using tcpdump.

I've tried the current version of libpcap 0.7.1, as well as the CVS daily 2003-02-12, and get the same results. The workaround is to use the following filter "ether multicast and ether[20:2] = 0x2000".

Converted from SourceForge issue 600755, submitted by renhoek

I need an up-to-date libpcap due to the nonblocking support. I compiled a simple program with the libpcap.a standard on my distro and it worked. I renamed the old lib, compiled the 0.7.1 and now the program fails. I tried the daily 2002.08.27 which also fails.

I'm compiling this program:

http://www.cet.nau.edu/~mc8/Socket/Tutorials/testpcap1.c

with cc -Wall testpcap1.c -o testpcap1 -lpcap

I have straces of the program compiled against the new and old lib.. here are the most interesting parts:

OLD

brk(0)                                  = 0x805cf98
brk(0x805d138)                          = 0x805d138
brk(0x805e000)                          = 0x805e000
socket(PF_PACKET, SOCK_RAW, 768)        = 3
ioctl(3, 0x8933, 0xbffff6fc)            = 0
ioctl(3, SIOCGIFHWADDR, 0xbffff6fc)     = 0
ioctl(3, 0x8933, 0xbffff6fc)            = 0
bind(3, {sin_family=AF_PACKET, proto=0x03, if2, pkttype=0, addr(0)={0, }, 20) = 0
setsockopt(3, 0x107 /* IPPROTO_??? */1, [2], 16) = 0
ioctl(3, SIOCGIFMTU, 0xbffff6fc)        = 0
recvfrom(3, "\0\20\247\2{\333\0\2D-k\25\10\0E\0\0Lt@@\0\200\6\3\0\300"...,
    8192, MSG_TRUNC, {sin_family=AF_PACKET, proto=0x800, if2, pkttype=0, addr(6)={1, }, [20]) = 90
ioctl(3, SIOCGSTAMP, 0xbffff708)        = 0

NEW

brk(0)                                  = 0x8062678
brk(0x8062818)                          = 0x8062818
brk(0x8063000)                          = 0x8063000
socket(PF_PACKET, SOCK_RAW, 3)          = 3
ioctl(3, 0x8933, 0xbffff56c)            = 0
ioctl(3, SIOCGIFHWADDR, 0xbffff56c)     = 0
ioctl(3, 0x8933, 0xbffff56c)            = 0
bind(3, {sin_family=AF_PACKET, proto=0x300, if2, pkttype=0, addr(0)={0, }, 20) = 0
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
setsockopt(3, 0x107 /* IPPROTO_??? */1, [2], 16) = 0
brk(0x8066000)                          = 0x8066000
recvfrom(3,

As you can see the new version just hangs on the recvfrom, and I can't figure out why.

I'm using gcc 2.95.3, Linux 2.2.19 on an i386 platform. My distro is Slackware 8.0.0. I'm unsure what pcap version is distributed with this distro, but I found this header in the original pcap.a, maybe that will tell you enough:

$Header: /tcpdump/master/libpcap/pcap-linux.c,v 1.51 2001 /01/03 01:06:16 guy Exp $ (LBL).

Converted from SourceForge issue 1008667, submitted by ip6research

I wrote a small program called ice9 that I have setup for
anonymous cvs if you need the source code to look at.
Anyways everythign works fine with the code if you are
looking at IPv4 traffic. After installing libpcap with IPv6
enabled everything for IPv4 still works fine. However,
IPv6 packets are never read. Tcpdump will read the
pcap data fine (which ensures I have valid data) but
pcap_next_ex() returns a -2 without ever reading one
packet in. Is there a bug in the code or someone else
have clairovoance that I don't and can tip the rest of us
to the secret?

Converted from SourceForge issue 625268, submitted by nobody

I am trying to install libpcap v.0.7 on Tru64 version 4.0
using flex 2.5.4.

When I run configure I am being told that the version of flex
I'm using is 2.4.6 is older. I've double-checked to make
sure that I have the most up-to-date version of flex that is
available.

Here is what is given in the configure information:

checking for flex... flex
checking for flex 2.4 or higher... no
configure: warning: ignoring obsolete flex executable (2.4 or
higher required)
checking for bison... no
checking for capable lex... insufficient
configure: error: Your operating system's lex is insufficient
to compile
libpcap. flex is a lex replacement that has many
advantages, including
being able to compile libpcap. For more information, see
http://www.gnu.org/software/flex/flex.html .

Converted from SourceForge issue 656337, submitted by tbearden

I am using cisco 340 AP's and 340 and 350 wireless
adapters. I am sniffing with different cards, but when
I have the correct wep key on the card, all the IV's
show 0x03aaaa. If the card doesn't have the wep key
then it shows random IV's as expected.

Converted from SourceForge issue 860815, submitted by guy_harris

While looking at bug 766013, I tested with theexpression

ether proto 0x86dd and
(ether[38:4] == 0x12345678 and ether[42:4] == 0x9abcdef0 and
 ether[46:4] == 0xfeedbabe and ether[50:4] == 0xdeadbeef) or
(ether[38:4] == 0x11112222 and ether[42:4] == 0x33334444 and
 ether[46:4] == 0x55556666 and ether[50:4] == 0x77778888)

That also generates bad code:

(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 10
(002) ld       [38]
(003) jeq      #0x12345678      jt 4    jf 10
(004) ld       [42]
(005) jeq      #0x9abcdef0      jt 6    jf 19
(006) ld       [46]
(007) jeq      #0xfeedbabe      jt 8    jf 19
(008) ld       [50]
(009) jeq      #0xdeadbeef      jt 18   jf 19
(010) ld       [38]
(011) jeq      #0x11112222      jt 12   jf 19
(012) ld       [42]
(013) jeq      #0x33334444      jt 14   jf 19
(014) ld       [46]
(015) jeq      #0x55556666      jt 16   jf 19
(016) ld       [50]
(017) jeq      #0x77778888      jt 18   jf 19
(018) ret      #68
(019) ret      #0

but only in the current CVS version - 0.7.x doesn't have that bug. It was introduced in revision 1.73 of
optimize.c - the change of

if (add == 0 || add->s.code != (BPF_ALU|BPF_ADD|BPF_X))
    break;

to

if (add == 0 || add->s.code != (BPF_ALU|BPF_ADD|BPF_X))
   continue;

introduced it.

Unfortunately, removing that change causes "1 & len == 1" to generate

(000) ld       #pktlen
(001) tax
(002) ld       #0x1
(003) and      x
(004) sub      #1
(005) jeq      #0x0             jt 6    jf 7
(006) ret      #68
(007) ret      #0

which, although correct, is a bit bogus, rather than generating

(000) ld       #pktlen
(001) tax      
(002) ld       #0x1
(003) and      x
(004) jeq      #0x1             jt 5    jf 6
(005) ret      #68
(006) ret      #0

and causes "0 - len == 1" to generate

(000) ld       #pktlen
(001) tax      
(002) ld       #0xffffffff
(003) jeq      x                jt 4    jf 5
(004) ret      #68
(005) ret      #0

rather than

(000) ld       #pktlen
(001) tax      
(002) ld       #0x0
(003) sub      x
(004) jeq      #0x1             jt 5    jf 6
(005) ret      #68
(006) ret      #0