pilha de rede OS X ignora consultas de associação IGMP

1

Temos um site remoto em que os Macs não estão respondendo a consultas de associação IGMP , mas as caixas do Windows não responder. Consequentemente, após cerca de 10 minutos, o comutador de rede com IGMP corta o fluxo de multicast para os Macs.

Aqui está uma captura de tela do Wireshark mostrando o problema:

OprimeiropacoteéoaplicativosolicitandoquearedecomeceapermitirqueospacotesIGMPdo239.255.20.1passemparaoMac.Então,vocêverá,acada125segundosapartirdeentão,oswitchderedeconfiguradocomooquerierIGMP(10.1.254.254)perguntaráseaindaestamosinteressadosnessefluxo.Observeanotávelfaltaderesposta.

Aquiestáoqueaconteceaquinaredelocal,paracomparação:

Aqui,acada95segundos,operguntadorIGMP(172.20.0.2)perguntaseaindaqueremosessefluxo,eoMacemquestão(172.20.0.144)diz:"Sim, continue enviando-o."

O firewall está desativado nos Macs com problemas na GUI, e eu verifiquei na linha de comando:

$ /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Firewall is disabled. (State = 0)
$ /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
Block all DISABLED! 
$ /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode
Stealth mode disabled 
$ /usr/libexec/ApplicationFirewall/socketfilterfw --getappblocked /Applications/mumblemutter.app/...
The application is not part of the firewall 

O aplicativo não importa, já que a pilha trata as consultas IGMP depois que o grupo é associado.

Os Macs com problemas estão rodando o 10.11.5, mas eu não posso acreditar que o problema seria corrigido atualizando para o mais recente, já que isso significaria que um sistema operacional baseado em BSD está corrigindo erros sérios em sua pilha de rede em 2016. Possível , mas probabilidade extremamente baixa.

    
por Warren Young 08.12.2016 / 21:58

1 resposta

2

O problema é mostrado na primeira captura de pacotes, onde você notará que o pacote IGMP join é um pacote IGMPv2, mas as respostas do querier IGMP são todas v3.

Isso pode parecer bom, já que o Mac OS X suporta o IGMPv3 há muito tempo, mas se você entrar no Implementação IGMP no kernel de código aberto Darwin , em igmp_input_v3_query() , você encontra este código:

/*
 * Discard the v3 query if we're in Compatibility Mode.
 * The RFC is not obviously worded that hosts need to stay in
 * compatibility mode until the Old Version Querier Present
 * timer expires.
 */
if (igi->igi_version != IGMP_VERSION_3) {
    ...etc...

O que isto significa é que o Mac OS X (ou macOS, se você quiser) está obedecendo a especificação IGMPv3 e colocando qualquer interface de rede em que tenha visto pacotes IGMPv2 em "modo de compatibilidade", o que significa que ele não reconhecerá os pacotes IGMPv3 nem falará IGMPv3 nessa interface de rede. Em termos do código acima, ele marca a interface como igi_version = 2 , então vamos atingir esse teste e ignorar v3 a consulta de associação de grupo na teoria de que não é seguro falar v3 nessa rede, para que os dispositivos v2 não sejam capazes para entender o que está acontecendo.

Eu vejo três soluções viáveis:

  1. Pegue os encarregados da rede no site remoto para reconfigurar seus switches para enviar consultas IGMPv2 para os clientes que solicitaram uma associação do grupo IGMPv2.

  2. Desative o suporte IGMPv3 nos comutadores de rede compatíveis com IGMP, para que eles enviem apenas consultas de associação IGMPv2.

  3. Monitore a rede para pacotes IGMPv2, encontre sua origem e corrija, atualize ou remova-os. Se a rede não puder ser feita para falar v3 thru-and-thru, vá com # 1 ou # 2.

Isso não é algo que você possa corrigir com uma alteração no código do aplicativo. A IP_ADD_MEMBERSHIP opção para setsockopt() não inclui um número de versão, portanto, o aplicativo não está em condições de exigir IGMPv3. Essa decisão depende da pilha.

Embora seja possível que exista uma configuração do sistema operacional que possa afetar isso, isso só poderia acontecer se a implementação do Mac OS X IGMP for diferente da que vemos no igmp.c vinculado acima.

Se você detectar a rede para IGMP em uma caixa do Windows, verá que ela responde a consultas de associação IGMPv3 com respostas v3, apesar da presença de v2 na rede. É, portanto, em violação do RFC; enquanto alguns administradores de rede dirão: "Bem, funciona, não funciona?", a resposta apropriada deve ser que, como você não pode forçar o OS X a desconsiderar o RFC, resta a solução para consertar a rede.

    
por 08.12.2016 / 23:30