[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#138847: ngrep-1.40-1 bus error on SS20 (sparc architecture)

Package: ngrep
Version: 1.40-1
Severity: grave

This appears to be a bug specific to the the Woody sparc port of this
package. I am running on a SS20, single hyper-sparc, 192M.

Upon execution I get a bus error:

debian3:/# ngrep
interface: eth0 (
Bus error

After some investigation I have made the following observations:

1. This may have to do with libpcap0-0.6.2-2. I force installed
libpcap0-0.4a6-3 and the problem doesn't seem to occur.

2. I tried several other packages that rely on libpcap0 and many of them
fail with a "Bus error" when using libpcap0-0.6.2-2. tcpflow is one other
such package. tcpdump (which I believe is co-developed with libpcap??)
does not have this problem.

3. Browsing the Internet a little revealed something about aligned -vs-
unaligned packets and libpcap. I am a novice programmer and have very
little socket experience, so do not fully understand this. It seems this
problem doesn't happen on i386 architecture. I also found references to
the fact that libpcap 0.6 can't guarantee aligned packets, where libpcap
0.4 versions could?? Again, my understanding is limited.

4. I did a little analysis of the tcpdump code, and see that it has code
branches to handle "unaligned" packets. It copies something into a buffer
and back, I assume to align it?? This can be seem in tcpdump's print-ip.c
file - search for #ifdef LBL_ALIGN.

5. I hacked together similar code for ngrep based on this "branch" in
tcpdump and inserted it into ngrep.c. I had limited success with this - no
more bus error and ngrep seems to function reasonably, but many things are
broken - like silent mode doesn't catch what it should be, ngrep outputs
way too many bytes for a single packet, ...etc. I'm sure this is due to my
not understanding the code and what's going on here.

In closing it seems that libpcap 0.6 changed a couple of things and the
ngrep source may not yet have the code to deal with these changes on a
sparc architecture. I am hoping that someone with a better understanding
of these issues can help out.


Reply to: