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

WS does not check Ipv4-Header-Total-Length?

0

I'm working for years with WS and am really pleased with it, but now, I've found something astonishing, which I can not believe to be bug after all these years, it must be misconfiguration on my side (I hope):

PROBLEM:

Wireshark seems not to check the 'Total-Length' field of an IPv4 header!

DETAILS:

A kind of conformancetest sends ethernet frames with always the same IPv4/UDP payload. For test purpose, the testtool changes single fields of the IP header only, e.g. the IP-HDR-CRC (which is detected by WS). But if the 'Total Length' field of the IPv4 Header s varied (too-small/too-big), WS tells nothing - although WS should be able to detect it with the help of the overall content of the ethernet frames. Please note, that under Preferences/Protocols/IPv4 all options are enabled (although nothing applies to the header field 'total length'). I'm using WS Version 1.12.5.

TEST FRAMES:

I uploaded a capture with 7 corrupted testframes, where #4 + #6 are the relevant ones:

  • no.4 - IP-Header-Total-Length set to 197 (instead of 192)
  • no.6 - IP-Header-Total-Length set to 224 (instead of 192)

(Note: 'Validation' seems to disabled in CloudShare, so please download and open it in WS to see the corruptions (in Cloudshare/more info../File/Download.)

QUESTION:

Might this be a bug in WS - or do I only use wrong settings or assumptions?

asked 21 Jun '15, 23:50

Ralf%20S's gravatar image

Ralf S
6114
accept rate: 0%

edited 21 Jun '15, 23:51


One Answer:

0

The code has checking for various situations build in:

  1. Shorter than header size
  2. 0 (i.c.o. TSO)
  3. Adjustment of buffer

and a remark on what could cause the total header length to be larger than what's in the packet. This could have legitimate reasons, so an all-out error would be wrong. Reasons being:

  1. IP header in an ICMP packet
  2. frame cut short during capture.
  3. others?

Specific code would have to be added to differentiate these situations. A bug? Maybe, for sure an option for enhancement.

answered 22 Jun '15, 04:50

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

Thank you Jaap for that fast reply and glance into WS sources.

None three situations mentioned by you above (and implemented in WS) apply to the corrupted testframes. So it's currently not supported. And of course I understand the complexity of validation (reasons above).

As WS development is widely out of my focus and as I really like to trigger this as a WS enhancement - whom could I give a '+1' for this proposal?

(22 Jun '15, 06:23) Ralf S

See the wiki page Reporting Bugs for info on how to submit a bug (or enhancement request).

(22 Jun '15, 07:37) grahamb ♦

Ok, I added this as an enhancement to the WS Bug Tracker,

see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11296

(22 Jun '15, 08:04) Ralf S