Re: Header field with scaling factor/units?

[Hadriel Kaplan <hadriel.kaplan () oracle com>]

On Apr 9, 2014, at 7:16 PM, Guy Harris <guy () alum mit edu> wrote:

> We might want to add syntax so that, for a field with a scale factor of 0.5, we might have
>
>       wlan.rate = raw(22)
>
> or
>
>       wlan.rate = 11
>
> (no, that was not a randomly-chosen field example :-)).  Other suggestions for the syntax are welcome.

This may seem crazy, but you asked so... I've often thought it would be nice if the fields which have multiple 
representations and properties could be automatically handled such that display filter sub-names were automagically 
available/understood, such as the following for the single "wlan.rate" field:

wlan.rate        == 11
wlan.rate.value  == 11
wlan.rate.raw    == 22
wlan.rate.scale  == 0.5
wlan.rate.units  == "bps"
wlan.rate.exists == TRUE
...

In other words, either have the display filter mechanism automatically understand those last tokens... or have the 
header_field_info registration mechanism auto-create them, and have the proto_add_item routines automatically add them 
in the tree as well. (as a sub-tree, so you could expand the field to see the detailed info, and no explicit dissector 
C-code needs to be written to add those fields or subtree items)

The point is they just feel like inherent properties/attributes of the field, as if the field were an object with 
members. (a la C++, Java, etc.)

And furthermore we should be able to create a new ftype of FT_URI, such that for a field named "http.request.uri", it 
should automagically enable me to do stuff like this:

http.request.uri == "http://wiki.wireshark.org/DisplayFilters";
http.request.uri.scheme != "https"
http.request.uri.port   == 80
http.request.uri.path   == "DisplayFilters"
http.request.uri.host   == "wiki.wireshark.org"

... and even this crazy idea:
*.uri.host == "wiki.wireshark.org"  // matches in any URI's host
*.uri.host contains "wireshark"     // matches in any URI's host

Obviously it doesn't make sense to do this for every complex field, but URIs happen to be common in multiple protocols; 
though sadly their structure might not be similar enough across protocols to warrant generalizing.

-hadriel

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