ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Evan Huus <eapache@xxxxxxxxx>
Date: Thu, 1 Oct 2015 09:10:34 -0400

On Oct 1, 2015, at 08:35, mmann78@xxxxxxxxxxxx wrote:

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?
 

I don't think so. You can use an FT_UINT32 and just tweak the dfilter grammar to recognize /## as a shortcut for integers generally.

 
-----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
___________________________________________________________________________
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