Why did wireless tools version 30 become a permanent beta?
Clash Royale CLAN TAG#URR8PPP
up vote
10
down vote
favorite
I found some good information about wireless tools in this Q/A. Apparently it was introduced to the Linux kernel in 1997 by Jean Tourrhiles sponsored by Hewlett Packard.
Edit: It seems WE(Wireless Extensions) was added to the Kernel by Tourrhiles, not the wireless tools themselves. The tools are available on most distros as the primary way to communicate with WE. You can see WE in the kernel at /proc/net/wireless
.
The last version released was v29
yet Ubuntu 14 & 16 seem to contain the v30
beta (iwconfig -v
).
I'm curious about what happened to this package? Why did the "beta" version 30 become the defacto standard version used?
Did HP stop funding Jean Tourrhiles so development stopped? Or maybe it was decided that it was stable enough to stop development, but if that was the case why would 30 still be a beta?
I found this Github page but it seems to be for historical reference only.
Version History
linux linux-kernel wifi history
add a comment |Â
up vote
10
down vote
favorite
I found some good information about wireless tools in this Q/A. Apparently it was introduced to the Linux kernel in 1997 by Jean Tourrhiles sponsored by Hewlett Packard.
Edit: It seems WE(Wireless Extensions) was added to the Kernel by Tourrhiles, not the wireless tools themselves. The tools are available on most distros as the primary way to communicate with WE. You can see WE in the kernel at /proc/net/wireless
.
The last version released was v29
yet Ubuntu 14 & 16 seem to contain the v30
beta (iwconfig -v
).
I'm curious about what happened to this package? Why did the "beta" version 30 become the defacto standard version used?
Did HP stop funding Jean Tourrhiles so development stopped? Or maybe it was decided that it was stable enough to stop development, but if that was the case why would 30 still be a beta?
I found this Github page but it seems to be for historical reference only.
Version History
linux linux-kernel wifi history
"Why did wireless tools version 30 in the Linux kernel ..." - wireless-tools isn't in the kernel. The drivers are in the kernel, wireless-tools is the (a) user-space component for configuring the kernel-space drivers.
â marcelm
Nov 29 '17 at 15:03
1
@marcelm I added a note in my question based on your comment. I guess he did add WE to the kernel/proc/net/wireless
but the wireless-tools themselves are not part of the kernel. Let me know if I'm wrong on that.
â Philip Kirkbride
Nov 29 '17 at 15:15
1
Yes, WE are part of the kernel. More accurately, "Wireless Extensions" is the name of the user space <-> kernel space interface exposed by the wireless plumbing in the kernel. wireless-tools uses that interface to manipulate the wireless devices. They are independently versioned; on my system wireless-tools is version 30, and it talks to my kernel (4.9.0) with WE version 22 :)
â marcelm
Nov 29 '17 at 15:30
add a comment |Â
up vote
10
down vote
favorite
up vote
10
down vote
favorite
I found some good information about wireless tools in this Q/A. Apparently it was introduced to the Linux kernel in 1997 by Jean Tourrhiles sponsored by Hewlett Packard.
Edit: It seems WE(Wireless Extensions) was added to the Kernel by Tourrhiles, not the wireless tools themselves. The tools are available on most distros as the primary way to communicate with WE. You can see WE in the kernel at /proc/net/wireless
.
The last version released was v29
yet Ubuntu 14 & 16 seem to contain the v30
beta (iwconfig -v
).
I'm curious about what happened to this package? Why did the "beta" version 30 become the defacto standard version used?
Did HP stop funding Jean Tourrhiles so development stopped? Or maybe it was decided that it was stable enough to stop development, but if that was the case why would 30 still be a beta?
I found this Github page but it seems to be for historical reference only.
Version History
linux linux-kernel wifi history
I found some good information about wireless tools in this Q/A. Apparently it was introduced to the Linux kernel in 1997 by Jean Tourrhiles sponsored by Hewlett Packard.
Edit: It seems WE(Wireless Extensions) was added to the Kernel by Tourrhiles, not the wireless tools themselves. The tools are available on most distros as the primary way to communicate with WE. You can see WE in the kernel at /proc/net/wireless
.
The last version released was v29
yet Ubuntu 14 & 16 seem to contain the v30
beta (iwconfig -v
).
I'm curious about what happened to this package? Why did the "beta" version 30 become the defacto standard version used?
Did HP stop funding Jean Tourrhiles so development stopped? Or maybe it was decided that it was stable enough to stop development, but if that was the case why would 30 still be a beta?
I found this Github page but it seems to be for historical reference only.
Version History
linux linux-kernel wifi history
edited Dec 3 '17 at 2:11
Jeff Schaller
32.1k849109
32.1k849109
asked Nov 28 '17 at 15:02
Philip Kirkbride
2,2922470
2,2922470
"Why did wireless tools version 30 in the Linux kernel ..." - wireless-tools isn't in the kernel. The drivers are in the kernel, wireless-tools is the (a) user-space component for configuring the kernel-space drivers.
â marcelm
Nov 29 '17 at 15:03
1
@marcelm I added a note in my question based on your comment. I guess he did add WE to the kernel/proc/net/wireless
but the wireless-tools themselves are not part of the kernel. Let me know if I'm wrong on that.
â Philip Kirkbride
Nov 29 '17 at 15:15
1
Yes, WE are part of the kernel. More accurately, "Wireless Extensions" is the name of the user space <-> kernel space interface exposed by the wireless plumbing in the kernel. wireless-tools uses that interface to manipulate the wireless devices. They are independently versioned; on my system wireless-tools is version 30, and it talks to my kernel (4.9.0) with WE version 22 :)
â marcelm
Nov 29 '17 at 15:30
add a comment |Â
"Why did wireless tools version 30 in the Linux kernel ..." - wireless-tools isn't in the kernel. The drivers are in the kernel, wireless-tools is the (a) user-space component for configuring the kernel-space drivers.
â marcelm
Nov 29 '17 at 15:03
1
@marcelm I added a note in my question based on your comment. I guess he did add WE to the kernel/proc/net/wireless
but the wireless-tools themselves are not part of the kernel. Let me know if I'm wrong on that.
â Philip Kirkbride
Nov 29 '17 at 15:15
1
Yes, WE are part of the kernel. More accurately, "Wireless Extensions" is the name of the user space <-> kernel space interface exposed by the wireless plumbing in the kernel. wireless-tools uses that interface to manipulate the wireless devices. They are independently versioned; on my system wireless-tools is version 30, and it talks to my kernel (4.9.0) with WE version 22 :)
â marcelm
Nov 29 '17 at 15:30
"Why did wireless tools version 30 in the Linux kernel ..." - wireless-tools isn't in the kernel. The drivers are in the kernel, wireless-tools is the (a) user-space component for configuring the kernel-space drivers.
â marcelm
Nov 29 '17 at 15:03
"Why did wireless tools version 30 in the Linux kernel ..." - wireless-tools isn't in the kernel. The drivers are in the kernel, wireless-tools is the (a) user-space component for configuring the kernel-space drivers.
â marcelm
Nov 29 '17 at 15:03
1
1
@marcelm I added a note in my question based on your comment. I guess he did add WE to the kernel
/proc/net/wireless
but the wireless-tools themselves are not part of the kernel. Let me know if I'm wrong on that.â Philip Kirkbride
Nov 29 '17 at 15:15
@marcelm I added a note in my question based on your comment. I guess he did add WE to the kernel
/proc/net/wireless
but the wireless-tools themselves are not part of the kernel. Let me know if I'm wrong on that.â Philip Kirkbride
Nov 29 '17 at 15:15
1
1
Yes, WE are part of the kernel. More accurately, "Wireless Extensions" is the name of the user space <-> kernel space interface exposed by the wireless plumbing in the kernel. wireless-tools uses that interface to manipulate the wireless devices. They are independently versioned; on my system wireless-tools is version 30, and it talks to my kernel (4.9.0) with WE version 22 :)
â marcelm
Nov 29 '17 at 15:30
Yes, WE are part of the kernel. More accurately, "Wireless Extensions" is the name of the user space <-> kernel space interface exposed by the wireless plumbing in the kernel. wireless-tools uses that interface to manipulate the wireless devices. They are independently versioned; on my system wireless-tools is version 30, and it talks to my kernel (4.9.0) with WE version 22 :)
â marcelm
Nov 29 '17 at 15:30
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
17
down vote
accepted
Wireless tools is deprecated in favor of iw
because the wireless extensions has been deprecated in favor of the new nl80211 interface for wireless devices. The kernel documentation for iw says that.
However, nl80211 is under active development and not all drivers have been migrated to it. Wireless tools is still required for devices that have not been migrated from wireless extensions.
The reason Ubuntu (and pretty much all distros I know of) provide version 30 beta is because that version fixes a critical bug that was in version 29, which caused the iwconfig to fail if there were too many networks in the area due to a buffer overflow. The Github repo for wireless tools does not show this, but here's the relevant patch from Arch
add a comment |Â
up vote
17
down vote
I should have read through the Q/A that I linked better because there was a link to a page discussing why this project was abandoned:
Is WE being further developed ?
No it is not. Only bug fixes are being accepted for WE.
Why we are abandoning WE
WEs are based on
ioctl()
and althoughioctl()
has been used and still
is being used as a standard transport for communication between user
âÂÂâ kernelspace new transports are being preferred for several reasons.
From Linux Device Drivers - 3rd Edition:
In user space, the ioctl system call has the following prototype:
int ioctl(int fd, unsigned long cmd, ...);
The prototype stands out in the list of Unix system calls because of
the dots, which usually mark the function as having a variable
number of arguments. In a real system, however, a system call canâÂÂt
actually have a variable number of arguments. System calls must have a
well-defined prototype, because user programs can access them only
through hardware âÂÂgates.â Therefore, the dots in the prototype
represent not a variable number of arguments but a single optional
argument, traditionally identified aschar *argp
. The dots are simply
there to prevent type checking during compilation.
It also states:
The unstructured nature of the
ioctl
call has caused it to fall out of favor among kernel developers. Eachioctl
command is,
essentially, a separate, usually undocumented system call, and there
is no way to audit these calls in any sort of comprehensive manner. It
is also difficult to make the unstructuredioctl
arguments work
identically on all systems; for example, consider 64-bit systems with
a userspace process running in 32-bit mode.
What is Wireless-Extensions' replacement
New development should be focused on cfg80211 and nl80211.
Side Note: It seems Jean Tourrhiles worked on the project from around 1997-2009. I found an article from 2014 saying Tourrhiles was still at HP, working on a project called OpenFlow:
HPâÂÂs Jean Tourrhiles also chairs the Extensibility Working Group,
which works as an âÂÂeditorâ to drive the latest technology into future
versions of OpenFlow
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
17
down vote
accepted
Wireless tools is deprecated in favor of iw
because the wireless extensions has been deprecated in favor of the new nl80211 interface for wireless devices. The kernel documentation for iw says that.
However, nl80211 is under active development and not all drivers have been migrated to it. Wireless tools is still required for devices that have not been migrated from wireless extensions.
The reason Ubuntu (and pretty much all distros I know of) provide version 30 beta is because that version fixes a critical bug that was in version 29, which caused the iwconfig to fail if there were too many networks in the area due to a buffer overflow. The Github repo for wireless tools does not show this, but here's the relevant patch from Arch
add a comment |Â
up vote
17
down vote
accepted
Wireless tools is deprecated in favor of iw
because the wireless extensions has been deprecated in favor of the new nl80211 interface for wireless devices. The kernel documentation for iw says that.
However, nl80211 is under active development and not all drivers have been migrated to it. Wireless tools is still required for devices that have not been migrated from wireless extensions.
The reason Ubuntu (and pretty much all distros I know of) provide version 30 beta is because that version fixes a critical bug that was in version 29, which caused the iwconfig to fail if there were too many networks in the area due to a buffer overflow. The Github repo for wireless tools does not show this, but here's the relevant patch from Arch
add a comment |Â
up vote
17
down vote
accepted
up vote
17
down vote
accepted
Wireless tools is deprecated in favor of iw
because the wireless extensions has been deprecated in favor of the new nl80211 interface for wireless devices. The kernel documentation for iw says that.
However, nl80211 is under active development and not all drivers have been migrated to it. Wireless tools is still required for devices that have not been migrated from wireless extensions.
The reason Ubuntu (and pretty much all distros I know of) provide version 30 beta is because that version fixes a critical bug that was in version 29, which caused the iwconfig to fail if there were too many networks in the area due to a buffer overflow. The Github repo for wireless tools does not show this, but here's the relevant patch from Arch
Wireless tools is deprecated in favor of iw
because the wireless extensions has been deprecated in favor of the new nl80211 interface for wireless devices. The kernel documentation for iw says that.
However, nl80211 is under active development and not all drivers have been migrated to it. Wireless tools is still required for devices that have not been migrated from wireless extensions.
The reason Ubuntu (and pretty much all distros I know of) provide version 30 beta is because that version fixes a critical bug that was in version 29, which caused the iwconfig to fail if there were too many networks in the area due to a buffer overflow. The Github repo for wireless tools does not show this, but here's the relevant patch from Arch
edited Nov 28 '17 at 15:56
Jeff Schaller
32.1k849109
32.1k849109
answered Nov 28 '17 at 15:34
Munir
2,097419
2,097419
add a comment |Â
add a comment |Â
up vote
17
down vote
I should have read through the Q/A that I linked better because there was a link to a page discussing why this project was abandoned:
Is WE being further developed ?
No it is not. Only bug fixes are being accepted for WE.
Why we are abandoning WE
WEs are based on
ioctl()
and althoughioctl()
has been used and still
is being used as a standard transport for communication between user
âÂÂâ kernelspace new transports are being preferred for several reasons.
From Linux Device Drivers - 3rd Edition:
In user space, the ioctl system call has the following prototype:
int ioctl(int fd, unsigned long cmd, ...);
The prototype stands out in the list of Unix system calls because of
the dots, which usually mark the function as having a variable
number of arguments. In a real system, however, a system call canâÂÂt
actually have a variable number of arguments. System calls must have a
well-defined prototype, because user programs can access them only
through hardware âÂÂgates.â Therefore, the dots in the prototype
represent not a variable number of arguments but a single optional
argument, traditionally identified aschar *argp
. The dots are simply
there to prevent type checking during compilation.
It also states:
The unstructured nature of the
ioctl
call has caused it to fall out of favor among kernel developers. Eachioctl
command is,
essentially, a separate, usually undocumented system call, and there
is no way to audit these calls in any sort of comprehensive manner. It
is also difficult to make the unstructuredioctl
arguments work
identically on all systems; for example, consider 64-bit systems with
a userspace process running in 32-bit mode.
What is Wireless-Extensions' replacement
New development should be focused on cfg80211 and nl80211.
Side Note: It seems Jean Tourrhiles worked on the project from around 1997-2009. I found an article from 2014 saying Tourrhiles was still at HP, working on a project called OpenFlow:
HPâÂÂs Jean Tourrhiles also chairs the Extensibility Working Group,
which works as an âÂÂeditorâ to drive the latest technology into future
versions of OpenFlow
add a comment |Â
up vote
17
down vote
I should have read through the Q/A that I linked better because there was a link to a page discussing why this project was abandoned:
Is WE being further developed ?
No it is not. Only bug fixes are being accepted for WE.
Why we are abandoning WE
WEs are based on
ioctl()
and althoughioctl()
has been used and still
is being used as a standard transport for communication between user
âÂÂâ kernelspace new transports are being preferred for several reasons.
From Linux Device Drivers - 3rd Edition:
In user space, the ioctl system call has the following prototype:
int ioctl(int fd, unsigned long cmd, ...);
The prototype stands out in the list of Unix system calls because of
the dots, which usually mark the function as having a variable
number of arguments. In a real system, however, a system call canâÂÂt
actually have a variable number of arguments. System calls must have a
well-defined prototype, because user programs can access them only
through hardware âÂÂgates.â Therefore, the dots in the prototype
represent not a variable number of arguments but a single optional
argument, traditionally identified aschar *argp
. The dots are simply
there to prevent type checking during compilation.
It also states:
The unstructured nature of the
ioctl
call has caused it to fall out of favor among kernel developers. Eachioctl
command is,
essentially, a separate, usually undocumented system call, and there
is no way to audit these calls in any sort of comprehensive manner. It
is also difficult to make the unstructuredioctl
arguments work
identically on all systems; for example, consider 64-bit systems with
a userspace process running in 32-bit mode.
What is Wireless-Extensions' replacement
New development should be focused on cfg80211 and nl80211.
Side Note: It seems Jean Tourrhiles worked on the project from around 1997-2009. I found an article from 2014 saying Tourrhiles was still at HP, working on a project called OpenFlow:
HPâÂÂs Jean Tourrhiles also chairs the Extensibility Working Group,
which works as an âÂÂeditorâ to drive the latest technology into future
versions of OpenFlow
add a comment |Â
up vote
17
down vote
up vote
17
down vote
I should have read through the Q/A that I linked better because there was a link to a page discussing why this project was abandoned:
Is WE being further developed ?
No it is not. Only bug fixes are being accepted for WE.
Why we are abandoning WE
WEs are based on
ioctl()
and althoughioctl()
has been used and still
is being used as a standard transport for communication between user
âÂÂâ kernelspace new transports are being preferred for several reasons.
From Linux Device Drivers - 3rd Edition:
In user space, the ioctl system call has the following prototype:
int ioctl(int fd, unsigned long cmd, ...);
The prototype stands out in the list of Unix system calls because of
the dots, which usually mark the function as having a variable
number of arguments. In a real system, however, a system call canâÂÂt
actually have a variable number of arguments. System calls must have a
well-defined prototype, because user programs can access them only
through hardware âÂÂgates.â Therefore, the dots in the prototype
represent not a variable number of arguments but a single optional
argument, traditionally identified aschar *argp
. The dots are simply
there to prevent type checking during compilation.
It also states:
The unstructured nature of the
ioctl
call has caused it to fall out of favor among kernel developers. Eachioctl
command is,
essentially, a separate, usually undocumented system call, and there
is no way to audit these calls in any sort of comprehensive manner. It
is also difficult to make the unstructuredioctl
arguments work
identically on all systems; for example, consider 64-bit systems with
a userspace process running in 32-bit mode.
What is Wireless-Extensions' replacement
New development should be focused on cfg80211 and nl80211.
Side Note: It seems Jean Tourrhiles worked on the project from around 1997-2009. I found an article from 2014 saying Tourrhiles was still at HP, working on a project called OpenFlow:
HPâÂÂs Jean Tourrhiles also chairs the Extensibility Working Group,
which works as an âÂÂeditorâ to drive the latest technology into future
versions of OpenFlow
I should have read through the Q/A that I linked better because there was a link to a page discussing why this project was abandoned:
Is WE being further developed ?
No it is not. Only bug fixes are being accepted for WE.
Why we are abandoning WE
WEs are based on
ioctl()
and althoughioctl()
has been used and still
is being used as a standard transport for communication between user
âÂÂâ kernelspace new transports are being preferred for several reasons.
From Linux Device Drivers - 3rd Edition:
In user space, the ioctl system call has the following prototype:
int ioctl(int fd, unsigned long cmd, ...);
The prototype stands out in the list of Unix system calls because of
the dots, which usually mark the function as having a variable
number of arguments. In a real system, however, a system call canâÂÂt
actually have a variable number of arguments. System calls must have a
well-defined prototype, because user programs can access them only
through hardware âÂÂgates.â Therefore, the dots in the prototype
represent not a variable number of arguments but a single optional
argument, traditionally identified aschar *argp
. The dots are simply
there to prevent type checking during compilation.
It also states:
The unstructured nature of the
ioctl
call has caused it to fall out of favor among kernel developers. Eachioctl
command is,
essentially, a separate, usually undocumented system call, and there
is no way to audit these calls in any sort of comprehensive manner. It
is also difficult to make the unstructuredioctl
arguments work
identically on all systems; for example, consider 64-bit systems with
a userspace process running in 32-bit mode.
What is Wireless-Extensions' replacement
New development should be focused on cfg80211 and nl80211.
Side Note: It seems Jean Tourrhiles worked on the project from around 1997-2009. I found an article from 2014 saying Tourrhiles was still at HP, working on a project called OpenFlow:
HPâÂÂs Jean Tourrhiles also chairs the Extensibility Working Group,
which works as an âÂÂeditorâ to drive the latest technology into future
versions of OpenFlow
edited Nov 28 '17 at 20:46
MSalters
30019
30019
answered Nov 28 '17 at 15:25
Philip Kirkbride
2,2922470
2,2922470
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f407517%2fwhy-did-wireless-tools-version-30-become-a-permanent-beta%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
"Why did wireless tools version 30 in the Linux kernel ..." - wireless-tools isn't in the kernel. The drivers are in the kernel, wireless-tools is the (a) user-space component for configuring the kernel-space drivers.
â marcelm
Nov 29 '17 at 15:03
1
@marcelm I added a note in my question based on your comment. I guess he did add WE to the kernel
/proc/net/wireless
but the wireless-tools themselves are not part of the kernel. Let me know if I'm wrong on that.â Philip Kirkbride
Nov 29 '17 at 15:15
1
Yes, WE are part of the kernel. More accurately, "Wireless Extensions" is the name of the user space <-> kernel space interface exposed by the wireless plumbing in the kernel. wireless-tools uses that interface to manipulate the wireless devices. They are independently versioned; on my system wireless-tools is version 30, and it talks to my kernel (4.9.0) with WE version 22 :)
â marcelm
Nov 29 '17 at 15:30