This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Import hex dump not working as expected

0

Hello,

I have created a TCL script that creates a text file containing a wireshark hex dump.

The text file consists of multiple lines similar to this one:

000000 90 b1 1c 99 53 f5 00 18 19 b5 86 44 08 00 4D FE 04 08 E7 5C 1B

This is just the beginning of a line, it contains a TCP packet encapsulated with IPv4 and then ethernet. I'd like to import my file to Wireshark and analyze it there, but when I do this, something odd happens.

Wireshark detects every line as a single packet, detects and analyses correct the information in the IPv4 and Ethernet headers, however the IPv4 payload that is supposed to be a TCP encapsulation is not loaded into Wireshark (the "Data" section of the IPv4 datagram is detected as being of 12 bytes length.).

I hope i have been explicit enough and that someone could help me :)

Thank you very much!

Extra information:

I managed to figure out why the data wasn't all loaded (had something wrong in the TCL script).

However, I stumbled upon something else.

Wireshark detects the payload of the IPv4 header as "data" instead of a TCP packet. I thought this happened before only because he was loading only 12 bytes of data.

This is an input file example: http://pastebin.com/uXY8tN52

asked 04 Jul '13, 07:13

Maio's gravatar image

Maio
11336
accept rate: 0%

edited 08 Jul '13, 00:51

please add more lines of the actual input

(04 Jul '13, 07:15) Kurt Knochner ♦

4D FE 04 08 E7 5C 1B

OK, so that's:

  • 4D - version 4, header length 13*4 = 52 bytes
  • FE - type of service
  • 04 08 - total length, 1032 bytes
  • E7 5C - identification
  • 1B - first byte of flags+fragment offset, so this isn't the first fragment

so that packet shouldn't be dissected as TCP unless you have the rest of the fragments.

Please give all the lines of at least one packet that's not being dissected as you expect.

(04 Jul '13, 09:12) Guy Harris ♦♦

2 Answers:

1

Wireshark detects the payload of the IPv4 header as "data" instead of a TCP packet. I thought this happened before only because he was loading only 12 bytes of data. This is an input file example: http://pastebin.com/uXY8tN52

Your TCL script is still not working correctly. The IP V4 header contains different flags and values, that should not be there (at least that's what I think, without knowing your data).

I recommend to check at least the DiffServ fields and the Fragemt offset. If I set those values to 0x00, I get at least something that looks like parts of a TCP frame (still not correct).

Then there are some $ signs in the text like $E and $5. Please fix that as well.

If think the script needs some more tweaking. Where do you get the packet data from?

Regards
Kurt

answered 08 Jul '13, 01:50

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 08 Jul '13, 02:02

0

Since you say that Wireshark reads every line as its own packet, from that I think you're TCL script is most likely (as suggested) using an all-zero offset for each line. Is that the case? How are you building those offsets?

I haven't touched a TCL script in years but if it helps this is how I build those hex offsets in perl, into a format that Wireshark will accept. In this loop, each entry in the "@packets" array is a packet in hexidecimal form:

foreach (@packets) { $packet = $_; $packet_length = $_ =~ tr/[0-9a-zA-Z]//; # The +0.999... is a cheap way to round up for the last line. $line_count = int(($packet_length/32) + 0.9999999999); for ($n=0; $n < $line_count; $n++){ $offset = sprintf("%x",($n*16)); # Assumes no offset greater than 4 hex characters. $lead_zeros = 4 - ($offset =~ tr/[0-9a-zA-Z]//); $lead_zeros = '0' x $lead_zeros; $bytes = substr($packet,$n*32,32); # Adds a space character after every byte. $bytes =~ s/([0-9a-zA-Z]{2})/$1 /g; print "$lead_zeros$offset $bytes\n"; } }

answered 04 Jul '13, 16:04

Quadratic's gravatar image

Quadratic
1.9k6928
accept rate: 13%

edited 04 Jul '13, 16:04