Joerg Mayer wrote:
As mentioned a few months ago: an SSID is specified in 802.11 as octets.
As also menitoned before: Most SSIDs I've come across do tend to contain
ASCII characters for most if not all octets.
I guess my question should have been
for SSIDs, should it check whether all characters in the SSID are
printable and, if so, display it as text, otherwise display it as hex?
In this specific instance, I consider '.' to be the better solution - as
it makes traces easier for me to read in a vast majority of cases.
Whether this should be changed in all places: I don't know. The only
other place where I ever noticed this as maybe a bit unreadable are the
"radius passwords". I think the people using these dissectors
should decide this on a case by case basis.
If it should be decided on a case-by-case-basis, then, instead of people
rolling their own code (or cutting and pasting existing code) to do
that, perhaps
1) there should be a flag to "format_text()" and "tvb_format_text()" to
specify how it should treat non-printable characters;
2) the "display" member of header_field_info should, for string fields,
have a flag to specify how to treat non-printable characters.
Also mentioned before: The display as ASCII is just a convenient thing
for most people living in areas where a latin alphabet is used. In
other areas of the world - this display will be worthless. Maybe if
soneone feels like it, an option to interpret octet fields as ascii,
latin1, utf-8 ..... could be added to the general preferences.
(Presumably you mean "string fields"; there are many octet fields that
are explicitly binary and that don't contain text.)
Strings should be interpreted in the appropriate encoding. Some strings
have encodings defined by the protocol (e.g., 2-byte little-endian
Unicode, UTF-8), and some strings have encodings defined by, in effect,
convention (e.g., "OEM character set" strings in SMB, where the
convention is the locale the machines are in), where the convention might
1) differ from field to field
and
2) possibly even differ for the *same* field from capture to capture
(or even packet to packet).
Thus, the option would perhaps be per-field or per-protocol, e.g. an SMB
option to select the encoding for "OEM character set" fields.
See my notes on this in the first entry in "Dissector infrastructure" on
the page at
http://wiki.ethereal.com/Development_2fWishlist
Until such a time, I'd be happy to have the interpretation as ASCII back :-)
The interpretation of which field? Currently, printable characters in
the SSID are interpreted as ASCII text, so it's not as if that
interpretation can be "had back".
