Là où je vis maintenant, la connexion Internet (filaire) présente les symptômes étranges suivants. Ils semblent être indépendants du fait que j'utilise des noms d'hôtes ou des adresses IP.
- Pinging fonctionne
- Skype fonctionne
- Wget se connecte, mais ne reçoit jamais de réponse. (Reste en attente à "Demande HTTP envoyée, en attente de réponse" jusqu'au délai d'expiration.)
- À l'exception d'un petit sous-ensemble de domaines, pour lequel cela fonctionne.
- Les commandes ssh (
ssh host ls) fonctionnent. - Le ssh interactif fonctionne pendant un court moment, mais se bloque rapidement, par exemple pendant le premier
ls- au même point à chaque fois. - Sous Windows, tout fonctionne bien.
Que puis-je faire pour diagnostiquer davantage cela? Jusqu'à présent, je viens de regarder la couche application. Puisqu'il existe une connexion Internet apparente, il doit y avoir un moyen de tunneler Firefox, mais je voudrais d'abord identifier le problème.
Cela est très probablement lié au fait que les gros paquets ne se frayent pas un chemin. J'ai découvert qu'il existe un MTU, mais le définir pour eth0 ne résout pas mon problème. Je pense que je suis derrière PPPOE et un routeur. Les IP externes sont les mêmes sous Windows et Linux.
Sortie de certaines commandes:
ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1024 qdisc mq state UP qlen 1000
link/ether 00:26:aa:aa:aa:61 brd ff:ff:ff:ff:ff:ff
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether c4:17:aa:aa:aa:ff brd ff:ff:ff:ff:ff:ff
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 5e:49:aa:aa:aa:27 brd ff:ff:ff:ff:ff:ff
ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.4 metric 1
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
169.254.0.0/16 dev eth0 scope link metric 1000
default via 192.168.1.1 dev eth0 proto static
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1024 qdisc mq state UP qlen 1000
link/ether 00:26:2d:78:ac:61 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.4/24 brd 192.168.1.255 scope global eth0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether c4:17:fe:3b:56:ff brd ff:ff:ff:ff:ff:ff
4: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 5e:49:01:03:55:27 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
inet6 fe80::5c49:1ff:fe03:5527/64 scope link
valid_lft forever preferred_lft forever
Je peux envoyer des pings jusqu'à la taille 1468.
tim@milagros:/$ ping -M do -c 1 -s 1470 stackexchange.com
PING stackexchange.com (64.34.119.12) 1470(1498) bytes of data.
--- stackexchange.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
tim@milagros:/$ ping -M do -c 1 -s 1468 stackexchange.com
PING stackexchange.com (64.34.119.12) 1468(1496) bytes of data.
1476 bytes from stackoverflow.com (64.34.119.12): icmp_seq=1 ttl=52 time=176 ms
--- stackexchange.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 176.539/176.539/176.539/0.000 ms
tim@milagros:~/projekt/perl$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:26:2d:78:ac:61
inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:161 errors:0 dropped:0 overruns:0 frame:0
TX packets:194 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:143947 (143.9 KB) TX bytes:67727 (67.7 KB)
Interrupt:16
ifconfigaffirme que le MTU est bien réglé correctement.Réponses:
Tim, je vous exhorte respectueusement à ignorer vos doutes quant au changement de MTU. Votre problème a un problème MTU écrit partout et je suis ingénieur réseau professionnel depuis plus de 15 ans.
Pour prouver si MTU aide, effectuez des tests à partir de votre machine Linux en utilisant ping avec le
DFbit défini dans l'en-tête IP ...J'ai calculé le
-sparamètre en supposant que votre MTU IP PPPoE est de 1300 octets. Si ce ping réussit, utilisez-s 1472et regardez ce qui se passe ... si le ping échoue maintenant, vous avez une preuve concluante qu'il y a un problème de MTU (en supposant que vous n'avez pas réglé votre MTU de liaison Ethernet plus bas). Pour info,-s 1472enverra une requête d'écho de charge utile Ethernet de 1 500 octets;-M do -s 1472envoie cette même charge utile de 1 500 octets avec le bit DF défini dans l'en-tête IP.N'oubliez pas non plus que MTU doit être défini sur deux côtés de la liaison ... vous devrez donc également le faire sur votre modem.
ÉDITER
Tim, vous n'avez toujours pas exécuté les commandes que je vous ai demandées . Permettez-moi de vous donner un exemple de ce qui ne va pas avec ce que vous avez fait (je dois modifier l'hôte de destination en stackexchange.com, en raison du pare-feu pour la fragmentation IP sur mon chemin vers 8.8.8.8)
Exemple négatif (en utilisant vos indicateurs de ping)
Question rhétorique: comment un paquet ping de 64 Ko a-t-il traversé un segment Ethernet de 1500 octets? (voir la note de fin A) Je ne peux pas m'empêcher de publier les informations que je demande. C'est le même exemple, avec
ping -M doExemple positif
ping -M dofournit des informations sur la MTU maximale le long du chemin (dans ce cas, nous savons que le segment Ethernet du premier saut a une longueurIP MTUde 1500 octets).Notes de fin:
A. Vos pings peuvent être complétés comme une série de fragments IP, car par défaut
pingpermet la fragmentation IP. Si vous essayez de trouver la taille de paquet maximale qui passera par un lien, vous devez modifier l'en-tête IP (que j'ai illustré avec-M do) pour vous assurer de ne pas obtenir un tas de réponses fragmentées assemblées à la fin. En utilisantping -c 1 -s 65507 64.34.119.12:la source
ifconfig eth0 mtu 1232, je pense), cela ne change pas le problème. La définition d'un MTU bien inférieur à la limite ne le fait pas non plus. Je ne savais pas que je devais définir le MTU de l'autre côté du lien - comment Windows 7, qui semble régler automatiquement son MTU, fait-il cela?ifconfig eth0 mtu 1500, la taille du ping semble plafonnée sur 1468, ce qui, avec les en-têtes, est très proche de 1500.