2015-06-25 16:13:06

by Joerg

[permalink] [raw]
Subject: iw and non-ASCII SSIDs

Hello all,
is there a way to submit a non-ASCII SSID with iw? One that contains 0 as in
an octet with value zero?

regards
Joerg



2015-06-25 18:10:57

by Johannes Berg

[permalink] [raw]
Subject: Re: iw and non-ASCII SSIDs

On Thu, 2015-06-25 at 16:12 +0000, Joerg wrote:
> Hello all,
> is there a way to submit a non-ASCII SSID with iw? One that contains
> 0 as in an octet with value zero?

No, that doesn't seem to be possible in the code.

But it's certainly possible in wp_supplicant config file, which you
should probably be using anyway?

johannes

2015-06-26 08:50:48

by Johannes Berg

[permalink] [raw]
Subject: Re: iw and non-ASCII SSIDs

On Thu, 2015-06-25 at 20:50 +0000, Joerg wrote:
> Johannes Berg <johannes@...> writes:
>
> >
> > On Thu, 2015-06-25 at 16:12 +0000, Joerg wrote:
> > > Hello all,
> > > is there a way to submit a non-ASCII SSID with iw? One that
> > > contains
> > > 0 as in an octet with value zero?
> >
> > No, that doesn't seem to be possible in the code.
> >
> > But it's certainly possible in wp_supplicant config file, which you
> > should probably be using anyway?
> >
> > johannes
>
> That's what I thought from looking at the code, too.
>
> And no, this is for an IBSS network that uses an IPsec overlay for
> security.
> It doesn't use wpa_supplicant and changing the code that way would be
> a major
> hassle.
>
> I would volunteer to change iw to accept a hex encoded binary blob as
> SSID.
> What commandline would be acceptable?

Well I guess you're not interested in "connect" but rather "ibss join"
then.

We *could* break backward compatibility and say that if you pass "\x00"
it's no longer interpreted as the bytes 5c 78 30 30 but rather as the
byte 00, but I'm not sure we should?

OTOH, what choice do we really have - the only other option would be to
add a command line flag indicating that this behaviour is desired?

johannes

2015-06-26 11:58:35

by Antonio Quartulli

[permalink] [raw]
Subject: Re: iw and non-ASCII SSIDs



On 26/06/15 10:50, Johannes Berg wrote:
>
> OTOH, what choice do we really have - the only other option would be to
> add a command line flag indicating that this behaviour is desired?

Why not just using wpa_supplicant with key_mgmt=NONE ? It can handle the
case where no encryption is required.

From your previous email I understood that it already supports hex
SSIDs, therefore this should probably work, I guess. Has somebody tried
this ?

This way there is no need to break/extend any other tool.

Cheers,


--
Antonio Quartulli


Attachments:
signature.asc (819.00 B)
OpenPGP digital signature

2015-06-25 20:50:34

by Joerg

[permalink] [raw]
Subject: Re: iw and non-ASCII SSIDs

Johannes Berg <johannes@...> writes:

>
> On Thu, 2015-06-25 at 16:12 +0000, Joerg wrote:
> > Hello all,
> > is there a way to submit a non-ASCII SSID with iw? One that contains
> > 0 as in an octet with value zero?
>
> No, that doesn't seem to be possible in the code.
>
> But it's certainly possible in wp_supplicant config file, which you
> should probably be using anyway?
>
> johannes

That's what I thought from looking at the code, too.

And no, this is for an IBSS network that uses an IPsec overlay for security.
It doesn't use wpa_supplicant and changing the code that way would be a major
hassle.

I would volunteer to change iw to accept a hex encoded binary blob as SSID.
What commandline would be acceptable?

Regards
Joerg




2015-06-29 08:23:38

by Johannes Berg

[permalink] [raw]
Subject: Re: iw and non-ASCII SSIDs

[please don't use HTML]

On Mon, 2015-06-29 at 08:17 +0000, Joerg Pommnitz wrote:
> We don't have to break compatibility. The commandline syntax of iw is
> iw [options] command
> My suggestion would be a new option "--binary-ssid" that sets a flag
> and causes all SSID to be treated as a hex encoded binary blob:
> iw --binary-ssid dev wlan0 ibss join 0034AA 2412
> and for consistency
> iw --binary-ssid dev wlan0 connect 0034AA
>
> Alternatively the option could be "--escaped-ssid" that would
> activate an escape processing for the SSID as you suggested. My
> preference is "--binary-ssid", because I'm always a little bit unsure
> what actually arrives in the program after the shell has done its own
> escape processing.
>


Yeah, that seems reasonable, though perhaps easier to do as

iw dev wlan0 ibss join --binary-ssid 0034AA 2412

since options before the command are treated as generic iw options.

Then again, if all places that use an SSID were to use a
"parse_ssid(argv[7])" function then the former could also be
implemented.

johannes

2015-06-29 16:59:01

by Paul Stewart

[permalink] [raw]
Subject: Re: iw and non-ASCII SSIDs

On Mon, Jun 29, 2015 at 1:23 AM, Johannes Berg
<[email protected]> wrote:
>
> [please don't use HTML]
>
> On Mon, 2015-06-29 at 08:17 +0000, Joerg Pommnitz wrote:
> > We don't have to break compatibility. The commandline syntax of iw is
> > iw [options] command
> > My suggestion would be a new option "--binary-ssid" that sets a flag
> > and causes all SSID to be treated as a hex encoded binary blob:
> > iw --binary-ssid dev wlan0 ibss join 0034AA 2412


Technically, I'd call this "--hex-ssid" considering the actual encoding
shown.

>
> > and for consistency
> > iw --binary-ssid dev wlan0 connect 0034AA
> >
> > Alternatively the option could be "--escaped-ssid" that would
> > activate an escape processing for the SSID as you suggested. My
> > preference is "--binary-ssid", because I'm always a little bit unsure
> > what actually arrives in the program after the shell has done its own
> > escape processing.
> >
>
>
> Yeah, that seems reasonable, though perhaps easier to do as
>
> iw dev wlan0 ibss join --binary-ssid 0034AA 2412
>
> since options before the command are treated as generic iw options.
>
> Then again, if all places that use an SSID were to use a
> "parse_ssid(argv[7])" function then the former could also be
> implemented.
>
> johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html