> On Oct 1, 2015, at 08:35, mman...@netscape.net 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 <whydo...@gmail.com> > To: Developer support list for Wireshark <wireshark-dev@wireshark.org> > 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" <g...@alum.mit.edu> wrote: >> >> On Sep 30, 2015, at 9:00 PM, Evan Huus <eapa...@gmail.com> 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@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > ___________________________________________________________________________ > Sent > via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: > https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: > https://wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe