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

Question

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

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

Oúltima versão lançadaainda era v29o Ubuntu 14 e 16 que parecia conter a v30versão beta ( iwconfig -v).

Estou curioso para saber 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 e o desenvolvimento parou? Ou talvez tenha sido decidido que era estável o suficiente para interromper o desenvolvimento, mas se fosse esse o caso, por que 30 ainda seria uma versão beta?

Eu achei istoPágina do Githubmas parece ser apenas para referência histórica.

Histórico de versões

Answer 1

As ferramentas sem fio foram descontinuadas porque iwas extensões sem fio foram descontinuadas em favor da nova interface nl80211 para dispositivos sem fio. Odocumentação do kernel para iwdiz que.

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 distros que conheço) fornece a versão 30 beta é porque essa versão corrige um bug crítico que estava na versão 29, que fazia com que o iwconfig falhasse se houvesse muitas redes na área devido a um buffer transbordar. O repositório do Github para ferramentas sem fio não mostra isso, mas aqui está o patch relevante deArco

Answer 2

Eu deveria ter lido melhor as perguntas e respostas que vinculei porque havia um link para uma página discutindopor que este projeto foi abandonado:

Será que NÓS estamos sendo mais desenvolvidos?

Não não é. Apenas correções de bugs estão sendo aceitas para WE.

Por que estamos abandonando NÓS

WEs são baseados ioctl()e embora ioctl()tenham sido usados ​​e ainda sejam usados ​​como um transporte padrão para comunicação entre o usuário ←→ kernelspace, novos transportes estão sendo preferidos por vários motivos.

Nos drivers de dispositivo Linux - 3ª edição:

In user space, the ioctl system call has the following prototype:

int ioctl(int fd, unsigned long cmd, ...);

O protótipo se destaca na lista de chamadas do sistema Unix por causa dos pontos, que geralmente marcam a função como tendo um número variável de argumentos. Em um sistema real, entretanto, uma chamada de sistema não pode ter um número variável de argumentos. As chamadas de sistema devem ter um protótipo bem definido, porque os programas do usuário só podem acessá-las através de “portas” de hardware. Portanto, os pontos no protótipo representam não um número variável de argumentos, mas um único argumento opcional, tradicionalmente identificado como char *argp. Os pontos existem simplesmente para evitar a verificação de tipo durante a compilação.

Também afirma:

A natureza não estruturada da ioctlchamada fez com que ela caísse em desuso entre os desenvolvedores do kernel. Cada ioctlcomando é, essencialmente, uma chamada de sistema separada, geralmente não documentada, e não há como auditar essas chamadas de maneira abrangente. Também é difícil fazer com que os ioctlargumentos não estruturados funcionem de forma idêntica em todos os sistemas; por exemplo, considere sistemas de 64 bits com um processo de espaço do usuário em execução no modo de 32 bits.

O que é o substituto das extensões sem fio

O novo desenvolvimento deve ser focado em cfg80211 e nl80211.

---

Nota:Parece que Jean Tourrhiles trabalhou no projeto entre 1997-2009. Eu encontrei umartigo de 2014dizendo que Tourrhiles ainda estava na HP, trabalhando em um projeto chamadoOpenFlow:

Jean Tourrhiles, da HP, também preside o Grupo de Trabalho de Extensibilidade, que funciona como um “editor” para conduzir a tecnologia mais recente em versões futuras do OpenFlow