Reputation: 21
I have a Windows PC, Marvell switch, Netgear switch and an Ubuntu machine connected together (via the Netgear switch).
I recently sent an packet from the Windows PC to Marvell switch. I am sniffing this packet on Wireshark however the fields of the packet i.e. Frame, Ethernet II, 802.1Q and Data, contain information I don't understand because of its format.
Here is an example -
Data (42 bytes)
Data: cf0b0800000100002000079898000b980000ffffffff0000...
0000 01 50 43 00 00 00 94 de 80 7e 7a fa 91 00 00 00
0010 40 fa cf 0b 08 00 00 01 00 00 20 00 07 98 98 00
0020 0b 98 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00
I am required to know what that actual data is, could someone suggest what I am required to do, so the data in the shown format is understandable.
Upvotes: 2
Views: 2239
Reputation: 21
I understand how it has destination and source address in first 14 bytes etc, in the protocol column it displays the protocol to be 0x40fa
p.no
1___ 0.000000__ Giga-Byt_7e:7a:fa__ MarvellS_00:00:00__ 0x40fa__
It doesn't display the packet to be malformed in wireshark
I made changes to the speed of a port via Marvells GUI hence why that packet was generated and captured after making the change. The packet data actually changes when I select a different port in GUI and make changes to port speed.
So I guess the packet is not malformed but rather have Marvells own structures which are not recognised by wireshark ?
So therefore am I wrong to think I may require access from Marvell to decode the actual data to see the structure of it
Upvotes: 0
Reputation:
"Frame" doesn't correspond to any of the data you show; it corresponds to "metadata" in the capture file, as supplied by the capture mechanism.
The raw packet data is the stuff after the "Data:" line.
The first 14 bytes of that are the Ethernet header; see the IEEE 802.3 spec, or, for example, the Wikipedia page on the Ethernet frame format for information on its format. Note that Wireshark does not capture the preamble or start frame delimiter, and usually doesn't capture the CRC, either, so they're not in the data.
The Ethernet type field is 91 00, which is the "QinQ" Ethernet type; that means it's part of a VLAN (802.1Q) header, which is 4 bytes long, including the Ethernet type field. See the IEEE 802.1Q specification or, for example, the Wikipedia page on 802.1Q for information on its format.
What should follow the VLAN header is another Ethernet type field, but the value of that type field is 40 fa, which is not a known Ethernet type, so Wireshark probably just gives up and shows everything after 40 fa as "Data".
So that frame is probably malformed, because its format is wrong.
Upvotes: 3