> On Thu, 26 Apr 2001, Guy Harris wrote:
>
> > Looks like a libc bug.
>
> but then why would this not show up with tcpdump 3.4?
Beats me - perhaps the tcpdump 3.4 on which it didn't show up was built
without HAVE_ETHER_NTOHOST defined and the tcpdump 3.6.2 on which it did
show up was built with HAVE_ETHER_NTOHOST defined, for whatever reason.
I found the thread in tcpdump-workers that I'd remembered; there is,
indeed, a bug in GNU libc:
http://www.tcpdump.org/lists/workers/2001/03/msg00082.html
"Seems to be fixed from the changelog of Debian's glibc 2.2.2 package:
2001-01-13 Jakub Jelinek <[EMAIL PROTECTED]>
* inet/ether_ntoh.c (lookup_function): Change arguments to match
_nss_*_getntohost_r prototype.
(ether_ntohost): Pass errno pointer to NSS function."
and
http://www.tcpdump.org/lists/workers/2001/03/msg00100.html
"This is a bug in glibc (I used 2.2), and corrected in 2.2.2 version.
In glibc's inet/ether_ntoh.c there was missing &errno argument to call
to (*fct)() routine (a pointer to nss routine), around line 69:
status = (*fct) (addr, ðerent, buffer, sizeof buffer, &errno);
(last &errno was missing in 2.2, and actual files_ether... routine
tried to set errno to NOENT using uninitialized pointer).
This can be trivially reproduced on 2.2 by just creating empty
/etc/ethers file (in this case nss lookup will be initialized
and tried, thus exploiting this bug)."
and
http://www.tcpdump.org/lists/workers/2001/03/msg00079.html
which shows a stack trace from a crash from a call to "ether_ntohost()"
from "init_etherarray()":
db> bt
#0 0x4022d643 in _nss_files_getntohost_r (addr=0x8096330, result=0xbffff7c0,
buffer=0xbffff3c0 "`\003", buflen=1024, errnop=0x40216fb9)
at nss_files/files-XXX.c:194
#1 0x401ef98a in ether_ntohost (hostname=0xbffff810 "", addr=0x8096330)
at ether_ntoh.c:68
#2 0x805f4ff in init_etherarray () at ./addrtoname.c:697
#3 0x805f5d4 in init_addrtoname (localnet=108736, mask=16777215)
at ./addrtoname.c:757
#4 0x804a1f8 in main (argc=1, argv=0xbffffb04) at ./tcpdump.c:404
#5 0x40116ee1 in __libc_start_main (main=0x8049b94 <main>, argc=1,
ubp_av=0xbffffb04, init=0x8049454 <_init>, fini=0x8077f3c <_fini>,
rtld_fini=0x4000e244 <_dl_fini>, stack_end=0xbffffafc)
at ../sysdeps/generic/libc-start.c:129
which is similar to the stack trace from the crash you saw:
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
(which may have been on an x86 rather than a SPARC; problem might
manifest itself differently on different platforms).
-
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
