Re: More issues with network monitor 3.3 traces

[Guy Harris <guy () alum mit edu>]

On Jul 21, 2010, at 9:49 PM, noah davids wrote:

> Well I downloaded Version 1.5.0-SVN-33606 (SVN Rev 33606 from /trunk) and 
> was able to read and decode the first network monitor 3.3 trace but not 
> another. The second gives me the error "The capture file has a packet with a 
> network a network type Wireshark doesn't support. (netmon: network type 0 
> unknown or unsupported)."

According to the help file for Network Monitor 3.4, network type 0 *IS* unknown.

We'd need to see the capture file in question to see what the problem is.

> Also I discovered the following when displaying the first trace. I have a 
> display filter of "ssl" and the TCP preference "Validate the TCP checksum if 
> possible" is checked

        ...

> But when I uncheck the TCP preference "Validate the TCP checksum if 
> possible" the trace changes to

        ...

> Why should validating the checksum change the interpretation of the data?

If the interface does TCP checksum offloading, the TCP checksum on outgoing frames, as it appears in capture files, 
will not be valid, because the packet will be given to the capture mechanism before it's given to the network adapter, 
and the host will *NOT* compute the checksum (because it'll leave that up to the network adapter), so the checksum will 
appear to be bad even though, on the network, it's presumably valid.

The TCP dissector won't reassemble packets that don't have a valid checksum.  If the checksum isn't checked, however, 
it will reassemble them.
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe