Ethereal-users: Re: [Ethereal-users] Ethereal 0.9.7 Crashes with One GPRS R98 Packet Injection

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

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Guy Harris <guy@xxxxxxxxxx>
Date: Mon, 21 Oct 2002 14:21:48 -0700
On Mon, Oct 21, 2002 at 10:26:37AM -0500, Kevin Poole wrote:
> However I am having a problems when I inject a GPRS R98
> Identification Response message with 5 Triplets Ethereal Crashes.  Here
> is the packet.  I would appreciate any help you could offer.

Well, after I convert the raw packet data to a form text2pcap could
handle (16 byte values per line, spaces between byte values, hex offset
at the beginning of each line), and use text2pcap to convert it to
libpcap format, and read it in Ethereal, the current CVS version of
Ethereal I have here doesn't crash, it just shows what it claims to be a
malformed packet.

I've attached the capture file in libpcap format, and the output of
Ethereal when I do a print to file.

If the capture file contains the correct data for the packet, and causes
your Ethereal to crash, this may be a bug fixed after 0.9.7 was
released, although the GTP dissector wasn't changed since then.  If you
are using UNIX, and you have a debugger handy, and Ethereal produced a
core dump when it crashed, please use the debugger to get a stack trace
and send it to us.

If the capture file doesn't contain the correct data for the packet,
please send us a capture file containing that data, rather than a hex
dump of that data.

Frame 1 (218 bytes on wire, 218 bytes captured)
    Arrival Time: Dec 31, 1969 16:00:00.000000000
    Time delta from previous packet: 0.000000000 seconds
    Time relative to first packet: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 218 bytes
    Capture Length: 218 bytes
Ethernet II, Src: 00:b0:d0:42:28:c6, Dst: 00:00:50:08:f3:f2
    Destination: 00:00:50:08:f3:f2 (00:00:50:08:f3:f2)
    Source: 00:b0:d0:42:28:c6 (00:b0:d0:42:28:c6)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 100.100.100.200 (100.100.100.200), Dst Addr: 100.100.100.100 (100.100.100.100)
    Version: 4
    Header length: 20 bytes
    Type of service: 0x00 (None)
        000. .... = Precedence: routine (0)
        ...0 .... = Delay: Normal
        .... 0... = Throughput: Normal
        .... .0.. = Reliability: Normal
        .... ..0. = Cost: Normal
    Total Length: 204
    Identification: 0x0000
    Flags: 0x04
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 4
    Protocol: UDP (0x11)
    Header checksum: 0xe42c (correct)
    Source: 100.100.100.200 (100.100.100.200)
    Destination: 100.100.100.100 (100.100.100.100)
User Datagram Protocol, Src Port: 3386 (3386), Dst Port: 3386 (3386)
    Source port: 3386 (3386)
    Destination port: 3386 (3386)
    Length: 184
    Checksum: 0xefae (correct)
GPRS Tunnelling Protocol v0
    Flags: 0x1e
        000. .... = Version: GTP release 97/98 version (0)
        ...1 .... = Protocol type: 1
        .... 111. = Reserved: 7
        .... ...0 = Is SNDCP N-PDU included?: no
    Message type: Identification response (0x31)
    Length: 156
    Sequence number: 0x0001
    Flow label: 0x0000
    SNDCP N-PDU LLC Number: 0xff
    TID: 2620200000003045
    [--- end of GTPv0 header, beginning of extension headers ---]
    Cause: Request accepted (128)
    IMSI: 262020000000304
    Authentication triplets
    RAND: d6bbdcd4a31025e8baa7628987622e50
    SRES: 731e7971
    Kc: 6b5804d1f02c72c
    Authentication triplets
    RAND: da4efbe55cc421685d5ccebbc6a4fb
    SRES: 7feb5e40
    Kc: f96184cdf8f96b1e
    Authentication triplets
    RAND: a2e7cf35f2ff588a2357d1bef3592d0a
    SRES: 7426a90
    Kc: 575afd2f86f2741b
    Authentication triplets
    RAND: 3a48eb8e602c94aefee21b34c792c2d
    SRES: a6012b1d
    Kc: 43a76cef4a4b8416
[Malformed Packet: GTPv0]

Attachment: gprs.pcap
Description: Binary data