On Sat, 22 Aug 2015 23:57:54 +0200
"tilt!" <tilt@???> wrote:
> Hello,
>
> it has come to my attention that an SSID is defined by a
> (closed) IEEE standard as (I quote inofficial source [1]):
>
> > [...] "0-32 octets with arbitrary contents. A 0-length
> > SSID indicates the wildcard SSID (in probe request
> > frames for instance)"
>
> This means that
>
> #1 SSIDs can have length zero.
> #2 SSIDs can contain the zerobyte.
>
> In the context of the CLI Back-En's (E)SSID encoder, this has
> the following consequences:
>
> a) I refuse to support case #1. It is a special case that
> to the extent of my knowledge only has use in special
> purpose frames exchanged in procedures of broadcasting
> or ad-hoc networking.
>
> If someone shows me otherwise, I will reconsider;
> it's of course not impossible to support it, just
> additional effort.
>
> b) I am currently unable to support case #2, because the
> frontend does not pass the information "length of the
> SSID" to the backend. Instead it passes ans an entry
> of argv[] a C-type string which is a sequence of nonzero
> bytes terminated by a zerobyte. Thus, the backend is not
> capable of receiveing an SSID completely that contains
> the zerobyte, and furthermore, the backend had no way of
> determining the actual length of the SSID in bytes.
>
> Ceterum censeo standards should be open.
If somebody's silly enough to put nullbytes in their ESSID or have it
blank (as opposed to not advertised), then I don't want to use their
silly setup. I think it's perfectly fine not to support those two IMHO
ridiculous situations.
SteveT
Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
::
Re: [DNG] CLI backend: (E)SSID issu…
