Hi Jean,
I have no idea where to send bug reports for iwlist so I'm mailing you
directly with CC to wireless-dev so others are aware.
Dan, for NM I suppose the right bug tracker would be redhats? I'm
offline as I'm writing this so I can't check.
Anyhow, the problem is that my landlord has an AP that broadcasts an
SSID with a 0xFC byte in it (supposedly an "ü" in windows). iwlist,
however, just prints
ESSID:"B
and nothing more (the SSID is B\xFC...). wpa_supplicant converts it to
an underscore in its output (B_...), and network-manager also seems to
not like it, though it doesn't display any networks right now. Might or
might not be related.
I think it shouldn't be displayed truncated, although it is probably not
possible to display it in a fashion that all shells will properly parse
and convert to the right binary before invoking iwconfig or such.
johannes
On Thu, 2007-09-13 at 09:11 +0200, Johannes Berg wrote:
> Ok. I'll have to do some more extensive tests but in my last test with
> zd1211 it wouldn't display anything. Might be a different issue, but
> scanning manually showed things.
Cool, I was totally wrong, seems the fact that it didn't display
anything was unrelated. I just tried again and NM 0.6.5 as shipped by
debian/unstable actually manages to display the ü umlaut that is
supposed to be the \xfc character.
Btw. Will there ever be a 0.7 release? :)
johannes
On Wed, Sep 12, 2007 at 11:22:52AM -0400, Dan Williams wrote:
> On Tue, 2007-09-11 at 18:07 +0200, Johannes Berg wrote:
> > Hi Jean,
> >=20
> > I have no idea where to send bug reports for iwlist so I'm mailing =
you
> > directly with CC to wireless-dev so others are aware.
> >=20
> > Dan, for NM I suppose the right bug tracker would be redhats? I'm
> > offline as I'm writing this so I can't check.
>=20
> NM 0.6.x and earlier (quite wrongly) treat the SSID as a string. Tha=
t
> has been fixed in 0.7 trunk, though we do need to make sure that NM
> 0.6.x and earlier don't puke with it.
>=20
> SSID conversion is really, really tricky, and NM tries a few things t=
o
> coerce the SSID to UTF-8, including trying your LANG encoding if it
> exists. None of these methods work reliably though.
I personally can't see how we could figure out the encoding,
because we are talking of other's people network. It would have been
nice for IEEE 802.11 to specify something, but it's now probably too
late, as each vendor did his own stuff.
Where it's get even weirder is that special characters don't
seem to be forbidden either, such as NUL, and all the control
character. There is no way we are going to print them properly.
> Any suggestions?
Print them in hex ? URL encoding ?
> Obviously NM needs to be fixed.
>=20
> > Anyhow, the problem is that my landlord has an AP that broadcasts a=
n
> > SSID with a 0xFC byte in it (supposedly an "=FC" in windows). iwlis=
t,
> > however, just prints
> >=20
> > ESSID:"B
>=20
> iwlist just stuffs the SSID into a null-terminated buffer and prints =
it,
> it doesn't try to do any cleanup of the SSID at all.
Up to now, it never had been an issue. I made sure it would be
possible to implement a more clever ESSID display routine, but never
did it. It's not terribly complex to implement, but we need to decide
how we do it.
Note that ideally, we should also do the same with regards to
setting an ESSID. And all the /proc files of the various drivers may
want to be sanitized (yuck).
> Dan
>=20
> > and nothing more (the SSID is B\xFC...). wpa_supplicant converts it=
to
> > an underscore in its output (B_...),
That would not be my prefered solution.
> > and network-manager also seems to
> > not like it, though it doesn't display any networks right now. Migh=
t or
> > might not be related.
> >=20
> > I think it shouldn't be displayed truncated, although it is probabl=
y not
> > possible to display it in a fashion that all shells will properly p=
arse
> > and convert to the right binary before invoking iwconfig or such.
One way would be to check if the ESSID is Ascii, and if it's
not, display it entirely in hex with a leading 0x. Then, iwconfig
would recognise the leading 0x and do the right stuff.
The problem with escaping is that you always have to escape
the escape sequence, otherwise you get ambiguity.
Jean
On Tue, Sep 18, 2007 at 12:15:22PM +0200, Johannes Berg wrote:
> On Mon, 2007-09-17 at 17:36 -0700, Jean Tourrilhes wrote:
>
> > > Yeah, I don't think they cared for non-ascii at the time.
> >
> > There were not concerned about UI, witness the mess in
> > specifying WEP keys (do you want passphrase with that ?).
>
> Is passphrase actually specified in 802.11? I always thought it was some
> external hashing but didn't look it up.
Yes, it's some external hashing, and if I remember there is at
least two variants of it.
> But yes, I don't think in 1999
> many people cared about general UIs...
>
> > I'm talking of all driver that have their own private API :
> > --------------------------------
> > # cat /proc/driver/aironet/eth0/SSID
> > MY_ESSID
> > --------------------------------
>
> Oh. I didn't think that existed. Is there any point in that or could we
> just remove it?
I say we just ignore it, it mostly legacy drivers, and some
people may use it.
> > I forgot one little issue.
> > Remember all the fuss about the ESSID API change a long while
> > back ? The goal was to support ESSID a array of char as opposed to
> > ASCII strings in the API. There was a big fuss, and at that time John
> > did a backward compatibility hack to support the old API in the
> > kernel.
> > Well, the hack of John is broken on the receive side. It
> > basically prevents us to implement what you want, amongst other
> > things. This is what you currently get :
> > ---------------------------------------
> > >./iwconfig eth0
> > eth0 IEEE 802.11b ESSID:"my_essid\x00" Nickname:"HERMES I"
> > Mode:Managed Frequency:2.422 GHz Access Point: Not-Associated
> > Bit Rate:11 Mb/s Sensitivity:1/3
> > ---------------------------------------
>
> Hmmm. So we already \x00-escape the trailing NUL?
No, that's only in the brand new version of Wireless Tools
30.pre1 that include the escaping code. I coded that following your
suggestions, it includes full escaping in output and input. But now
I'm stuck because of that bug, I can't really distribute it.
> > I've already sent the patch to fix that to John, don't know
> > where it went :
> > http://marc.info/?t=118401941300001&r=1&w=2
> > I can resend you a copy if you want. I feel this patch ought
> > to go also in the various stable series.
>
> Probably got lost, you should probably resend and to -stable as well.
I'll do, but you seem much more efficient at getting stuff in
the kernel ;-)
> johannes
Regards,
Jean
On Tue, 2007-09-18 at 10:37 -0700, Jean Tourrilhes wrote:
> On Tue, Sep 18, 2007 at 12:15:22PM +0200, Johannes Berg wrote:
> > On Mon, 2007-09-17 at 17:36 -0700, Jean Tourrilhes wrote:
> >
> > > > Yeah, I don't think they cared for non-ascii at the time.
> > >
> > > There were not concerned about UI, witness the mess in
> > > specifying WEP keys (do you want passphrase with that ?).
> >
> > Is passphrase actually specified in 802.11? I always thought it was some
> > external hashing but didn't look it up.
>
> Yes, it's some external hashing, and if I remember there is at
> least two variants of it.
There are three: a) ASCII passphrase, b) MD5 passphrase (the most
popular), and c) Apple Airport password.
All three result in a different key for the same input.
Dan
> > But yes, I don't think in 1999
> > many people cared about general UIs...
> >
> > > I'm talking of all driver that have their own private API :
> > > --------------------------------
> > > # cat /proc/driver/aironet/eth0/SSID
> > > MY_ESSID
> > > --------------------------------
> >
> > Oh. I didn't think that existed. Is there any point in that or could we
> > just remove it?
>
> I say we just ignore it, it mostly legacy drivers, and some
> people may use it.
>
> > > I forgot one little issue.
> > > Remember all the fuss about the ESSID API change a long while
> > > back ? The goal was to support ESSID a array of char as opposed to
> > > ASCII strings in the API. There was a big fuss, and at that time John
> > > did a backward compatibility hack to support the old API in the
> > > kernel.
> > > Well, the hack of John is broken on the receive side. It
> > > basically prevents us to implement what you want, amongst other
> > > things. This is what you currently get :
> > > ---------------------------------------
> > > >./iwconfig eth0
> > > eth0 IEEE 802.11b ESSID:"my_essid\x00" Nickname:"HERMES I"
> > > Mode:Managed Frequency:2.422 GHz Access Point: Not-Associated
> > > Bit Rate:11 Mb/s Sensitivity:1/3
> > > ---------------------------------------
> >
> > Hmmm. So we already \x00-escape the trailing NUL?
>
> No, that's only in the brand new version of Wireless Tools
> 30.pre1 that include the escaping code. I coded that following your
> suggestions, it includes full escaping in output and input. But now
> I'm stuck because of that bug, I can't really distribute it.
>
> > > I've already sent the patch to fix that to John, don't know
> > > where it went :
> > > http://marc.info/?t=118401941300001&r=1&w=2
> > > I can resend you a copy if you want. I feel this patch ought
> > > to go also in the various stable series.
> >
> > Probably got lost, you should probably resend and to -stable as well.
>
> I'll do, but you seem much more efficient at getting stuff in
> the kernel ;-)
>
> > johannes
>
> Regards,
>
> Jean
>
On Fri, 2007-09-14 at 14:33 -0400, Dan Williams wrote:
> For whatever reason, driving wpa_supplicant with D-Bus is a lot more
> reliable than talking to it over the unix domain socket. I've long
> suspected that's part of the issue with random failures of
> wpa_supplicant in situations where the results between NM-driven and
> plain wpa_supplicant are different.
Yeah, you mentioned that.
> Would be interesting to see some wpa_supplicant debug output from Ben's
> machine though to see where it's failing and what info NM is pushing to
> it.
Except it's not Ben but David and it's a lot harder to coerce useful
output from him when he's in Spain ;)
Though I can ask him to try and then send me the syslog.
johannes
On Fri, 2007-09-14 at 14:09 -0400, Dan Williams wrote:
> I've been burning the midnight oil on it for the past few weeks, check
> NM and applet changelogs. Still not quite there yet, there's some core
> work left to do getting NM to talk to the settings daemons (ie,
> nm-client or knetworkmanager) correctly, getting GUI bits for Connection
> editing in the applet, and making sure the relevant settings are
> honored.
Great, good to know. There are various quirks in 0.6.5, my brother tells
me for example that it's impossible to log on to an _open_ network at
the university where he currently is while it works fine with iwconfig.
Some other things too, my wpa network at home never works with nm and I
was never able to determine why...
johannes
On Tue, 2007-09-11 at 18:07 +0200, Johannes Berg wrote:
> Hi Jean,
>=20
> I have no idea where to send bug reports for iwlist so I'm mailing yo=
u
> directly with CC to wireless-dev so others are aware.
>=20
> Dan, for NM I suppose the right bug tracker would be redhats? I'm
> offline as I'm writing this so I can't check.
NM 0.6.x and earlier (quite wrongly) treat the SSID as a string. That
has been fixed in 0.7 trunk, though we do need to make sure that NM
0.6.x and earlier don't puke with it.
SSID conversion is really, really tricky, and NM tries a few things to
coerce the SSID to UTF-8, including trying your LANG encoding if it
exists. None of these methods work reliably though.
Any suggestions?
Obviously NM needs to be fixed.
> Anyhow, the problem is that my landlord has an AP that broadcasts an
> SSID with a 0xFC byte in it (supposedly an "=C3=BC" in windows). iwli=
st,
> however, just prints
>=20
> ESSID:"B
iwlist just stuffs the SSID into a null-terminated buffer and prints it=
,
it doesn't try to do any cleanup of the SSID at all.
Dan
> and nothing more (the SSID is B\xFC...). wpa_supplicant converts it t=
o
> an underscore in its output (B_...), and network-manager also seems t=
o
> not like it, though it doesn't display any networks right now. Might =
or
> might not be related.
>=20
> I think it shouldn't be displayed truncated, although it is probably =
not
> possible to display it in a fashion that all shells will properly par=
se
> and convert to the right binary before invoking iwconfig or such.
>=20
> johannes
On Mon, 2007-09-17 at 17:36 -0700, Jean Tourrilhes wrote:
> > Yeah, I don't think they cared for non-ascii at the time.
>
> There were not concerned about UI, witness the mess in
> specifying WEP keys (do you want passphrase with that ?).
Is passphrase actually specified in 802.11? I always thought it was some
external hashing but didn't look it up. But yes, I don't think in 1999
many people cared about general UIs...
> I'm talking of all driver that have their own private API :
> --------------------------------
> # cat /proc/driver/aironet/eth0/SSID
> MY_ESSID
> --------------------------------
Oh. I didn't think that existed. Is there any point in that or could we
just remove it?
> I forgot one little issue.
> Remember all the fuss about the ESSID API change a long while
> back ? The goal was to support ESSID a array of char as opposed to
> ASCII strings in the API. There was a big fuss, and at that time John
> did a backward compatibility hack to support the old API in the
> kernel.
> Well, the hack of John is broken on the receive side. It
> basically prevents us to implement what you want, amongst other
> things. This is what you currently get :
> ---------------------------------------
> >./iwconfig eth0
> eth0 IEEE 802.11b ESSID:"my_essid\x00" Nickname:"HERMES I"
> Mode:Managed Frequency:2.422 GHz Access Point: Not-Associated
> Bit Rate:11 Mb/s Sensitivity:1/3
> ---------------------------------------
Hmmm. So we already \x00-escape the trailing NUL?
> I've already sent the patch to fix that to John, don't know
> where it went :
> http://marc.info/?t=118401941300001&r=1&w=2
> I can resend you a copy if you want. I feel this patch ought
> to go also in the various stable series.
Probably got lost, you should probably resend and to -stable as well.
johannes
On Fri, 2007-09-14 at 20:25 +0200, Johannes Berg wrote:
> On Fri, 2007-09-14 at 14:09 -0400, Dan Williams wrote:
>
> > I've been burning the midnight oil on it for the past few weeks, check
> > NM and applet changelogs. Still not quite there yet, there's some core
> > work left to do getting NM to talk to the settings daemons (ie,
> > nm-client or knetworkmanager) correctly, getting GUI bits for Connection
> > editing in the applet, and making sure the relevant settings are
> > honored.
>
> Great, good to know. There are various quirks in 0.6.5, my brother tells
> me for example that it's impossible to log on to an _open_ network at
> the university where he currently is while it works fine with iwconfig.
> Some other things too, my wpa network at home never works with nm and I
> was never able to determine why...
For whatever reason, driving wpa_supplicant with D-Bus is a lot more
reliable than talking to it over the unix domain socket. I've long
suspected that's part of the issue with random failures of
wpa_supplicant in situations where the results between NM-driven and
plain wpa_supplicant are different.
Would be interesting to see some wpa_supplicant debug output from Ben's
machine though to see where it's failing and what info NM is pushing to
it.
Dan
On Thu, Sep 13, 2007 at 09:11:36AM +0200, Johannes Berg wrote:
>
> > [Jean]
> > I personally can't see how we could figure out the encoding,
> > because we are talking of other's people network. It would have been
> > nice for IEEE 802.11 to specify something, but it's now probably too
> > late, as each vendor did his own stuff.
>
> Yeah, I don't think they cared for non-ascii at the time.
There were not concerned about UI, witness the mess in
specifying WEP keys (do you want passphrase with that ?).
> > Note that ideally, we should also do the same with regards to
> > setting an ESSID. And all the /proc files of the various drivers may
> > want to be sanitized (yuck).
>
> I thought it all went through some common code?
I'm talking of all driver that have their own private API :
--------------------------------
# cat /proc/driver/aironet/eth0/SSID
MY_ESSID
--------------------------------
> > One way would be to check if the ESSID is Ascii, and if it's
> > not, display it entirely in hex with a leading 0x. Then, iwconfig
> > would recognise the leading 0x and do the right stuff.
> > The problem with escaping is that you always have to escape
> > the escape sequence, otherwise you get ambiguity.
>
> Yeah, that's the thing. I don't like displaying it entirely in hex just
> because a single character is not ascii though. I think we should
> display as much in ascii as possible. Maybe a regular \xAA conversion
> would be appropriate as having a backslash in an SSID is probably less
> common than using Umlauts or even Chinese.
I forgot one little issue.
Remember all the fuss about the ESSID API change a long while
back ? The goal was to support ESSID a array of char as opposed to
ASCII strings in the API. There was a big fuss, and at that time John
did a backward compatibility hack to support the old API in the
kernel.
Well, the hack of John is broken on the receive side. It
basically prevents us to implement what you want, amongst other
things. This is what you currently get :
---------------------------------------
>./iwconfig eth0
eth0 IEEE 802.11b ESSID:"my_essid\x00" Nickname:"HERMES I"
Mode:Managed Frequency:2.422 GHz Access Point: Not-Associated
Bit Rate:11 Mb/s Sensitivity:1/3
---------------------------------------
I've already sent the patch to fix that to John, don't know
where it went :
http://marc.info/?t=118401941300001&r=1&w=2
I can resend you a copy if you want. I feel this patch ought
to go also in the various stable series.
> johannes
Have fun...
Jean
Let me reply to both of your mails at once.
> > [Dan]
> > NM 0.6.x and earlier (quite wrongly) treat the SSID as a string. That
> > has been fixed in 0.7 trunk, though we do need to make sure that NM
> > 0.6.x and earlier don't puke with it.
Ok. I'll have to do some more extensive tests but in my last test with
zd1211 it wouldn't display anything. Might be a different issue, but
scanning manually showed things.
> > SSID conversion is really, really tricky, and NM tries a few things to
> > coerce the SSID to UTF-8, including trying your LANG encoding if it
> > exists. None of these methods work reliably though.
Especially since I have UTF-8 LANG and this is some windows foo.
> [Jean]
> I personally can't see how we could figure out the encoding,
> because we are talking of other's people network. It would have been
> nice for IEEE 802.11 to specify something, but it's now probably too
> late, as each vendor did his own stuff.
Yeah, I don't think they cared for non-ascii at the time.
> Where it's get even weirder is that special characters don't
> seem to be forbidden either, such as NUL, and all the control
> character. There is no way we are going to print them properly.
True.
> Up to now, it never had been an issue. I made sure it would be
> possible to implement a more clever ESSID display routine, but never
> did it. It's not terribly complex to implement, but we need to decide
> how we do it.
Yeah.
> Note that ideally, we should also do the same with regards to
> setting an ESSID. And all the /proc files of the various drivers may
> want to be sanitized (yuck).
I thought it all went through some common code?
> > > [Johannes]
> > > and nothing more (the SSID is B\xFC...). wpa_supplicant converts it to
> > > an underscore in its output (B_...),
>
> That would not be my prefered solution.
No, especially since it's ambiguous if you want to use the SSID later.
> One way would be to check if the ESSID is Ascii, and if it's
> not, display it entirely in hex with a leading 0x. Then, iwconfig
> would recognise the leading 0x and do the right stuff.
> The problem with escaping is that you always have to escape
> the escape sequence, otherwise you get ambiguity.
Yeah, that's the thing. I don't like displaying it entirely in hex just
because a single character is not ascii though. I think we should
display as much in ascii as possible. Maybe a regular \xAA conversion
would be appropriate as having a backslash in an SSID is probably less
common than using Umlauts or even Chinese.
johannes
On Fri, 2007-09-14 at 21:12 +0200, dragoran wrote:
> Dan Williams wrote:
> > On Thu, 2007-09-13 at 20:18 +0200, Johannes Berg wrote:
> > =20
> >> On Thu, 2007-09-13 at 09:11 +0200, Johannes Berg wrote:
> >>
> >> =20
> >>> Ok. I'll have to do some more extensive tests but in my last test=
with
> >>> zd1211 it wouldn't display anything. Might be a different issue, =
but
> >>> scanning manually showed things.
> >>> =20
> >> Cool, I was totally wrong, seems the fact that it didn't display
> >> anything was unrelated. I just tried again and NM 0.6.5 as shipped=
by
> >> debian/unstable actually manages to display the =C3=BC umlaut that=
is
> >> supposed to be the \xfc character.
> >>
> >> Btw. Will there ever be a 0.7 release? :)
> >> =20
> >
> > I've been burning the midnight oil on it for the past few weeks, ch=
eck
> > NM and applet changelogs. Still not quite there yet, there's some =
core
> > work left to do getting NM to talk to the settings daemons (ie,
> > nm-client or knetworkmanager) correctly, getting GUI bits for Conne=
ction
> > editing in the applet, and making sure the relevant settings are
> > honored.
> > =20
> might be a bit OT but:
> are you still planning to include it in F8 ? seems that the snapshot=20
> didn't make it into test2 ..
There was a snapshot queued, but it really sucked, and was thankfully
dropped. Look for something in rawhide this week that actually works.
Dan
Dan Williams wrote:
> On Fri, 2007-09-14 at 21:12 +0200, dragoran wrote:
> =20
>> Dan Williams wrote:
>> =20
>>> On Thu, 2007-09-13 at 20:18 +0200, Johannes Berg wrote:
>>> =20
>>> =20
>>>> On Thu, 2007-09-13 at 09:11 +0200, Johannes Berg wrote:
>>>>
>>>> =20
>>>> =20
>>>>> Ok. I'll have to do some more extensive tests but in my last test=
with
>>>>> zd1211 it wouldn't display anything. Might be a different issue, =
but
>>>>> scanning manually showed things.
>>>>> =20
>>>>> =20
>>>> Cool, I was totally wrong, seems the fact that it didn't display
>>>> anything was unrelated. I just tried again and NM 0.6.5 as shipped=
by
>>>> debian/unstable actually manages to display the =C3=BC umlaut that=
is
>>>> supposed to be the \xfc character.
>>>>
>>>> Btw. Will there ever be a 0.7 release? :)
>>>> =20
>>>> =20
>>> I've been burning the midnight oil on it for the past few weeks, ch=
eck
>>> NM and applet changelogs. Still not quite there yet, there's some =
core
>>> work left to do getting NM to talk to the settings daemons (ie,
>>> nm-client or knetworkmanager) correctly, getting GUI bits for Conne=
ction
>>> editing in the applet, and making sure the relevant settings are
>>> honored.
>>> =20
>>> =20
>> might be a bit OT but:
>> are you still planning to include it in F8 ? seems that the snapshot=
=20
>> didn't make it into test2 ..
>> =20
>
> There was a snapshot queued, but it really sucked, and was thankfully
> dropped.=20
ok I noticed thats broken after getting it from koji ...
> Look for something in rawhide this week that actually works.
>
> =20
ok :)
Dan Williams wrote:
> On Thu, 2007-09-13 at 20:18 +0200, Johannes Berg wrote:
> =20
>> On Thu, 2007-09-13 at 09:11 +0200, Johannes Berg wrote:
>>
>> =20
>>> Ok. I'll have to do some more extensive tests but in my last test w=
ith
>>> zd1211 it wouldn't display anything. Might be a different issue, bu=
t
>>> scanning manually showed things.
>>> =20
>> Cool, I was totally wrong, seems the fact that it didn't display
>> anything was unrelated. I just tried again and NM 0.6.5 as shipped b=
y
>> debian/unstable actually manages to display the =C3=BC umlaut that i=
s
>> supposed to be the \xfc character.
>>
>> Btw. Will there ever be a 0.7 release? :)
>> =20
>
> I've been burning the midnight oil on it for the past few weeks, chec=
k
> NM and applet changelogs. Still not quite there yet, there's some co=
re
> work left to do getting NM to talk to the settings daemons (ie,
> nm-client or knetworkmanager) correctly, getting GUI bits for Connect=
ion
> editing in the applet, and making sure the relevant settings are
> honored.
> =20
might be a bit OT but:
are you still planning to include it in F8 ? seems that the snapshot=20
didn't make it into test2 ..
On Thu, 2007-09-13 at 20:18 +0200, Johannes Berg wrote:
> On Thu, 2007-09-13 at 09:11 +0200, Johannes Berg wrote:
>=20
> > Ok. I'll have to do some more extensive tests but in my last test w=
ith
> > zd1211 it wouldn't display anything. Might be a different issue, bu=
t
> > scanning manually showed things.
>=20
> Cool, I was totally wrong, seems the fact that it didn't display
> anything was unrelated. I just tried again and NM 0.6.5 as shipped by
> debian/unstable actually manages to display the =C3=BC umlaut that is
> supposed to be the \xfc character.
>=20
> Btw. Will there ever be a 0.7 release? :)
I've been burning the midnight oil on it for the past few weeks, check
NM and applet changelogs. Still not quite there yet, there's some core
work left to do getting NM to talk to the settings daemons (ie,
nm-client or knetworkmanager) correctly, getting GUI bits for Connectio=
n
editing in the applet, and making sure the relevant settings are
honored.
Dan
On Mon, Oct 15, 2007 at 05:57:11PM -0700, Jean Tourrilhes wrote:
> On Tue, Sep 11, 2007 at 06:07:53PM +0200, Johannes Berg wrote:
> > Hi Jean,
>=20
> Hi again,
>=20
> > Anyhow, the problem is that my landlord has an AP that broadcasts a=
n
> > SSID with a 0xFC byte in it (supposedly an "=FC" in windows). iwlis=
t,
> > however, just prints
> >=20
> > ESSID:"B
>=20
> You remember that problem ? Well, we now have a new version of
> Wireless Tools that support that. However, this is blocked because th=
e
> necessary kernel patch has not gone yet in the kernel.
> I've sent the patch to John twice, with you in cc for the last
> occurence. It seems that John for some reason does not receive e-mail
> from me, or something else. This was the last time :
> http://marc.info/?l=3Dlinux-wireless&m=3D119022849315111&w=3D2
> So, would you mind pushing yourself this patch to John ?
> Thanks in advance...
>=20
> Jean
>=20
> Signed-off-by: Jean Tourrilhes <[email protected]>
Jean, you can keep whining and complaining. But you never address
the issue of preserving the userland ABI. Simply releasing a new,
smarter, better wireless-tools does not change the situation.
Because of the confusion in SSID handling when WEXT was defined,
WEXT is just never going to support a 32-byte SSID unless it happens
to end in a NULL. Sorry.
I don't see how the patch you wish to revert has anything to do with
the umlaut issue. If it does, please explain how or feel free to
propose a patch that corrects it while still preserving the userland
ABI.
John
P.S. Please note that the userland ABI concern is not some pet issue
for me. This comes from the community at large, including Linus,
Jeff Garzik, and other notable contributors.
--=20
John W. Linville
[email protected]
On Tue, Sep 11, 2007 at 06:07:53PM +0200, Johannes Berg wrote:
> Hi Jean,
Hi again,
> Anyhow, the problem is that my landlord has an AP that broadcasts an
> SSID with a 0xFC byte in it (supposedly an "=FC" in windows). iwlist,
> however, just prints
>=20
> ESSID:"B
You remember that problem ? Well, we now have a new version of
Wireless Tools that support that. However, this is blocked because the
necessary kernel patch has not gone yet in the kernel.
I've sent the patch to John twice, with you in cc for the last
occurence. It seems that John for some reason does not receive e-mail
from me, or something else. This was the last time :
http://marc.info/?l=3Dlinux-wireless&m=3D119022849315111&w=3D2
So, would you mind pushing yourself this patch to John ?
Thanks in advance...
Jean
Signed-off-by: Jean Tourrilhes <[email protected]>
-----------------------------------------------------------
--- linux/net/wireless/wext.j1.c 2007-07-09 13:19:22.000000000 -0700
+++ linux/net/wireless/wext.c 2007-07-09 13:19:59.000000000 -0700
@@ -741,39 +741,11 @@ static int ioctl_standard_call(struct ne
int extra_size;
int user_length =3D 0;
int err;
- int essid_compat =3D 0;
=20
/* Calculate space needed by arguments. Always allocate
* for max space. Easier, and won't last long... */
extra_size =3D descr->max_tokens * descr->token_size;
=20
- /* Check need for ESSID compatibility for WE < 21 */
- switch (cmd) {
- case SIOCSIWESSID:
- case SIOCGIWESSID:
- case SIOCSIWNICKN:
- case SIOCGIWNICKN:
- if (iwr->u.data.length =3D=3D descr->max_tokens + 1)
- essid_compat =3D 1;
- else if (IW_IS_SET(cmd) && (iwr->u.data.length !=3D 0)) {
- char essid[IW_ESSID_MAX_SIZE + 1];
-
- err =3D copy_from_user(essid, iwr->u.data.pointer,
- iwr->u.data.length *
- descr->token_size);
- if (err)
- return -EFAULT;
-
- if (essid[iwr->u.data.length - 1] =3D=3D '\0')
- essid_compat =3D 1;
- }
- break;
- default:
- break;
- }
-
- iwr->u.data.length -=3D essid_compat;
-
/* Check what user space is giving us */
if (IW_IS_SET(cmd)) {
/* Check NULL pointer */
@@ -811,7 +783,6 @@ static int ioctl_standard_call(struct ne
}
=20
/* Create the kernel buffer */
- /* kzalloc ensures NULL-termination for essid_compat */
extra =3D kzalloc(extra_size, GFP_KERNEL);
if (extra =3D=3D NULL)
return -ENOMEM;
@@ -830,8 +801,6 @@ static int ioctl_standard_call(struct ne
/* Call the handler */
ret =3D handler(dev, &info, &(iwr->u), extra);
=20
- iwr->u.data.length +=3D essid_compat;
-
/* If we have something to return to the user */
if (!ret && IW_IS_GET(cmd)) {
/* Check if there is enough buffer up there */
On Tue, Oct 16, 2007 at 12:58:03PM -0400, John W. Linville wrote:
>
> Jean, you can keep whining and complaining. But you never address
> the issue of preserving the userland ABI. Simply releasing a new,
> smarter, better wireless-tools does not change the situation.
The old ABI has been deprecated for almost 2 years. Compare to
some other kernel ABI that change almost on a weekly basis, that's
quite stable. You will not find anything in the wild using the old
ABI.
> I don't see how the patch you wish to revert has anything to do with
> the umlaut issue.
Try Wireless Tools 30. That's the first version that support
the umlaut.
> If it does, please explain how or feel free to propose a patch that
> corrects it while still preserving the userland ABI.
It can not be done. The point is that the current hack in the
kernel is based on faulty assumptions, and therefore does not work as
advertised.
> John
>
> P.S. Please note that the userland ABI concern is not some pet issue
> for me. This comes from the community at large, including Linus,
> Jeff Garzik, and other notable contributors.
Unfortunately, it's only true with some subsystems, but not
all of them. If you go back to the original thread, the concern was
the minimise user disruption. The point Linus made is that ABI change
are not forbidden, we just need to make sure to minimise user
disruption.
Have fun...
Jean
On Tue, Oct 16, 2007 at 12:58:03PM -0400, John W. Linville wrote:
>
> Because of the confusion in SSID handling when WEXT was defined,
> WEXT is just never going to support a 32-byte SSID unless it happens
> to end in a NULL. Sorry.
Actually, you did not read the bug report and you are totally
wrong on that. We currently can not support 32-byte ESSID at all,
regardless of the NUL termination. Please try it.
Jean