wrong bogus ipv4 info

asked 2021-03-23 15:20:18 +0000

nmlnmtot gravatar image

the payload for ib pkt starts with 0x0800, and the wireshark makes a decision that this appears to be ethertype encapsulated, and there are zeros behind the 0800, which trigers a bogus ipv4 version info. Is there any way to colse the analysis of ib payload.

edit retag flag offensive close merge delete

Comments

Can you share the capture in question? Use a public share such as Google Drive, DropBox etc. and post a link to it back back here.

grahamb gravatar imagegrahamb ( 2021-03-23 15:23:51 +0000 )edit

sorry, I can't uploade any file because of the firewall in this pc. I copied the raw txt info

Internet Protocol Version 4, Src: 100.1.1.101, Dst: 40.1.1.141
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x6a (DSCP: AF31, ECN: ECT(0))
    Total Length: 60
    Identification: 0x0000 (0)
    Flags: 0x40, Don't fragment
    Fragment Offset: 0
    Time to Live: 62
    Protocol: UDP (17)
    Header Checksum: 0xad53 [correct]
    [Header checksum status: Good]
    [Calculated Checksum: 0xad53]
    Source Address: 100.1.1.101
    Destination Address: 40.1.1.141
User Datagram Protocol, Src Port: 54, Dst Port: 4791
InfiniBand
    Base Transport Header
    ***IBA Payload - appears to be EtherType encapsulated***
        Ethertype: IPv4 (0x0800)
        Reserved: 0000
    Invariant CRC: 0x11066b64
Internet Protocol Version 4
    0000 .... = Version: 0
        ***[Expert Info (Error/Protocol): Bogus IPv4 version]***
            [Bogus IPv4 version]
            [Severity level: Error]
            [Group: Protocol]
nmlnmtot gravatar imagenmlnmtot ( 2021-03-23 15:34:35 +0000 )edit

here's the pkt raw hex data

0000   f4 9b  63 3e 8b b7 8d 4e 8f fe 81 00 60 28
0010   08 00 45 6a 00 3c 00 00 40 00 3e 11 ad 53 64 01
0020   01 65 28 01 01 8d 00 36 12 b7 00 28 00 00 04 40
0030   ff ff 10 00 00 e0 80 b0 8c c7 08 00 00 00 00 00
0040   00 00 0c 00 00 00 03 00 00 00 11 06 6b 64
nmlnmtot gravatar imagenmlnmtot ( 2021-03-23 15:45:31 +0000 )edit

Your pkt raw hex data is missing two octets in the first line. If we add data for the two missing octets between 9b and 53 to make the first six octets read f4 9b 00 00 63 3e then use text2pcap against the amended hex file we will produce a single packet pcap file that by default dissects identically to the packet details pasted above.

Jim Young gravatar imageJim Young ( 2021-03-23 18:22:23 +0000 )edit

yes, i missed two octets, thanks @Jim Young for pointing out.

nmlnmtot gravatar imagenmlnmtot ( 2021-03-24 12:58:04 +0000 )edit
add a comment