Ping respostas ausentes, mas pode vê-las no tcpdump

Question

Ping respostas ausentes, mas pode vê-las no tcpdump

#1 resposta do (0 votos)

0

Redhat 2.6.32-754.el6.x86_64

Eu tenho uma placa FPGA atuando como uma placa de rede com um driver associado.

No meu host RH, se eu executar o ping pela FPGA NIC, vejo muitas respostas ausentes. No entanto, se eu também executar o tcpdump e filtrar no icmp, poderei ver as respostas chegando.

Aqui está um exemplo de saída do ping (observe os vários números de sequência ausentes):

 from 172.16.1.9: icmp_seq=465 ttl=128 time=0.600 ms
64 bytes from 172.16.1.9: icmp_seq=467 ttl=128 time=0.490 ms
64 bytes from 172.16.1.9: icmp_seq=480 ttl=128 time=0.565 ms
64 bytes from 172.16.1.9: icmp_seq=482 ttl=128 time=0.590 ms
64 bytes from 172.16.1.9: icmp_seq=516 ttl=128 time=0.448 ms
64 bytes from 172.16.1.9: icmp_seq=526 ttl=128 time=0.649 ms
64 bytes from 172.16.1.9: icmp_seq=528 ttl=128 time=0.534 ms
64 bytes from 172.16.1.9: icmp_seq=539 ttl=128 time=0.424 ms
64 bytes from 172.16.1.9: icmp_seq=546 ttl=128 time=0.606 ms
64 bytes from 172.16.1.9: icmp_seq=562 ttl=128 time=0.521 ms
64 bytes from 172.16.1.9: icmp_seq=569 ttl=128 time=0.651 ms
64 bytes from 172.16.1.9: icmp_seq=591 ttl=128 time=0.503 ms
64 bytes from 172.16.1.9: icmp_seq=617 ttl=128 time=0.652 ms
64 bytes from 172.16.1.9: icmp_seq=642 ttl=128 time=0.503 ms
64 bytes from 172.16.1.9: icmp_seq=643 ttl=128 time=0.672 ms
64 bytes from 172.16.1.9: icmp_seq=644 ttl=128 time=0.443 ms
64 bytes from 172.16.1.9: icmp_seq=657 ttl=128 time=0.427 ms
64 bytes from 172.16.1.9: icmp_seq=668 ttl=128 time=0.503 ms
64 bytes from 172.16.1.9: icmp_seq=704 ttl=128 time=0.332 ms
64 bytes from 172.16.1.9: icmp_seq=741 ttl=128 time=0.486 ms
64 bytes from 172.16.1.9: icmp_seq=742 ttl=128 time=0.478 ms
64 bytes from 172.16.1.9: icmp_seq=751 ttl=128 time=0.513 ms
64 bytes from 172.16.1.9: icmp_seq=753 ttl=128 time=0.511 ms
From 172.16.0.156 icmp_seq=788 Destination Host Unreachable
From 172.16.0.156 icmp_seq=789 Destination Host Unreachable
From 172.16.0.156 icmp_seq=790 Destination Host Unreachable
From 172.16.0.156 icmp_seq=792 Destination Host Unreachable
From 172.16.0.156 icmp_seq=793 Destination Host Unreachable
From 172.16.0.156 icmp_seq=794 Destination Host Unreachable
64 bytes from 172.16.1.9: icmp_seq=798 ttl=128 time=0.671 ms
64 bytes from 172.16.1.9: icmp_seq=799 ttl=128 time=0.608 ms
64 bytes from 172.16.1.9: icmp_seq=801 ttl=128 time=0.538 ms
64 bytes from 172.16.1.9: icmp_seq=814 ttl=128 time=0.402 ms
64 bytes from 172.16.1.9: icmp_seq=923 ttl=128 time=0.458 ms
From 172.16.0.156 icmp_seq=952 Destination Host Unreachable
From 172.16.0.156 icmp_seq=953 Destination Host Unreachable
From 172.16.0.156 icmp_seq=954 Destination Host Unreachable
From 172.16.0.156 icmp_seq=956 Destination Host Unreachable
From 172.16.0.156 icmp_seq=957 Destination Host Unreachable
From 172.16.0.156 icmp_seq=958 Destination Host Unreachable
64 bytes from 172.16.1.9: icmp_seq=966 ttl=128 time=0.472 ms
From 172.16.0.156 icmp_seq=979 Destination Host Unreachable
From 172.16.0.156 icmp_seq=980 Destination Host Unreachable
From 172.16.0.156 icmp_seq=981 Destination Host Unreachable
64 bytes from 172.16.1.9: icmp_seq=993 ttl=128 time=0.586 ms
^C
--- 172.16.1.9 ping statistics ---
997 packets transmitted, 96 received, +15 errors, 90% packet loss, time 996823ms
rtt min/avg/max/mdev = 0.332/31.837/2001.563/226.238 ms, pipe 3

