Gluon: Solicitação de recurso: use recursos 802.11s para melhor controle de links de malha

Acho que a maioria das opções de 11s não são muito interessantes para nós, pois fazemos todas as decisões de roteamento em um protocolo de roteamento de camada superior e usamos apenas 11s como substituto para o modo adhoc.

Algum trabalho sobre permitir links na lista negra foi feito em freifunk-gluon/packages#118, mas não está concluído.

Aumentar o intervalo de beacon é provavelmente uma boa ideia, só precisamos decidir sobre um bom valor (também, todos os VIFs usam o mesmo intervalo de beacon, então as mudanças afetarão as interfaces AP também).

Aumentar o intervalo do beacon não resolverá o problema de uma frequência estar lotada. Não espere muito aumento de largura de banda disso (máximo de 10%). O que você realmente quer é TDMA ou pelo menos RTS/CTS em caso de sobreposição de BSSs. Por exemplo, http://netshe.ru/ construiu uma implementação TDMA baseada em batadv14 que não usa perda de pacotes, mas informações wifi nl80211 para cálculos de métricas (mas é de código fechado e não é mantido bem o suficiente).
ATH9K HMAC https://github.com/szehl/ath9k-hmac é uma implementação de prova de conceito usando um pequeno hack para fazer o TDMA funcionar sem quebrar o CSMA/CA. Com isso, pode-se garantir que as redes AP não interfiram nas redes Mesh, mas precisaria de alguém como o NeoRaider para limpar isso para suporte ao kernel upstream. A interface de comunicação netlink do espaço do usuário é escrita em C++ e precisa ser reescrita em C primeiro. Também não há manipulador para configuração dinâmica de regras TDMA.

Talvez eu tenha encontrado um problema que piora o desempenho do 802.11s.
O 802.11s possui um recurso chamado MCCA, que é um mecanismo de prevenção de colisões que funciona de maneira semelhante ao TDMA. Todos os vizinhos 802.11s são sincronizados (consulte Sincronização de malha 802.11s ) por padrão. Isso é surpreendentemente preciso (média <10 microssegundos). Ao contrário do TDMA, o MCCA não usa timeslots, mas sim intervalos DTIM. Um nó 802.11s pode solicitar via unicast ou multicast um intervalo DTIM para seu uso. Todos os nós vizinhos negarão ou aceitarão isso por meio de uma resposta, dependendo de qualquer sobreposição com seus próprios intervalos. Assim, MCCA é algum tipo de recurso TDMA auto-organizado para 802.11s, o que é muito legal e eu gostaria de saber sobre isso antes.

Tanto quanto posso ver, os intervalos DTIM da interface mesh não têm efeito sobre os outros VIFs.

Edit: Acho que esse não é o grande problema, pois parece que o MCCA não está implementado no ath9k. O EDCA pode ter algum problema com vários VIFs (ele utiliza agendamento de fila)? E quanto aos drivers broadcom/ralink? Acho que se pode verificar os IEs se o código for de código fechado ou simplesmente muito confuso. Infelizmente eu não sei o formato correto para isso e encontrei apenas isso:

Cada estação pode
habilite seu suporte para MCCA e mostre este suporte configurando para 1 o bit MCCA Enabled,
que está no subcampo de capacidade de malha do elemento de configuração de malha presente em
beacons e respostas de sonda. Outra estação pode suportar MCCA, mas não implementá-lo (o
O subcampo Mesh Capability também inclui um bit MCCA Supported). Nesse caso, a estação pode
participar do mecanismo MCCA, mas não pode iniciar nenhuma reserva MCCA.
consulte https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf

Fechamento: A maioria das opções de 11s não são relevantes para Gluon. Se encontrarmos uma opção específica interessante para oferecer suporte, uma questão separada deve ser aberta.

Veja também:

• #421 (bloqueando links de malha individuais)
• #2028 (configuração de intervalo de beacon)