On Fri, Mar 24, 2000 at 10:54:28PM -0800, Guy Harris wrote:
> > i am expierencing etherreal hangs on tcpdump dumps with default snaplen.
>
> It's probably some dissector that's not checking to see if it runs past
> the end of the captured data in the frame.
>
> If you do "kill -ABRT <process ID of Ethereal>", that *should* cause it
> to dump core. (If "kill" rejects "-ABRT", use the signal number for
> SIGABRT or, if your system doesn't define SIGABRT, use the signal number
> for SIGIOT.)
>
> A stack trace from that should indicate which dissector it is.
Its the l2tp-dissector ... BTW: Etherreal allocates megabytes of memory
during the "hang" :) - Tight loop allocating memory ... Ill dig into
that a bit further probably on monday as running ethereal via remote
X over a 64Kbit/s ISDN is not really funny.
#0 0x402f2e77 in g_node_insert_before ()
#1 0x80c699c in proto_tree_add_node (tree=0x8311a14, fi=0x86d2818)
at proto.c:837
#2 0x80c69f7 in proto_tree_add_pi (tree=0x8311a14, hfindex=465, start=70,
length=0, format=0x8108eba "AVP Type %s ", visible=1, pfi=0xbfffdf34,
ap=0xbfffdf58) at proto.c:860
#3 0x80c6883 in proto_tree_add_uint_format (tree=0x8311a14, hfindex=465,
start=70, length=0, value=10, format=0x8108eba "AVP Type %s ")
at proto.c:778
#4 0x807ed2b in dissect_l2tp (pd=0x8325ce8 "", offset=70, fd=0x81c63b0,
tree=0x831199c) at packet-l2tp.c:370
#5 0x80b5305 in dissect_udp (pd=0x8325ce8 "", offset=42, fd=0x81c63b0,
tree=0x831199c) at packet-udp.c:347
#6 0x8076bb5 in dissect_ip (pd=0x8325ce8 "", offset=34, fd=0x81c63b0,
tree=0x831199c) at packet-ip.c:1016
#7 0x80c1ae9 in ethertype (etype=2048, offset=14, pd=0x8325ce8 "",
fd=0x81c63b0, tree=0x831199c, fh_tree=0x8311b54, item_id=272)
at ethertype.c:105
#8 0x806ddb4 in dissect_eth (pd=0x8325ce8 "", offset=14, fd=0x81c63b0,
tree=0x831199c) at packet-eth.c:248
Flo
--
Florian Lohoff flo@xxxxxxxxxx +49-5241-470566
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."