Create PCAP file from values in a database

Question

I have a database filled with a lot of logged IPV4 messages. It is used to get queries like: "give me all messages from MacAddress ... that were logged in the period ... to ... that have ..."

Some queries will result in a huge amount of logged messages. Therefore we decided to make a PCAP file if such a request was made.

"Please create a PCAP file containing all logged messages from your database that ..."

So upon request, my service should fetch the requested data from the database (in pages) and create a PCAP file filled with the data fetched from the database. Later callers can ask for a read-only OWIN stream to this file

The service can create such a file. The problem is that it is not recognized as a proper WireShark file.

I've read Libcap File Format. Whenever I have to create a file filled with LoggedMessages I fill a binary file as follows.

• Global Header
• Per logged message:
  • A packet header
  • Packet data with:
    • Ethernet Frame: Destination Mac, Source Mac, EtherType (0x800)
    • IPV4 header
    • Logged Data

Wireshark starts complaining about the file when it attempts to read the Ethertype. It says this is a Length. Definition of Ethernet Frame with EtherType

So below I show the start of my file. Hexadecimal format per byte + my interpretation of it. After that the comments from wireshark

The created stream starts with the Global Header: a 32 bytes structure. First the hexadecimal values then the interpretation:

=== Global Header ====
D4 C3 B2 A1 02 00 04 00
00 00 00 00 00 00 00 00
FF FF 00 00 01 00 00 00

Magic number A1B2C3D4 (Original Time Precision) Version: 2 - 4 ThisZone 0 sigFigs 0 snapLen 0000FFFF datalinkType 1

Note that the magic number has the LSB first, indicating that every multi-byte number will have the least significant byte first. So a 2 byte value of 0x1234 will have in memory first 34 then 12.

After that the Packets should come. Every time one Packet Header, followed by one Packet Data

=== Packet header ===
09 89 58 5A C8 85 0B 00
6B 00 00 00 6B 00 00 00

Timestamp: 1515751689.7551446 (usec precision) Number of saved bytes (incl_len) 107 bytes (0x006b) Actual packet length (orig_len) 107 bytes (0x006b)

=== Packet Data ===
CF 31 59 D3 E7 98 53 39 - 17 F0 A9 9C 00 08 45 00
5D 00 00 00 00 00 FF 00 - E0 0D 8A 84 77 44 E0 2B
9C FB 4D 43 D5 8A 00 00 - 00 00 41 41 41 41 41 41
41 41 41 41 41 41 41 41 - 41 41 41 41 41 41 41 41
// etc, until total 107 bytes

The packet data consists of a Mac Header, IPV4 header and a couple of 0x41 as data

=== Mac Header ===
Destination Mac: CF:31:59:D3:E7:98
Source Mac: 53:39:17:F0:A9:9C
Ether type: 0800

Note that the magic number showed that every multi-byte number has the LSB first, so the two bytes 00 08 will have a 16-bit meaning of 0x0800

If you look at the PCAP file interpretation I show below, then the problem starts here: the Ether Type is not interpreted as Ether Type, but as length.

After remark in one of the answers, I tried to reverse the two byte ether type from 00 08 into 08 00 (MSB first), but that made the problems worse.

=== IPV4 header ===
- 45 00 5D 00
- 00 00 00 00
- FF 00 E0 0D
- 8A 84 77 44
- E0 2B 9C FB

Specification of the IPV4 header structure

DWORD 0
- bits 00..04: version; bits 04..07 IP Header Length: 04 05
- bits 08..13 DSCP; bits 14..15 ECN:                  00
- bits 16..31 Total Length (header + Payload):        93 (005D)

DWORD 1
- bits 00..15 Identification:            0000
- bits 16..18 Flags; bits 19..31 offset: 0000

DWORD 2
- bits 00..07 Time to Live            FF
- bits 08..15 Protocol; used protocol 00
- bits 16..31 Header Checksum         3552 (0DE0)

DWORD 3 and 4
Source IP:      138.132.119.68
Destination IP: 224.43.156.251

Bacause wireshark complains about checksum, I verify as follows:

Verify checksum:
Header: 0045 005D 0000 0000 00FF 0DE0 848A 4477 2BE0 FB9C
69 + 93 + 0 + 0 + 255 + 3552 + 33930 + 17527 + 11232 + 64412 = 131070 (01FFFE)
0001 + FFFE = FFFF
1's complement: 0000 (checksum ok)

This is what WireShark (version 2.4.4) makes of it:

The following seems normal:

Frame 1: 107 bytes on wire (856 bits), 107 bytes captured (856 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 12, 2018 11:08:09.755144000 W. Europe Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1515751689.755144000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 107 bytes (856 bits)
Capture Length: 107 bytes (856 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:llc:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String [truncated]: eth.fcs.status=="Bad" || 
ip.checksum.status=="Bad" || tcp.checksum.status=="Bad" || 
udp.checksum.status=="Bad" || sctp.checksum.status=="Bad" || 
mstp.checksum.status=="Bad" || cdp.checksum.status=="Bad" ||]

Here comes the first problem: EtherType is interpreted as Length

IEEE 802.3 Ethernet 
Destination: cf:31:59:d3:e7:98 (cf:31:59:d3:e7:98)
Source: 53:39:17:f0:a9:9c (53:39:17:f0:a9:9c)
Length: 8
Padding: ff00e00d8a847744e02b9cfb4d43d58a0000000041414141...
Trailer: 414141414141414141414141414141414141414141414141...
Frame check sequence: 0x41414141 incorrect, should be 0xe19cae36
[FCS Status: Bad]

After the length, which I meant as an EtherType, comes a lot of padding, instead of interpretation of my 5 DWORDs.

The link to the Ethernet Frame in wikipedia I showed says:

The EtherType field is two octets long and it can be used for two different purposes. Values of 1500 and below mean that it is used to indicate the size of the payload in octets, while values of 1536 and above indicate that it is used as an EtherType, to indicate which protocol is encapsulated in the payload of the frame.

My value if 0x0800 = 2048. This certainly is above 1536

For example, an EtherType value of 0x0800 signals that the frame contains an IPv4 datagram.

If value 0x0800 the incorrect value? Or is my error somewhere else?

Answer 1

Looks like your ethertype has the wrong byte order. It should be:

=== Packet Data ===
CF 31 59 D3 E7 98 53 39 - 17 F0 A9 9C 08 00 XX XX