O que está parando nossos pacotes UDP (como ele sabe que a rota está inativa)?

Question

Temos um servidor (câmera) enviando pacotes de vídeo RTSP via UDP. No site de um cliente, ele percorre vários saltos, um dos quais pode ser um link de Wi-Fi não confiável que libera o pacote ímpar ou cinco. Normalmente, isso passa despercebido, mas às vezes mata o fluxo por alguns segundos e causa insatisfação do cliente (eu sei, sua rede cr * p é de alguma forma nosso problema ...)

Ao testar usando tc para simular uma conexão desonesta, encontramos uma situação estranha: Se quebrarmos a conexão na direção retorno ( pacotes descartados silenciosamente ), depois de alguns segundos o fluxo de pacotes UDP de nossa câmera pára, mesmo que o cliente RTSP (Live555 Wis-Streamer) ainda acredite que está enviando pacotes UDP alegremente pelo canal.

Isso é estranho, pois obviamente os pacotes UDP não são aceitos e o link físico nunca cai, então nosso sistema não tem como saber que os pacotes estão caindo no balde de bits mais acima na cadeia e o streamer não tem jeito de saber que ninguém está ouvindo (o tempo limite da sessão do streamer não expira até mais tarde).

EDIT: Vemos ARPing (Quem tem < cliente >) no momento em que os pacotes UDP param de chegar, mas nenhum antes do que diria à pilha que a conectividade caiu.

Então eu tenho duas perguntas:

1. Existe algum outro mecanismo pelo qual a pilha de rede pode dizer que a conexão tem problemas?
2. A pilha de rede elimina silenciosamente os pacotes sob certas circunstâncias?

Para demonstrar nossa configuração de testes:

Estado normal, conectividade nos dois sentidos:

Our server <==> Switch <==> TC  <==> Switch <==> PC
                 |                    |
  Wireshark <-- TAP                   |
                                      |
  Wireshark <----------------------- TAP

Estado de falha, TC descartando pacotes voltando ao nosso servidor:

Our server --> Switch --> TC  <==> Switch <==> PC
                 |                    |
  Wireshark <-- TAP                   |
                                      |
  Wireshark <----------------------- TAP

    

Answer 1

Bem, parece que a tabela ARP ficou obsoleta (apesar de estarmos transmitindo o UDP como um louco, que não chuta os tempos limite do ARP e o tráfego TCP é muito mais esparso em operações normais) aumentando os tempos limite problema de aparecer para "interrupções" de menos de ~ 2 minutos (no ponto em que a sessão do cliente RTSP atinge o tempo limite):

ARP gc_staletime extended from 60sec to 360sec
ARP base_unreachable time extended from 30sec to 240sec

Infelizmente, isso foi um pouco difícil, já que estamos no Busybox sem um comando arp disponível, mas agora parece confiável para a situação que estamos tentando resolver.

Ainda estou ansioso para entender como funciona a pilha de rede - no momento em que a tabela / entrada ARP se torna obsoleta, ela pára de enviar pacotes, mas aparentemente não causa erros maiores na cadeia do código que está tentando enviar pacotes .

    

Answer 2

Depois de interromper a conexão, você deve começar a receber pacotes de destino inacessíveis do ICMP para notificá-lo de que a conexão está interrompida. Esse é o comportamento normal do IP.

Existem ferramentas que monitoram e exibem pacotes ICMP. Outras ferramentas podem ser usadas para descarregar ou capturar todo o tráfego que corresponda a um critério de seleção.

Pode ser melhor usar um servidor proxy personalizado para descartar seus pacotes.