Tenho um fornecedor que envia mensagens multicast usando a porta 40000. Quando observo o tráfego usando tcpdump, a porta está reportando como safetynetp, como pode ser visto abaixo. O aplicativo que está escutando o tráfego em 40.000 nunca recebe as mensagens.
Este é um conflito de porta que faria com que as mensagens não fossem entregues ao aplicativo que as escuta ou tudo ainda deveria funcionar com o safetynetp usando essa porta?
O tráfego de despejo tcp se parece com
09:16:16.565887 IP x.x.x.x.33957 > x.x.x.x.safetynetp: UDP, length 263
09:16:16.569960 IP x.x.x.x.57385 > x.x.x.x.safetynetp: UDP, length 263
09:16:17.225545 IP x.x.x.x.39261 > x.x.x.x.safetynetp: UDP, length 50
Isto está em um servidor rodando RHEL 7. Existe uma maneira de permitir que o aplicativo receba essas mensagens?
Responder1
Parece improvável que este seja um conflito portuário. O utilitário tcpdump está simplesmente lendo o nome da porta do /etc/servicesarquivo, consulte services(5) para mais informações. O arquivo /etc/service mapeia um nome para uma porta/protocolo, por exemplo
safetynetp 40000/tcp # SafetyNET p
safetynetp 40000/udp # SafetyNET p
A menos que você tenha tomado medidas para permitir uma conexão na porta 40000/udp, a configuração padrão do firewall CentOS 7 bloqueará a conexão. Você deve abrir a porta em seu arquivo.