O pacote que você capturou mostra uma solicitação de mapeamento de porta do protocolo de controle de porta (PCP: o sucessor de trilha de padrões IETF para NAT-PMP). A porta do cliente para o mapeamento solicitado é 9 / TCP. O cliente não tem nenhuma sugestão para o que a porta externa deve ser, portanto, deixa o campo de porta externa sugerido definido como zero. O IETF RFC 6887, que define o PCP, deixa claro que zero significa "nenhuma sugestão" neste campo.
Acho que quem implementou o PCP para este bilhão de roteadores leu o RFC de maneira errada. Você vê, em alguns casos muito limitados e bem definidos, um zero no campo da outra porta poderia significar "todas as portas". Como quando o tempo de vida solicitado para essa solicitação de mapeamento é zero, uma porta de cliente zero significaria "excluir todos os mapeamentos para todas as portas nesse endereço IP do cliente".
Mas, novamente, no campo de porta externa sugerido, zero deve sempre significar "sem sugestão". Nunca é suposto significar "todas as portas" neste campo.
Portanto, parece bastante claro que você encontrou um bug PCP neste roteador Billion.
Outra coisa estranha aqui é a porta do cliente. Tradicionalmente, 9 / TCP é a porta do discard
service, mas o serviço discard
está obsoleto, então não tenho certeza de quem o executaria mais ou por que qualquer coisa estaria solicitando um mapeamento de porta para ele. / p>
Por que o mDNSResponder está enviando essas solicitações, é simplesmente porque o mDNSResponder atua como o daemon PCP / NAT-PMP / UPnP no macOS, além de suas tarefas habituais de resolução de mDNS, DNS-SD e DNS. Quando qualquer processo no macOS aciona o sistema para solicitar um mapeamento de porta do roteador, é sempre tarefa do mDNSResponder criar e enviar os pacotes de solicitação de mapeamento de porta reais.