Wireshark · Wireshark-dev: Re: [Wireshark-dev] Should an IPv4 netmask be its own fieldtype?

[mmann78@xxxxxxxxxxxx]

But doesn't any of these potential representations (mostly network prefix) require a specific field type (and not a display type) for display filtering purposes?

 

 

-----Original Message-----
From: Jeffrey Smith <whydoubt@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Thu, Oct 1, 2015 1:46 am
Subject: Re: [Wireshark-dev] Should an IPv4 netmask be its own fieldtype?

RFC950: "Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address."

So essentially any mask IS legal (even if not recommended).

The two standard subnets notations are dotted decimal (e.g. 255.255.255.0) and network prefix (e.g. /24).  So recognizing just "24" may not be terrible, but I find no precedent for doing so.

On Sep 30, 2015 11:03 PM, "Guy Harris" <guy@xxxxxxxxxxxx> wrote:

On Sep 30, 2015, at 9:00 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

> A pure netmask (without an associated address) is representable as
> just a UINT8. Would it be terrible to write `protocolXYZ.netmask ==
> 24`?

Some are sent over the wire as a 32-bit mask, which could, conceivably, have holes in the middle.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent
via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:   
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
            
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe