Why did wireless tools version 30 become a permanent beta?

The name of the pictureThe name of the pictureThe name of the pictureClash 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



Version history







share|improve this question






















  • "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














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



Version history







share|improve this question






















  • "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












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



Version history







share|improve this question














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



Version history









share|improve this question













share|improve this question




share|improve this question








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
















  • "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










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






share|improve this answer





























    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 although ioctl() 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 as char *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. Each ioctl 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 unstructured ioctl 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







    share|improve this answer






















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      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






























      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






      share|improve this answer


























        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






        share|improve this answer
























          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






          share|improve this answer














          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







          share|improve this answer














          share|improve this answer



          share|improve this answer








          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






















              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 although ioctl() 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 as char *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. Each ioctl 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 unstructured ioctl 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







              share|improve this answer


























                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 although ioctl() 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 as char *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. Each ioctl 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 unstructured ioctl 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







                share|improve this answer
























                  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 although ioctl() 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 as char *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. Each ioctl 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 unstructured ioctl 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







                  share|improve this answer














                  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 although ioctl() 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 as char *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. Each ioctl 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 unstructured ioctl 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








                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Nov 28 '17 at 20:46









                  MSalters

                  30019




                  30019










                  answered Nov 28 '17 at 15:25









                  Philip Kirkbride

                  2,2922470




                  2,2922470



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      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













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Bahrain

                      Postfix configuration issue with fips on centos 7; mailgun relay