E aqui está um trecho do tcpdump que estava sendo executado ao mesmo tempo:

16:27:24.300566 IP 172.16.1.9 > 172.16.0.156: ICMP echo reply, id 56849, seq 990, length 64
    0x0000:  4500 0054 571e 0000 8001 89c5 ac10 0109  E..TW...........
    0x0010:  ac10 009c 0000 e573 de11 03de ecd8 f65b  .......s.......[
    0x0020:  0000 0000 9294 0400 0000 0000 1011 1213  ................
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637 0000                           4567..
16:27:25.300102 IP 172.16.0.156 > 172.16.1.9: ICMP echo request, id 56849, seq 991, length 64
    0x0000:  4500 0054 0000 4000 4001 e0e3 ac10 009c  E..T..@.@.......
    0x0010:  ac10 0109 0800 5073 de11 03df edd8 f65b  ......Ps.......[
    0x0020:  0000 0000 1e94 0400 0000 0000 1011 1213  ................
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567
16:27:25.300683 IP 172.16.1.9 > 172.16.0.156: ICMP echo reply, id 56849, seq 991, length 64
    0x0000:  4500 0054 571f 0000 8001 89c4 ac10 0109  E..TW...........
    0x0010:  ac10 009c 0000 5873 de11 03df edd8 f65b  ......Xs.......[
    0x0020:  0000 0000 1e94 0400 0000 0000 1011 1213  ................
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637 0000                           4567..
16:27:26.300166 IP 172.16.0.156 > 172.16.1.9: ICMP echo request, id 56849, seq 992, length 64
    0x0000:  4500 0054 0000 4000 4001 e0e3 ac10 009c  E..T..@.@.......
    0x0010:  ac10 0109 0800 0a72 de11 03e0 eed8 f65b  .......r.......[
    0x0020:  0000 0000 6394 0400 0000 0000 1011 1213  ....c...........
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567
16:27:26.300766 IP 172.16.1.9 > 172.16.0.156: ICMP echo reply, id 56849, seq 992, length 64
    0x0000:  4500 0054 5720 0000 8001 89c3 ac10 0109  E..TW...........
    0x0010:  ac10 009c 0000 1272 de11 03e0 eed8 f65b  .......r.......[
    0x0020:  0000 0000 6394 0400 0000 0000 1011 1213  ....c...........
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637 0000                           4567..
16:27:27.300141 IP 172.16.0.156 > 172.16.1.9: ICMP echo request, id 56849, seq 993, length 64
    0x0000:  4500 0054 0000 4000 4001 e0e3 ac10 009c  E..T..@.@.......
    0x0010:  ac10 0109 0800 2071 de11 03e1 efd8 f65b  .......q.......[
    0x0020:  0000 0000 4c94 0400 0000 0000 1011 1213  ....L...........
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637                                4567
16:27:27.300694 IP 172.16.1.9 > 172.16.0.156: ICMP echo reply, id 56849, seq 993, length 64
    0x0000:  4500 0054 5721 0000 8001 89c2 ac10 0109  E..TW!..........
    0x0010:  ac10 009c 0000 2871 de11 03e1 efd8 f65b  ......(q.......[
    0x0020:  0000 0000 4c94 0400 0000 0000 1011 1213  ....L...........
    0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
    0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
    0x0050:  3435 3637 0000                           4567..
^C
1034 packets captured
1036 packets received by filter
0 packets dropped by kernel
1034 packets captured
1036 packets received by filter
0 packets dropped by kernel

Portanto, esperamos que você possa ver as respostas de eco na saída tcpdump com os números de seqüência 992, 991 e 990, que são completamente perdidos pelo ping.

Se eu alternar para o NIC incorporado, o ping funcionará conforme o esperado. Isso me fez suspeitar do meu motorista. No entanto, se o driver foi a culpa seria tcpdump também não ver as respostas icmp?

drivers ping tcpdump rhel

por Adi 22.11.2018 / 17:51

1 resposta

Tags drivers ping tcpdump rhel

Particionamento do disco rígido do Linux Sinais de Porcentagem para o Shell Vars para Remover a Extensão [duplicado]

score 0 · Answer 1

Foi o meu motorista! Ficou confuso com o material relacionado a deslocamento NET_IP_ALIGN e o endereço MAC de destino da resposta ICMP estava tendo os dois primeiros bytes mutilados pelo driver. Obviamente, o tcpdump não se importa com o endereço MAC (modo promíscuo), mas o ping faz isso.

Curiosamente, ping não viu as respostas se os dois primeiros bytes do endereço MAC de destino fossem 0x00, mas parecia que se eles fossem qualquer outra coisa, eles apareceriam! Então, eles não parecem ter que ser os valores corretos, apenas não 0x00. Novamente, isso pode ser um problema com o meu driver.