Por que a versão 30 das ferramentas sem fio se tornou uma versão beta permanente?

10

Encontrei algumas boas informações sobre ferramentas sem fio neste Perguntas e Respostas . Aparentemente, foi introduzido no kernel Linux em 1997 por Jean Tourrhiles, patrocinado pela Hewlett Packard.

Edit: Parece que WE (Wireless Extensions) foi adicionado ao Kernel por Tourrhiles, e não as ferramentas sem fio em si. As ferramentas estão disponíveis na maioria das distros como a principal forma de se comunicar com a WE. Você pode ver o WE no kernel em /proc/net/wireless .

A última versão lançada foi v29 yet Ubuntu 14 & 16 parecem conter o v30 beta ( iwconfig -v ).

Estou curioso sobre o que aconteceu com este pacote? Por que a versão "beta" 30 se tornou a versão padrão usada?

A HP parou de financiar Jean Tourrhiles para que o desenvolvimento parasse? Ou talvez tenha sido decidido que era estável o suficiente para parar o desenvolvimento, mas se esse fosse o caso, por que 30 ainda seria um beta?

Eu encontrei esta página do Github , mas ela parece ser apenas para referência histórica.

Histórico de versões

    
por Philip Kirkbride 28.11.2017 / 16:02

2 respostas

17

As ferramentas sem fio estão obsoletas em favor de iw porque as extensões sem fio foram preteridas em favor da nova interface nl80211 para dispositivos sem fio. A documentação do kernel para o iw diz isso.

No entanto, o nl80211 está em desenvolvimento ativo e nem todos os drivers foram migrados para ele. As ferramentas sem fio ainda são necessárias para dispositivos que não foram migrados de extensões sem fio.

A razão pela qual o Ubuntu (e praticamente todas as distribuições que eu conheço) fornece a versão 30 beta é porque essa versão corrige um bug crítico que estava na versão 29, o que causou falha no iwconfig se houvesse muitas redes na área devido para um estouro de buffer. O repositório do Github para ferramentas sem fio não mostra isso, mas aqui está o patch relevante de Arco

    
por 28.11.2017 / 16:34
17

Eu deveria ter lido o Q / A que eu vinculei melhor porque havia um link para uma página discutindo por que este projeto foi abandonado :

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.

Nota: Parece que Jean Tourrhiles trabalhou no projeto por volta de 1997-2009. Eu encontrei um artigo de 2014 dizendo que Tourrhiles ainda estava na HP, trabalhando em um projeto chamado 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

    
por 28.11.2017 / 16:25