Como alguém determina o processo causando uma solicitação ARP?

Question

Eu tenho uma máquina que executa um aplicativo intensivo de rede que gera muitos processos. Percebi recentemente que a máquina está produzindo solicitações ARP procurando por um endereço IP que não existe. Gostaria de rastrear qual processo na caixa está causando as solicitações ARP a serem geradas para resolução de problemas (para que eu possa saber qual parte do aplicativo está procurando por esse IP inexistente).

Os IPs foram alterados, mas não são importantes de qualquer forma.

Eu descobri essas solicitações ARP executando tcpdump em outra máquina na mesma rede:

# tcpdump -i eth0 arp -t -n
ARP, Request who-has 1.1.1.100 tell 1.1.1.1, length 46

Não é para ser um dispositivo com o endereço 1.1.1.100 , por isso, quero encontrar o processo em que 1.1.1.1 está procurando.

Eu tentei usar ss -np | grep 1.1.1.100 , bem como netstat -np | grep 1.1.1.100 ( netstat é considerado reprovado no lugar de ss para os curiosos, ss tem a maioria das mesmas opções e serve para executar as mesmas funções) . Nenhum deles retorna nenhum resultado, provavelmente porque ss e netstat listam soquetes abertos, e a solicitação ARP seria anterior a um soquete sendo criado.

Então, como posso discernir qual processo causa uma solicitação ARP?

    

Answer 1

ss mostra conexões que ainda não foram resolvidas pelo arp. Eles estão no estado SYN-SENT . O problema é que tal estado é mantido por apenas alguns segundos, então a conexão falha, então você pode não vê-lo. Você poderia tentar uma pesquisa rápida com

while ! ss -p state syn-sent | grep 1.1.1.100; do sleep .1; done

Uma maneira de estender o tempo neste estado é definir um endereço mac arbitrário com fio para o endereço IP em sua tabela arp. Em seguida, uma conexão levará mais de 30 segundos para expirar e será mais fácil ver com ss .

Por exemplo, com minha eth0 em 192.168.1.1

$ socat tcp:192.168.1.100:80 - 
$ arp -i eth0 -n | grep 192.168.1.100
192.168.1.100 (incomplete) eth0

configurar o endereço mac torna a socat facilmente visível

$ sudo arp -i eth0 -s 192.168.1.100 80:ef:00:ff:ff:ff
$ socat tcp:192.168.1.100:80 - &
$ ss -p state syn-sent
Netid  Recv-Q Send-Q Local Address:Port Peer Address:Port                
tcp    0      1      192.168.1.1:46608 192.168.1.100:http users:(("socat",pid=20230,fd=3))

    

Answer 2

Você pode usar o programa nethogs que exibe o tráfego de rede por processo. Mas arp não será gerado diretamente pelo processo em execução, ele seria gerado pelo sistema operacional. Alguns programas podem querer se comunicar com 1.1.1.100 e este IP não existe na tabela ARP, então o pacote ARP está sendo enviado pelo SO para preencher a tabela de endereços mac.

O servidor DHCP está executando em 1.1.1.1? Eu diria que o servidor DHCP detecta endereços no intervalo de concessão para ver quais deles são gratuitos.

    

Answer 3

Eu tive esse mesmo problema agora. Tendo tentado algumas coisas, voltei para o sysdig. Isso funcionou muito bem para mim:

sysdig fd.rip=1.1.1.100

No meu caso, o IP em questão era na verdade 172.28.210.22, e a saída era:

# sysdig fd.rip=172.28.210.22
5987580 15:42:55.952661802 7 dhclient (1232) < sendto res=300 data=...............*............RT..................................................
6318682 15:43:01.237021372 7 dhclient (1232) > sendto fd=6(<4u>172.28.210.22:67->172.28.208.42:68) size=300 tuple=0.0.0.0:68->172.28.210.22:67
6318683 15:43:01.237080305 7 dhclient (1232) < sendto res=300 data=...............*............RT..................................................
6926596 15:43:10.092470330 7 dhclient (1232) > sendto fd=6(<4u>172.28.210.22:67->172.28.208.42:68) size=300 tuple=0.0.0.0:68->172.28.210.22:67
6926608 15:43:10.092541255 7 dhclient (1232) < sendto res=300 data=...............*............RT..................................................
8882391 15:43:31.595024934 7 dhclient (1232) > sendto fd=6(<4u>172.28.210.22:67->172.28.208.42:68) size=300 tuple=0.0.0.0:68->172.28.210.22:67

que mostrava claramente que isso vinha do dhclient.