Em nossa instância, nosso problema foi resolvido pelos parâmetros sysctl, um diferente do Maciej.
Por favor, note que eu não falo para o OP (buecking), eu vim a este post devido ao problema ser relacionado pelo detalhe básico (sem tráfego multicast no userland).
Temos um aplicativo que lê dados enviados para quatro endereços multicast e uma porta exclusiva por endereço multicast, de um dispositivo que é (geralmente) conectado diretamente a uma interface no servidor de recebimento.
Estávamos tentando implantar esse software em um site do cliente quando ele misteriosamente falhava sem motivo conhecido. Tentativas de depurar este software resultaram na inspeção de todas as chamadas do sistema, no final todas elas nos disseram a mesma coisa:
Nosso software solicita dados e o sistema operacional nunca fornece nenhum.
O contador de pacotes multicast foi incrementado, o tcpdump mostrou o tráfego chegando à caixa / interface específica, mas não conseguimos fazer nada com ele. O SELinux foi desativado, o iptables estava em execução, mas não tinha regras em nenhuma das tabelas.
Ficamos confusos.
Ao bisbilhotar aleatoriamente, começamos a pensar sobre os parâmetros do kernel que o sysctl manipula, mas nenhum dos recursos documentados era particularmente relevante ou, se tivessem a ver com o tráfego multicast, eles estavam habilitados. Ah, e ifconfig listou "MULTICAST" na linha de recursos (up, broadcast, running, multicast). Por curiosidade, olhamos para /etc/sysctl.conf . E eis que, a imagem de base desse cliente tinha algumas linhas extras adicionadas a ele na parte inferior.
No nosso caso, o cliente definiu net.ipv4.all.rp_filter = 1 . rp_filter é o filtro Caminho de Rota, que (pelo que entendi) rejeita todo o tráfego que não poderia ter atingido essa caixa. Rede de sub-rede hopping, o pensamento é que o IP de origem está sendo falsificado.
Bem, esse servidor estava em uma sub-rede 192.168.1 / 24 e o endereço IP de origem do dispositivo para o tráfego multicast estava em algum lugar na rede 10. *. Assim, o filtro estava impedindo o servidor de fazer algo significativo com o tráfego.
Alguns ajustes aprovados pelo cliente; net.ipv4.eth0.rp_filter = 1 e net.ipv4.eth1.rp_filter = 0 e estávamos correndo felizes.