Portanto, o principal sintoma que me deixa desconfiado é que o ping leva cerca de um segundo ou mais para começar a imprimir quando o executo no Ubuntu e inicia quase imediatamente em um laptop OSX (não tenho o Ubuntu em um laptop, então o SO é meio que possivelmente coincidência).
Normalmente eu suspeitaria de DNS, mas este é o meu teste de DNS do Ubuntu:
dig +trace www.stackoverflow.com
; <<>> DiG 9.16.1-Ubuntu <<>> +trace www.stackoverflow.com
;; global options: +cmd
;; Received 40 bytes from 10.0.0.1#53(10.0.0.1) in 7 ms
mtr, ping e teste de velocidade estão bem em suas métricas. Por exemplo, isso é ping na área de trabalho do Ubuntu:
ping www.stackoverflow.com
PING stackoverflow.com (151.101.1.69) 56(84) bytes of data.
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=1 ttl=57 time=9.87 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=2 ttl=57 time=8.95 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=3 ttl=57 time=9.17 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=4 ttl=57 time=8.83 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=5 ttl=57 time=9.14 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=6 ttl=57 time=9.08 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=7 ttl=57 time=9.16 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=8 ttl=57 time=9.03 ms
64 bytes from 151.101.1.69 (151.101.1.69): icmp_seq=9 ttl=57 time=8.91 ms
mas o principal é que demorou quase dois segundos para começar a imprimir os tempos de ping.
Eu percebo que isso pode ser algo totalmente não relacionado ao Ubuntu, mas acho que pode haver alguns componentes internos do Linux ou conhecimento de depuração aqui que podem ajudar.
Eu posso olhar para a saída strace do ping, mas não tenho certeza do que estou procurando. strace imprime coisas e depois trava por dois segundos enquanto está fazendo o que está fazendo. esta é a saída quando eu o mato nesse ponto
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\23\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=18504, ...}) = 0
mmap(NULL, 20496, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f565ae48000
mmap(0x7f565ae49000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1000) = 0x7f565ae49000
mmap(0x7f565ae4b000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x3000) = 0x7f565ae4b000
mmap(0x7f565ae4c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x3000) = 0x7f565ae4c000
close(5) = 0
mprotect(0x7f565ae4c000, 4096, PROT_READ) = 0
munmap(0x7f565ae4e000, 155550) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0644, st_size=155550, ...}) = 0
mmap(NULL, 155550, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7f565ae4e000
close(5) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_dns.so.2", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 #\0\0\0\0\0\0"..., 832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=31176, ...}) = 0
mmap(NULL, 32984, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7f565ae3f000
mmap(0x7f565ae41000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x2000) = 0x7f565ae41000
mmap(0x7f565ae45000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x6000) = 0x7f565ae45000
mmap(0x7f565ae46000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x6000) = 0x7f565ae46000
close(5) = 0
mprotect(0x7f565ae46000, 4096, PROT_READ) = 0
munmap(0x7f565ae4e000, 155550) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
setsockopt(5, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.1.1")}, 16) = 0
poll([{fd=5, events=POLLOUT}], 1, 0) = 1 ([{fd=5, revents=POLLOUT}])
sendmmsg(5, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base=">\326\1\0\0\1\0\0\0\0\0\0\3www\rstackoverflow\3c"..., iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="w\256\1\0\0\1\0\0\0\0\0\0\3www\rstackoverflow\3c"..., iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=39}], 2, MSG_NOSIGNAL) = 2
poll([{fd=5, events=POLLIN}], 1, 5000^C) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
strace: Process 1242328 detached
Quaisquer ideias bem-vindas.
ATUALIZAR:
Agora suspeito que seja a conexão com o roteador/modem. Mas a coisa MUITO estranha é que o seguinte é lento no meu desktop Ubuntu, mas normal nos laptops (OSX).
ping dsldevice.lan
PING dsldevice.lan (192.168.1.254) 56(84) bytes of data.
64 bytes from dsldevice.lan (192.168.1.254): icmp_seq=1 ttl=63 time=2.08 ms
64 bytes from dsldevice.lan (192.168.1.254): icmp_seq=2 ttl=63 time=1.89 ms
ATUALIZAR:
Depois de muita brincadeira, executando uma atualização do apt e reiniciando, parece que estou de volta ao normal agora. Eu olhei para o tcpdump antes (quando o problema estava ocorrendo) e depois e não estou percebendo muito.
Ainda não tenho idéia, mas agora o problema desapareceu por enquanto. Será atualizado se ocorrer novamente. Parece um bom exercício de aprendizagem.
ATUALIZAÇÃO: (Isso está ficando longo)
Para referência nas perguntas da MTU, estou me conectando do Ubuntu sem fio a um roteador netgear conectado a uma conexão de fibra plusnet (usando ADSL nas instalações).
ATUALIZAÇÃO: Testando o tamanho do mtu como em https://mike632t.wordpress.com/2019/03/03/determine-mtu-size-using-ping/
Acho que algo está muito errado quando testo mtu contra 8.8.8.8? Para tamanhos maiores, recebo o erro "mensagem muito longa", mas à medida que diminuo o tamanho, a mensagem não aparece mais, mas recebo 100% de perda de pacotes até o tamanho 68 = 96-28. Talvez isso seja esperado por algum motivo?
ping -c 4 -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.254 icmp_seq=1 Frag needed and DF set (mtu = 1488)
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping -s $((97 - 28)) -D 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 69(97) bytes of data.
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
ping -s $((96 - 28)) -D 8.8.8.8 -c 1
PING 8.8.8.8 (8.8.8.8) 68(96) bytes of data.
[1620817285.571725] 76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=10.7 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.680/10.680/10.680/0.000 ms
UPDATE: outro ponto de dados.
Estou suspeitando que isso pertence mais a um fórum de rede, pois descobrirei que isso não tem nada a ver com o lado do driver do Ubuntu, como eu suspeitava anteriormente, mas ainda não tenho certeza
ping -c 3 -s $((1489 - 28)) -M do bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1461(1489) bytes of data.
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
--- bbc.co.uk ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2037ms
ping -c 3 -s $((1488 - 28)) -M do bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1460(1488) bytes of data.
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=1 ttl=58 time=11.8 ms
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=2 ttl=58 time=12.0 ms
1468 bytes from 151.101.0.81 (151.101.0.81): icmp_seq=3 ttl=58 time=10.7 ms
--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.702/11.519/12.029/0.583 ms
ATUALIZAR:
O resultado da consulta do tracepath conforme solicitado. Isso está na configuração mtu 1500. Observe que os testes mtr usuais estão mostrando boa velocidade e latência, bem como poucos pacotes.
tracepath www.ebay.com
1?: [LOCALHOST] pmtu 1488
1: www.routerlogin.com 1.048ms
1: www.routerlogin.com 1.003ms
2: dsldevice.lan 2.037ms
3: no reply
4: no reply
5: 128.hiper04.sheff.dial.plus.net.uk 10.954ms asymm 7
6: peer3-et3-1-1.slough.ukcore.bt.net 85.034ms asymm 7
7: peer2-xe8-0-2.telehouse.ukcore.bt.net 25.399ms asymm 8
8: no reply
9: no reply
10: no reply
11: no reply
ATUALIZAR:
Apenas para confirmar, o mtu está definido para 1500.
ip link | grep wlxa09f10b9ff56
3: wlxa09f10b9ff56: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
ATUALIZAÇÃO: log completo dos testes de ping contra 8.8.8.8
$ ping -c 4 -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
From 192.168.1.254 icmp_seq=1 Frag needed and DF set (mtu = 1488)
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3028ms
$ ping -c 4 -M do -s 1462 8.8.8.8 # may show fragmentation
PING 8.8.8.8 (8.8.8.8) 1462(1490) bytes of data.
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
ping: local error: message too long, mtu=1488
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3049ms
$ ping -c 4 -M do -s 1452 8.8.8.8 # no fragmentation?
PING 8.8.8.8 (8.8.8.8) 1452(1480) bytes of data.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3003ms
$ ping -c 4 -M do -s 1453 8.8.8.8 # still no fragmentation?
PING 8.8.8.8 (8.8.8.8) 1453(1481) bytes of data.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3005ms
$ ping -c 4 -M do -s 69 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 69(97) bytes of data.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3004ms
$ ping -c 4 -M do -s 68 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 68(96) bytes of data.
76 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=60.2 ms
76 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=9.07 ms
76 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=8.89 ms
76 bytes from 8.8.8.8: icmp_seq=4 ttl=116 time=9.04 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 8.887/21.802/60.215/22.177 ms
ATUALIZAÇÃO :
Para o que vale a pena, estou "em fibra" na Plusnet, mas com uma conexão ADSL curta (é o que eles me dizem de qualquer maneira). De acordo com este tópico, isso significa que o padrão do roteador Plusnet é 1500 e eu tenho tudo upstream (roteador netgear, desktop ubuntu) definido para 1500 também.
Seu problema é com a configuração de MTU para sua conexão DSL.
Há uma configuração de MTU na configuração de rede do Ubuntu e uma configuração de WAN MTU em seu roteador.
Para DSL, uma configuração comum de MTU é 1492. Vá em frente e tente esse valor primeiro e veja se seus sites agora estão acessíveis.
Para determinar a configuração correta, comece com todas as configurações de MTU = 1500 e VPN = desativada. (VPN requer testes diferentes).
No
terminal:ping [-c count] [-M do] [-s packet_size] [host]
As opções utilizadas são:
c count: número de vezes para pingM hint: Selecione a estratégia Path MTU Discovery. pode serdo(proibir a fragmentação, mesmo local),want(fazer descoberta de PMTU, fragmentar localmente quando o tamanho do pacote for grande) oudont(não definir o sinalizador DF).s packet_size: Especifica o número de bytes de dados a serem enviados.Você deve sempre começar em 1472 e diminuir em 10 a cada vez. Depois de obter uma resposta, suba em 1 até obter um pacote fragmentado. Pegue esse valor (último valor válido) e adicione 28 ao valor para contabilizar os vários cabeçalhos TCP/IP. Por exemplo. digamos que 1452 era o tamanho de pacote adequado (onde você obteve uma resposta ICMP ao seu ping). O tamanho real da MTU seria 1480, que é o ideal para a rede com a qual estamos trabalhando.
ping -c 4 -M do -s 1472 8.8.8.8# isso provavelmente mostrará fragmentaçãoping -c 4 -M do -s 1462 8.8.8.8# pode mostrar fragmentaçãoping -c 4 -M do -s 1452 8.8.8.8# sem fragmentação?ping -c 4 -M do -s 1453 8.8.8.8# ainda sem fragmentação?referência: Como determinar o tamanho adequado da MTU com pings ICMP
Verifique seu WiFi
MTU, usandoobserve também o nome da sua interface WiFi.
A
MTU(Unidade Máxima de Transmissão) é o tamanho do maior pacote que pode ser enviado em uma única transmissão de rede. Se um pacote exceder aMTUde um link, os dados devem ser divididos em vários pacotes (fragmentados). Esses vários pacotes devem ser enviados pelo link, recebidos, reconhecidos e remontados na extremidade oposta. Se o seu link estiver mal configurado e você precisar fragmentar todos os pacotes enviados, sua taxa de transferência de dados real cairá.As redes Ethernet (com fio) usam
MTU1500 bytes.Devido à sobrecarga adicional por pacote para WiFi (cabeçalho PPPoE de 8 bytes), o WiFi usa um
MTUde 1492.Seu
MTUdeve ser definido pelo seu servidor DHCP, verifique a configuração do seu roteador.Você pode definir o seu próprio
MTU(a configuração não persiste nas reinicializações) comonde "name" é o nome da interface acima.
Aqui está um exemplo:
Meu "nome da interface" WiFi é "
wlxf46d04b1790f".