Dear all!
I have the following problem with wpa supplicant/ipw3945. First the
versions:
kernel: 2.6.18-mm2 (self compiled)
ieee80211: 1.1.14
ipw3945: git source
ipw3945d: 1.7.19
wpa supplicant: 0.5.5 (Debian/unstable 0.5.5-1)
Config file of wpa_supplicant:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
network={
ssid="norbunet"
key_mgmt=NONE
auth_alg=SHARED
wep_key0=HEXKEY1
wep_key1=HEXKEY2
wep_key2=HEXKEY3
wep_key3=HEXKEY4
wep_tx_keyidx=0
priority=5
}
When I start ipw3945d and wpa_supplicant it does not connect. And the
reason is that when typing
iwconfig eth2
(eth0 cable, eth1 not present!?!, eth2 ipw3945) I see that the ESSID is
set to
"norbune"
instead of
"norbunet"
Calling
iwconfig eth2 essid "norbunet "
(mind the space at the end) immediately connects (even with encryption)
and everything is working.
Do you have any idea what this might be related to?
The last kernel I tried which worked out of the box (well, with
comnpiling ieee and ipw) was 2.6.18-rc4.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Universit? di Siena
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
`I think you ought to know that I'm feeling very
depressed.'
`Life, don't talk to me about life.'
`Here I am, brain the size of a planet and they ask me to
take you down to the bridge. Call that "job satisfaction"?
'Cos I don't.'
`I've got this terrible pain in all the diodes down my
left side.'
--- Guess who.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
On 10/2/06, Norbert Preining <[email protected]> wrote:
> Dear all!
>
> I have the following problem with wpa supplicant/ipw3945. First the
> versions:
> kernel: 2.6.18-mm2 (self compiled)
> ieee80211: 1.1.14
> ipw3945: git source
> ipw3945d: 1.7.19
> wpa supplicant: 0.5.5 (Debian/unstable 0.5.5-1)
>
>
> Config file of wpa_supplicant:
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=0
> eapol_version=1
> ap_scan=1
> network={
> ssid="norbunet"
> key_mgmt=NONE
> auth_alg=SHARED
> wep_key0=HEXKEY1
> wep_key1=HEXKEY2
> wep_key2=HEXKEY3
> wep_key3=HEXKEY4
> wep_tx_keyidx=0
> priority=5
> }
>
> When I start ipw3945d and wpa_supplicant it does not connect. And the
> reason is that when typing
> iwconfig eth2
> (eth0 cable, eth1 not present!?!, eth2 ipw3945) I see that the ESSID is
> set to
> "norbune"
> instead of
> "norbunet"
>
> Calling
> iwconfig eth2 essid "norbunet "
> (mind the space at the end) immediately connects (even with encryption)
> and everything is working.
>
> Do you have any idea what this might be related to?
>
> The last kernel I tried which worked out of the box (well, with
> comnpiling ieee and ipw) was 2.6.18-rc4.
Hi Norbert,
we've been just through an email thread where it has been
determined that wpa_supplicant 0.4.9 (I would assume that
0.5.5 is also okay) and wireless-tools from Jean's latest
tarball are necessary to work with the recent wireless
extensions v21 that have been merged in.
What wireless-tools are you using ?
Ciao,
--alessandro
"Well a man has two reasons for things that he does
the first one is pride and the second one is love
all understandings must come by this way"
(Husker Du, 'She Floated Away')
On Mon, 02 Okt 2006, Alessandro Suardi wrote:
> we've been just through an email thread where it has been
> determined that wpa_supplicant 0.4.9 (I would assume that
> 0.5.5 is also okay) and wireless-tools from Jean's latest
> tarball are necessary to work with the recent wireless
> extensions v21 that have been merged in.
>
> What wireless-tools are you using ?
wireless-tools from Debian/unstable, version 28-1, so I assume wireless
v28. And the README tells the same. What would be the newest version?
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Universit? di Siena
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
FROLESWORTH (n.)
Measure. The minimum time it is necessary to spend frowning in deep
concentration at each picture in an art gallery in order that everyone
else doesn't think you've a complete moron.
--- Douglas Adams, The Meaning of Liff
On 10/2/06, Norbert Preining <[email protected]> wrote:
> On Mon, 02 Okt 2006, Alessandro Suardi wrote:
> > we've been just through an email thread where it has been
> > determined that wpa_supplicant 0.4.9 (I would assume that
> > 0.5.5 is also okay) and wireless-tools from Jean's latest
> > tarball are necessary to work with the recent wireless
> > extensions v21 that have been merged in.
> >
> > What wireless-tools are you using ?
>
> wireless-tools from Debian/unstable, version 28-1, so I assume wireless
> v28. And the README tells the same. What would be the newest version?
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/wireless_tools.29.pre10.tar.gz
which, from Jean's page, has the following:
The main features of the latest beta is WE-21 support (long/short
retry, power saving level, modulation), enhanced command line parser
in iwconfig, scanning options, more WPA support and more footprint
reduction tricks
Cheers,
--alessandro
"Well a man has two reasons for things that he does
the first one is pride and the second one is love
all understandings must come by this way"
(Husker Du, 'She Floated Away')
Hi all!
On Mon, 02 Okt 2006, Alessandro Suardi wrote:
> The main features of the latest beta is WE-21 support (long/short
> retry, power saving level, modulation), enhanced command line parser
> in iwconfig, scanning options, more WPA support and more footprint
> reduction tricks
Bingo. I build the new 29-pre10 and everything is working.
Thanks for the tip!
Now for the Debian bug report.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Universit? di Siena
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
LOCHRANZA (n.)
The long unaccomplished wail in the middle of a Scottish folk song
where the pipes nip around the corner for a couple of drinks.
--- Douglas Adams, The Meaning of Liff
On Mon, 2006-10-02 at 09:21 +0000, Alessandro Suardi wrote:
> we've been just through an email thread where it has been
> determined that wpa_supplicant 0.4.9 (I would assume that
> 0.5.5 is also okay) and wireless-tools from Jean's latest
> tarball are necessary to work with the recent wireless
> extensions v21 that have been merged in.
>
> What wireless-tools are you using ?
This must be considered a kernel bug - it's not allowed to break
userspace compatibility in a stable series.
Lee
On Mon, 02 Okt 2006, Norbert Preining wrote:
> > The main features of the latest beta is WE-21 support (long/short
> > retry, power saving level, modulation), enhanced command line parser
> > in iwconfig, scanning options, more WPA support and more footprint
> > reduction tricks
>
> Bingo. I build the new 29-pre10 and everything is working.
Sorry, that was over-optimistic. still same behaviour as with the Debian
v28 version.
The last character is cut of from wpa_supplicant. I have to set the
essid by hadn with
"real-essid "
mark the space at the end!
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <[email protected]> Universit? di Siena
Debian Developer <[email protected]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
MELCOMBE REGIS (n.)
The name of the style of decoration used in cocktail lounges in mock
Tudor hotels in Surrey.
--- Douglas Adams, The Meaning of Liff
On Mon, 2006-10-02 at 18:50 +0200, Norbert Preining wrote:
> On Mon, 02 Okt 2006, Norbert Preining wrote:
> > > The main features of the latest beta is WE-21 support (long/short
> > > retry, power saving level, modulation), enhanced command line parser
> > > in iwconfig, scanning options, more WPA support and more footprint
> > > reduction tricks
> >
> > Bingo. I build the new 29-pre10 and everything is working.
>
> Sorry, that was over-optimistic. still same behaviour as with the Debian
> v28 version.
>
> The last character is cut of from wpa_supplicant. I have to set the
> essid by hadn with
> "real-essid "
> mark the space at the end!
You have a mismatch between your wireless-tools, your kernel, and/or
wpa_supplicant. WE-21 uses the _real_ ssid length rather than the
kludge of hacking off the last byte used previously. Please ensure that
your tools, driver, and kernel are using WE-21.
'cat /proc/net/wireless' should tell you what your kernel is using.
Getting the driver WE is a bit harder and you may have to look at the
source.
Dan
>
> Best wishes
>
> Norbert
>
> -------------------------------------------------------------------------------
> Dr. Norbert Preining <[email protected]> Università di Siena
> Debian Developer <[email protected]> Debian TeX Group
> gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
> -------------------------------------------------------------------------------
> MELCOMBE REGIS (n.)
> The name of the style of decoration used in cocktail lounges in mock
> Tudor hotels in Surrey.
> --- Douglas Adams, The Meaning of Liff
> _______________________________________________
> HostAP mailing list
> [email protected]
> http://lists.shmoo.com/mailman/listinfo/hostap
On Mon, 02 Oct 2006 12:58:24 -0400
Dan Williams <[email protected]> wrote:
> On Mon, 2006-10-02 at 18:50 +0200, Norbert Preining wrote:
> > On Mon, 02 Okt 2006, Norbert Preining wrote:
> > > > The main features of the latest beta is WE-21 support (long/short
> > > > retry, power saving level, modulation), enhanced command line parser
> > > > in iwconfig, scanning options, more WPA support and more footprint
> > > > reduction tricks
> > >
> > > Bingo. I build the new 29-pre10 and everything is working.
> >
> > Sorry, that was over-optimistic. still same behaviour as with the Debian
> > v28 version.
> >
> > The last character is cut of from wpa_supplicant. I have to set the
> > essid by hadn with
> > "real-essid "
> > mark the space at the end!
>
> You have a mismatch between your wireless-tools, your kernel, and/or
> wpa_supplicant. WE-21 uses the _real_ ssid length rather than the
> kludge of hacking off the last byte used previously. Please ensure that
> your tools, driver, and kernel are using WE-21.
> 'cat /proc/net/wireless' should tell you what your kernel is using.
> Getting the driver WE is a bit harder and you may have to look at the
> source.
Jean, John: the amount of trouble which this change is causing is quite
high considering that we're not even at -rc1 yet. It's going to get worse.
It doesn't sound like it'll be too hard to arrange for the kernel to
continue to work correctly with old userspace?
On Mon, Oct 02, 2006 at 11:15:37AM -0700, Andrew Morton wrote:
> On Mon, 02 Oct 2006 12:58:24 -0400
> >
> > You have a mismatch between your wireless-tools, your kernel, and/or
> > wpa_supplicant. WE-21 uses the _real_ ssid length rather than the
> > kludge of hacking off the last byte used previously. Please ensure that
> > your tools, driver, and kernel are using WE-21.
> > 'cat /proc/net/wireless' should tell you what your kernel is using.
> > Getting the driver WE is a bit harder and you may have to look at the
> > source.
>
> Jean, John: the amount of trouble which this change is causing is quite
> high considering that we're not even at -rc1 yet. It's going to get worse.
We have to split between the different issues we have seen.
Tools issue (the wpa_supplicant problem). -> those can only be
fixed by people upgrading. Fortunately, there are not so many tools
affected, and new version of those tools were released last
April/May. As I said, most distro have those in the pipe.
In-Kernel driver issues (the Orinoco driver problem). -> those
can be patched and fixed as we go along. I would not worry about
those.
Out-of-kernel issues (the ipw3945 driver problem). -> those
drivers need to be updated. That's the problem of living outside the
kernel. Very often those drivers are reactive with respect to kernel
API changes, rather than pro-active, so there is not much we can do.
> It doesn't sound like it'll be too hard to arrange for the kernel to
> continue to work correctly with old userspace?
Actually, it's impossible. New userspace can work across both
version, old userspace fails on new version.
The whole point of the -rc process is to find problems and the
scope of it, there is no way I can know everything. At this point, we
can decide if WE-21 should go in 2.6.19 or wait for 2.6.20. But I know
that most Linux-Wireless people such as Dan and Jouni have been
waiting impatiently for those changes...
Have fun...
Jean
On Mon, 2006-10-02 at 11:55 -0700, Jean Tourrilhes wrote:
> On Mon, Oct 02, 2006 at 11:15:37AM -0700, Andrew Morton wrote:
> > On Mon, 02 Oct 2006 12:58:24 -0400
> > >
> > > You have a mismatch between your wireless-tools, your kernel, and/or
> > > wpa_supplicant. WE-21 uses the _real_ ssid length rather than the
> > > kludge of hacking off the last byte used previously. Please ensure that
> > > your tools, driver, and kernel are using WE-21.
> > > 'cat /proc/net/wireless' should tell you what your kernel is using.
> > > Getting the driver WE is a bit harder and you may have to look at the
> > > source.
> >
> > Jean, John: the amount of trouble which this change is causing is quite
> > high considering that we're not even at -rc1 yet. It's going to get worse.
>
> We have to split between the different issues we have seen.
> Tools issue (the wpa_supplicant problem). -> those can only be
> fixed by people upgrading. Fortunately, there are not so many tools
> affected, and new version of those tools were released last
> April/May. As I said, most distro have those in the pipe.
> In-Kernel driver issues (the Orinoco driver problem). -> those
> can be patched and fixed as we go along. I would not worry about
> those.
> Out-of-kernel issues (the ipw3945 driver problem). -> those
> drivers need to be updated. That's the problem of living outside the
> kernel. Very often those drivers are reactive with respect to kernel
> API changes, rather than pro-active, so there is not much we can do.
>
> > It doesn't sound like it'll be too hard to arrange for the kernel to
> > continue to work correctly with old userspace?
>
> Actually, it's impossible. New userspace can work across both
> version, old userspace fails on new version.
>
> The whole point of the -rc process is to find problems and the
> scope of it, there is no way I can know everything. At this point, we
> can decide if WE-21 should go in 2.6.19 or wait for 2.6.20. But I know
> that most Linux-Wireless people such as Dan and Jouni have been
> waiting impatiently for those changes...
Right; we need to get this settled and we need to figure out a way with
Wireless Extensions to allow exact SSIDs to be sent and retrieved from
the card/driver. How much cruft do we add to drivers and/or WE bits to
bend over backwards and preserve compatibility with a lot of older bits?
I can think of a few ways here to preserve backwards compat, but most
involve adding bits to 3 places in each driver and a new flag to WE,
which puts us right back in the same situation we're in right now;
inconsistent drivers and poor semantics both inside and outside the
kernel.
Maybe the answer here _is_ to bend over backwards to preserve
compatibility, restore null-termination-and-increment-length bits in
drivers and WE, and kludge all the user-space tools. Then just Do The
Right Thing with nl80211/cfg80211 (whenever they come around) and fix
stuff up in the nl80211 WE compat layer. I don't know. But nl80211
isn't here yet, and it's unclear when it will be.
Dan
> Have fun...
>
> Jean
On 10/2/06, Jean Tourrilhes <[email protected]> wrote:
> On Mon, Oct 02, 2006 at 11:15:37AM -0700, Andrew Morton wrote:
>
> > It doesn't sound like it'll be too hard to arrange for the kernel to
> > continue to work correctly with old userspace?
>
> Actually, it's impossible. New userspace can work across both
> version, old userspace fails on new version.
>
> The whole point of the -rc process is to find problems and the
> scope of it, there is no way I can know everything. At this point, we
> can decide if WE-21 should go in 2.6.19 or wait for 2.6.20. But I know
> that most Linux-Wireless people such as Dan and Jouni have been
> waiting impatiently for those changes...
>
It would be nice if need of a specific version of wireless tools was
documented in Documentaion/Changes. It was a surprise for me when my
wireless card stopped working.
--
Dmitry
On Mon, Oct 02, 2006 at 11:15:37AM -0700, Andrew Morton wrote:
>
> Jean, John: the amount of trouble which this change is causing is quite
> high considering that we're not even at -rc1 yet. It's going to get worse.
>
> It doesn't sound like it'll be too hard to arrange for the kernel to
> continue to work correctly with old userspace?
Actually, I have the perfect solution. We ship a new version
of the Wireless Tools and wpa_supplicant alongside the kernel, and
install those when the user install the new kernel. That way, we make
sure they always use the correct version of userspace with the kernel.
Regards,
Jean
On Mon, Oct 02, 2006 at 03:34:04PM -0400, Dmitry Torokhov wrote:
> On 10/2/06, Jean Tourrilhes <[email protected]> wrote:
> >
> > The whole point of the -rc process is to find problems and the
> >scope of it, there is no way I can know everything. At this point, we
> >can decide if WE-21 should go in 2.6.19 or wait for 2.6.20. But I know
> >that most Linux-Wireless people such as Dan and Jouni have been
> >waiting impatiently for those changes...
> >
>
> It would be nice if need of a specific version of wireless tools was
> documented in Documentaion/Changes. It was a surprise for me when my
> wireless card stopped working.
The Wireless Tols themselves issue a nice warning telling you
about the version mismatch and the need to upgrade. This is even more
powerful, as most people don't read the doc, but they run the tools.
Don't tell my you ignored the warning !
> Dmitry
Jean
On Monday, 2 October 2006 20:55, Jean Tourrilhes wrote:
> On Mon, Oct 02, 2006 at 11:15:37AM -0700, Andrew Morton wrote:
> > On Mon, 02 Oct 2006 12:58:24 -0400
> > >
> > > You have a mismatch between your wireless-tools, your kernel, and/or
> > > wpa_supplicant. WE-21 uses the _real_ ssid length rather than the
> > > kludge of hacking off the last byte used previously. Please ensure that
> > > your tools, driver, and kernel are using WE-21.
> > > 'cat /proc/net/wireless' should tell you what your kernel is using.
> > > Getting the driver WE is a bit harder and you may have to look at the
> > > source.
> >
> > Jean, John: the amount of trouble which this change is causing is quite
> > high considering that we're not even at -rc1 yet. It's going to get worse.
>
> We have to split between the different issues we have seen.
> Tools issue (the wpa_supplicant problem). -> those can only be
> fixed by people upgrading. Fortunately, there are not so many tools
> affected, and new version of those tools were released last
> April/May. As I said, most distro have those in the pipe.
> In-Kernel driver issues (the Orinoco driver problem). -> those
> can be patched and fixed as we go along. I would not worry about
> those.
> Out-of-kernel issues (the ipw3945 driver problem). -> those
> drivers need to be updated. That's the problem of living outside the
> kernel. Very often those drivers are reactive with respect to kernel
> API changes, rather than pro-active, so there is not much we can do.
>
> > It doesn't sound like it'll be too hard to arrange for the kernel to
> > continue to work correctly with old userspace?
>
> Actually, it's impossible. New userspace can work across both
> version, old userspace fails on new version.
<rant>
Well, please tell me now what number of people actually _will_ upgrade?
And if they don't, will they use the -rc kernels? No, they won't, because
of the apparent wireless breakage.
This way we loose quite a few testers and the entire development
process is affected, and that's _only_ because you have decided it
will be _convenient_ to change the ABI. However, such changes affect
_everyone_ and in a wrong way, except for a few people who actually want the
change. They cause more damage than they are worth, so they should be avoided
at all reasonable cost.
It would be fair to introduce the change when distributions actually ship the
userland tools capable of handling it, but not _now_.
</rant>
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
On 10/2/06, Jean Tourrilhes <[email protected]> wrote:
> On Mon, Oct 02, 2006 at 03:34:04PM -0400, Dmitry Torokhov wrote:
> > On 10/2/06, Jean Tourrilhes <[email protected]> wrote:
> > >
> > > The whole point of the -rc process is to find problems and the
> > >scope of it, there is no way I can know everything. At this point, we
> > >can decide if WE-21 should go in 2.6.19 or wait for 2.6.20. But I know
> > >that most Linux-Wireless people such as Dan and Jouni have been
> > >waiting impatiently for those changes...
> > >
> >
> > It would be nice if need of a specific version of wireless tools was
> > documented in Documentaion/Changes. It was a surprise for me when my
> > wireless card stopped working.
>
> The Wireless Tols themselves issue a nice warning telling you
> about the version mismatch and the need to upgrade. This is even more
> powerful, as most people don't read the doc, but they run the tools.
> Don't tell my you ignored the warning !
>
I think it was giving me that warning for the last couple of years...
I think FC3 was shipped with version 17? "May not work" is different
from "need release x.y.z" to work.
--
Dmitry
On Mon, Oct 02, 2006 at 03:22:03PM -0400, Dan Williams wrote:
>
> Right; we need to get this settled and we need to figure out a way with
> Wireless Extensions to allow exact SSIDs to be sent and retrieved from
> the card/driver. How much cruft do we add to drivers and/or WE bits to
> bend over backwards and preserve compatibility with a lot of older bits?
> I can think of a few ways here to preserve backwards compat, but most
> involve adding bits to 3 places in each driver and a new flag to WE,
> which puts us right back in the same situation we're in right now;
> inconsistent drivers and poor semantics both inside and outside the
> kernel.
There is no way old tools are going to set/process those extra
flags, so it does not work. And this won't fix out-of-tree drivers...
> Maybe the answer here _is_ to bend over backwards to preserve
> compatibility, restore null-termination-and-increment-length bits in
> drivers and WE, and kludge all the user-space tools.
Let's not throw the baby with the bathwater.
This is *not* the first time I've done such incompatible
change in WE (size in set, pointer in scan, remove pointer in
events). The other time, it went completely under the radar, you guys
did not noticed anything (apart Jouni).
The difference is that this time I attempted to do it a bit
quicker than usual. Maybe I was too fast this time. But I've noticed
that some distro have become slower to pick up changes than in the
past, which is frustrating me.
To me, the solution is just to let a bit more time for the
userspace to propagate to the distro. And to educate users to pay
attention to the incompatibility warnings displayed by the tools.
> Dan
Have fun...
Jean
On Mon, 2006-10-02 at 12:41 -0700, Jean Tourrilhes wrote:
> On Mon, Oct 02, 2006 at 11:15:37AM -0700, Andrew Morton wrote:
> >
> > Jean, John: the amount of trouble which this change is causing is quite
> > high considering that we're not even at -rc1 yet. It's going to get worse.
> >
> > It doesn't sound like it'll be too hard to arrange for the kernel to
> > continue to work correctly with old userspace?
>
> Actually, I have the perfect solution. We ship a new version
> of the Wireless Tools and wpa_supplicant alongside the kernel, and
> install those when the user install the new kernel. That way, we make
> sure they always use the correct version of userspace with the kernel.
Like udev :) And libsysfs :)
> Regards,
>
> Jean
>
On Mon, 2006-10-02 at 21:47 +0200, Rafael J. Wysocki wrote:
> On Monday, 2 October 2006 20:55, Jean Tourrilhes wrote:
> > On Mon, Oct 02, 2006 at 11:15:37AM -0700, Andrew Morton wrote:
> > > On Mon, 02 Oct 2006 12:58:24 -0400
> > > >
> > > > You have a mismatch between your wireless-tools, your kernel, and/or
> > > > wpa_supplicant. WE-21 uses the _real_ ssid length rather than the
> > > > kludge of hacking off the last byte used previously. Please ensure that
> > > > your tools, driver, and kernel are using WE-21.
> > > > 'cat /proc/net/wireless' should tell you what your kernel is using.
> > > > Getting the driver WE is a bit harder and you may have to look at the
> > > > source.
> > >
> > > Jean, John: the amount of trouble which this change is causing is quite
> > > high considering that we're not even at -rc1 yet. It's going to get worse.
> >
> > We have to split between the different issues we have seen.
> > Tools issue (the wpa_supplicant problem). -> those can only be
> > fixed by people upgrading. Fortunately, there are not so many tools
> > affected, and new version of those tools were released last
> > April/May. As I said, most distro have those in the pipe.
> > In-Kernel driver issues (the Orinoco driver problem). -> those
> > can be patched and fixed as we go along. I would not worry about
> > those.
> > Out-of-kernel issues (the ipw3945 driver problem). -> those
> > drivers need to be updated. That's the problem of living outside the
> > kernel. Very often those drivers are reactive with respect to kernel
> > API changes, rather than pro-active, so there is not much we can do.
> >
> > > It doesn't sound like it'll be too hard to arrange for the kernel to
> > > continue to work correctly with old userspace?
> >
> > Actually, it's impossible. New userspace can work across both
> > version, old userspace fails on new version.
>
> <rant>
> Well, please tell me now what number of people actually _will_ upgrade?
If you're using a distro, the distro maintainers should be making sure
versions are compatible. If you don't, well, then you need to be making
sure versions are compatible.
> And if they don't, will they use the -rc kernels? No, they won't, because
> of the apparent wireless breakage.
>
> This way we loose quite a few testers and the entire development
> process is affected, and that's _only_ because you have decided it
> will be _convenient_ to change the ABI. However, such changes affect
> _everyone_ and in a wrong way, except for a few people who actually want the
> change. They cause more damage than they are worth, so they should be avoided
> at all reasonable cost.
>
> It would be fair to introduce the change when distributions actually ship the
> userland tools capable of handling it, but not _now_.
Distributions _are_ shipping those tools already. The problem is more
with older distributions where, for example, the kernel gets upgraded
but other stuff does not. If a kernel upgrade happens, then the distro
needs to make sure userspace works with it. That's nothing new.
Dan
> </rant>
>
> Greetings,
> Rafael
>
>
On Mon, Oct 02, 2006 at 04:57:37PM -0400, Dan Williams wrote:
> On Mon, 2006-10-02 at 12:41 -0700, Jean Tourrilhes wrote:
> >
> > Actually, I have the perfect solution. We ship a new version
> > of the Wireless Tools and wpa_supplicant alongside the kernel, and
> > install those when the user install the new kernel. That way, we make
> > sure they always use the correct version of userspace with the kernel.
>
> Like udev :) And libsysfs :)
Wait, wait, this starts to look too much like *BSD ;-)
Jean
On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
> Distributions _are_ shipping those tools already. The problem is more
> with older distributions where, for example, the kernel gets upgraded
> but other stuff does not. If a kernel upgrade happens, then the distro
> needs to make sure userspace works with it. That's nothing new.
Um, *which* distro's are shipping it already? RHEL4? SLES10? I
thought we saw a note saying that even Debian **unstable** didn't have
a new enough version of the wireless-tools....
- Ted
On Mon, Oct 02, 2006 at 05:26:04PM -0400, Theodore Tso wrote:
> On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
> > Distributions _are_ shipping those tools already. The problem is more
> > with older distributions where, for example, the kernel gets upgraded
> > but other stuff does not. If a kernel upgrade happens, then the distro
> > needs to make sure userspace works with it. That's nothing new.
>
> Um, *which* distro's are shipping it already? RHEL4? SLES10? I
> thought we saw a note saying that even Debian **unstable** didn't have
> a new enough version of the wireless-tools....
I personally never said it was shipping already in all distro.
Debian Testing has the proper version since last May (forget
about Stable, as usual). So, Debian is in fine shape, I would say...
Gentoo 2006.1 is obviously shipping with it.
FC6 has it since August. It's currently in RC.
I believe Mandriva 2007 has it, and it's also in RC. They make
it hard for non-club member to know what's happening.
SuSE I can't figure out.
Slackware has it in the dev version. 10.2 was one year ago, so
they are due for a new release, I guess.
Note that both rpmseek and rpmfind are obsolete, so it's
actually a pain trying to track down all that info.
> - Ted
Have fun...
Jean
On 10/2/06, Theodore Tso <[email protected]> wrote:
> On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
> > Distributions _are_ shipping those tools already. The problem is more
> > with older distributions where, for example, the kernel gets upgraded
> > but other stuff does not. If a kernel upgrade happens, then the distro
> > needs to make sure userspace works with it. That's nothing new.
>
> Um, *which* distro's are shipping it already? RHEL4? SLES10? I
> thought we saw a note saying that even Debian **unstable** didn't have
> a new enough version of the wireless-tools....
That was my point initially. FC5-latest is apparently carrying
tools which are "too old"... and I yum update twice or thrice
a week. Not that *I* minded building packages from source,
but this is likely a bit too much for a good slice of the userbase.
Ciao,
--alessandro
"Well a man has two reasons for things that he does
the first one is pride and the second one is love
all understandings must come by this way"
(Husker Du, 'She Floated Away')
On Tue, 2006-10-03 at 00:08 +0200, Alessandro Suardi wrote:
> On 10/2/06, Theodore Tso <[email protected]> wrote:
> > On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
> > > Distributions _are_ shipping those tools already. The problem is more
> > > with older distributions where, for example, the kernel gets upgraded
> > > but other stuff does not. If a kernel upgrade happens, then the distro
> > > needs to make sure userspace works with it. That's nothing new.
> >
> > Um, *which* distro's are shipping it already? RHEL4? SLES10? I
> > thought we saw a note saying that even Debian **unstable** didn't have
> > a new enough version of the wireless-tools....
>
> That was my point initially. FC5-latest is apparently carrying
> tools which are "too old"... and I yum update twice or thrice
> a week. Not that *I* minded building packages from source,
> but this is likely a bit too much for a good slice of the userbase.
And that's my fault. I was made aware of this issue last week and am
currently testing out the newer wireless-tools with the intention of
pushing them to FC5-updates. Had I actually been tracking the
wireless-tools release cycle more closely, I would have pushed the
wireless-tools-28 final version when it came out.
But, as far as I know (please correct me if I'm wrong), that 2.6.18
doesn't actually include WE-21! [1] Somebody is trying to run
out-of-kernel ipw3945 drivers using a 2.6.18 kernel from FC5 that's
WE-20 only, but the driver uses WE-21?
ipw3945 isn't in the upstream kernel, and Fedora certainly isn't going
to go out of its way to make sure every piece of software under the sun
that's not included in the distro works with it [2]. Distros try to
make sure they are internally consistent, not globally consistent. If
somebody uses out-of-kernel drivers, they take that responsibility. The
solution to the problem is to make sure that ipw3945 gets in the kernel
as quickly as possible, something I think we'd all like to have happen.
Dan
[1] /lib/modules/2.6.18-1.2708.fc6/build/include/linux/wireless.h
defines WIRELESS_EXT = 20
[2] Yeah it would be nice; but go out of the way to have Skype w/ OSS,
Nvidia binary drivers, ATI binary drivers, ndiswrapper,
out-of-kernel-drivers? No.
> Ciao,
>
> --alessandro
>
> "Well a man has two reasons for things that he does
> the first one is pride and the second one is love
> all understandings must come by this way"
>
> (Husker Du, 'She Floated Away')
On Mon, Oct 02, 2006 at 12:44:42PM -0400, Lee Revell wrote:
> On Mon, 2006-10-02 at 09:21 +0000, Alessandro Suardi wrote:
> > we've been just through an email thread where it has been
> > determined that wpa_supplicant 0.4.9 (I would assume that
> > 0.5.5 is also okay) and wireless-tools from Jean's latest
> > tarball are necessary to work with the recent wireless
> > extensions v21 that have been merged in.
> >
> > What wireless-tools are you using ?
>
> This must be considered a kernel bug - it's not allowed to break
> userspace compatibility in a stable series.
But there is no development series. The closest thing we have is the
merge window after each release -- which is exactly when this issue
revealed itself.
Wireless in general (and the wireless extensions api in particular)
is a bit of a 'whipping boy' in the Linux world. OK, we suck.
Everyone wants to display their wisdom by telling us how much we suck!
We know all about it...
We have sucked, and we continue to suck -- and we are working on it.
But, we are not going to be able to whip-up this omelette without
breaking a few eggs. If we can't do that during the merge windows,
WHEN CAN WE DO IT?
John
--
John W. Linville
[email protected]
On 10/3/06, Dan Williams <[email protected]> wrote:
> On Tue, 2006-10-03 at 00:08 +0200, Alessandro Suardi wrote:
> > On 10/2/06, Theodore Tso <[email protected]> wrote:
> > > On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
> > > > Distributions _are_ shipping those tools already. The problem is more
> > > > with older distributions where, for example, the kernel gets upgraded
> > > > but other stuff does not. If a kernel upgrade happens, then the distro
> > > > needs to make sure userspace works with it. That's nothing new.
> > >
> > > Um, *which* distro's are shipping it already? RHEL4? SLES10? I
> > > thought we saw a note saying that even Debian **unstable** didn't have
> > > a new enough version of the wireless-tools....
> >
> > That was my point initially. FC5-latest is apparently carrying
> > tools which are "too old"... and I yum update twice or thrice
> > a week. Not that *I* minded building packages from source,
> > but this is likely a bit too much for a good slice of the userbase.
>
> And that's my fault. I was made aware of this issue last week and am
> currently testing out the newer wireless-tools with the intention of
> pushing them to FC5-updates. Had I actually been tracking the
> wireless-tools release cycle more closely, I would have pushed the
> wireless-tools-28 final version when it came out.
>
> But, as far as I know (please correct me if I'm wrong), that 2.6.18
> doesn't actually include WE-21! [1] Somebody is trying to run
> out-of-kernel ipw3945 drivers using a 2.6.18 kernel from FC5 that's
> WE-20 only, but the driver uses WE-21?
>
> ipw3945 isn't in the upstream kernel, and Fedora certainly isn't going
> to go out of its way to make sure every piece of software under the sun
> that's not included in the distro works with it [2]. Distros try to
> make sure they are internally consistent, not globally consistent. If
> somebody uses out-of-kernel drivers, they take that responsibility. The
> solution to the problem is to make sure that ipw3945 gets in the kernel
> as quickly as possible, something I think we'd all like to have happen.
>
> Dan
>
> [1] /lib/modules/2.6.18-1.2708.fc6/build/include/linux/wireless.h
> defines WIRELESS_EXT = 20
>
> [2] Yeah it would be nice; but go out of the way to have Skype w/ OSS,
> Nvidia binary drivers, ATI binary drivers, ndiswrapper,
> out-of-kernel-drivers? No.
While strongly agreeing with the above reasoning, I'd just
point out that the two current reports were
mine -> FC5, in-kernel ipw2200, wpa_supplicant and wireless-tools "too old",
rebuild userspace from recent sources => all fine and dandy
Norbert's -> Debian unstable, out-of-kernel ipw3945, wpa_supplicant okay,
wireless-tools "too old", rebuild these from recent sources =>
still a few issues
so it was only myself running FC5, and with a WE-21 capable Torvalds kernel
as I test at least 4 -git snapshots per week (and yes, 2.6.18 doesn't
have WE-21,
which is the root of the reports - WE-21 went in in 2.6.18-git9).
Indeed the in-kernel driver appeared to be the easily solved case, as
expected...
Thanks, ciao,
--alessandro
"Well a man has two reasons for things that he does
the first one is pride and the second one is love
all understandings must come by this way"
(Husker Du, 'She Floated Away')
On Tue, Oct 03, 2006 at 08:12:53AM -0400, Dan Williams wrote:
> On Tue, 2006-10-03 at 00:08 +0200, Alessandro Suardi wrote:
> > On 10/2/06, Theodore Tso <[email protected]> wrote:
> > > On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
> > > > Distributions _are_ shipping those tools already. The problem is more
> > > > with older distributions where, for example, the kernel gets upgraded
> > > > but other stuff does not. If a kernel upgrade happens, then the distro
> > > > needs to make sure userspace works with it. That's nothing new.
> > >
> > > Um, *which* distro's are shipping it already? RHEL4? SLES10? I
> > > thought we saw a note saying that even Debian **unstable** didn't have
> > > a new enough version of the wireless-tools....
> >
> > That was my point initially. FC5-latest is apparently carrying
> > tools which are "too old"... and I yum update twice or thrice
> > a week. Not that *I* minded building packages from source,
> > but this is likely a bit too much for a good slice of the userbase.
>
> And that's my fault. I was made aware of this issue last week and am
> currently testing out the newer wireless-tools with the intention of
> pushing them to FC5-updates. Had I actually been tracking the
> wireless-tools release cycle more closely, I would have pushed the
> wireless-tools-28 final version when it came out.
>
> But, as far as I know (please correct me if I'm wrong), that 2.6.18
> doesn't actually include WE-21! [1] Somebody is trying to run
> out-of-kernel ipw3945 drivers using a 2.6.18 kernel from FC5 that's
> WE-20 only, but the driver uses WE-21?
Obviously I was a bit optimisitic in accepting the notion that distros
had already upgraded their userland bits to handle WE-21. I apologize.
As Dan points-out, it will be a while before distros (other than
Fedora rawhide and equivalents) have 2.6.19 kernels for general
users. For now, those experiencing this issue should be comfortable
experiencing some breakage...?
So, is the window between now and the release of 2.6.19 big enough
to give the distros time to get wireless-tools and wpa_supplicant
into their update streams? Or do we need to go through the pain of
reverting/delaying WE-21?
John
--
John W. Linville
[email protected]
John,
Has someone documented somewhere what all of the constraints
are? I have gathered from various messages that part of the problem
is that different drivers and different userspace tools have a
different idea of what the structures are and what various size fields
mean, and that trying to coordinate changes between the kernel,
multiple userspace tools, and some very popular out-of-tree drivers
(some of which have been kept out of the kernel for issues that I
don't agree with, but which the GPL purists go balistic over), that
you feel that the problem is over-constrained.
Is there a document or an e-mail message that in one place
describes what the current situation is, why it sucks, what the
changes are, and what eggs are getting broken and why it's better than
where we are today?
Thanks, regards,
- Ted
On Tue, Oct 03, 2006 at 08:49:07AM -0400, John W. Linville wrote:
> As Dan points-out, it will be a while before distros (other than
> Fedora rawhide and equivalents) have 2.6.19 kernels for general
> users. For now, those experiencing this issue should be comfortable
> experiencing some breakage...?
>
> So, is the window between now and the release of 2.6.19 big enough
> to give the distros time to get wireless-tools and wpa_supplicant
> into their update streams? Or do we need to go through the pain of
> reverting/delaying WE-21?
There is a fundamental question hiding here, which is whether or not
it is acceptable to break users who are running some large set of
mainline distro's, such as RHEL 4, SLES/SLED 10, Ubuntu Dapper,
et. al, but who want to upgrade to a newer 2.6 kernel?
Many users have moved to Ubuntu Dapper, or RHEL 4, or SLES/SLED 10
because they don't want to deal with a constantly changing/breaking
GNOME/X world, where packages are constantly being updated and
possibly breaking their desktop. Some of these users are in fact
kernel developers, who want to live and test on the bleeding edge, but
who don't want to deal with an unstable Desktop/X world, since that's
not where their expertise lies. Other users are ones which have to
use a mainstream distribution for one reason or another (maybe they
have software that only works on RHEL 4), but are interested in
testing bleeding edge kernels because they want to help contribute to
testing and quality assurance. Is it acceptable to break them with
ABI changes?
If the answer that it is acceptable to break the "slower moving"
distro's, how much time do we need to allow to elapse before the
"faster moving" distro's have accepted the necessary userspace bits?
Is it 30 days? 60 days? 90 days? Or do we do it by distribution. If
all of Debian testing, Ubuntu development, Fedora Core n and n-1,
OpenSuse, Gentoo, has accepted the newer bits, is that enough time?
Clearly the wireless updates failed the second series of tests; but we
haven't even decided, amongst kernel developers, under what
circumstances is it permissible to break the first set of distro's.
Clearly in the best of all worlds new interfaces are carefully
documented, and no new interface is introduced without thinking very
carefully about forwards and backwards compatibility. Unfortuately,
the wireless ABI interface is a legacy interface which seems to be
really broken in many different ways.
John, has the wireless community considered creating a new interface
which *is* carefully designed, and supporting both the new and the
legacy interface for 2-3 years until all of the mainstream
distributions have had a chance to cycle? It would be hard, I know,
but would it be harder than some of the alternatives, and would it be
worth it?
Regards,
- Ted
On Tue, 2006-10-03 at 09:38 -0400, Theodore Tso wrote:
> On Tue, Oct 03, 2006 at 08:49:07AM -0400, John W. Linville wrote:
> > As Dan points-out, it will be a while before distros (other than
> > Fedora rawhide and equivalents) have 2.6.19 kernels for general
> > users. For now, those experiencing this issue should be comfortable
> > experiencing some breakage...?
> >
> > So, is the window between now and the release of 2.6.19 big enough
> > to give the distros time to get wireless-tools and wpa_supplicant
> > into their update streams? Or do we need to go through the pain of
> > reverting/delaying WE-21?
>
> There is a fundamental question hiding here, which is whether or not
> it is acceptable to break users who are running some large set of
> mainline distro's, such as RHEL 4, SLES/SLED 10, Ubuntu Dapper,
> et. al, but who want to upgrade to a newer 2.6 kernel?
>
> Many users have moved to Ubuntu Dapper, or RHEL 4, or SLES/SLED 10
> because they don't want to deal with a constantly changing/breaking
> GNOME/X world, where packages are constantly being updated and
> possibly breaking their desktop. Some of these users are in fact
> kernel developers, who want to live and test on the bleeding edge, but
> who don't want to deal with an unstable Desktop/X world, since that's
I'm certain these people already experience breakage when using new bits
that haven't been settled into their desktop/distro of choice. It
wasn't so long ago (2.6.10 - 2.6.13) that installing a new kernel would
break the expectations of udev, HAL, and libsysfs while sysfs directory
structure was getting laid out for stuff like power management, wireless
devices, etc. If you're a core system developer, you've got to expect
breakage somewhere.
> not where their expertise lies. Other users are ones which have to
> use a mainstream distribution for one reason or another (maybe they
> have software that only works on RHEL 4), but are interested in
> testing bleeding edge kernels because they want to help contribute to
> testing and quality assurance. Is it acceptable to break them with
> ABI changes?
>
> If the answer that it is acceptable to break the "slower moving"
> distro's, how much time do we need to allow to elapse before the
I'd point out here that one is not breaking the _distro_, as long as we
assume that distros are internally consistent (which one of the major
points of a distro!). What's getting broken is people who
install/replace distro-provided software with their own bits. In the
first case, the distro people are responsible to making sure that
breakage does not occur, and that distro users are not affected. In the
second case, that responsibility falls to the user who
installed/replaced the distro-provided software, precisely because that
software is no longer distro provided.
We've _got_ to accept that somebody installing their own stuff has
_some_ responsibility to ensure compatibility of the random code they
install. In a perfect world, distros never make a mistake. But usually
a distro has a much broader and deeper set of expertise than any one
person, and is at least peripherally aware of changes coming down the
pike. One single person cannot hope to assume the responsibilities of
many maintainers working by division of labor.
Obviously we don't try to break stuff unintentionally, or when the pain
would be too severe, because we know better than most what's going on
and it's Just Not Nice. But ultimately, whoever is installing the
software bears the consequences of his/her actions, precisely because
they pulled the trigger.
> "faster moving" distro's have accepted the necessary userspace bits?
> Is it 30 days? 60 days? 90 days? Or do we do it by distribution. If
> all of Debian testing, Ubuntu development, Fedora Core n and n-1,
> OpenSuse, Gentoo, has accepted the newer bits, is that enough time?
>
> Clearly the wireless updates failed the second series of tests; but we
> haven't even decided, amongst kernel developers, under what
> circumstances is it permissible to break the first set of distro's.
> Clearly in the best of all worlds new interfaces are carefully
> documented, and no new interface is introduced without thinking very
> carefully about forwards and backwards compatibility. Unfortuately,
> the wireless ABI interface is a legacy interface which seems to be
> really broken in many different ways.
>
> John, has the wireless community considered creating a new interface
> which *is* carefully designed, and supporting both the new and the
> legacy interface for 2-3 years until all of the mainstream
Yes, nl80211/cfg80211 (sent to netdev@ last week) is the likely
successor. Please, if you have suggestions for ABI/API-proofability,
review the patch and post suggestions! We all know a carefully designed
is not just about the code, but about the semantics, structures, etc as
well. It would be quite valuable to have everyone's input to make sure
it's as future-proof as possible.
Dan
> distributions have had a chance to cycle? It would be hard, I know,
> but would it be harder than some of the alternatives, and would it be
> worth it?
>
> Regards,
>
> - Ted
On Tue, Oct 03, 2006 at 10:12:59AM -0400, Dan Williams wrote:
> On Tue, 2006-10-03 at 09:38 -0400, Theodore Tso wrote:
> > John, has the wireless community considered creating a new interface
> > which *is* carefully designed, and supporting both the new and the
> > legacy interface for 2-3 years until all of the mainstream
>
> Yes, nl80211/cfg80211 (sent to netdev@ last week) is the likely
> successor. Please, if you have suggestions for ABI/API-proofability,
> review the patch and post suggestions! We all know a carefully designed
> is not just about the code, but about the semantics, structures, etc as
> well. It would be quite valuable to have everyone's input to make sure
> it's as future-proof as possible.
Dan is quick on his keyboard today! :-)
As Dan points-out, there is serious work underway on the next
generation wireless management A[BP]I. That work is (perhaps
unfortunately) closely linked to the new wireless stack work currently
underway.
John
P.S. Ted, thanks for your calm and respectful communications!
--
John W. Linville
[email protected]
On Tue, 2006-10-03 at 08:38 -0400, John W. Linville wrote:
> On Mon, Oct 02, 2006 at 12:44:42PM -0400, Lee Revell wrote:
> > On Mon, 2006-10-02 at 09:21 +0000, Alessandro Suardi wrote:
> > > we've been just through an email thread where it has been
> > > determined that wpa_supplicant 0.4.9 (I would assume that
> > > 0.5.5 is also okay) and wireless-tools from Jean's latest
> > > tarball are necessary to work with the recent wireless
> > > extensions v21 that have been merged in.
> > >
> > > What wireless-tools are you using ?
> >
> > This must be considered a kernel bug - it's not allowed to break
> > userspace compatibility in a stable series.
>
> But there is no development series. The closest thing we have is the
> merge window after each release -- which is exactly when this issue
> revealed itself.
>
> Wireless in general (and the wireless extensions api in particular)
> is a bit of a 'whipping boy' in the Linux world. OK, we suck.
> Everyone wants to display their wisdom by telling us how much we suck!
> We know all about it...
>
> We have sucked, and we continue to suck -- and we are working on it.
> But, we are not going to be able to whip-up this omelette without
> breaking a few eggs. If we can't do that during the merge windows,
> WHEN CAN WE DO IT?
This is a question for Linus, it's his rule...
Lee
On Tue, Oct 03, 2006 at 10:12:59AM -0400, Dan Williams wrote:
> I'd point out here that one is not breaking the _distro_, as long as we
> assume that distros are internally consistent (which one of the major
> points of a distro!). What's getting broken is people who
> install/replace distro-provided software with their own bits. In the
> first case, the distro people are responsible to making sure that
> breakage does not occur, and that distro users are not affected. In the
> second case, that responsibility falls to the user who
> installed/replaced the distro-provided software, precisely because that
> software is no longer distro provided.
I'm using short-hand here. When I say breaking the _distro_, what I
mean is that we are breaking the ability for users of that distro to
test development kernels, which is generally considered a good thing
by the kernel development community.
One could make the case that telling them that they have to download
something relatively trivial, like wireless tools, is less of a big
deal than something huge and very painful to build and replace, like
glibc (with udev, hal, et. al, probably falling somewhere in between
these two extremes), but up until now, the goal that kernel
development has made is that we add new interfaces, but we try
extremely hard not to break existing interfaces without a lot of
notice.
Consider that that the normal, MINIMUM waiting period for *removing*
an interface or functionality is six months. I would argue that this
means that we should be waiting that long before making
backwards-incompatible changes to an interface should be at least that
long.
> Yes, nl80211/cfg80211 (sent to netdev@ last week) is the likely
> successor. Please, if you have suggestions for ABI/API-proofability,
> review the patch and post suggestions! We all know a carefully designed
> is not just about the code, but about the semantics, structures, etc as
> well. It would be quite valuable to have everyone's input to make sure
> it's as future-proof as possible.
As a suggestion, has someone written up the a formal interface
specification? If so, posting that for review along with the code
might be a good idea.
Regards,
- Ted
On Tue, 3 Oct 2006, Lee Revell wrote:
> >
> > We have sucked, and we continue to suck -- and we are working on it.
> > But, we are not going to be able to whip-up this omelette without
> > breaking a few eggs. If we can't do that during the merge windows,
> > WHEN CAN WE DO IT?
>
> This is a question for Linus, it's his rule...
In general, the answer to "when can we break user space" is very simple.
Never.
It's just not acceptable. We maintain old interfaces for years (and in
some cases, well over a decade by now), simply because the pain from not
doing so is horrendous, and it makes debugging impossible. You get into
situations where users need to upgrade to tools that don't work with older
kernels, and can thus not downgrade, etc etc.
That said, system tools have been given some dispensation. Not a lot, and
sometimes they take more liberties than they are given - udev in
particular had too many problems, and some people who maintained it seemed
to think that they had the "right" to break things as much as they did. I
think that got cleared up, but the point is: system tools sometimes cannot
avoid some issues, but damn it, breaking them "just because it fixes
things" is NOT ACCEPTABLE.
So even if it's a case of "..but it fixes a problem", that in itself is
not a valid reason for breaking a tool that used to work. It really _has_
to be: "It fixes a serious problem, and we tried hard as _hell_ to avoid
any breakage at all, and it wasn't possible, but this is a one-time
event".
Quite frankly, the parts of the discussion I have seen does not at all
imply to me that people tried as hard as possible. For example, I saw Jean
say that "The wireless tools themselves told about the version mismatch",
as if that had ANY RELEVANCE AT ALL!
If the kernel knows about the version number, it should make sure that the
interfaces are honored. Yes, it often means some ugly code at the
interface layer, but dammit, that's the job of the kernel. It's the whole
reason why we have some of the abstraction layers we do in the kernel. The
original reason the readdir() function got a "filldir_t" callback was
simply the fact that we needed to support two different formats for it.
The reason we have the whole internal "struct kstat" is exactly the same.
We don't do this version skew dance. If we need to break something, it had
better be some damn substantial reasons, and even then we're generally
better off supporting _both_ interfaces for a while (perhaps using a
version code), and then marking the old one deprecated.
Ugly? Yes, often. But _users_ do matter more. Really.
Linus
On Tue, Oct 03, 2006 at 08:12:53AM -0400, Dan Williams wrote:
>
> But, as far as I know (please correct me if I'm wrong), that 2.6.18
> doesn't actually include WE-21! [1] Somebody is trying to run
> out-of-kernel ipw3945 drivers using a 2.6.18 kernel from FC5 that's
> WE-20 only, but the driver uses WE-21?
No, It was out-of-kernel ipw3945 + 2.6.18-git9 kernel. The
kernel was using WE-21 and the driver was using WE-20.
Jean
On Tue, Oct 03, 2006 at 09:38:45AM -0400, Theodore Tso wrote:
>
> John, has the wireless community considered creating a new interface
> which *is* carefully designed, and supporting both the new and the
> legacy interface for 2-3 years until all of the mainstream
> distributions have had a chance to cycle? It would be hard, I know,
> but would it be harder than some of the alternatives, and would it be
> worth it?
No API is guaranteed to be stable forever. And I think the
overall track record of stability for the Wireless Extensions is
pretty good.
On top of that, the tools themselves *WARNS YOU* when there is
an API incompatibility, giving the user the change to correct the
issue. There is not many API having such feature...
In my mind, the whole point of the GIT and RC process is to
test changes before setting them in stone, so that we have the time to
correct our mistakes. I definitely think the process is working
properly.
If you think I jumped the gun, consider that both FC and
Mandriva which have the right userspace bits are in RC phase
(FC6-test3 and 2007-rc2), and therefore will ship about the same time
2.6.19 hits final. And Debian with the right userspace bits is
supposed to be released in december (no comment).
> Regards,
>
> - Ted
Have fun...
Jean
On Tue, Oct 03, 2006 at 12:00:41PM -0400, Theodore Tso wrote:
>
> Consider that that the normal, MINIMUM waiting period for *removing*
> an interface or functionality is six months. I would argue that this
> means that we should be waiting that long before making
> backwards-incompatible changes to an interface should be at least that
> long.
Wireless Tools with the new API were released in
April. wpa_supplicant with the new API was release May 5th. That makes
it 6 months.
Wireless Tools v28 was included in Gentoo April 11th and in
Debian testing May 27th. wpa_supplicant 0.4.9 was included in Gentoo
May 27th and Debian testing June 10th.
Please consider the facts before assuming.
Jean
On Tue, Oct 03, 2006 at 09:38:45AM -0400, Theodore Tso wrote:
>
> There is a fundamental question hiding here, which is whether or not
> it is acceptable to break users who are running some large set of
> mainline distro's, such as RHEL 4, SLES/SLED 10, Ubuntu Dapper,
> et. al, but who want to upgrade to a newer 2.6 kernel?
>
> Many users have moved to Ubuntu Dapper, or RHEL 4, or SLES/SLED 10
> because they don't want to deal with a constantly changing/breaking
> GNOME/X world, where packages are constantly being updated and
> possibly breaking their desktop.
In the past, I personally tried to upgrade Red-Hat Workstation
4 with a pristine 2.6 kernel. This was far from trivial, as Red-Hat
did compile their kernel with some weird options/patches, and
userspace (libc) were expecting those.
On the other hand, I've been personally running the latest
2.6.X kernels on Debian stable for as long as 2.6.X was
available. And, things *do* break, in the past I had trouble with
module tools, I can't run devfs or udev, Pcmcia is on the verge of
breaking, etc...
In other words, running a bleeding edge kernel with a
super-stable distro has never been for the casual user. And, I wonder
what's the wisdom of it for the casual user, has he certainly can't
use the advanced features of the new kernel unless he updates his
userspace.
My main box is Debian stable with a 2.4.X kernel. For that
box, I don't see the point of going to the latest 2.6.X kernel, it
would give me more trouble than benefits.
Just for kicks. Today, a new Slackware was released. And guess
what, it has Wireless Tools 28 ;-)
Jean
On Tue, 2006-10-03 at 10:23 -0700, Jean Tourrilhes wrote:
> On Tue, Oct 03, 2006 at 09:38:45AM -0400, Theodore Tso wrote:
> >
> > There is a fundamental question hiding here, which is whether or not
> > it is acceptable to break users who are running some large set of
> > mainline distro's, such as RHEL 4, SLES/SLED 10, Ubuntu Dapper,
> > et. al, but who want to upgrade to a newer 2.6 kernel?
> >
> > Many users have moved to Ubuntu Dapper, or RHEL 4, or SLES/SLED 10
> > because they don't want to deal with a constantly changing/breaking
> > GNOME/X world, where packages are constantly being updated and
> > possibly breaking their desktop.
>
> In the past, I personally tried to upgrade Red-Hat Workstation
> 4 with a pristine 2.6 kernel. This was far from trivial, as Red-Hat
> did compile their kernel with some weird options/patches, and
> userspace (libc) were expecting those.
> On the other hand, I've been personally running the latest
> 2.6.X kernels on Debian stable for as long as 2.6.X was
> available. And, things *do* break, in the past I had trouble with
> module tools, I can't run devfs or udev, Pcmcia is on the verge of
> breaking, etc...
>
> In other words, running a bleeding edge kernel with a
> super-stable distro has never been for the casual user. And, I wonder
> what's the wisdom of it for the casual user, has he certainly can't
> use the advanced features of the new kernel unless he updates his
> userspace.
> My main box is Debian stable with a 2.4.X kernel. For that
> box, I don't see the point of going to the latest 2.6.X kernel, it
> would give me more trouble than benefits.
>
> Just for kicks. Today, a new Slackware was released. And guess
> what, it has Wireless Tools 28 ;-)
I'm going to push wireless-tools-28 final for FC5-updates this week too.
Dan
>
> Jean
On Tue, Oct 03, 2006 at 10:23:27AM -0700, jt wrote:
>
> Just for kicks. Today, a new Slackware was released. And guess
> what, it has Wireless Tools 28 ;-)
It must be one of those day. Mandriva 2007 was just released
today, and guess what, it has Wireless Tools v28 and wpa_supplicant
0.5.5.
Jean
On Tue, Oct 03, 2006 at 09:27:34AM -0700, Linus Torvalds wrote:
> We don't do this version skew dance. If we need to break something, it had
> better be some damn substantial reasons, and even then we're generally
> better off supporting _both_ interfaces for a while (perhaps using a
> version code), and then marking the old one deprecated.
FWIW, this clean-up is not intended to break older binaries.
It is intended to standardize driver implementations of the WE API.
Breakage is (merely!) a side-effect...
The overall purpose of the WE-21 patch was to continue disambiguating
how drivers implement the WE API. This is intended to (hopefully)
avoid strange, hidden bugs lurking out there in driver/tool
interaction, especially for tools other than wireless-tools
(e.g. NetworkManager, wpa_supplicant, etc). In this case, it looks
like maybe some older versions of these tools were effectively
exploting the strange, hidden bugs... :-(
It seems there were a few genuine bugs which crept into the WE-21
implementation. Jean has posted fixes for those today. It looks
like those patches get things working again when combined with
updated tools.
Today's news seems to indicate that at least the major distros are
already shipping the updated tools, or on the verge of shipping them.
The window of breakage for most users looks like it will be fairly
small, no matter what action taken.
The more we can clean-up the WE API, the easier it will be to implement
the cfg80211 WE compatibility layer intended for wireless-dev.
I think WE-21 makes things better in that respect.
Finally, I already scaled-back Jean's original WE-21 patch. I only
anticipate minor bug fixes for WE from now on, with nl80211/cfg80211
as the heir-apparent.
With all that said, I'd prefer to keep the existing WE-21 patches and
add Jean's fixes ASAP. Is this acceptable? If not, I'll submit the
reversions to Jeff ASAP.
Suggestions?
John
--
John W. Linville
[email protected]
John W. Linville wrote:
> The more we can clean-up the WE API, the easier it will be to implement
> the cfg80211 WE compatibility layer intended for wireless-dev.
> I think WE-21 makes things better in that respect.
>
> Finally, I already scaled-back Jean's original WE-21 patch. I only
> anticipate minor bug fixes for WE from now on, with nl80211/cfg80211
> as the heir-apparent.
>
> With all that said, I'd prefer to keep the existing WE-21 patches and
> add Jean's fixes ASAP. Is this acceptable? If not, I'll submit the
> reversions to Jeff ASAP.
I for one don't want to change the userspace ABI for this... If I had
realized the userspace ABI was changing (<- my fault), I wouldn't have
merged the changes in the first place.
Jeff
On Tue, 3 Oct 2006, John W. Linville wrote:
>
> Today's news seems to indicate that at least the major distros are
> already shipping the updated tools, or on the verge of shipping them.
> The window of breakage for most users looks like it will be fairly
> small, no matter what action taken.
>
> The more we can clean-up the WE API, the easier it will be to implement
> the cfg80211 WE compatibility layer intended for wireless-dev.
> I think WE-21 makes things better in that respect.
Please correct me if I'm wrong: isn't it the case that a few of the
distros are now coming out with wireless_tools.28 supporting WE-20,
but current 2.6.18-git wireless drivers are WE-21, supported only
by wireless_tools.29.pre10?
Hugh
On Tue, Oct 03, 2006 at 02:19:42PM -0400, Jeff Garzik wrote:
> John W. Linville wrote:
> >The more we can clean-up the WE API, the easier it will be to implement
> >the cfg80211 WE compatibility layer intended for wireless-dev.
> >I think WE-21 makes things better in that respect.
> >
> >Finally, I already scaled-back Jean's original WE-21 patch. I only
> >anticipate minor bug fixes for WE from now on, with nl80211/cfg80211
> >as the heir-apparent.
> >
> >With all that said, I'd prefer to keep the existing WE-21 patches and
> >add Jean's fixes ASAP. Is this acceptable? If not, I'll submit the
> >reversions to Jeff ASAP.
>
> I for one don't want to change the userspace ABI for this... If I had
> realized the userspace ABI was changing (<- my fault), I wouldn't have
> merged the changes in the first place.
>
> Jeff
Jeff,
This was discussed publically on this mailing list last
January.
http://marc.theaimsgroup.com/?t=113710086000009&r=1&w=2
I made clear at that time that I did not like this change
because the userspace ABI would change, but I was overruled by a wide
consensus. So, don't blame me.
This change was rediscussed and reconfirmed at the Wireless
Summit. I only tried to make such change smooth, but it was not my
idea.
Now it's too late, those changes have propagated to userspace
tools, and are now shipping in some actual release of some distro. So,
what are we going to say to Mandriva 2007 and FC6 users, to revert
back to an *older* version of the tools ?
Because userspace has already been updated, we have only two
options, merge it now, or in 2.6.20.
Regards,
Jean
On Tue, Oct 03, 2006 at 07:31:08PM +0100, Hugh Dickins wrote:
> On Tue, 3 Oct 2006, John W. Linville wrote:
> >
> > Today's news seems to indicate that at least the major distros are
> > already shipping the updated tools, or on the verge of shipping them.
> > The window of breakage for most users looks like it will be fairly
> > small, no matter what action taken.
> >
> > The more we can clean-up the WE API, the easier it will be to implement
> > the cfg80211 WE compatibility layer intended for wireless-dev.
> > I think WE-21 makes things better in that respect.
>
> Please correct me if I'm wrong: isn't it the case that a few of the
> distros are now coming out with wireless_tools.28 supporting WE-20,
> but current 2.6.18-git wireless drivers are WE-21, supported only
> by wireless_tools.29.pre10?
>
> Hugh
wireless_tools.28 do support WE-21. I'm not a fool.
Jean
Jean Tourrilhes wrote:
> Now it's too late, those changes have propagated to userspace
> tools, and are now shipping in some actual release of some distro. So,
> what are we going to say to Mandriva 2007 and FC6 users, to revert
> back to an *older* version of the tools ?
> Because userspace has already been updated, we have only two
> options, merge it now, or in 2.6.20.
If the choice is between the ABI used by a bunch of distros in
production, and the ABI used by two re-release distros, I think the
choice is obvious...
Jeff
On 10/3/06, Jean Tourrilhes <[email protected]> wrote:
>
> Now it's too late, those changes have propagated to userspace
> tools, and are now shipping in some actual release of some distro. So,
> what are we going to say to Mandriva 2007 and FC6 users, to revert
> back to an *older* version of the tools ?
> Because userspace has already been updated, we have only two
> options, merge it now, or in 2.6.20.
>
Are you saying that compatibility is broken both ways?? Not only one
needs new tools for the new kernels but also has to downgrade tools to
work with older kernels??
--
Dmitry
On Tue, Oct 03, 2006 at 02:59:29PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> > Now it's too late, those changes have propagated to userspace
> >tools, and are now shipping in some actual release of some distro. So,
> >what are we going to say to Mandriva 2007 and FC6 users, to revert
> >back to an *older* version of the tools ?
> > Because userspace has already been updated, we have only two
> >options, merge it now, or in 2.6.20.
>
> If the choice is between the ABI used by a bunch of distros in
> production, and the ABI used by two re-release distros, I think the
> choice is obvious...
>
> Jeff
Which means 2.6.20. Case closed.
Jean
On Tue, Oct 03, 2006 at 03:08:43PM -0400, Dmitry Torokhov wrote:
> On 10/3/06, Jean Tourrilhes <[email protected]> wrote:
> >
> > Now it's too late, those changes have propagated to userspace
> >tools, and are now shipping in some actual release of some distro. So,
> >what are we going to say to Mandriva 2007 and FC6 users, to revert
> >back to an *older* version of the tools ?
> > Because userspace has already been updated, we have only two
> >options, merge it now, or in 2.6.20.
> >
>
> Are you saying that compatibility is broken both ways?? Not only one
> needs new tools for the new kernels but also has to downgrade tools to
> work with older kernels??
No, it's not. But as soon as *some part* of WE-21 appears in
the kernel, the userspace expect the ESSID change. If we want to have
WE-21 without the ESSID change, we need to fix userspace.
> Dmitry
Jean
On Tue, Oct 03, 2006 at 02:59:29PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> > Now it's too late, those changes have propagated to userspace
> >tools, and are now shipping in some actual release of some distro. So,
> >what are we going to say to Mandriva 2007 and FC6 users, to revert
> >back to an *older* version of the tools ?
> > Because userspace has already been updated, we have only two
> >options, merge it now, or in 2.6.20.
>
> If the choice is between the ABI used by a bunch of distros in
> production, and the ABI used by two re-release distros, I think the
> choice is obvious...
>
> Jeff
And remember that it's not *terminally* broken, the user can
still use the old tools with WE-21, he just need to add a dummy
character at the end of the ESSID string.
It's probably annoying, but it's not the end of the world.
Jean
John W. Linville wrote:
> Unfortunately, I don't see any way to "fix" WE-21 without similarly
> breaking wireless-tools 29 and other "WE-21 aware" apps. And since
> I'll bet that the various WE-aware apps have checks like "if WE >
> 20" for managing ESSID length settings, we may have painted ourselves
> into a korner (sic).
The apps are based on a pre-release kernel, which everyone knows could
change, precisely for reasons like this. Sounds like somebody took a
risk, and lost...
Jeff
On Tue, Oct 03, 2006 at 02:59:29PM -0400, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> > Now it's too late, those changes have propagated to userspace
> >tools, and are now shipping in some actual release of some distro. So,
> >what are we going to say to Mandriva 2007 and FC6 users, to revert
> >back to an *older* version of the tools ?
> > Because userspace has already been updated, we have only two
> >options, merge it now, or in 2.6.20.
>
> If the choice is between the ABI used by a bunch of distros in
> production, and the ABI used by two re-release distros, I think the
> choice is obvious...
I (grudgingly?) agree...
Unfortunately, I don't see any way to "fix" WE-21 without similarly
breaking wireless-tools 29 and other "WE-21 aware" apps. And since
I'll bet that the various WE-aware apps have checks like "if WE >
20" for managing ESSID length settings, we may have painted ourselves
into a korner (sic).
I.E. With "WE-21 aware" tools already in the wild, it isn't now clear
to me how WE can evolve any further than WE-20. Unless the ESSID
length changes in WE-21 is somehow deemed acceptable for 2.6.20 or
some later kernel version, I don't see how WE can continue to change.
Wireless developers, it's time to get d80211 ready to merge...or
figure-out how to get nl80211 on the current stack...hmmm...
John
---
The following changes since commit 8ccb3dcd1f8e80e8702642e1de26541b52f6bb7c:
Linus Torvalds:
x86: Fix booting with "no387 nofxsr"
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git we21-revert
John W. Linville:
wireless: revert WE-21 patches
drivers/net/wireless/airo.c | 19 ++++----
drivers/net/wireless/atmel.c | 18 ++++---
drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 2 -
drivers/net/wireless/hostap/hostap_ioctl.c | 10 ++--
drivers/net/wireless/ipw2100.c | 14 +++---
drivers/net/wireless/ipw2200.c | 16 ++++--
drivers/net/wireless/orinoco.c | 10 ++--
drivers/net/wireless/prism54/isl_ioctl.c | 16 +++---
drivers/net/wireless/ray_cs.c | 2 -
drivers/net/wireless/wl3501_cs.c | 6 +-
drivers/net/wireless/zd1201.c | 2 -
drivers/net/wireless/zd1211rw/zd_netdev.c | 2 -
include/linux/netdevice.h | 1
include/linux/wireless.h | 24 ++--------
net/core/net-sysfs.c | 5 ++
net/core/wireless.c | 67 ++++++++++-----------------
net/ieee80211/softmac/ieee80211softmac_wx.c | 8 ++-
17 files changed, 98 insertions(+), 124 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index 39d0934..1864b07 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -5883,7 +5883,7 @@ static int airo_set_essid(struct net_dev
int index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
/* Check the size of the string */
- if(dwrq->length > IW_ESSID_MAX_SIZE) {
+ if(dwrq->length > IW_ESSID_MAX_SIZE+1) {
return -E2BIG ;
}
/* Check if index is valid */
@@ -5895,7 +5895,7 @@ static int airo_set_essid(struct net_dev
memset(SSID_rid.ssids[index].ssid, 0,
sizeof(SSID_rid.ssids[index].ssid));
memcpy(SSID_rid.ssids[index].ssid, extra, dwrq->length);
- SSID_rid.ssids[index].len = dwrq->length;
+ SSID_rid.ssids[index].len = dwrq->length - 1;
}
SSID_rid.len = sizeof(SSID_rid);
/* Write it to the card */
@@ -6005,7 +6005,7 @@ static int airo_set_nick(struct net_devi
struct airo_info *local = dev->priv;
/* Check the size of the string */
- if(dwrq->length > 16) {
+ if(dwrq->length > 16 + 1) {
return -E2BIG;
}
readConfigRid(local, 1);
@@ -6030,7 +6030,7 @@ static int airo_get_nick(struct net_devi
readConfigRid(local, 1);
strncpy(extra, local->config.nodeName, 16);
extra[16] = '\0';
- dwrq->length = strlen(extra);
+ dwrq->length = strlen(extra) + 1;
return 0;
}
@@ -6782,9 +6782,9 @@ static int airo_set_retry(struct net_dev
}
readConfigRid(local, 1);
if(vwrq->flags & IW_RETRY_LIMIT) {
- if(vwrq->flags & IW_RETRY_LONG)
+ if(vwrq->flags & IW_RETRY_MAX)
local->config.longRetryLimit = vwrq->value;
- else if (vwrq->flags & IW_RETRY_SHORT)
+ else if (vwrq->flags & IW_RETRY_MIN)
local->config.shortRetryLimit = vwrq->value;
else {
/* No modifier : set both */
@@ -6820,14 +6820,14 @@ static int airo_get_retry(struct net_dev
if((vwrq->flags & IW_RETRY_TYPE) == IW_RETRY_LIFETIME) {
vwrq->flags = IW_RETRY_LIFETIME;
vwrq->value = (int)local->config.txLifetime * 1024;
- } else if((vwrq->flags & IW_RETRY_LONG)) {
- vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ } else if((vwrq->flags & IW_RETRY_MAX)) {
+ vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
vwrq->value = (int)local->config.longRetryLimit;
} else {
vwrq->flags = IW_RETRY_LIMIT;
vwrq->value = (int)local->config.shortRetryLimit;
if((int)local->config.shortRetryLimit != (int)local->config.longRetryLimit)
- vwrq->flags |= IW_RETRY_SHORT;
+ vwrq->flags |= IW_RETRY_MIN;
}
return 0;
@@ -7005,7 +7005,6 @@ static int airo_set_power(struct net_dev
local->config.rmode |= RXMODE_BC_MC_ADDR;
set_bit (FLAG_COMMIT, &local->flags);
case IW_POWER_ON:
- /* This is broken, fixme ;-) */
break;
default:
return -EINVAL;
diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
index 0fc267d..995c7be 100644
--- a/drivers/net/wireless/atmel.c
+++ b/drivers/net/wireless/atmel.c
@@ -1656,13 +1656,13 @@ static int atmel_set_essid(struct net_de
priv->connect_to_any_BSS = 0;
/* Check the size of the string */
- if (dwrq->length > MAX_SSID_LENGTH)
+ if (dwrq->length > MAX_SSID_LENGTH + 1)
return -E2BIG;
if (index != 0)
return -EINVAL;
- memcpy(priv->new_SSID, extra, dwrq->length);
- priv->new_SSID_size = dwrq->length;
+ memcpy(priv->new_SSID, extra, dwrq->length - 1);
+ priv->new_SSID_size = dwrq->length - 1;
}
return -EINPROGRESS;
@@ -2120,9 +2120,9 @@ static int atmel_set_retry(struct net_de
struct atmel_private *priv = netdev_priv(dev);
if (!vwrq->disabled && (vwrq->flags & IW_RETRY_LIMIT)) {
- if (vwrq->flags & IW_RETRY_LONG)
+ if (vwrq->flags & IW_RETRY_MAX)
priv->long_retry = vwrq->value;
- else if (vwrq->flags & IW_RETRY_SHORT)
+ else if (vwrq->flags & IW_RETRY_MIN)
priv->short_retry = vwrq->value;
else {
/* No modifier : set both */
@@ -2144,15 +2144,15 @@ static int atmel_get_retry(struct net_de
vwrq->disabled = 0; /* Can't be disabled */
- /* Note : by default, display the short retry number */
- if (vwrq->flags & IW_RETRY_LONG) {
- vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ /* Note : by default, display the min retry number */
+ if (vwrq->flags & IW_RETRY_MAX) {
+ vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
vwrq->value = priv->long_retry;
} else {
vwrq->flags = IW_RETRY_LIMIT;
vwrq->value = priv->short_retry;
if (priv->long_retry != priv->short_retry)
- vwrq->flags |= IW_RETRY_SHORT;
+ vwrq->flags |= IW_RETRY_MIN;
}
return 0;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index 9b7b15c..888077f 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -334,7 +334,7 @@ static int bcm43xx_wx_get_nick(struct ne
size_t len;
mutex_lock(&bcm->mutex);
- len = strlen(bcm->nick);
+ len = strlen(bcm->nick) + 1;
memcpy(extra, bcm->nick, len);
data->data.length = (__u16)len;
data->data.flags = 1;
diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
index d061fb3..7a49785 100644
--- a/drivers/net/wireless/hostap/hostap_ioctl.c
+++ b/drivers/net/wireless/hostap/hostap_ioctl.c
@@ -1412,9 +1412,9 @@ #if 0
/* what could be done, if firmware would support this.. */
if (rrq->flags & IW_RETRY_LIMIT) {
- if (rrq->flags & IW_RETRY_LONG)
+ if (rrq->flags & IW_RETRY_MAX)
HFA384X_RID_LONGRETRYLIMIT = rrq->value;
- else if (rrq->flags & IW_RETRY_SHORT)
+ else if (rrq->flags & IW_RETRY_MIN)
HFA384X_RID_SHORTRETRYLIMIT = rrq->value;
else {
HFA384X_RID_LONGRETRYLIMIT = rrq->value;
@@ -1468,14 +1468,14 @@ static int prism2_ioctl_giwretry(struct
rrq->value = le16_to_cpu(altretry);
else
rrq->value = local->manual_retry_count;
- } else if ((rrq->flags & IW_RETRY_LONG)) {
- rrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ } else if ((rrq->flags & IW_RETRY_MAX)) {
+ rrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
rrq->value = longretry;
} else {
rrq->flags = IW_RETRY_LIMIT;
rrq->value = shortretry;
if (shortretry != longretry)
- rrq->flags |= IW_RETRY_SHORT;
+ rrq->flags |= IW_RETRY_MIN;
}
}
return 0;
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index 599e2fe..3e01c3d 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -6972,7 +6972,7 @@ static int ipw2100_wx_set_essid(struct n
}
if (wrqu->essid.flags && wrqu->essid.length) {
- length = wrqu->essid.length;
+ length = wrqu->essid.length - 1;
essid = extra;
}
@@ -7065,7 +7065,7 @@ static int ipw2100_wx_get_nick(struct ne
struct ipw2100_priv *priv = ieee80211_priv(dev);
- wrqu->data.length = strlen(priv->nick);
+ wrqu->data.length = strlen(priv->nick) + 1;
memcpy(extra, priv->nick, wrqu->data.length);
wrqu->data.flags = 1; /* active */
@@ -7357,14 +7357,14 @@ static int ipw2100_wx_set_retry(struct n
goto done;
}
- if (wrqu->retry.flags & IW_RETRY_SHORT) {
+ if (wrqu->retry.flags & IW_RETRY_MIN) {
err = ipw2100_set_short_retry(priv, wrqu->retry.value);
IPW_DEBUG_WX("SET Short Retry Limit -> %d \n",
wrqu->retry.value);
goto done;
}
- if (wrqu->retry.flags & IW_RETRY_LONG) {
+ if (wrqu->retry.flags & IW_RETRY_MAX) {
err = ipw2100_set_long_retry(priv, wrqu->retry.value);
IPW_DEBUG_WX("SET Long Retry Limit -> %d \n",
wrqu->retry.value);
@@ -7397,14 +7397,14 @@ static int ipw2100_wx_get_retry(struct n
if ((wrqu->retry.flags & IW_RETRY_TYPE) == IW_RETRY_LIFETIME)
return -EINVAL;
- if (wrqu->retry.flags & IW_RETRY_LONG) {
- wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ if (wrqu->retry.flags & IW_RETRY_MAX) {
+ wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
wrqu->retry.value = priv->long_retry_limit;
} else {
wrqu->retry.flags =
(priv->short_retry_limit !=
priv->long_retry_limit) ?
- IW_RETRY_LIMIT | IW_RETRY_SHORT : IW_RETRY_LIMIT;
+ IW_RETRY_LIMIT | IW_RETRY_MIN : IW_RETRY_LIMIT;
wrqu->retry.value = priv->short_retry_limit;
}
diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
index 5685d7b..7358664 100644
--- a/drivers/net/wireless/ipw2200.c
+++ b/drivers/net/wireless/ipw2200.c
@@ -8875,6 +8875,8 @@ static int ipw_wx_set_essid(struct net_d
}
length = min((int)wrqu->essid.length, IW_ESSID_MAX_SIZE);
+ if (!extra[length - 1])
+ length--;
priv->config |= CFG_STATIC_ESSID;
@@ -8951,7 +8953,7 @@ static int ipw_wx_get_nick(struct net_de
struct ipw_priv *priv = ieee80211_priv(dev);
IPW_DEBUG_WX("Getting nick\n");
mutex_lock(&priv->mutex);
- wrqu->data.length = strlen(priv->nick);
+ wrqu->data.length = strlen(priv->nick) + 1;
memcpy(extra, priv->nick, wrqu->data.length);
wrqu->data.flags = 1; /* active */
mutex_unlock(&priv->mutex);
@@ -9274,9 +9276,9 @@ static int ipw_wx_set_retry(struct net_d
return -EINVAL;
mutex_lock(&priv->mutex);
- if (wrqu->retry.flags & IW_RETRY_SHORT)
+ if (wrqu->retry.flags & IW_RETRY_MIN)
priv->short_retry_limit = (u8) wrqu->retry.value;
- else if (wrqu->retry.flags & IW_RETRY_LONG)
+ else if (wrqu->retry.flags & IW_RETRY_MAX)
priv->long_retry_limit = (u8) wrqu->retry.value;
else {
priv->short_retry_limit = (u8) wrqu->retry.value;
@@ -9305,11 +9307,11 @@ static int ipw_wx_get_retry(struct net_d
return -EINVAL;
}
- if (wrqu->retry.flags & IW_RETRY_LONG) {
- wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ if (wrqu->retry.flags & IW_RETRY_MAX) {
+ wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
wrqu->retry.value = priv->long_retry_limit;
- } else if (wrqu->retry.flags & IW_RETRY_SHORT) {
- wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_SHORT;
+ } else if (wrqu->retry.flags & IW_RETRY_MIN) {
+ wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MIN;
wrqu->retry.value = priv->short_retry_limit;
} else {
wrqu->retry.flags = IW_RETRY_LIMIT;
diff --git a/drivers/net/wireless/orinoco.c b/drivers/net/wireless/orinoco.c
index 9e19a96..1840b69 100644
--- a/drivers/net/wireless/orinoco.c
+++ b/drivers/net/wireless/orinoco.c
@@ -3037,7 +3037,7 @@ static int orinoco_ioctl_getessid(struct
}
erq->flags = 1;
- erq->length = strlen(essidbuf);
+ erq->length = strlen(essidbuf) + 1;
return 0;
}
@@ -3078,7 +3078,7 @@ static int orinoco_ioctl_getnick(struct
memcpy(nickbuf, priv->nick, IW_ESSID_MAX_SIZE+1);
orinoco_unlock(priv, &flags);
- nrq->length = strlen(nickbuf);
+ nrq->length = strlen(nickbuf)+1;
return 0;
}
@@ -3575,14 +3575,14 @@ static int orinoco_ioctl_getretry(struct
rrq->value = lifetime * 1000; /* ??? */
} else {
/* By default, display the min number */
- if ((rrq->flags & IW_RETRY_LONG)) {
- rrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ if ((rrq->flags & IW_RETRY_MAX)) {
+ rrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
rrq->value = long_limit;
} else {
rrq->flags = IW_RETRY_LIMIT;
rrq->value = short_limit;
if(short_limit != long_limit)
- rrq->flags |= IW_RETRY_SHORT;
+ rrq->flags |= IW_RETRY_MIN;
}
}
diff --git a/drivers/net/wireless/prism54/isl_ioctl.c b/drivers/net/wireless/prism54/isl_ioctl.c
index 286325c..c09fbf7 100644
--- a/drivers/net/wireless/prism54/isl_ioctl.c
+++ b/drivers/net/wireless/prism54/isl_ioctl.c
@@ -742,9 +742,9 @@ prism54_set_essid(struct net_device *nde
/* Check if we were asked for `any' */
if (dwrq->flags && dwrq->length) {
- if (dwrq->length > 32)
+ if (dwrq->length > min(33, IW_ESSID_MAX_SIZE + 1))
return -E2BIG;
- essid.length = dwrq->length;
+ essid.length = dwrq->length - 1;
memcpy(essid.octets, extra, dwrq->length);
} else
essid.length = 0;
@@ -814,7 +814,7 @@ prism54_get_nick(struct net_device *ndev
dwrq->length = 0;
down_read(&priv->mib_sem);
- dwrq->length = strlen(priv->nickname);
+ dwrq->length = strlen(priv->nickname) + 1;
memcpy(extra, priv->nickname, dwrq->length);
up_read(&priv->mib_sem);
@@ -992,9 +992,9 @@ prism54_set_retry(struct net_device *nde
return -EINVAL;
if (vwrq->flags & IW_RETRY_LIMIT) {
- if (vwrq->flags & IW_RETRY_SHORT)
+ if (vwrq->flags & IW_RETRY_MIN)
slimit = vwrq->value;
- else if (vwrq->flags & IW_RETRY_LONG)
+ else if (vwrq->flags & IW_RETRY_MAX)
llimit = vwrq->value;
else {
/* we are asked to set both */
@@ -1035,18 +1035,18 @@ prism54_get_retry(struct net_device *nde
mgt_get_request(priv, DOT11_OID_MAXTXLIFETIME, 0, NULL, &r);
vwrq->value = r.u * 1024;
vwrq->flags = IW_RETRY_LIFETIME;
- } else if ((vwrq->flags & IW_RETRY_LONG)) {
+ } else if ((vwrq->flags & IW_RETRY_MAX)) {
/* we are asked for the long retry limit */
rvalue |=
mgt_get_request(priv, DOT11_OID_LONGRETRIES, 0, NULL, &r);
vwrq->value = r.u;
- vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
} else {
/* default. get the short retry limit */
rvalue |=
mgt_get_request(priv, DOT11_OID_SHORTRETRIES, 0, NULL, &r);
vwrq->value = r.u;
- vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_SHORT;
+ vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MIN;
}
return rvalue;
diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
index e82548e..4574290 100644
--- a/drivers/net/wireless/ray_cs.c
+++ b/drivers/net/wireless/ray_cs.c
@@ -1173,7 +1173,7 @@ static int ray_set_essid(struct net_devi
return -EOPNOTSUPP;
} else {
/* Check the size of the string */
- if(dwrq->length > IW_ESSID_MAX_SIZE) {
+ if(dwrq->length > IW_ESSID_MAX_SIZE + 1) {
return -E2BIG;
}
diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
index e3ae5f6..e0d294c 100644
--- a/drivers/net/wireless/wl3501_cs.c
+++ b/drivers/net/wireless/wl3501_cs.c
@@ -1802,15 +1802,15 @@ static int wl3501_get_retry(struct net_d
&retry, sizeof(retry));
if (rc)
goto out;
- if (wrqu->retry.flags & IW_RETRY_LONG) {
- wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
+ if (wrqu->retry.flags & IW_RETRY_MAX) {
+ wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
goto set_value;
}
rc = wl3501_get_mib_value(this, WL3501_MIB_ATTR_SHORT_RETRY_LIMIT,
&retry, sizeof(retry));
if (rc)
goto out;
- wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_SHORT;
+ wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MIN;
set_value:
wrqu->retry.value = retry;
wrqu->retry.disabled = 0;
diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
index 80af9a9..f50ec10 100644
--- a/drivers/net/wireless/zd1201.c
+++ b/drivers/net/wireless/zd1201.c
@@ -1218,7 +1218,7 @@ static int zd1201_set_essid(struct net_d
return -EINVAL;
if (data->length < 1)
data->length = 1;
- zd->essidlen = data->length;
+ zd->essidlen = data->length-1;
memset(zd->essid, 0, IW_ESSID_MAX_SIZE+1);
memcpy(zd->essid, essid, data->length);
return zd1201_join(zd, zd->essid, zd->essidlen);
diff --git a/drivers/net/wireless/zd1211rw/zd_netdev.c b/drivers/net/wireless/zd1211rw/zd_netdev.c
index af3a7b3..440ef24 100644
--- a/drivers/net/wireless/zd1211rw/zd_netdev.c
+++ b/drivers/net/wireless/zd1211rw/zd_netdev.c
@@ -82,7 +82,7 @@ static int iw_get_nick(struct net_device
union iwreq_data *req, char *extra)
{
strcpy(extra, "zd1211");
- req->data.length = strlen(extra);
+ req->data.length = strlen(extra) + 1;
req->data.flags = 1;
return 0;
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9264139..f159c72 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -334,6 +334,7 @@ #define NETIF_F_ALL_CSUM (NETIF_F_IP_CSU
struct net_device_stats* (*get_stats)(struct net_device *dev);
+ struct iw_statistics* (*get_wireless_stats)(struct net_device *dev);
/* List of functions to handle Wireless Extensions (instead of ioctl).
* See <net/iw_handler.h> for details. Jean II */
diff --git a/include/linux/wireless.h b/include/linux/wireless.h
index a50a013..1358856 100644
--- a/include/linux/wireless.h
+++ b/include/linux/wireless.h
@@ -1,7 +1,7 @@
/*
* This file define a set of standard wireless extensions
*
- * Version : 21 14.3.06
+ * Version : 20 17.2.06
*
* Authors : Jean Tourrilhes - HPL - <[email protected]>
* Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved.
@@ -69,14 +69,9 @@ #define _LINUX_WIRELESS_H
/***************************** INCLUDES *****************************/
-/* This header is used in user-space, therefore need to be sanitised
- * for that purpose. Those includes are usually not compatible with glibc.
- * To know which includes to use in user-space, check iwlib.h. */
-#ifdef __KERNEL__
#include <linux/types.h> /* for "caddr_t" et al */
#include <linux/socket.h> /* for "struct sockaddr" et al */
#include <linux/if.h> /* for IFNAMSIZ and co... */
-#endif /* __KERNEL__ */
/***************************** VERSION *****************************/
/*
@@ -85,7 +80,7 @@ #endif /* __KERNEL__ */
* (there is some stuff that will be added in the future...)
* I just plan to increment with each new version.
*/
-#define WIRELESS_EXT 21
+#define WIRELESS_EXT 20
/*
* Changes :
@@ -213,14 +208,6 @@ #define WIRELESS_EXT 21
* V19 to V20
* ----------
* - RtNetlink requests support (SET/GET)
- *
- * V20 to V21
- * ----------
- * - Remove (struct net_device *)->get_wireless_stats()
- * - Change length in ESSID and NICK to strlen() instead of strlen()+1
- * - Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers
- * - Power/Retry relative values no longer * 100000
- * - Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI
*/
/**************************** CONSTANTS ****************************/
@@ -461,7 +448,6 @@ #define IW_QUAL_DBM 0x08 /* Level + Noi
#define IW_QUAL_QUAL_INVALID 0x10 /* Driver doesn't provide value */
#define IW_QUAL_LEVEL_INVALID 0x20
#define IW_QUAL_NOISE_INVALID 0x40
-#define IW_QUAL_RCPI 0x80 /* Level + Noise are 802.11k RCPI */
#define IW_QUAL_ALL_INVALID 0x70
/* Frequency flags */
@@ -514,12 +500,10 @@ #define IW_RETRY_ON 0x0000 /* No detail
#define IW_RETRY_TYPE 0xF000 /* Type of parameter */
#define IW_RETRY_LIMIT 0x1000 /* Maximum number of retries*/
#define IW_RETRY_LIFETIME 0x2000 /* Maximum duration of retries in us */
-#define IW_RETRY_MODIFIER 0x00FF /* Modify a parameter */
+#define IW_RETRY_MODIFIER 0x000F /* Modify a parameter */
#define IW_RETRY_MIN 0x0001 /* Value is a minimum */
#define IW_RETRY_MAX 0x0002 /* Value is a maximum */
#define IW_RETRY_RELATIVE 0x0004 /* Value is not in seconds/ms/us */
-#define IW_RETRY_SHORT 0x0010 /* Value is for short packets */
-#define IW_RETRY_LONG 0x0020 /* Value is for long packets */
/* Scanning request flags */
#define IW_SCAN_DEFAULT 0x0000 /* Default scan of the driver */
@@ -1033,7 +1017,7 @@ struct iw_range
/* Note : this frequency list doesn't need to fit channel numbers,
* because each entry contain its channel index */
- __u32 enc_capa; /* IW_ENC_CAPA_* bit field */
+ __u32 enc_capa; /* IW_ENC_CAPA_* bit field */
};
/*
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index f47f319..1347276 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -344,6 +344,8 @@ static ssize_t wireless_show(struct clas
if(dev->wireless_handlers &&
dev->wireless_handlers->get_wireless_stats)
iw = dev->wireless_handlers->get_wireless_stats(dev);
+ else if (dev->get_wireless_stats)
+ iw = dev->get_wireless_stats(dev);
if (iw != NULL)
ret = (*format)(iw, buf);
}
@@ -463,7 +465,8 @@ int netdev_register_sysfs(struct net_dev
*groups++ = &netstat_group;
#ifdef WIRELESS_EXT
- if (net->wireless_handlers && net->wireless_handlers->get_wireless_stats)
+ if (net->get_wireless_stats
+ || (net->wireless_handlers && net->wireless_handlers->get_wireless_stats))
*groups++ = &wireless_group;
#endif
diff --git a/net/core/wireless.c b/net/core/wireless.c
index ffff0da..3168fca 100644
--- a/net/core/wireless.c
+++ b/net/core/wireless.c
@@ -68,14 +68,6 @@
*
* v8 - 17.02.06 - Jean II
* o RtNetlink requests support (SET/GET)
- *
- * v8b - 03.08.06 - Herbert Xu
- * o Fix Wireless Event locking issues.
- *
- * v9 - 14.3.06 - Jean II
- * o Change length in ESSID and NICK to strlen() instead of strlen()+1
- * o Make standard_ioctl_num and standard_event_num unsigned
- * o Remove (struct net_device *)->get_wireless_stats()
*/
/***************************** INCLUDES *****************************/
@@ -242,24 +234,24 @@ static const struct iw_ioctl_description
[SIOCSIWESSID - SIOCIWFIRST] = {
.header_type = IW_HEADER_TYPE_POINT,
.token_size = 1,
- .max_tokens = IW_ESSID_MAX_SIZE,
+ .max_tokens = IW_ESSID_MAX_SIZE + 1,
.flags = IW_DESCR_FLAG_EVENT,
},
[SIOCGIWESSID - SIOCIWFIRST] = {
.header_type = IW_HEADER_TYPE_POINT,
.token_size = 1,
- .max_tokens = IW_ESSID_MAX_SIZE,
+ .max_tokens = IW_ESSID_MAX_SIZE + 1,
.flags = IW_DESCR_FLAG_DUMP,
},
[SIOCSIWNICKN - SIOCIWFIRST] = {
.header_type = IW_HEADER_TYPE_POINT,
.token_size = 1,
- .max_tokens = IW_ESSID_MAX_SIZE,
+ .max_tokens = IW_ESSID_MAX_SIZE + 1,
},
[SIOCGIWNICKN - SIOCIWFIRST] = {
.header_type = IW_HEADER_TYPE_POINT,
.token_size = 1,
- .max_tokens = IW_ESSID_MAX_SIZE,
+ .max_tokens = IW_ESSID_MAX_SIZE + 1,
},
[SIOCSIWRATE - SIOCIWFIRST] = {
.header_type = IW_HEADER_TYPE_PARAM,
@@ -346,8 +338,8 @@ static const struct iw_ioctl_description
.max_tokens = sizeof(struct iw_pmksa),
},
};
-static const unsigned standard_ioctl_num = (sizeof(standard_ioctl) /
- sizeof(struct iw_ioctl_description));
+static const int standard_ioctl_num = (sizeof(standard_ioctl) /
+ sizeof(struct iw_ioctl_description));
/*
* Meta-data about all the additional standard Wireless Extension events
@@ -397,8 +389,8 @@ static const struct iw_ioctl_description
.max_tokens = sizeof(struct iw_pmkid_cand),
},
};
-static const unsigned standard_event_num = (sizeof(standard_event) /
- sizeof(struct iw_ioctl_description));
+static const int standard_event_num = (sizeof(standard_event) /
+ sizeof(struct iw_ioctl_description));
/* Size (in bytes) of the various private data types */
static const char iw_priv_type_size[] = {
@@ -473,6 +465,17 @@ static inline struct iw_statistics *get_
(dev->wireless_handlers->get_wireless_stats != NULL))
return dev->wireless_handlers->get_wireless_stats(dev);
+ /* Old location, field to be removed in next WE */
+ if(dev->get_wireless_stats) {
+ static int printed_message;
+
+ if (!printed_message++)
+ printk(KERN_DEBUG "%s (WE) : Driver using old /proc/net/wireless support, please fix driver !\n",
+ dev->name);
+
+ return dev->get_wireless_stats(dev);
+ }
+
/* Not found */
return (struct iw_statistics *) NULL;
}
@@ -1840,33 +1843,8 @@ #endif /* CONFIG_NET_WIRELESS_RTNETLINK
*/
#ifdef WE_EVENT_RTNETLINK
-/* ---------------------------------------------------------------- */
-/*
- * Locking...
- * ----------
- *
- * Thanks to Herbert Xu <[email protected]> for fixing
- * the locking issue in here and implementing this code !
- *
- * The issue : wireless_send_event() is often called in interrupt context,
- * while the Netlink layer can never be called in interrupt context.
- * The fully formed RtNetlink events are queued, and then a tasklet is run
- * to feed those to Netlink.
- * The skb_queue is interrupt safe, and its lock is not held while calling
- * Netlink, so there is no possibility of dealock.
- * Jean II
- */
-
static struct sk_buff_head wireless_nlevent_queue;
-static int __init wireless_nlevent_init(void)
-{
- skb_queue_head_init(&wireless_nlevent_queue);
- return 0;
-}
-
-subsys_initcall(wireless_nlevent_init);
-
static void wireless_nlevent_process(unsigned long data)
{
struct sk_buff *skb;
@@ -1943,6 +1921,13 @@ static inline void rtmsg_iwinfo(struct n
tasklet_schedule(&wireless_nlevent_tasklet);
}
+static int __init wireless_nlevent_init(void)
+{
+ skb_queue_head_init(&wireless_nlevent_queue);
+ return 0;
+}
+
+subsys_initcall(wireless_nlevent_init);
#endif /* WE_EVENT_RTNETLINK */
/* ---------------------------------------------------------------- */
diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
index 2aa779d..75320b6 100644
--- a/net/ieee80211/softmac/ieee80211softmac_wx.c
+++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
@@ -80,10 +80,10 @@ ieee80211softmac_wx_set_essid(struct net
* If it's our network, ignore the change, we're already doing it!
*/
if((sm->associnfo.associating || sm->associated) &&
- (data->essid.flags && data->essid.length)) {
+ (data->essid.flags && data->essid.length && extra)) {
/* Get the associating network */
n = ieee80211softmac_get_network_by_bssid(sm, sm->associnfo.bssid);
- if(n && n->essid.len == data->essid.length &&
+ if(n && n->essid.len == (data->essid.length - 1) &&
!memcmp(n->essid.data, extra, n->essid.len)) {
dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
MAC_ARG(sm->associnfo.bssid));
@@ -109,8 +109,8 @@ ieee80211softmac_wx_set_essid(struct net
sm->associnfo.static_essid = 0;
sm->associnfo.assoc_wait = 0;
- if (data->essid.flags && data->essid.length) {
- length = min((int)data->essid.length, IW_ESSID_MAX_SIZE);
+ if (data->essid.flags && data->essid.length && extra /*required?*/) {
+ length = min(data->essid.length - 1, IW_ESSID_MAX_SIZE);
if (length) {
memcpy(sm->associnfo.req_essid.data, extra, length);
sm->associnfo.static_essid = 1;
--
John W. Linville
[email protected]
On Tue, 3 Oct 2006, John W. Linville wrote:
>
> I.E. With "WE-21 aware" tools already in the wild, it isn't now clear
> to me how WE can evolve any further than WE-20.
Well, if you get a WE-22 out soon enough, the situation will be one where
people who are fast at updating will have a fixed version quickly, and the
ones that aren't quick at updating will never have even seen the broken
case.
And without any actual release kernel actually having had the issue, we
should be pretty well off - the only people who actually saw semantics
change were people who build their own kernels etc, and those people
aren't the problem cases.
The users that you need to care about are the ones that upgrade rather
seldom and/or need to maintain a stable setup for other reasons (eg it's
not at all unheard of to have a common base release, but then have certain
machines on the network with more modern kernels because they have new
hardware that requires a modern kernel for support, for example: that's
the situation where you may want to have a much older common user space,
even if you have a new kernel).
Kernel developers tend to be happy to upgrade their user programs, and
don't generally see it as a big problem. The people for whom it is a
problem are elsewhere :)
Linus
On Tue, Oct 03, 2006 at 02:59:16PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 3 Oct 2006, John W. Linville wrote:
> >
> > I.E. With "WE-21 aware" tools already in the wild, it isn't now clear
> > to me how WE can evolve any further than WE-20.
>
> Well, if you get a WE-22 out soon enough, the situation will be one where
> people who are fast at updating will have a fixed version quickly, and the
> ones that aren't quick at updating will never have even seen the broken
> case.
Wrong.
Slackware has just released with WE-21 aware tools. Users of
this version of Slackware will never see anything else than WE-21
aware tools. And if there is a distro and users which are
conservative, this is Slackware.
Same deal for Mandriva 2007.
Regards,
Jean
Jean Tourrilhes wrote:
> Wrong.
> Slackware has just released with WE-21 aware tools. Users of
> this version of Slackware will never see anything else than WE-21
> aware tools. And if there is a distro and users which are
> conservative, this is Slackware.
> Same deal for Mandriva 2007.
And those distros have the standard option of doing what you always do
when you release based on an unreleased API...
Jeff
On Tue, Oct 03, 2006 at 05:48:11PM -0400, Jeff Garzik wrote:
> John W. Linville wrote:
> >Unfortunately, I don't see any way to "fix" WE-21 without similarly
> >breaking wireless-tools 29 and other "WE-21 aware" apps. And since
> >I'll bet that the various WE-aware apps have checks like "if WE >
> >20" for managing ESSID length settings, we may have painted ourselves
> >into a korner (sic).
>
> The apps are based on a pre-release kernel, which everyone knows could
> change, precisely for reasons like this. Sounds like somebody took a
> risk, and lost...
>
> Jeff
Jeff,
Let's not make a mountain of this molehill. If you want to use
old versions of Wireless Tools and wpa_supplicant with WE-21, what you
need is just to add a dummy character at the end of your ESSID. And
everything will be fine.
Also, there is no other way to update cleanly a kernel API
than to push userspace first. I think I took way more care in term of
smoothing over the API transition than any other kernel subsystem, so
I don't know what could have been done better. I don't remember this
level of flamewar when those other subsystems did change their
userspace APIs.
I try to be constructive about all this, so let's find a way
forward without loosing perspective.
Regards,
Jean
On Tue, Oct 03, 2006 at 10:23:27AM -0700, Jean Tourrilhes wrote:
> In the past, I personally tried to upgrade Red-Hat Workstation
> 4 with a pristine 2.6 kernel. This was far from trivial, as Red-Hat
> did compile their kernel with some weird options/patches, and
> userspace (libc) were expecting those.
I (well, me and my team) am supporting a customer using a RHEL 4
userspace and a 2.6.16 kernel with Ingo's real-time patches. We just
used Red Hat config file as the basis, and it wasn't that hard. There
were some initrd breakages, which I've complained about in the past,
but the goal is that this sort of thing is supposed to work! (And for
the most part, it does).
> On the other hand, I've been personally running the latest
> 2.6.X kernels on Debian stable for as long as 2.6.X was
> available. And, things *do* break, in the past I had trouble with
> module tools, I can't run devfs or udev, Pcmcia is on the verge of
> breaking, etc...
I'm currently using the latest 2.6 kernel with Ubuntu 6.06 (their
stable release), and to date, I haven't had any problems.
Of course, that may be about to change, given that Ubuntu is shipping
with wireless-tools version "27+28pre13-1ub", which I assume is a
version between 27 and 28. Do you know off-hand whether this is is
WE-21 capable?
- Ted
Jean Tourrilhes wrote:
> Let's not make a mountain of this molehill. If you want to use
> old versions of Wireless Tools and wpa_supplicant with WE-21, what you
> need is just to add a dummy character at the end of your ESSID. And
> everything will be fine.
FALSE. Old apps are by definition already in place. "all you need to
do..." is an impossible condition to satisfy.
> Also, there is no other way to update cleanly a kernel API
> than to push userspace first. I think I took way more care in term of
> smoothing over the API transition than any other kernel subsystem, so
> I don't know what could have been done better. I don't remember this
> level of flamewar when those other subsystems did change their
> userspace APIs.
Userspace APIs can change, as long as they remain backwards compatible.
Just follow LKML to see all the flack people get, when userspace APIs
change in an incompatible way. Or heck, just look at the changelog for
the patches we revert, when such brokenness is detected.
Finally, until an API is actually in a kernel release, it has the
potential to change. That's just a fact of Linux development. I
certainly understand trying to get stuff out ahead of a kernel release,
but you must understand the negative consequences of doing so, when
something goes wrong. Like it did here.
Jeff
On Tue, Oct 03, 2006 at 06:30:29PM -0400, Theodore Tso wrote:
>
> I'm currently using the latest 2.6 kernel with Ubuntu 6.06 (their
> stable release), and to date, I haven't had any problems.
>
> Of course, that may be about to change, given that Ubuntu is shipping
> with wireless-tools version "27+28pre13-1ub", which I assume is a
> version between 27 and 28. Do you know off-hand whether this is is
> WE-21 capable?
No it's not.
> - Ted
Jean
We are ready and looking forward to d80211 stack but When it will be in
the Kernel?
John W. Linville wrote:
> On Tue, Oct 03, 2006 at 02:59:29PM -0400, Jeff Garzik wrote:
>
>> Jean Tourrilhes wrote:
>>
>>> Now it's too late, those changes have propagated to userspace
>>> tools, and are now shipping in some actual release of some distro. So,
>>> what are we going to say to Mandriva 2007 and FC6 users, to revert
>>> back to an *older* version of the tools ?
>>> Because userspace has already been updated, we have only two
>>> options, merge it now, or in 2.6.20.
>>>
>> If the choice is between the ABI used by a bunch of distros in
>> production, and the ABI used by two re-release distros, I think the
>> choice is obvious...
>>
>
> I (grudgingly?) agree...
>
> Unfortunately, I don't see any way to "fix" WE-21 without similarly
> breaking wireless-tools 29 and other "WE-21 aware" apps. And since
> I'll bet that the various WE-aware apps have checks like "if WE >
> 20" for managing ESSID length settings, we may have painted ourselves
> into a korner (sic).
>
> I.E. With "WE-21 aware" tools already in the wild, it isn't now clear
> to me how WE can evolve any further than WE-20. Unless the ESSID
> length changes in WE-21 is somehow deemed acceptable for 2.6.20 or
> some later kernel version, I don't see how WE can continue to change.
>
> Wireless developers, it's time to get d80211 ready to merge...or
> figure-out how to get nl80211 on the current stack...hmmm...
>
> John
>
> ---
>
> The following changes since commit 8ccb3dcd1f8e80e8702642e1de26541b52f6bb7c:
> Linus Torvalds:
> x86: Fix booting with "no387 nofxsr"
>
> are found in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git we21-revert
>
> John W. Linville:
> wireless: revert WE-21 patches
>
> drivers/net/wireless/airo.c | 19 ++++----
> drivers/net/wireless/atmel.c | 18 ++++---
> drivers/net/wireless/bcm43xx/bcm43xx_wx.c | 2 -
> drivers/net/wireless/hostap/hostap_ioctl.c | 10 ++--
> drivers/net/wireless/ipw2100.c | 14 +++---
> drivers/net/wireless/ipw2200.c | 16 ++++--
> drivers/net/wireless/orinoco.c | 10 ++--
> drivers/net/wireless/prism54/isl_ioctl.c | 16 +++---
> drivers/net/wireless/ray_cs.c | 2 -
> drivers/net/wireless/wl3501_cs.c | 6 +-
> drivers/net/wireless/zd1201.c | 2 -
> drivers/net/wireless/zd1211rw/zd_netdev.c | 2 -
> include/linux/netdevice.h | 1
> include/linux/wireless.h | 24 ++--------
> net/core/net-sysfs.c | 5 ++
> net/core/wireless.c | 67 ++++++++++-----------------
> net/ieee80211/softmac/ieee80211softmac_wx.c | 8 ++-
> 17 files changed, 98 insertions(+), 124 deletions(-)
>
> diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
> index 39d0934..1864b07 100644
> --- a/drivers/net/wireless/airo.c
> +++ b/drivers/net/wireless/airo.c
> @@ -5883,7 +5883,7 @@ static int airo_set_essid(struct net_dev
> int index = (dwrq->flags & IW_ENCODE_INDEX) - 1;
>
> /* Check the size of the string */
> - if(dwrq->length > IW_ESSID_MAX_SIZE) {
> + if(dwrq->length > IW_ESSID_MAX_SIZE+1) {
> return -E2BIG ;
> }
> /* Check if index is valid */
> @@ -5895,7 +5895,7 @@ static int airo_set_essid(struct net_dev
> memset(SSID_rid.ssids[index].ssid, 0,
> sizeof(SSID_rid.ssids[index].ssid));
> memcpy(SSID_rid.ssids[index].ssid, extra, dwrq->length);
> - SSID_rid.ssids[index].len = dwrq->length;
> + SSID_rid.ssids[index].len = dwrq->length - 1;
> }
> SSID_rid.len = sizeof(SSID_rid);
> /* Write it to the card */
> @@ -6005,7 +6005,7 @@ static int airo_set_nick(struct net_devi
> struct airo_info *local = dev->priv;
>
> /* Check the size of the string */
> - if(dwrq->length > 16) {
> + if(dwrq->length > 16 + 1) {
> return -E2BIG;
> }
> readConfigRid(local, 1);
> @@ -6030,7 +6030,7 @@ static int airo_get_nick(struct net_devi
> readConfigRid(local, 1);
> strncpy(extra, local->config.nodeName, 16);
> extra[16] = '\0';
> - dwrq->length = strlen(extra);
> + dwrq->length = strlen(extra) + 1;
>
> return 0;
> }
> @@ -6782,9 +6782,9 @@ static int airo_set_retry(struct net_dev
> }
> readConfigRid(local, 1);
> if(vwrq->flags & IW_RETRY_LIMIT) {
> - if(vwrq->flags & IW_RETRY_LONG)
> + if(vwrq->flags & IW_RETRY_MAX)
> local->config.longRetryLimit = vwrq->value;
> - else if (vwrq->flags & IW_RETRY_SHORT)
> + else if (vwrq->flags & IW_RETRY_MIN)
> local->config.shortRetryLimit = vwrq->value;
> else {
> /* No modifier : set both */
> @@ -6820,14 +6820,14 @@ static int airo_get_retry(struct net_dev
> if((vwrq->flags & IW_RETRY_TYPE) == IW_RETRY_LIFETIME) {
> vwrq->flags = IW_RETRY_LIFETIME;
> vwrq->value = (int)local->config.txLifetime * 1024;
> - } else if((vwrq->flags & IW_RETRY_LONG)) {
> - vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + } else if((vwrq->flags & IW_RETRY_MAX)) {
> + vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> vwrq->value = (int)local->config.longRetryLimit;
> } else {
> vwrq->flags = IW_RETRY_LIMIT;
> vwrq->value = (int)local->config.shortRetryLimit;
> if((int)local->config.shortRetryLimit != (int)local->config.longRetryLimit)
> - vwrq->flags |= IW_RETRY_SHORT;
> + vwrq->flags |= IW_RETRY_MIN;
> }
>
> return 0;
> @@ -7005,7 +7005,6 @@ static int airo_set_power(struct net_dev
> local->config.rmode |= RXMODE_BC_MC_ADDR;
> set_bit (FLAG_COMMIT, &local->flags);
> case IW_POWER_ON:
> - /* This is broken, fixme ;-) */
> break;
> default:
> return -EINVAL;
> diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
> index 0fc267d..995c7be 100644
> --- a/drivers/net/wireless/atmel.c
> +++ b/drivers/net/wireless/atmel.c
> @@ -1656,13 +1656,13 @@ static int atmel_set_essid(struct net_de
> priv->connect_to_any_BSS = 0;
>
> /* Check the size of the string */
> - if (dwrq->length > MAX_SSID_LENGTH)
> + if (dwrq->length > MAX_SSID_LENGTH + 1)
> return -E2BIG;
> if (index != 0)
> return -EINVAL;
>
> - memcpy(priv->new_SSID, extra, dwrq->length);
> - priv->new_SSID_size = dwrq->length;
> + memcpy(priv->new_SSID, extra, dwrq->length - 1);
> + priv->new_SSID_size = dwrq->length - 1;
> }
>
> return -EINPROGRESS;
> @@ -2120,9 +2120,9 @@ static int atmel_set_retry(struct net_de
> struct atmel_private *priv = netdev_priv(dev);
>
> if (!vwrq->disabled && (vwrq->flags & IW_RETRY_LIMIT)) {
> - if (vwrq->flags & IW_RETRY_LONG)
> + if (vwrq->flags & IW_RETRY_MAX)
> priv->long_retry = vwrq->value;
> - else if (vwrq->flags & IW_RETRY_SHORT)
> + else if (vwrq->flags & IW_RETRY_MIN)
> priv->short_retry = vwrq->value;
> else {
> /* No modifier : set both */
> @@ -2144,15 +2144,15 @@ static int atmel_get_retry(struct net_de
>
> vwrq->disabled = 0; /* Can't be disabled */
>
> - /* Note : by default, display the short retry number */
> - if (vwrq->flags & IW_RETRY_LONG) {
> - vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + /* Note : by default, display the min retry number */
> + if (vwrq->flags & IW_RETRY_MAX) {
> + vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> vwrq->value = priv->long_retry;
> } else {
> vwrq->flags = IW_RETRY_LIMIT;
> vwrq->value = priv->short_retry;
> if (priv->long_retry != priv->short_retry)
> - vwrq->flags |= IW_RETRY_SHORT;
> + vwrq->flags |= IW_RETRY_MIN;
> }
>
> return 0;
> diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> index 9b7b15c..888077f 100644
> --- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> +++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
> @@ -334,7 +334,7 @@ static int bcm43xx_wx_get_nick(struct ne
> size_t len;
>
> mutex_lock(&bcm->mutex);
> - len = strlen(bcm->nick);
> + len = strlen(bcm->nick) + 1;
> memcpy(extra, bcm->nick, len);
> data->data.length = (__u16)len;
> data->data.flags = 1;
> diff --git a/drivers/net/wireless/hostap/hostap_ioctl.c b/drivers/net/wireless/hostap/hostap_ioctl.c
> index d061fb3..7a49785 100644
> --- a/drivers/net/wireless/hostap/hostap_ioctl.c
> +++ b/drivers/net/wireless/hostap/hostap_ioctl.c
> @@ -1412,9 +1412,9 @@ #if 0
> /* what could be done, if firmware would support this.. */
>
> if (rrq->flags & IW_RETRY_LIMIT) {
> - if (rrq->flags & IW_RETRY_LONG)
> + if (rrq->flags & IW_RETRY_MAX)
> HFA384X_RID_LONGRETRYLIMIT = rrq->value;
> - else if (rrq->flags & IW_RETRY_SHORT)
> + else if (rrq->flags & IW_RETRY_MIN)
> HFA384X_RID_SHORTRETRYLIMIT = rrq->value;
> else {
> HFA384X_RID_LONGRETRYLIMIT = rrq->value;
> @@ -1468,14 +1468,14 @@ static int prism2_ioctl_giwretry(struct
> rrq->value = le16_to_cpu(altretry);
> else
> rrq->value = local->manual_retry_count;
> - } else if ((rrq->flags & IW_RETRY_LONG)) {
> - rrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + } else if ((rrq->flags & IW_RETRY_MAX)) {
> + rrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> rrq->value = longretry;
> } else {
> rrq->flags = IW_RETRY_LIMIT;
> rrq->value = shortretry;
> if (shortretry != longretry)
> - rrq->flags |= IW_RETRY_SHORT;
> + rrq->flags |= IW_RETRY_MIN;
> }
> }
> return 0;
> diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
> index 599e2fe..3e01c3d 100644
> --- a/drivers/net/wireless/ipw2100.c
> +++ b/drivers/net/wireless/ipw2100.c
> @@ -6972,7 +6972,7 @@ static int ipw2100_wx_set_essid(struct n
> }
>
> if (wrqu->essid.flags && wrqu->essid.length) {
> - length = wrqu->essid.length;
> + length = wrqu->essid.length - 1;
> essid = extra;
> }
>
> @@ -7065,7 +7065,7 @@ static int ipw2100_wx_get_nick(struct ne
>
> struct ipw2100_priv *priv = ieee80211_priv(dev);
>
> - wrqu->data.length = strlen(priv->nick);
> + wrqu->data.length = strlen(priv->nick) + 1;
> memcpy(extra, priv->nick, wrqu->data.length);
> wrqu->data.flags = 1; /* active */
>
> @@ -7357,14 +7357,14 @@ static int ipw2100_wx_set_retry(struct n
> goto done;
> }
>
> - if (wrqu->retry.flags & IW_RETRY_SHORT) {
> + if (wrqu->retry.flags & IW_RETRY_MIN) {
> err = ipw2100_set_short_retry(priv, wrqu->retry.value);
> IPW_DEBUG_WX("SET Short Retry Limit -> %d \n",
> wrqu->retry.value);
> goto done;
> }
>
> - if (wrqu->retry.flags & IW_RETRY_LONG) {
> + if (wrqu->retry.flags & IW_RETRY_MAX) {
> err = ipw2100_set_long_retry(priv, wrqu->retry.value);
> IPW_DEBUG_WX("SET Long Retry Limit -> %d \n",
> wrqu->retry.value);
> @@ -7397,14 +7397,14 @@ static int ipw2100_wx_get_retry(struct n
> if ((wrqu->retry.flags & IW_RETRY_TYPE) == IW_RETRY_LIFETIME)
> return -EINVAL;
>
> - if (wrqu->retry.flags & IW_RETRY_LONG) {
> - wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + if (wrqu->retry.flags & IW_RETRY_MAX) {
> + wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> wrqu->retry.value = priv->long_retry_limit;
> } else {
> wrqu->retry.flags =
> (priv->short_retry_limit !=
> priv->long_retry_limit) ?
> - IW_RETRY_LIMIT | IW_RETRY_SHORT : IW_RETRY_LIMIT;
> + IW_RETRY_LIMIT | IW_RETRY_MIN : IW_RETRY_LIMIT;
>
> wrqu->retry.value = priv->short_retry_limit;
> }
> diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c
> index 5685d7b..7358664 100644
> --- a/drivers/net/wireless/ipw2200.c
> +++ b/drivers/net/wireless/ipw2200.c
> @@ -8875,6 +8875,8 @@ static int ipw_wx_set_essid(struct net_d
> }
>
> length = min((int)wrqu->essid.length, IW_ESSID_MAX_SIZE);
> + if (!extra[length - 1])
> + length--;
>
> priv->config |= CFG_STATIC_ESSID;
>
> @@ -8951,7 +8953,7 @@ static int ipw_wx_get_nick(struct net_de
> struct ipw_priv *priv = ieee80211_priv(dev);
> IPW_DEBUG_WX("Getting nick\n");
> mutex_lock(&priv->mutex);
> - wrqu->data.length = strlen(priv->nick);
> + wrqu->data.length = strlen(priv->nick) + 1;
> memcpy(extra, priv->nick, wrqu->data.length);
> wrqu->data.flags = 1; /* active */
> mutex_unlock(&priv->mutex);
> @@ -9274,9 +9276,9 @@ static int ipw_wx_set_retry(struct net_d
> return -EINVAL;
>
> mutex_lock(&priv->mutex);
> - if (wrqu->retry.flags & IW_RETRY_SHORT)
> + if (wrqu->retry.flags & IW_RETRY_MIN)
> priv->short_retry_limit = (u8) wrqu->retry.value;
> - else if (wrqu->retry.flags & IW_RETRY_LONG)
> + else if (wrqu->retry.flags & IW_RETRY_MAX)
> priv->long_retry_limit = (u8) wrqu->retry.value;
> else {
> priv->short_retry_limit = (u8) wrqu->retry.value;
> @@ -9305,11 +9307,11 @@ static int ipw_wx_get_retry(struct net_d
> return -EINVAL;
> }
>
> - if (wrqu->retry.flags & IW_RETRY_LONG) {
> - wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + if (wrqu->retry.flags & IW_RETRY_MAX) {
> + wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> wrqu->retry.value = priv->long_retry_limit;
> - } else if (wrqu->retry.flags & IW_RETRY_SHORT) {
> - wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_SHORT;
> + } else if (wrqu->retry.flags & IW_RETRY_MIN) {
> + wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MIN;
> wrqu->retry.value = priv->short_retry_limit;
> } else {
> wrqu->retry.flags = IW_RETRY_LIMIT;
> diff --git a/drivers/net/wireless/orinoco.c b/drivers/net/wireless/orinoco.c
> index 9e19a96..1840b69 100644
> --- a/drivers/net/wireless/orinoco.c
> +++ b/drivers/net/wireless/orinoco.c
> @@ -3037,7 +3037,7 @@ static int orinoco_ioctl_getessid(struct
> }
>
> erq->flags = 1;
> - erq->length = strlen(essidbuf);
> + erq->length = strlen(essidbuf) + 1;
>
> return 0;
> }
> @@ -3078,7 +3078,7 @@ static int orinoco_ioctl_getnick(struct
> memcpy(nickbuf, priv->nick, IW_ESSID_MAX_SIZE+1);
> orinoco_unlock(priv, &flags);
>
> - nrq->length = strlen(nickbuf);
> + nrq->length = strlen(nickbuf)+1;
>
> return 0;
> }
> @@ -3575,14 +3575,14 @@ static int orinoco_ioctl_getretry(struct
> rrq->value = lifetime * 1000; /* ??? */
> } else {
> /* By default, display the min number */
> - if ((rrq->flags & IW_RETRY_LONG)) {
> - rrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + if ((rrq->flags & IW_RETRY_MAX)) {
> + rrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> rrq->value = long_limit;
> } else {
> rrq->flags = IW_RETRY_LIMIT;
> rrq->value = short_limit;
> if(short_limit != long_limit)
> - rrq->flags |= IW_RETRY_SHORT;
> + rrq->flags |= IW_RETRY_MIN;
> }
> }
>
> diff --git a/drivers/net/wireless/prism54/isl_ioctl.c b/drivers/net/wireless/prism54/isl_ioctl.c
> index 286325c..c09fbf7 100644
> --- a/drivers/net/wireless/prism54/isl_ioctl.c
> +++ b/drivers/net/wireless/prism54/isl_ioctl.c
> @@ -742,9 +742,9 @@ prism54_set_essid(struct net_device *nde
>
> /* Check if we were asked for `any' */
> if (dwrq->flags && dwrq->length) {
> - if (dwrq->length > 32)
> + if (dwrq->length > min(33, IW_ESSID_MAX_SIZE + 1))
> return -E2BIG;
> - essid.length = dwrq->length;
> + essid.length = dwrq->length - 1;
> memcpy(essid.octets, extra, dwrq->length);
> } else
> essid.length = 0;
> @@ -814,7 +814,7 @@ prism54_get_nick(struct net_device *ndev
> dwrq->length = 0;
>
> down_read(&priv->mib_sem);
> - dwrq->length = strlen(priv->nickname);
> + dwrq->length = strlen(priv->nickname) + 1;
> memcpy(extra, priv->nickname, dwrq->length);
> up_read(&priv->mib_sem);
>
> @@ -992,9 +992,9 @@ prism54_set_retry(struct net_device *nde
> return -EINVAL;
>
> if (vwrq->flags & IW_RETRY_LIMIT) {
> - if (vwrq->flags & IW_RETRY_SHORT)
> + if (vwrq->flags & IW_RETRY_MIN)
> slimit = vwrq->value;
> - else if (vwrq->flags & IW_RETRY_LONG)
> + else if (vwrq->flags & IW_RETRY_MAX)
> llimit = vwrq->value;
> else {
> /* we are asked to set both */
> @@ -1035,18 +1035,18 @@ prism54_get_retry(struct net_device *nde
> mgt_get_request(priv, DOT11_OID_MAXTXLIFETIME, 0, NULL, &r);
> vwrq->value = r.u * 1024;
> vwrq->flags = IW_RETRY_LIFETIME;
> - } else if ((vwrq->flags & IW_RETRY_LONG)) {
> + } else if ((vwrq->flags & IW_RETRY_MAX)) {
> /* we are asked for the long retry limit */
> rvalue |=
> mgt_get_request(priv, DOT11_OID_LONGRETRIES, 0, NULL, &r);
> vwrq->value = r.u;
> - vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> } else {
> /* default. get the short retry limit */
> rvalue |=
> mgt_get_request(priv, DOT11_OID_SHORTRETRIES, 0, NULL, &r);
> vwrq->value = r.u;
> - vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_SHORT;
> + vwrq->flags = IW_RETRY_LIMIT | IW_RETRY_MIN;
> }
>
> return rvalue;
> diff --git a/drivers/net/wireless/ray_cs.c b/drivers/net/wireless/ray_cs.c
> index e82548e..4574290 100644
> --- a/drivers/net/wireless/ray_cs.c
> +++ b/drivers/net/wireless/ray_cs.c
> @@ -1173,7 +1173,7 @@ static int ray_set_essid(struct net_devi
> return -EOPNOTSUPP;
> } else {
> /* Check the size of the string */
> - if(dwrq->length > IW_ESSID_MAX_SIZE) {
> + if(dwrq->length > IW_ESSID_MAX_SIZE + 1) {
> return -E2BIG;
> }
>
> diff --git a/drivers/net/wireless/wl3501_cs.c b/drivers/net/wireless/wl3501_cs.c
> index e3ae5f6..e0d294c 100644
> --- a/drivers/net/wireless/wl3501_cs.c
> +++ b/drivers/net/wireless/wl3501_cs.c
> @@ -1802,15 +1802,15 @@ static int wl3501_get_retry(struct net_d
> &retry, sizeof(retry));
> if (rc)
> goto out;
> - if (wrqu->retry.flags & IW_RETRY_LONG) {
> - wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_LONG;
> + if (wrqu->retry.flags & IW_RETRY_MAX) {
> + wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MAX;
> goto set_value;
> }
> rc = wl3501_get_mib_value(this, WL3501_MIB_ATTR_SHORT_RETRY_LIMIT,
> &retry, sizeof(retry));
> if (rc)
> goto out;
> - wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_SHORT;
> + wrqu->retry.flags = IW_RETRY_LIMIT | IW_RETRY_MIN;
> set_value:
> wrqu->retry.value = retry;
> wrqu->retry.disabled = 0;
> diff --git a/drivers/net/wireless/zd1201.c b/drivers/net/wireless/zd1201.c
> index 80af9a9..f50ec10 100644
> --- a/drivers/net/wireless/zd1201.c
> +++ b/drivers/net/wireless/zd1201.c
> @@ -1218,7 +1218,7 @@ static int zd1201_set_essid(struct net_d
> return -EINVAL;
> if (data->length < 1)
> data->length = 1;
> - zd->essidlen = data->length;
> + zd->essidlen = data->length-1;
> memset(zd->essid, 0, IW_ESSID_MAX_SIZE+1);
> memcpy(zd->essid, essid, data->length);
> return zd1201_join(zd, zd->essid, zd->essidlen);
> diff --git a/drivers/net/wireless/zd1211rw/zd_netdev.c b/drivers/net/wireless/zd1211rw/zd_netdev.c
> index af3a7b3..440ef24 100644
> --- a/drivers/net/wireless/zd1211rw/zd_netdev.c
> +++ b/drivers/net/wireless/zd1211rw/zd_netdev.c
> @@ -82,7 +82,7 @@ static int iw_get_nick(struct net_device
> union iwreq_data *req, char *extra)
> {
> strcpy(extra, "zd1211");
> - req->data.length = strlen(extra);
> + req->data.length = strlen(extra) + 1;
> req->data.flags = 1;
> return 0;
> }
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 9264139..f159c72 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -334,6 +334,7 @@ #define NETIF_F_ALL_CSUM (NETIF_F_IP_CSU
>
>
> struct net_device_stats* (*get_stats)(struct net_device *dev);
> + struct iw_statistics* (*get_wireless_stats)(struct net_device *dev);
>
> /* List of functions to handle Wireless Extensions (instead of ioctl).
> * See <net/iw_handler.h> for details. Jean II */
> diff --git a/include/linux/wireless.h b/include/linux/wireless.h
> index a50a013..1358856 100644
> --- a/include/linux/wireless.h
> +++ b/include/linux/wireless.h
> @@ -1,7 +1,7 @@
> /*
> * This file define a set of standard wireless extensions
> *
> - * Version : 21 14.3.06
> + * Version : 20 17.2.06
> *
> * Authors : Jean Tourrilhes - HPL - <[email protected]>
> * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved.
> @@ -69,14 +69,9 @@ #define _LINUX_WIRELESS_H
>
> /***************************** INCLUDES *****************************/
>
> -/* This header is used in user-space, therefore need to be sanitised
> - * for that purpose. Those includes are usually not compatible with glibc.
> - * To know which includes to use in user-space, check iwlib.h. */
> -#ifdef __KERNEL__
> #include <linux/types.h> /* for "caddr_t" et al */
> #include <linux/socket.h> /* for "struct sockaddr" et al */
> #include <linux/if.h> /* for IFNAMSIZ and co... */
> -#endif /* __KERNEL__ */
>
> /***************************** VERSION *****************************/
> /*
> @@ -85,7 +80,7 @@ #endif /* __KERNEL__ */
> * (there is some stuff that will be added in the future...)
> * I just plan to increment with each new version.
> */
> -#define WIRELESS_EXT 21
> +#define WIRELESS_EXT 20
>
> /*
> * Changes :
> @@ -213,14 +208,6 @@ #define WIRELESS_EXT 21
> * V19 to V20
> * ----------
> * - RtNetlink requests support (SET/GET)
> - *
> - * V20 to V21
> - * ----------
> - * - Remove (struct net_device *)->get_wireless_stats()
> - * - Change length in ESSID and NICK to strlen() instead of strlen()+1
> - * - Add IW_RETRY_SHORT/IW_RETRY_LONG retry modifiers
> - * - Power/Retry relative values no longer * 100000
> - * - Add explicit flag to tell stats are in 802.11k RCPI : IW_QUAL_RCPI
> */
>
> /**************************** CONSTANTS ****************************/
> @@ -461,7 +448,6 @@ #define IW_QUAL_DBM 0x08 /* Level + Noi
> #define IW_QUAL_QUAL_INVALID 0x10 /* Driver doesn't provide value */
> #define IW_QUAL_LEVEL_INVALID 0x20
> #define IW_QUAL_NOISE_INVALID 0x40
> -#define IW_QUAL_RCPI 0x80 /* Level + Noise are 802.11k RCPI */
> #define IW_QUAL_ALL_INVALID 0x70
>
> /* Frequency flags */
> @@ -514,12 +500,10 @@ #define IW_RETRY_ON 0x0000 /* No detail
> #define IW_RETRY_TYPE 0xF000 /* Type of parameter */
> #define IW_RETRY_LIMIT 0x1000 /* Maximum number of retries*/
> #define IW_RETRY_LIFETIME 0x2000 /* Maximum duration of retries in us */
> -#define IW_RETRY_MODIFIER 0x00FF /* Modify a parameter */
> +#define IW_RETRY_MODIFIER 0x000F /* Modify a parameter */
> #define IW_RETRY_MIN 0x0001 /* Value is a minimum */
> #define IW_RETRY_MAX 0x0002 /* Value is a maximum */
> #define IW_RETRY_RELATIVE 0x0004 /* Value is not in seconds/ms/us */
> -#define IW_RETRY_SHORT 0x0010 /* Value is for short packets */
> -#define IW_RETRY_LONG 0x0020 /* Value is for long packets */
>
> /* Scanning request flags */
> #define IW_SCAN_DEFAULT 0x0000 /* Default scan of the driver */
> @@ -1033,7 +1017,7 @@ struct iw_range
> /* Note : this frequency list doesn't need to fit channel numbers,
> * because each entry contain its channel index */
>
> - __u32 enc_capa; /* IW_ENC_CAPA_* bit field */
> + __u32 enc_capa; /* IW_ENC_CAPA_* bit field */
> };
>
> /*
> diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
> index f47f319..1347276 100644
> --- a/net/core/net-sysfs.c
> +++ b/net/core/net-sysfs.c
> @@ -344,6 +344,8 @@ static ssize_t wireless_show(struct clas
> if(dev->wireless_handlers &&
> dev->wireless_handlers->get_wireless_stats)
> iw = dev->wireless_handlers->get_wireless_stats(dev);
> + else if (dev->get_wireless_stats)
> + iw = dev->get_wireless_stats(dev);
> if (iw != NULL)
> ret = (*format)(iw, buf);
> }
> @@ -463,7 +465,8 @@ int netdev_register_sysfs(struct net_dev
> *groups++ = &netstat_group;
>
> #ifdef WIRELESS_EXT
> - if (net->wireless_handlers && net->wireless_handlers->get_wireless_stats)
> + if (net->get_wireless_stats
> + || (net->wireless_handlers && net->wireless_handlers->get_wireless_stats))
> *groups++ = &wireless_group;
> #endif
>
> diff --git a/net/core/wireless.c b/net/core/wireless.c
> index ffff0da..3168fca 100644
> --- a/net/core/wireless.c
> +++ b/net/core/wireless.c
> @@ -68,14 +68,6 @@
> *
> * v8 - 17.02.06 - Jean II
> * o RtNetlink requests support (SET/GET)
> - *
> - * v8b - 03.08.06 - Herbert Xu
> - * o Fix Wireless Event locking issues.
> - *
> - * v9 - 14.3.06 - Jean II
> - * o Change length in ESSID and NICK to strlen() instead of strlen()+1
> - * o Make standard_ioctl_num and standard_event_num unsigned
> - * o Remove (struct net_device *)->get_wireless_stats()
> */
>
> /***************************** INCLUDES *****************************/
> @@ -242,24 +234,24 @@ static const struct iw_ioctl_description
> [SIOCSIWESSID - SIOCIWFIRST] = {
> .header_type = IW_HEADER_TYPE_POINT,
> .token_size = 1,
> - .max_tokens = IW_ESSID_MAX_SIZE,
> + .max_tokens = IW_ESSID_MAX_SIZE + 1,
> .flags = IW_DESCR_FLAG_EVENT,
> },
> [SIOCGIWESSID - SIOCIWFIRST] = {
> .header_type = IW_HEADER_TYPE_POINT,
> .token_size = 1,
> - .max_tokens = IW_ESSID_MAX_SIZE,
> + .max_tokens = IW_ESSID_MAX_SIZE + 1,
> .flags = IW_DESCR_FLAG_DUMP,
> },
> [SIOCSIWNICKN - SIOCIWFIRST] = {
> .header_type = IW_HEADER_TYPE_POINT,
> .token_size = 1,
> - .max_tokens = IW_ESSID_MAX_SIZE,
> + .max_tokens = IW_ESSID_MAX_SIZE + 1,
> },
> [SIOCGIWNICKN - SIOCIWFIRST] = {
> .header_type = IW_HEADER_TYPE_POINT,
> .token_size = 1,
> - .max_tokens = IW_ESSID_MAX_SIZE,
> + .max_tokens = IW_ESSID_MAX_SIZE + 1,
> },
> [SIOCSIWRATE - SIOCIWFIRST] = {
> .header_type = IW_HEADER_TYPE_PARAM,
> @@ -346,8 +338,8 @@ static const struct iw_ioctl_description
> .max_tokens = sizeof(struct iw_pmksa),
> },
> };
> -static const unsigned standard_ioctl_num = (sizeof(standard_ioctl) /
> - sizeof(struct iw_ioctl_description));
> +static const int standard_ioctl_num = (sizeof(standard_ioctl) /
> + sizeof(struct iw_ioctl_description));
>
> /*
> * Meta-data about all the additional standard Wireless Extension events
> @@ -397,8 +389,8 @@ static const struct iw_ioctl_description
> .max_tokens = sizeof(struct iw_pmkid_cand),
> },
> };
> -static const unsigned standard_event_num = (sizeof(standard_event) /
> - sizeof(struct iw_ioctl_description));
> +static const int standard_event_num = (sizeof(standard_event) /
> + sizeof(struct iw_ioctl_description));
>
> /* Size (in bytes) of the various private data types */
> static const char iw_priv_type_size[] = {
> @@ -473,6 +465,17 @@ static inline struct iw_statistics *get_
> (dev->wireless_handlers->get_wireless_stats != NULL))
> return dev->wireless_handlers->get_wireless_stats(dev);
>
> + /* Old location, field to be removed in next WE */
> + if(dev->get_wireless_stats) {
> + static int printed_message;
> +
> + if (!printed_message++)
> + printk(KERN_DEBUG "%s (WE) : Driver using old /proc/net/wireless support, please fix driver !\n",
> + dev->name);
> +
> + return dev->get_wireless_stats(dev);
> + }
> +
> /* Not found */
> return (struct iw_statistics *) NULL;
> }
> @@ -1840,33 +1843,8 @@ #endif /* CONFIG_NET_WIRELESS_RTNETLINK
> */
>
> #ifdef WE_EVENT_RTNETLINK
> -/* ---------------------------------------------------------------- */
> -/*
> - * Locking...
> - * ----------
> - *
> - * Thanks to Herbert Xu <[email protected]> for fixing
> - * the locking issue in here and implementing this code !
> - *
> - * The issue : wireless_send_event() is often called in interrupt context,
> - * while the Netlink layer can never be called in interrupt context.
> - * The fully formed RtNetlink events are queued, and then a tasklet is run
> - * to feed those to Netlink.
> - * The skb_queue is interrupt safe, and its lock is not held while calling
> - * Netlink, so there is no possibility of dealock.
> - * Jean II
> - */
> -
> static struct sk_buff_head wireless_nlevent_queue;
>
> -static int __init wireless_nlevent_init(void)
> -{
> - skb_queue_head_init(&wireless_nlevent_queue);
> - return 0;
> -}
> -
> -subsys_initcall(wireless_nlevent_init);
> -
> static void wireless_nlevent_process(unsigned long data)
> {
> struct sk_buff *skb;
> @@ -1943,6 +1921,13 @@ static inline void rtmsg_iwinfo(struct n
> tasklet_schedule(&wireless_nlevent_tasklet);
> }
>
> +static int __init wireless_nlevent_init(void)
> +{
> + skb_queue_head_init(&wireless_nlevent_queue);
> + return 0;
> +}
> +
> +subsys_initcall(wireless_nlevent_init);
> #endif /* WE_EVENT_RTNETLINK */
>
> /* ---------------------------------------------------------------- */
> diff --git a/net/ieee80211/softmac/ieee80211softmac_wx.c b/net/ieee80211/softmac/ieee80211softmac_wx.c
> index 2aa779d..75320b6 100644
> --- a/net/ieee80211/softmac/ieee80211softmac_wx.c
> +++ b/net/ieee80211/softmac/ieee80211softmac_wx.c
> @@ -80,10 +80,10 @@ ieee80211softmac_wx_set_essid(struct net
> * If it's our network, ignore the change, we're already doing it!
> */
> if((sm->associnfo.associating || sm->associated) &&
> - (data->essid.flags && data->essid.length)) {
> + (data->essid.flags && data->essid.length && extra)) {
> /* Get the associating network */
> n = ieee80211softmac_get_network_by_bssid(sm, sm->associnfo.bssid);
> - if(n && n->essid.len == data->essid.length &&
> + if(n && n->essid.len == (data->essid.length - 1) &&
> !memcmp(n->essid.data, extra, n->essid.len)) {
> dprintk(KERN_INFO PFX "Already associating or associated to "MAC_FMT"\n",
> MAC_ARG(sm->associnfo.bssid));
> @@ -109,8 +109,8 @@ ieee80211softmac_wx_set_essid(struct net
> sm->associnfo.static_essid = 0;
> sm->associnfo.assoc_wait = 0;
>
> - if (data->essid.flags && data->essid.length) {
> - length = min((int)data->essid.length, IW_ESSID_MAX_SIZE);
> + if (data->essid.flags && data->essid.length && extra /*required?*/) {
> + length = min(data->essid.length - 1, IW_ESSID_MAX_SIZE);
> if (length) {
> memcpy(sm->associnfo.req_essid.data, extra, length);
> sm->associnfo.static_essid = 1;
>
On Tue, Oct 03, 2006 at 05:40:44PM -0400, John W. Linville wrote:
> Unfortunately, I don't see any way to "fix" WE-21 without similarly
> breaking wireless-tools 29 and other "WE-21 aware" apps. And since
> I'll bet that the various WE-aware apps have checks like "if WE >
> 20" for managing ESSID length settings, we may have painted ourselves
> into a korner (sic).
OK, I'm going to ask a stupid question. Why is the kernel<->wireless
driver interface have to be tied to the userspace<->wireless
interface? The first is internal to the kernel and is free to change,
and if it breaks out-of-tree drivers, I'll complain to Intel about why
the !@#@ the ipw3945 driver hasn't been merged, but we've never made
any guarantees about break out-of-tree drivers, so I wouldn't have the
right to complain to anyone else.
The second is an external userspace ABI, and that should remain
constant. It sounds like right now one gets pushed straight out to
the other, but what if the wireless infrastructure layer in the kernel
provided "interface glue" so you can translate between multiple
interface versions --- and then force the userspace (or at least new
versions of the userspace) to declare to the kernel what version of
the interface they are expecting?
That's what we do with the stat system call. Userspace tells the
kernel whether they want the v1, v2, v3, v4, or v5 version of the stat
structure, and we have interface glue to support all of the old versions.
Is there some reason why this would be too hard to do with the current
interface? Or is the arguement that if you're going to invest that
much energy in fixing the userspace interface code, you would rather
go to d80211/nl80211?
Regards,
- Ted
On Tue, Oct 03, 2006 at 07:16:48PM -0400, Theodore Tso wrote:
> On Tue, Oct 03, 2006 at 05:40:44PM -0400, John W. Linville wrote:
> > Unfortunately, I don't see any way to "fix" WE-21 without similarly
> > breaking wireless-tools 29 and other "WE-21 aware" apps. And since
> > I'll bet that the various WE-aware apps have checks like "if WE >
> > 20" for managing ESSID length settings, we may have painted ourselves
> > into a korner (sic).
>
> OK, I'm going to ask a stupid question. Why is the kernel<->wireless
> driver interface have to be tied to the userspace<->wireless
> interface?
They are not tied since WE-13. But you need a certain amount
of consistency, otherwise it's pure madness. If the driver does X
(no-NUL), but the userspace sees Y (mandatory NUL), then both driver
writer and application writer will go insane. You really want the API
to be as transparent as possible.
But that's not the issue. The issue is that the userspace API
change was decided at the wireless summit last spring, and this was
something that most wireless people were very strongly advocating for,
including userspace people (Dan, Jouni). And most of it has already
been implemented.
I think we can trust both Dan and Jouni to have a pretty good
idea of the impact of such changes. They are the one having to
implement it and dealing with the angry users.
I've done many incompatible changes to the WE API over the
years, and it all went fine and dandy (anybody did notice those
changes ?). They key is to get userspace in place when you do the
kernel change.
As I said, I was against that change, and I'm the one being
flamed.
> Is there some reason why this would be too hard to do with the current
> interface?
It's already done with the current interface, you can access
the API with either ioctls or RtNetlink.
> - Ted
Have fun...
Jean
On Tue, 3 Oct 2006 16:31:38 -0700
Jean Tourrilhes <[email protected]> wrote:
> It's already done with the current interface, you can access
> the API with either ioctls or RtNetlink.
Does this answer Ted's question though? Why can't userspace request
the new v48 interface to get the changed API while older tools
get the v47 interface and continue to work without needing to
be upgraded?
Sean
On Tue, Oct 03, 2006 at 08:27:54PM -0400, Sean wrote:
> On Tue, 3 Oct 2006 16:31:38 -0700
> Jean Tourrilhes <[email protected]> wrote:
>
> > It's already done with the current interface, you can access
> > the API with either ioctls or RtNetlink.
>
> Does this answer Ted's question though? Why can't userspace request
> the new v48 interface to get the changed API while older tools
> get the v47 interface and continue to work without needing to
> be upgraded?
How does that happen in practice ? Kernel has no clue on what
userpace version is running.
> Sean
Jean
On Tue, 3 Oct 2006 17:30:31 -0700
Jean Tourrilhes <[email protected]> wrote:
> How does that happen in practice ? Kernel has no clue on what
> userpace version is running.
>
Ted mentioned that the way it works for stat is that userspace requests
an API version and the kernel delivers it. So old versions request old
API and new versions request new API. You only ever _add_ new API, and
never remove older versions.
Sean
On Tue, Oct 03, 2006 at 03:27:07PM -0700, Jean Tourrilhes wrote:
> Let's not make a mountain of this molehill. If you want to use
> old versions of Wireless Tools and wpa_supplicant with WE-21, what you
> need is just to add a dummy character at the end of your ESSID. And
> everything will be fine.
Nope, everything won't be fine with WPA-PSK which is using SSID as part
of the key derivation. In other words, you cannot add a dummy character
in the end of the SSID in wpa_supplicant configuration for a WPA-PSK
network and expect everything to work.
--
Jouni Malinen PGP id EFC895FA
On Tue, Oct 03, 2006 at 12:49:57PM -0700, Jean Tourrilhes wrote:
> No, it's not. But as soon as *some part* of WE-21 appears in
> the kernel, the userspace expect the ESSID change. If we want to have
> WE-21 without the ESSID change, we need to fix userspace.
Or leave WIRELESS_EXT at 20 and come up with a new way of versioning any
future changes in WE.. Yes, having two different mechanisms for version
number is ugly, but it could prevent userspace breakage.
(And based on the other messages in this thread, it might be useful to
include the userspace program's idea of the version in those new
commands to allow multiple interface versions to be supported by the
kernel).
--
Jouni Malinen PGP id EFC895FA
On Tue, 2006-10-03 at 19:21 -0700, Jouni Malinen wrote:
> On Tue, Oct 03, 2006 at 12:49:57PM -0700, Jean Tourrilhes wrote:
>
> > No, it's not. But as soon as *some part* of WE-21 appears in
> > the kernel, the userspace expect the ESSID change. If we want to have
> > WE-21 without the ESSID change, we need to fix userspace.
>
> Or leave WIRELESS_EXT at 20 and come up with a new way of versioning any
> future changes in WE.. Yes, having two different mechanisms for version
> number is ugly, but it could prevent userspace breakage.
>
> (And based on the other messages in this thread, it might be useful to
> include the userspace program's idea of the version in those new
> commands to allow multiple interface versions to be supported by the
> kernel).
or... don't use a NUMBER for this.
If you have a bitmap for supported features, it's much more powerful!
That way you can even do this per driver/hardware, and you can
add/retract individual capabilities rather than lumping everything into
one big number.
On Tue, 2006-10-03 at 19:16 -0400, Theodore Tso wrote:
> OK, I'm going to ask a stupid question. Why is the kernel<->wireless
> driver interface have to be tied to the userspace<->wireless
> interface?
Haha. Because Jean thinks it isn't and thus everything is fine. But in
reality it is.
> Is there some reason why this would be too hard to do with the current
> interface?
Yes: drivers are expected to mostly handle the ioctls directly without a
layer between them and userspace.
> Or is the arguement that if you're going to invest that
> much energy in fixing the userspace interface code, you would rather
> go to d80211/nl80211?
cfg80211 and nl80211 actually do this abstraction, nl80211 gets requests
and rewrites them to cfg80211 structures that are passed to the driver.
I have plans for wext/cfg80211 compat code, essentially replacing the
interface between the drivers and wext by cfg80211 and letting userspace
not even be aware of it.
johannes
On Tue, 2006-10-03 at 17:40 -0400, John W. Linville wrote:
> Wireless developers, it's time to get d80211 ready to merge...or
> figure-out how to get nl80211 on the current stack...hmmm...
Actually, cfg80211/nl80211 are not really tied to the stack, the intent
always was to make them replace wext even for legacy drivers.
Hence, all legacy drivers need to do is assign their net_device's struct
ieee80211_ptr and register a wiphy operations structure (and profit).
johannes
On Tue, Oct 03, 2006 at 08:36:46PM -0400, Sean wrote:
> On Tue, 3 Oct 2006 17:30:31 -0700
> Jean Tourrilhes <[email protected]> wrote:
>
> > How does that happen in practice ? Kernel has no clue on what
> > userpace version is running.
> >
>
> Ted mentioned that the way it works for stat is that userspace requests
> an API version and the kernel delivers it. So old versions request old
> API and new versions request new API. You only ever _add_ new API, and
> never remove older versions.
I think the point is that the API currently has no such facility.
Adding a new set of WE ioctls is unpalatable, both for general
ioctl-haters and because the WE ioctl collection is quite broad.
Maybe that could be solved by forcing the new WE stuff to use
the netlink-based WE facilities, but then you are expanding the
compatibility nightmare for whatever replaces WE.
John
--
John W. Linville
[email protected]
On Wed, Oct 04, 2006 at 09:33:23AM +0200, Arjan van de Ven wrote:
> On Tue, 2006-10-03 at 19:21 -0700, Jouni Malinen wrote:
> > (And based on the other messages in this thread, it might be useful to
> > include the userspace program's idea of the version in those new
> > commands to allow multiple interface versions to be supported by the
> > kernel).
>
>
> or... don't use a NUMBER for this.
>
> If you have a bitmap for supported features, it's much more powerful!
> That way you can even do this per driver/hardware, and you can
> add/retract individual capabilities rather than lumping everything into
> one big number.
Arjan (as usual) makes a very good suggestion here...
--
John W. Linville
[email protected]
On Tue, Oct 03, 2006 at 02:59:16PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 3 Oct 2006, John W. Linville wrote:
> >
> > I.E. With "WE-21 aware" tools already in the wild, it isn't now clear
> > to me how WE can evolve any further than WE-20.
>
> Well, if you get a WE-22 out soon enough, the situation will be one where
> people who are fast at updating will have a fixed version quickly, and the
> ones that aren't quick at updating will never have even seen the broken
> case.
Linus,
You can't froze kernel userspace API forever. That is simply
not workable, it will lead to stagnation and obsolescence. This is
especially unfair because some other kernel userspace API are allow to
change whenever their maintainers feels like.
Just to give you an example why we sometime need to
change. The first two generations of 802.11 hardware were using the
ESSID as a C-string (no NUL char), so the API was also using a
C-string (no NUL char). New 802.11 hardware do accept NUL in the
ESSID, therefore the API need to evolve away from C-string to offer
this new feature to userspace. Especially that new WPA standard may
use that in the future (cf. Jouni's e-mail).
In the past, kernel userspace API changes were done during the
devel series, but we don't have this option anymore. What I would like
people to discuss is what are the best practice to perform kernel
userspace API changes in 2.6.X.
I personally thought that I went beyond the usual practice by
waiting 6 months, auditing all userspace and making sure the bits had
propagated to distro. And let's not forget that the tools warn users
about API mismatch.
If you feel we need 1 more month, that's perfectly ok with all
of us. If your target is that some specific distros ship with
compatible userspace, I can personally monitor that and report. You
may want to be a bit more explicit in your standards, that would help
all of us doing a better job.
Have fun...
Jean
Jean Tourrilhes wrote:
> You can't froze kernel userspace API forever. That is simply
> not workable, it will lead to stagnation and obsolescence. This is
> especially unfair because some other kernel userspace API are allow to
> change whenever their maintainers feels like.
>
> Just to give you an example why we sometime need to
> change. The first two generations of 802.11 hardware were using the
> ESSID as a C-string (no NUL char), so the API was also using a
> C-string (no NUL char). New 802.11 hardware do accept NUL in the
> ESSID, therefore the API need to evolve away from C-string to offer
> this new feature to userspace. Especially that new WPA standard may
> use that in the future (cf. Jouni's e-mail).
>
> In the past, kernel userspace API changes were done during the
> devel series, but we don't have this option anymore. What I would like
> people to discuss is what are the best practice to perform kernel
> userspace API changes in 2.6.X.
You can _add_ to the userspace API, because that obviously does not
break old programs.
You just should not introduce changes which break old programs.
Binaries built in the 1990's still work under Linux, you know...
API changes require new ioctl/sub-ioctl numbers, so that new programs
can take advantage of new capabilities while old programs continue to work.
Jeff
On Wed, Oct 04, 2006 at 02:32:51PM -0400, Jeff Garzik wrote:
>
> Binaries built in the 1990's still work under Linux, you know...
Completely untrue for system utils. I've got plenty of counter
examples.
Jean
On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
>
> You can't froze kernel userspace API forever. That is simply
> not workable
Stop arguing this way.
It's not what we have ever done. We've _extended_ the API. But we don't
break old ones.
I don't even see why you argue. Even the people directly involved with
this thing seem to say that it should have some simple translation layer
and do the internal format thing. We've had major subsystem that do that,
and I don't see why you think wireless is so different, and so special in
this respect.
The whole _point_ of a kernel is to act as a abstraction layer and
resource management between user programs and hardware/outside world.
That's why kernels _exist_. Breaking user-land API's is thus by definition
something totally idiotic.
If you need to break something, you create a new interface, and try to
translate between the two, and maybe you deprecate the old one so that it
can be removed once it's not in use any more. If you can't see that this
is how a kernel should work, you're missing the point of having a kernel
in the first place.
Also, I don't want to hear about how this makes things harder and more
complicated. The fact is, we're programmers, and we should care about the
_users_. If we don't, we're just masturbating. There's a whole other side
to this "create software" than just the "me, me, me" side, and if you lose
sight of that side, that's a really bad thing.
Linus
On Wed, Oct 04, 2006 at 11:38:19AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
> >
> > You can't froze kernel userspace API forever. That is simply
> > not workable
>
> Stop arguing this way.
>
> It's not what we have ever done. We've _extended_ the API. But we don't
> break old ones.
Old APIs get deprecated, and people are forced to the new API,
which is exactly the same as far as userspace is concerned. This
transition is exactly the same as what you propose, both kernel API
coexist for some time, except it happens in userspace instead of in
kernel, which is an implementation detail.
So, my question is when can I remove the old ESSID API.
> I don't even see why you argue. Even the people directly involved with
> this thing seem to say that it should have some simple translation layer
> and do the internal format thing. We've had major subsystem that do that,
> and I don't see why you think wireless is so different, and so special in
> this respect.
The Wireless people (Jouni, Dan) decided to change the
*userspace* API. We could translate the new *userspace* API to the old
kernel API, but I don't see the point.
> If you need to break something, you create a new interface, and try to
> translate between the two, and maybe you deprecate the old one so that it
> can be removed once it's not in use any more.
That's exactly what it hinges on. What is your criteria for
removing the old ESSID API. My understanding was 6 months.
Jean
Jean Tourrilhes wrote:
> On Wed, Oct 04, 2006 at 11:38:19AM -0700, Linus Torvalds wrote:
>>
>> On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
>>> You can't froze kernel userspace API forever. That is simply
>>> not workable
>> Stop arguing this way.
>>
>> It's not what we have ever done. We've _extended_ the API. But we don't
>> break old ones.
>
> Old APIs get deprecated, and people are forced to the new API,
> which is exactly the same as far as userspace is concerned. This
> transition is exactly the same as what you propose, both kernel API
> coexist for some time, except it happens in userspace instead of in
> kernel, which is an implementation detail.
> So, my question is when can I remove the old ESSID API.
>
>> I don't even see why you argue. Even the people directly involved with
>> this thing seem to say that it should have some simple translation layer
>> and do the internal format thing. We've had major subsystem that do that,
>> and I don't see why you think wireless is so different, and so special in
>> this respect.
>
> The Wireless people (Jouni, Dan) decided to change the
> *userspace* API. We could translate the new *userspace* API to the old
> kernel API, but I don't see the point.
Kernel API and userspace API are two vastly different things. We change
the kernel API all the time. We _don't_ change the userspace API,
except when "change" is defined as an additional to an existing API.
>> If you need to break something, you create a new interface, and try to
>> translate between the two, and maybe you deprecate the old one so that it
>> can be removed once it's not in use any more.
>
> That's exactly what it hinges on. What is your criteria for
> removing the old ESSID API. My understanding was 6 months.
There is no reason why the old ESSID API cannot live on for years and
years. Just like stat(2) version 1 doesn't support modern time
granularity, old ESSID API won't support the full range of modern
ESSIDs. So what? That's what a new API -- living alongside the old one
-- is for.
Jeff
On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
> >
> > It's not what we have ever done. We've _extended_ the API. But we don't
> > break old ones.
>
> Old APIs get deprecated, and people are forced to the new API,
> which is exactly the same as far as userspace is concerned. This
> transition is exactly the same as what you propose, both kernel API
> coexist for some time, except it happens in userspace instead of in
> kernel, which is an implementation detail.
> So, my question is when can I remove the old ESSID API.
That isn't the question here.
The current situation seems to be designed to add the new one and removing
the old one as a single step. THAT IS BROKEN.
The new one and the old one needs to work at the same time, exactly so
that there's a transition mechanism.
That's the part you seem to now have understood. There should be no "flag
day" when people have to switch over.
> The Wireless people (Jouni, Dan) decided to change the
> *userspace* API. We could translate the new *userspace* API to the old
> kernel API, but I don't see the point.
You do not indeed see the point.
The point is, we can switch internal kernel ABI's - new or old - at any
point. But user-level ABI's should never require a one-way update.
> That's exactly what it hinges on. What is your criteria for
> removing the old ESSID API. My understanding was 6 months.
But we didn't have 6 months of the new API, did we? People complained.
The person you merged through explicitly said that if he had realized what
you did, he wouldn't have merged.
That should tell you something. Why are you ignoring this?
Linus
On Wed, Oct 04, 2006 at 12:21:46PM -0700, Linus Torvalds wrote:
>
> The current situation seems to be designed to add the new one and removing
> the old one as a single step. THAT IS BROKEN.
This is not the case, I don't know where you got this
idea. This is a *two* step process with a 6 month interval between the
two steps. This was clearly detailed earlier in this thread.
> The new one and the old one needs to work at the same time, exactly so
> that there's a transition mechanism.
Yes, this is precisely what we have been doing, the two APIs
have been working at the same time for more than 6 months.
> > That's exactly what it hinges on. What is your criteria for
> > removing the old ESSID API. My understanding was 6 months.
>
> But we didn't have 6 months of the new API, did we?
Yes, we had more of 6 months of the new API. Please check the
facts : included April 11th in Gentoo.
> People complained.
Yes, maybe 6 months was two short. That's why I say that we
should give it one or two more months. Maybe we need FC6 to be
released.
> The person you merged through explicitly said that if he had realized what
> you did, he wouldn't have merged.
I did not merge through Jeff.
> Linus
Jean
On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
>
> Yes, this is precisely what we have been doing, the two APIs
> have been working at the same time for more than 6 months.
In the kernel for any particular driver?
Or just in user-land?
There's a big difference.
Linus
In other words, if we really have had the code to handle both interfaces
in the kernel, I vote for just reverting the patch that "fixed" it to just
one.
But I suspect that's not what you're really saying. I think you're saying
is that we've had two different interfaces for _different_ chips, and that
some user-space tools have supported both. And since clearly the distros
haven't updated to those tools yet (or this wouldn't be an issue), we
still want to avoid a flag-day, and wait until they have done so.
Linus
On Wed, Oct 04, 2006 at 01:12:17PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
> >
> > Yes, this is precisely what we have been doing, the two APIs
> > have been working at the same time for more than 6 months.
>
> In the kernel for any particular driver?
>
> Or just in user-land?
>
> There's a big difference.
Both actually.
I've slightly simplified the situation, because you may not
care for all the details, but if you want to know the gory details...
It's all started with some kernel drivers changing the way
they handle ESSID. That was last January. So, in the kernel, you had
half the drivers doing the old way (NUL terminated), and half doing
the new way (not NUL terminated).
I immediately asked to revert to the old way. All the Wireless
people were against me, and this mish-mash of API was kept (it was
public on netdev). At this point, nobody cared that userspace API was
broken and I was left cleaning up the mess.
Of course, some part of the Wireless Tools did broke on the
new API (I had bug reports), so I had to push new version of Wireless
Tools. And I took this opportunity to finish moving over the API to
the new way.
Sometime breaking userspace APIs is perfectly OK, while
sometimes it's not. You just have to make sure that Linus does not
hear about it, I guess ;-)
> Linus
Have fun...
Jean
On Wed, Oct 04, 2006 at 12:52:29PM -0700, Jean Tourrilhes wrote:
> On Wed, Oct 04, 2006 at 12:21:46PM -0700, Linus Torvalds wrote:
> > The person you merged through explicitly said that if he had realized what
> > you did, he wouldn't have merged.
>
> I did not merge through Jeff.
You did, just indirectly. I was directly upstream from you.
For the record, I did not fully comprehend that we would be breaking
existing tools (and their users) -- I certainly should have, but I
did not. I apologize both to you for being part of this scenario I
inadvertantly allowed to unfold and to the users who experienced the
resulting breakage.
This was the second time I took patches for extending WE, and I have
received nothing but grief from either set of patches. Even had
things gone smoothly, WE was already hated near universally. WE has
survived based on being "good enough" for a long time. But I think
it is safe to say that if WE were not already in the kernel, it would
have little chance of making it in today.
All the legitimate options for extending WE now amount to forking a
new API. But work is already underway on a WE replacement. I think
the best option is to invest in that replacement, and a compatibility
layer to support older WE-aware applications. Please see the nl80211
and cfg80211 currently on the netdev list.
I do not intend or expect to take any more WE enhancment patches.
Only bug fixes to WE will be accepted from now onward.
Jean, I thank you for your long-running contributions. I hope this
will not discourage you from further participation.
Thanks,
John
--
John W. Linville
[email protected]
On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
>
> Sometime breaking userspace APIs is perfectly OK, while
> sometimes it's not. You just have to make sure that Linus does not
> hear about it, I guess ;-)
I see the smiley, and I think you're trying to be funny and clever, but
the thing is, I actually think that's _true_.
It's perfectly fine to break ABI's if nobody ever complains loudly enough
that other developers notice.
So yes, we could actually even make it a real hard rule:
"Breaking ABI's is fine. As long as you can hide the breakage so well
that nobody complains loudly enough that anybody ever notices".
The very fact that this turned into a discussion is a sign that the ABI
breakage wasn't handled well enough. Usually, when we do something, nobody
ever even notices.
(For an example of such a ABI breakage: I changed ptrace() to not allow
ptracing another thread in the same thread group about a year ago, because
it turned out that it was a serious local DoS problem. In the 12 months
since, I think we had two people who ever actually noticed, and both of
them actually caused some discussion about ways to perhaps unbreak it.)
Linus
On Wed, Oct 04, 2006 at 11:59:03AM -0700, Jean Tourrilhes wrote:
> That's exactly what it hinges on. What is your criteria for
> removing the old ESSID API. My understanding was 6 months.
Just to make it clear. The current practice is that 6 months is the
_minimum_, after an extensive discussion on LKML and an understanding
that costs of supporting both the old and the new interface outweighs
the cost and pain to the user community of removing the old interface.
Then after there is an agrement on how long the deprecation window
will be (and sometimes it is negotiated to be longer than six months),
it is documented in
/usr/src/linux/Documentation/feature-removal-schedule.txt
But it's never been the case that after six months, we can remove a
feature just because we feel like it, or it's slightly more convenient
to programmers at the cost of imposing pain on users, or at the cost
of discouraging users from testing bleeding edge kernels.
As others have pointed out, we have maintained old stat system call
interfaces for over a ***decade***.
So perhaps that's something to keep in mind as we start considering
with the next generation wireless interface looks like, and whether it
is sufficiently well defined and has enough forwards and backwards
compatibility, both at the driver level and at the userspace level, so
that we can avoid these sorts of problems going forward.
Regards,
- Ted
P.S. Because of all of these changing interfaces, I *still* haven't
been able to get wpa_supplicant working with LEAP so I can get
wireless access to in IBM offices using my ipw3945 driver. I've
tried, and failed. Sigh, I guess I'm not smart enough....
On Wed, Oct 04, 2006 at 03:26:09PM -0700, Linus Torvalds wrote:
>
> The very fact that this turned into a discussion is a sign that the ABI
> breakage wasn't handled well enough. Usually, when we do something, nobody
> ever even notices.
There was the grand total of *ONE* user who was personally
impacted by the userspace API change (the two other, one was hit by a
bug, now fixed, one was hit because of kernel API change + external
driver). And I immediately proposed to postpone the change to a later
time.
The people who contributed most to this tread were had not
experienced any breakage. I don't know what conclusion to reach from
that, and I don't understand why it took such proportions.
Guessing the right time to deprecate an old API can be a trial
and error process. So, we just have to wait for the release of FC6...
Jean
On Wed, Oct 04, 2006 at 07:29:39PM -0400, Theodore Tso wrote:
>
> P.S. Because of all of these changing interfaces, I *still* haven't
> been able to get wpa_supplicant working with LEAP so I can get
> wireless access to in IBM offices using my ipw3945 driver. I've
> tried, and failed. Sigh, I guess I'm not smart enough....
Which changing interface are you talking about ? I'm afraid
that WPA is a complex business and the ipw3945 driver is still
beta. Jouni and the people on the hostap mailing list should be able
to help.
Regards,
Jean
On Wed, Oct 04, 2006 at 07:29:39PM -0400, Theodore Tso wrote:
> P.S. Because of all of these changing interfaces, I *still* haven't
> been able to get wpa_supplicant working with LEAP so I can get
> wireless access to in IBM offices using my ipw3945 driver. I've
> tried, and failed. Sigh, I guess I'm not smart enough....
This is getting somewhat off topic to the main thread, but anyway, LEAP
is quite an odd beast as far as EAP methods are concerned and the way it
is implemented in Cisco APs makes it even worse.. LEAP can mean so many
different things that it is difficult to give any generic answer to how
to do this. Just about any other wireless security configuration would
be easier to explain.. ;-)
Feel free to write me more details on the configuration used in the
network and I can try to figure out how that would need to be
configured. I would need to know whether LEAP is being used with IEEE
802.1X (dynamic WEP keys; key_mgmt=IEEE8021X in wpa_supplicant)) or with
WPA (key_mgmt=WPA-EAP in wpa_supplicant). In addition, it would be
useful to know whether the APs are configured to require Cisco
prorietary "Network EAP" authentication algorithm (auth_alg=LEAP in
wpa_supplicant) or not. Many of the drivers do not support that at all..
I don't know whether ipw3945 does since I have not tested this myself
and do not remember having heard of a clear report on this being used.
And just hope that the APs do not require Cisco proprietary CKIP or CMIC
encryption algorithms which are most likely not supported by ipw3945 (or
most Linux drivers for that matter)..
--
Jouni Malinen PGP id EFC895FA
On Wed, 4 Oct 2006, Jean Tourrilhes wrote:
>
> There was the grand total of *ONE* user who was personally
> impacted by the userspace API change (the two other, one was hit by a
> bug, now fixed, one was hit because of kernel API change + external
> driver). And I immediately proposed to postpone the change to a later
> time.
Heh, ok. I'm personally not able to really judge any wireless-extensions
stuff, so I have to go by how noisy the discussion becomes ;)
I'll leave this to you guys to sort out, I just did want to pipe up (since
I was asked to) that as far as _I_ am concerned, user-space interfaces
really are very important. Whether this is one of the really important
ones or not, I leave to the people involved to figure out, but I really
don't want to have developers dismissing the issue.
(I think some people used to, and I think we've gotten better at it. But
maybe I'm just being overly optimistic again ;)
Linus
Jean Tourrilhes (on Mon, 2 Oct 2006 14:58:12 -0700) wrote:
>On Mon, Oct 02, 2006 at 05:26:04PM -0400, Theodore Tso wrote:
>> On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
>> > Distributions _are_ shipping those tools already. The problem is more
>> > with older distributions where, for example, the kernel gets upgraded
>> > but other stuff does not. If a kernel upgrade happens, then the distro
>> > needs to make sure userspace works with it. That's nothing new.
>>
>> Um, *which* distro's are shipping it already? RHEL4? SLES10? I
>> thought we saw a note saying that even Debian **unstable** didn't have
>> a new enough version of the wireless-tools....
>
> I personally never said it was shipping already in all distro.
>...
> SuSE I can't figure out.
SLES9 SP3:
wireless-tools-27pre12-39.31 (WE_VERSION 16)
No wpa_supplicant
SLES10:
wireless-tools-28pre13-22.4 (WE_VERSION 19)
wpa_supplicant-0.4.8-14.8
SuSELinux 10.1:
wireless-tools-28pre13-20 (WE_VERSION 19)
wpa_supplicant-0.4.8-14
openSUSE-10.2-Alpha4:
wireless-tools-29pre10-3 (WE_VERSION 21)
wpa_supplicant-gui-0.4.8-17
Only openSUSE 10.2 (which is still in Alpha status) has WE_VERSION 21
support.
On 10/5/06, Jean Tourrilhes <[email protected]> wrote:
> On Wed, Oct 04, 2006 at 03:26:09PM -0700, Linus Torvalds wrote:
> >
> > The very fact that this turned into a discussion is a sign that the ABI
> > breakage wasn't handled well enough. Usually, when we do something, nobody
> > ever even notices.
>
> There was the grand total of *ONE* user who was personally
> impacted by the userspace API change (the two other, one was hit by a
> bug, now fixed, one was hit because of kernel API change + external
> driver). And I immediately proposed to postpone the change to a later
> time.
And said user, being me, is currently running with upgraded userspace
without any issues (counting upgrading userspace as a non-issue).
I originally logged my report as I do for other things that break or look
different in new snapshots, in order to provide early feedback to the
kernel developers - I guess it's the actual point of having snapshots
from kernel.org...
Thanks, ciao,
--alessandro
"Well a man has two reasons for things that he does
the first one is pride and the second one is love
all understandings must come by this way"
(Husker Du, 'She Floated Away')
On Thu, Oct 05, 2006 at 03:20:06PM +0000, Alessandro Suardi wrote:
> On 10/5/06, Jean Tourrilhes <[email protected]> wrote:
> >On Wed, Oct 04, 2006 at 03:26:09PM -0700, Linus Torvalds wrote:
> >>
> >> The very fact that this turned into a discussion is a sign that the ABI
> >> breakage wasn't handled well enough. Usually, when we do something,
> >nobody
> >> ever even notices.
> >
> > There was the grand total of *ONE* user who was personally
> >impacted by the userspace API change (the two other, one was hit by a
> >bug, now fixed, one was hit because of kernel API change + external
> >driver). And I immediately proposed to postpone the change to a later
> >time.
>
> And said user, being me, is currently running with upgraded userspace
> without any issues (counting upgrading userspace as a non-issue).
>
> I originally logged my report as I do for other things that break or look
> different in new snapshots, in order to provide early feedback to the
> kernel developers - I guess it's the actual point of having snapshots
> from kernel.org...
Precisely. We are not omniscient. Based on your feedback, I
decided to postpone WE-21.
Your feedback was useful and appreciated. I will never blame
the messenger.
> Thanks, ciao,
>
> --alessandro
Ciao...
Jean
On Wed, Oct 04, 2006 at 09:49:39AM +0200, Johannes Berg wrote:
> On Tue, 2006-10-03 at 19:16 -0400, Theodore Tso wrote:
>
> > OK, I'm going to ask a stupid question. Why is the kernel<->wireless
> > driver interface have to be tied to the userspace<->wireless
> > interface?
>
> Haha. Because Jean thinks it isn't and thus everything is fine. But in
> reality it is.
>
> > Is there some reason why this would be too hard to do with the current
> > interface?
>
> Yes: drivers are expected to mostly handle the ioctls directly without a
> layer between them and userspace.
Once again, your facts are totally wrong about Wireless
Extensions.
Have you ever looked at the code in the kernel ? I guarantee
you that adding whatever specific WE translation is quite easy. In
this precise case, this would only increase confusion, so this should
be considered bad API practice.
Regards,
Jean
Jean Tourrilhes wrote:
> Once again, your facts are totally wrong about Wireless
> Extensions.
> Have you ever looked at the code in the kernel ? I guarantee
> you that adding whatever specific WE translation is quite easy. In
> this precise case, this would only increase confusion, so this should
> be considered bad API practice.
Wireless Extensions has reached end-of-life, and so we only need to
support what's out there in wide distribution.
Jeff
On Thu Oct 05, 2006 at 12:43:57PM -0400, Jeff Garzik wrote:
> Wireless Extensions has reached end-of-life, and so we only need to
> support what's out there in wide distribution.
Hmm, so what is going to replace it? I was messing about with my
old powerbook G4 titanium, trying to make wpa_supplicant work
when I realized the airport/orinoco driver used for my powerbook
can't handle WPA since that apparently requires at least WE-18.
I started looking into what it would take to teach the orinoco
driver about WE>=18. But I suppose there is no point in my
looking further if WE is heading to the great bit-bucket in the
sky.
Is 'Wireless Extensions The Next Generation' described and
documented somewhere? Or am I better off if I just give up and
move on to some other more realistic project? :-)
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Erik Andersen wrote:
> On Thu Oct 05, 2006 at 12:43:57PM -0400, Jeff Garzik wrote:
>> Wireless Extensions has reached end-of-life, and so we only need to
>> support what's out there in wide distribution.
>
> Hmm, so what is going to replace it? I was messing about with my
> old powerbook G4 titanium, trying to make wpa_supplicant work
> when I realized the airport/orinoco driver used for my powerbook
> can't handle WPA since that apparently requires at least WE-18.
> I started looking into what it would take to teach the orinoco
> driver about WE>=18. But I suppose there is no point in my
> looking further if WE is heading to the great bit-bucket in the
> sky.
>
> Is 'Wireless Extensions The Next Generation' described and
> documented somewhere? Or am I better off if I just give up and
> move on to some other more realistic project? :-)
Look around for references to nl80211 / cfg80211, particularly on the
[email protected] list.
Jeff
P.S. Your mailer is generating buggy Mail-Followup-To lines.
On Thu, Oct 05, 2006 at 11:42:41AM -0600, Erik Andersen wrote:
> On Thu Oct 05, 2006 at 12:43:57PM -0400, Jeff Garzik wrote:
> > Wireless Extensions has reached end-of-life, and so we only need to
> > support what's out there in wide distribution.
>
> Hmm, so what is going to replace it? I was messing about with my
> old powerbook G4 titanium, trying to make wpa_supplicant work
> when I realized the airport/orinoco driver used for my powerbook
> can't handle WPA since that apparently requires at least WE-18.
> I started looking into what it would take to teach the orinoco
> driver about WE>=18. But I suppose there is no point in my
> looking further if WE is heading to the great bit-bucket in the
> sky.
Driver fixes to support later WE versions are still welcome.
Information on supporting WPA for that driver will still be needed
for cfg80211.
Thanks,
John
--
John W. Linville
[email protected]
Hi!
> > The very fact that this turned into a discussion is a sign that the ABI
> > breakage wasn't handled well enough. Usually, when we do something, nobody
> > ever even notices.
>
> There was the grand total of *ONE* user who was personally
> impacted by the userspace API change (the two other, one was hit by a
> bug, now fixed, one was hit because of kernel API change + external
> driver). And I immediately proposed to postpone the change to a later
> time.
The fact that all the wireless tools print...
Warning: Driver for device eth1 has been compiled with version 20
of Wireless Extension, while this program supports up to version 17.
...shows that wireless is not as backwards compatible as usual kernel
ABIs are. I'm afraid that wireless extensions can not be helped
(designed with back-compatibility at wrong place), but can we make
sure new netlink ABI does not have similar problems?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Theodore Tso <[email protected]> writes:
> On Mon, Oct 02, 2006 at 05:00:31PM -0400, Dan Williams wrote:
>> Distributions _are_ shipping those tools already. The problem is more
>> with older distributions where, for example, the kernel gets upgraded
>> but other stuff does not. If a kernel upgrade happens, then the distro
>> needs to make sure userspace works with it. That's nothing new.
>
> Um, *which* distro's are shipping it already? RHEL4? SLES10? I
> thought we saw a note saying that even Debian **unstable** didn't have
> a new enough version of the wireless-tools....
Debian is currently in (pre-) freeze mode, and new upstream versions of
core packages are uploaded very very carefully. To see whats going on
with the wireless-tools package, see [1, 2].
[3] shows that 29pre10 was uploaded to experimental on Thu, 4 May 2006
So you are right, debian unstable doesn't ship the latest version,
because that would have the potential to make problems with the release
of debian 4.0 (aka etch). The updated package however is there. If this
package should go to etch, because 2.6.18 is likely to be the kernel
etch ships, then both the maintainer and the release team needs to be
convinced about that.
[1] http://packages.debian.org/wireless-tools
[2] http://packages.qa.debian.org/wireless-tools
[3] http://packages.qa.debian.org/w/wireless-tools/news/20060504T210628Z.html
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4