Bill,

Because of your curiousity, I inferred that the seg fault was not
expected. You see, when the unmodified code seg faulted, I just assumed
this was the current state of the code (ie, broken). Bad assumption on my
part :-)

I tested it out on other machines (Sparc Solaris 5.7, Intel Linux 2.2.x,
Sparc Linux 2.2.x). The only one that saw a seg fault was the one running
on Sparc Linux. One thing to note is that both the Solaris and Sparc Linux
machines have special configurations; they have aliased interfaces. So I
suspect that this may be the problem for Linux, but since you probably
know the code more than me... You may be the better judge of that.  Below
is the output of ifconfig. I have also answered your previous email inline
further below.

eth0      Link encap:Ethernet  HWaddr 08:00:20:9C:29:8E
          inet addr:128.175.201.107  Bcast:128.175.201.127 Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2382472 errors:0 dropped:0 overruns:0 frame:0
          TX packets:689621 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:96 Base address:0xa300

eth0:1    Link encap:Ethernet  HWaddr 08:00:20:9C:29:8E
          inet addr:10.128.201.107  Bcast:10.128.201.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:96 Base address:0xa300

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:8020  Metric:1
          RX packets:960699 errors:0 dropped:0 overruns:0 frame:0
          TX packets:960699 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0


On Thu, 26 Apr 2001, Bill Fenner wrote:

> I'm curious about the seg fault.  Can you build a debugging version
> and send a backtrace,

(gdb) run
Starting program:
/home/pel/sctp/tcpdump-sctp/acaro/tcpdump3.6-patchWork/tcpdump-sctp/tcpdump

Program received signal SIGSEGV, Segmentation fault.
0x7015bc14 in _nss_db_endetherent () from /lib/libnss_db.so.2
(gdb) backtrace
#0  0x7015bc14 in _nss_db_endetherent () from /lib/libnss_db.so.2
#1  0x7015bf88 in _nss_db_getntohost_r () from /lib/libnss_db.so.2
#2  0x70117b2c in ether_ntohost () from /lib/libc.so.6
#3  0x29e24 in init_etherarray () at ./addrtoname.c:696
#4  0x29f50 in init_addrtoname (localnet=2159004000, mask=4294967264)
    at ./addrtoname.c:756
#5  0x11fcc in main (argc=1, argv=0xeffffb64) at ./tcpdump.c:413
(gdb)

> or can you capture the data that makes it fault (perhaps writing the
> captured data to a file with "-w foo" won't fault?)

nope, can't do that cause it seg faults immediately.

Also, I am working on a revised patch for sctp support. This patch will be
for both tcpdump and libpcap. The revision to tcpdump will be simply to
fix the license issues that you mentioned in another email. I have sent an
email to the author of the GPL'd .h files to resolve this. The patch to
libpcap (which is ready) is to allow 'sctp' as a valid command line proto
option. So once the license issue is resolved, I will submit both patches
together.

Thanks,
Armando

-----------------------------------------------------------------------
Armando L. Caro Jr.                                  [EMAIL PROTECTED]
University of Delaware                   http://www.cis.udel.edu/~acaro
-----------------------------------------------------------------------






-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe

Reply via email to