SUMMARY: Displaying packets from a snoop capture file results in a segment ation fault

Just one response on this problem (below) and that was from Dennis Martens.
Dennis recommended dropping the -o option when running snoop and just piping
the output to a plain ascii file i.e. snoop -whatever_options > file.
Straightforward and simple! So, thanks to Dennis for that.

Part of me is still curious about the segmentation fault, while another part
is embarassed about not using something like the suggestion above originally
and the remainder is busy trying to solve the problem that got me using
snoop! :-)

Cheers

James


-----Original Message-----
From: eSolutions, Techlist [mailto:eSolutionsT@misys.com]
Sent: 29 October 2002 12:24
To: 'sunmanagers@sunmanagers.org'
Subject: Displaying packets from a snoop capture file results in a
segment ation fault


Hi everyone,

I'm trying to investigate a problem by using snoop to capture the packets
exchanged with a particular host. We have a capture file which is about 1Mb
and when I use:
 snoop -i snoop-capture-file -t a | more  OR
 snoop -i snoop-capture-file | more OR
 snoop -i snoop-capture-file tcp | more
 I'm getting a segmenation fault (I've tried several other combinations of
options for snoop). As far as I can see this is happening at/after a
specific packet each time (47 if you think there's a numerological reason)
On some occassions I'm seeing the following output as well as the
segmentation fault message:

offset 11460: length=21504
(warning) packet length greater than MTU in capture file
offset 32964: length=1326079820
(warning) packet length greater than MTU in capture file
Segmentation Fault (core dumped)

I'm assuming because that's a warning it shouldn't be fatal and most likely
isn't part of my segmenation fault issue, but it's in for completeness. I
used truss with my command above and the tail of its output gives me the
following, which is way beyond my ability to interpret.

write(2, " ( w a r n i n g )   p a".., 57)      = 57
    Incurred fault #6, FLTBOUNDS  %pc = 0x000178A8
      siginfo: SIGSEGV SEGV_MAPERR addr=0x3E4AE020
    Received signal #11, SIGSEGV [default]
      siginfo: SIGSEGV SEGV_MAPERR addr=0x3E4AE020
        [** process killed ***

I've looked through the archives and google. All I can see are similar
problems going back a few years which recognise that there is an issue when
you use an keyword on the snoop command line that maps to an ethertype (UDP
and TCP should work fine, hence the 3rd command I used in testing this).

If anyone has any suggestions or can help in anyway, I'd appreciate it.

Thanks

James Gallagher
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers