Ethereal-users: [Ethereal-users] ethereal v0.8.14.1 and 0.8.14 on NT4SP5 grabs a packet it GPF's

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Michael Hennessy <hennessy@xxxxxxxxxxxxxxxx>
Date: Fri, 15 Dec 2000 15:44:16 +1000
Hi all,

I've been using ethereal for a little while now (since about v0.8.12, now 
on v0.18.14.1) on NT (v4,SP5) with winpcap (v2.02) and found it very 
helpful for network traffic analysis, however I've come across a problem 
I'd like others' thoughts (ie help) on.

Whilst doing some traffic captures on a network the other day I had 
ethereal in capture mode, and it GPF'd (Exception number: c0000005 (access 
violation)), which had never happened before..... after some fiddling 
around it became apparent that the crash was happening when ethereal tried 
to decode some part of what it had captured, so I ran some captures using 
tethereal for later reference and left the site.

Back in the office, I ran ethereal on the captures and reliably reproduced 
the GPF's - some captures did and some didnt but always the same ones.
I ran a 'tethereal -t ad -r capfile > caplist.txt' on one of the captures 
that gpf'd under ethereal and it completed listing the summary details of 
all packets in the dump, without crashing, but a 'tethereal -V -x -t ad -r 
capfile > longcaplist.txt' gpf'd as well, and the output was truncated near 
the end of frame 13096.

After some fiddling with editcap and tethereal's, I've found that frame 
13097 in the dump file will reliably GPF ethereal and tethereal.
(there may well be others later in the dump - havnt got that far yet)

The short summary of the packet is that its a 'SMBgetatr Response', but 
there are lots of others of the same type in the capture file before it 
that decode OK.
If I run a decode on just that packet with tethereal -V -x there is nothing 
output before it GPF's....

I'm guessing that something in the packet is causing the decoder to die, 
but the question is whether its a bug in the decoder or theres really some 
foul data been running on the wire.... either way I need some way of 
getting more detailed info on whats up....

Whats the next step? are there some other tools for working out whats wrong 
with this dump/capture? is there any debug options in ethereal I could turn 
on?

The packet in question is available for testing if someone wants to have a 
go at it - its only 153 bytes long.

regards,

Michael Hennessy
------------------------------------------------------------------------  
----------
Excalibur Engineering Pty. Ltd.

Mobile Phone No : (+61) 0411 789392
Office Phone No. : (+61) 0249 400133
Office Fax     No. : (+61) 0249 400266
Email  Address    : hennessy@xxxxxxxxxxxxxxxx

Postal Address    : PO Box 1088 Newcastle NSW 2300, Australia
Street Address    : 80 Chin Chen Street, Islington,
                              Newcastle, 2296, Australia
------------------------------------------------------------------------  
----------