libpcap generates bus error on arm when using specific filte about libpcap HOT 7 CLOSED

Submitted by guy_harris

Logged In: YES
user_id=541179

Well, when I tried it with the current CVS version on
Solaris on SPARC, it didn't crash, so either

1. it's fixed in the current CVS version

or

2. it's not something as simple as an alignment problem
   (does ARM require strict alignment?)

However, we haven't changed anything I can think of, since
the 2003-02-12 snapshot, that would fix the problem, so I
suspect 1) is not the answer.

Is it possible to get a core dump from the Zaurus and get a
stack trace from it? (I assume you either have an ARM
machine on which you're doing compiles or have
cross-development tools, hopefully including cross-GDB.)

from libpcap.

Submitted by guy_harris

Logged In: YES
user_id=541179

Actually, there's also

3. it happens with 802.11 but not Ethernet

(as I suspect the interface was an 802.11 interface, not an
Ethernet interface) so I should try a filter such as that
with an 802.11 capture (Sun servers, such as the one I tried
it on, rarely have 802.11 interfaces so a live capture would
be a bit hard).

However, the kernel on the Zaurus might, or might not,
support "raw 802.11" capture; if not, it's fake Ethernet
anyway.

A stack trace would still be helpful in any case.

from libpcap.

Submitted by ronnocol

Logged In: YES
user_id=130960

I tried again with the 2002.02.20 snapshot, and received the same result, bus error.

Hardware:
Sharp Zaurus SL-5500 ROM 2.38
CompactFlash 10/100 Ethernet card

Background:
I'm porting my application, cdpr, to the arm processor so that I can use it on the Sharp Zaurus SL-5500 PDA. I have existing ports to x86, SPARC, PA-RISC, and RS6000. All platforms except the ARM use the following packet filter:

char filter_app[] = "ether host 01:00:0c:cc:cc:cc and ether[20:2] = 0x2000";

Compiled:

pcap_compile(handle, &filter, filter_app, 0, net);

Activated:

pcap_setfilter(handle, &filter);
pcap_freecode(&filter);

Wait for a packet:

do
{
    packet = pcap_next(handle, &header);
} while (!packet);

On the ARM processor I found that this generated a bus error in the pcap code, which without a debuger on the PDA I determined by putting printf's in the begining of each function. When none of the debug printf's occured in my code, I added debug printf's to the pcap code and determined that it was dying somewhere in pcap_read_packet in pcap-linux.c. I thought that perhaps it was because I was doing a cross-compile, so I then used the CerfCube in sourceforge's compilefarm to compile it natively, and had the same results. I also downloaded tcpdump for the Zaurus, and it had the same results. However, I determined that if I change the filter to be:

char filter_app[] = "ether multicast and ether[20:2] = 0x2000";

(all other code the same) and it works fine on the ARM.

I've installed gdb on the Zaurus, but I don't have a complete development environment setup there, so I haven't transfered the source, but I was able to get a backtrace from the bus error.

BackTrace:

Program received signal SIGBUS, Bus error.
bpf_filter (pc=0x2f418,
    p=0x309da "ÿÿÿÿÿÿ", wirelen=92, buflen=92) at bpf_filter.c:309
309     bpf_filter.c: No such file or directory.
        in bpf_filter.c
(gdb) bt
#0  bpf_filter (pc=0x2f418,
    p=0x309da "ÿÿÿÿÿÿ", wirelen=92, buflen=92)
    at bpf_filter.c:309
#1  0x0000a79c in pcap_read_packet (
    handle=0x2e938,
    callback=0xc2c0 <pcap_oneshot>,
    userdata=0xbffffadc "\034ûÿ¿à\237\a@\220üÿ¿ôúÿ¿$¢") at ./pcap-linux.c:585
#2  0x0000a5a0 in pcap_read (handle=0x2f418,
    max_packets=199130, callback=0,
    user=0xc <Address 0xc out of bounds>)
    at ./pcap-linux.c:410
#3  0x0000c22c in pcap_dispatch (p=0x2f418,
    cnt=199130, callback=0xbffffacc,
    user=0xc <Address 0xc out of bounds>)
    at ./pcap.c:70
#4  0x0000c30c in pcap_next (p=0x2f418,
    h=0x309da) at ./pcap.c:120
#5  0x0000a224 in main (argc=1,
    argv=0xbffffcb4) at cdpr.c:538
#6  0x40042070 in __libc_start_main ()
   from /lib/libc.so.6         

Let me know if there is anything else I can provide.

from libpcap.

Submitted by guy_harris

Logged In: YES
user_id=541179

Oh, f*ckballs. It's crashing in the BPF interpreter,
probably because, when the BPF interpreter was compiled,
LBL_ALIGN wasn't set, and code that assumed that unaligned
accesses are OK was compiled in.

"bpf_filter.c" currently doesn't include "config.h", so that
might be the problem - it has code to forcibly set LBL_ALIGN
on some platforms if it's not defined, but ARM isn't one of
them.

I don't know what the magic #define is for testing whether
something is being compiled for ARM (there might be more
than one, if there are non-GCC compilers with which libpcap
might be compiled).

Perhaps, however, the right answer is to include "config.h",
IF it defines LBL_ALIGN when configuring for an ARM
target. (If it doesn't, that might still be the right thing
to do - but it still won't help here.)

Is LBL_ALIGN defined in the "config.h" file in the tree in
which you built libpcap?

from libpcap.

Submitted by ronnocol

Logged In: YES
user_id=130960

Using the 2003.02.20 snapshot, I was able to work around
the problem (using the original filter) by adding "|| defined
(arm)" to the end of line 81of ./bpf/net/bpf_filter.c, the
line that defines which architecture to define LBL_ALIGN on.

from libpcap.

Submitted by guy_harris

Logged In: YES
user_id=541179

I've checked into bpf_filter.c changes to

1. include "config.h", so that LBL_ALIGN should be defined
   on ARM when building on UNIX

and

2. add "arm" to the list of things we check for if
   LBL_ALIGN isn't defined.

Give the next snapshot (the 02.23 one) a try.

from libpcap.

Submitted by ronnocol

Logged In: YES
user_id=130960

Sorry it has taken so long to get back to you, and I see
you already set this to closed, yes, your changes worked.

from libpcap.