- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).
Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :
18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20
Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.
- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).
Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :
18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20
Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.
- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).
Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :
18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20
Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.
Salut,
JKB a écrit :
- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).
Echoue de quelle façon ?
Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :
18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Salut,
JKB a écrit :
- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).
Echoue de quelle façon ?
Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :
18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Salut,
JKB a écrit :
- certains sites qui sont résolus en IPv6 me sont inaccessibles ;
- un apt-get update échoue (sur ftp.fr.debian.org).
Echoue de quelle façon ?
Je viens de tracer ce qu'il se passe lors de l'apt-get et je vois
les choses suivantes :
18:53:47.843327 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 403:442, ack 495, win 225, options [nop,nop,TS val 2393879 ecr
180210981], length 39
18:53:47.897096 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 495:505, ack 442, win 224, options [nop,nop,TS val 180331135 ecr
2393879], length 10
18:53:47.897126 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [.],
ack 505, win 225, options [nop,nop,TS val 2393893 ecr 180331135], length
0
18:53:47.897156 IP6 rayleigh.37676 > debian.proxad.net.ftp: Flags [P.],
seq 442:481, ack 505, win 225, options [nop,nop,TS val 2393893 ecr
180331135], length 39
18:53:47.948996 IP6 debian.proxad.net.ftp > rayleigh.37676: Flags [P.],
seq 505:525, ack 481, win 224, options [nop,nop,TS val 180331188 ecr
2393893], length 20
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je communique donc bien avec le serveur distant. Celui-ci me répond
quelque chose.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.
Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...
E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.
Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...
E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.
Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...
JKB a écrit :
E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]
"Port de données", apparemment ça concerne la connexion de données.
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.
Tu as les logs complets de la session de commande avec ce client ?
Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.
Si c'est une connexion Nerim, ça peut venir du tunnel L2TP entre le LNS
et le BAS, qui peut avoir une MTU d'environ 1460 si les liens
sous-jacents ont une MTU de 1500. En IPv4 les LNS de Nerim font du
"clamping MSS" pour limiter les problèmes en TCP, je ne sais pas s'ils
le font en IPv6. J'ai configuré radvd sur mon routeur pour annoncer une
MTU de 1460 dans ses RA.
Mais habituellement le symptôme est que les petits paquets SYN et ACK
passent, mais pas les gros paquets de données de taille maximum. Or ici
on ne voit aucun paquet d'une connexion de données FTP. Tu peux quand
même essayer de baisser la MTU de l'interface pour voir si ça change
quelque chose.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...
On verrait l'avancement de la session de commande FTP. Si un transfert
en mode passif est initialisé, c'est le client qui devrait émettre un
SYN vers le serveur. Si on ne le voit pas partir, c'est que le problème
est local. Tu fais bien la capture sur le poste client ?
JKB a écrit :
E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]
"Port de données", apparemment ça concerne la connexion de données.
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.
Tu as les logs complets de la session de commande avec ce client ?
Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.
Si c'est une connexion Nerim, ça peut venir du tunnel L2TP entre le LNS
et le BAS, qui peut avoir une MTU d'environ 1460 si les liens
sous-jacents ont une MTU de 1500. En IPv4 les LNS de Nerim font du
"clamping MSS" pour limiter les problèmes en TCP, je ne sais pas s'ils
le font en IPv6. J'ai configuré radvd sur mon routeur pour annoncer une
MTU de 1460 dans ses RA.
Mais habituellement le symptôme est que les petits paquets SYN et ACK
passent, mais pas les gros paquets de données de taille maximum. Or ici
on ne voit aucun paquet d'une connexion de données FTP. Tu peux quand
même essayer de baisser la MTU de l'interface pour voir si ça change
quelque chose.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...
On verrait l'avancement de la session de commande FTP. Si un transfert
en mode passif est initialisé, c'est le client qui devrait émettre un
SYN vers le serveur. Si on ne le voit pas partir, c'est que le problème
est local. Tu fais bien la capture sur le poste client ?
JKB a écrit :
E: Impossible de récupérer
ftp://ftp.fr.debian.org/debian/pool/main/f/fail2ban/fail2ban_0.9.1-1_all.deb
Pas de réponse du port de données dans les délais [IP : 2a01:e0c:1:1598::2 21]
"Port de données", apparemment ça concerne la connexion de données.
On ne voit que des paquets de la connexion de commande FTP (port 21),
pas de connexion de données. Tu as filtré la capture ou il n'y a rien
d'autre ?
Je n'ai rien filtré. J'ai essayé à la main avec un client ftp
classique, ça échoue bien.
Tu as les logs complets de la session de commande avec ce client ?
Ça ressemble en tout point au fameux
"trou de MTU" qu'on pouvait avoir en IPv4 lorsqu'on laissait 1500 en
PPPoE, mais je ne vois pas du tout d'où ça pourrait venir.
Si c'est une connexion Nerim, ça peut venir du tunnel L2TP entre le LNS
et le BAS, qui peut avoir une MTU d'environ 1460 si les liens
sous-jacents ont une MTU de 1500. En IPv4 les LNS de Nerim font du
"clamping MSS" pour limiter les problèmes en TCP, je ne sais pas s'ils
le font en IPv6. J'ai configuré radvd sur mon routeur pour annoncer une
MTU de 1460 dans ses RA.
Mais habituellement le symptôme est que les petits paquets SYN et ACK
passent, mais pas les gros paquets de données de taille maximum. Or ici
on ne voit aucun paquet d'une connexion de données FTP. Tu peux quand
même essayer de baisser la MTU de l'interface pour voir si ça change
quelque chose.
Il faudrait analyser le dialogue FTP dans la connexion de commande avec
un programme de capture qui en est capable comme tshark/wireshark.
Peut-être, mais comme un tcpdump ne donne rien et qu'il n'y a rien
de filtré, je ne vois pas trop ce que pourrait donner un outil de capture
plus sophistiqué...
On verrait l'avancement de la session de commande FTP. Si un transfert
en mode passif est initialisé, c'est le client qui devrait émettre un
SYN vers le serveur. Si on ne le voit pas partir, c'est que le problème
est local. Tu fais bien la capture sur le poste client ?
Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique
RADVD State : Enable
mais je ne vois pas comment le configurer finement.
Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.
Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique
RADVD State : Enable
mais je ne vois pas comment le configurer finement.
Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.
Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique
RADVD State : Enable
mais je ne vois pas comment le configurer finement.
Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.
JKB a écrit :
Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique
RADVD State : Enable
mais je ne vois pas comment le configurer finement.
radvd est le démon sous Linux qui gère les annonces de routeur IPv6 (RA)
utilisées pour l'autoconf sans état sur le LAN. Il transmet le préfixe,
l'adresse de routeur et optionnellement d'autres paramètres comme les
DNS et la MTU.Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
JKB a écrit :
Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique
RADVD State : Enable
mais je ne vois pas comment le configurer finement.
radvd est le démon sous Linux qui gère les annonces de routeur IPv6 (RA)
utilisées pour l'autoconf sans état sur le LAN. Il transmet le préfixe,
l'adresse de routeur et optionnellement d'autres paramètres comme les
DNS et la MTU.
Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
JKB a écrit :
Avec une MTU de 1460 sur le lien en question, ça semble me permettre
d'atteindre les sites auparavant dans le néant. Mon modem ne propose
pas de radvd. Plus exactement, il m'indique
RADVD State : Enable
mais je ne vois pas comment le configurer finement.
radvd est le démon sous Linux qui gère les annonces de routeur IPv6 (RA)
utilisées pour l'autoconf sans état sur le LAN. Il transmet le préfixe,
l'adresse de routeur et optionnellement d'autres paramètres comme les
DNS et la MTU.Tu vas rigoler, mais j'ai l'impression qu'avec une MTU de 1460,
j'arrive à utiliser le client ftp. J'avoue que je ne comprends pas
trop.
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg écrivait :
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?
Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?
Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg écrivait :
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?
JKB a écrit :Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg écrivait :
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?
Ça devient un peu confus pour moi. Tu parles toujours d'IPv6 avec ta
connexion actuelle ? Peux-tu détailler ce qui fonctionne ou pas (IPv4,
IPv6) avec quelle valeur de MTU, sur quelle connexion, avec quel modem
dans quel mode (bridge ou routeur) et à quel moment ?
PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?
JKB a écrit :
Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?
Ça devient un peu confus pour moi. Tu parles toujours d'IPv6 avec ta
connexion actuelle ? Peux-tu détailler ce qui fonctionne ou pas (IPv4,
IPv6) avec quelle valeur de MTU, sur quelle connexion, avec quel modem
dans quel mode (bridge ou routeur) et à quel moment ?
PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?
JKB a écrit :Le Sun, 11 Jan 2015 11:21:23 +0100,
Pascal Hambourg écrivait :
Tu peux faire des essais pour déterminer la valeur maxi de MTU qui
passe, qui n'est pas forcément 1460. Si ta connexion internet est en
PPPoE, la limite de 1492 s'applique aussi en IPv6.
Justement, je me posais aussi la question. Dans l'ancien temps,
j'avais des modems Speestream 5200 et il fallait forcer le MTU à
1492. Je suis passé en PPPoA sur des Netopia 3346 et là, comme par
magie, une MTU de 1500 fonctionne. Repassage en PPPoE, en IPv4, avec
1492, ça fonctionne toujours. Avec un ZyXEL, même chose. As-tu une
explication ?
Ça devient un peu confus pour moi. Tu parles toujours d'IPv6 avec ta
connexion actuelle ? Peux-tu détailler ce qui fonctionne ou pas (IPv4,
IPv6) avec quelle valeur de MTU, sur quelle connexion, avec quel modem
dans quel mode (bridge ou routeur) et à quel moment ?
PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?
eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.
eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.
Les deux liens sont du Nerim First.
PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?
Pourquoi pas... Je n'ai pas plus d'avis que cela.
eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.
eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.
Les deux liens sont du Nerim First.
PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?
Pourquoi pas... Je n'ai pas plus d'avis que cela.
eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.
eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.
Les deux liens sont du Nerim First.
PS : on ne devrait pas poursuivre dans fr.comp.reseaux.ip plutôt ?
Pourquoi pas... Je n'ai pas plus d'avis que cela.
JKB a écrit :eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.
eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.
Les deux liens sont du Nerim First.
Encore une question : la MTU est fixée sur les routeurs ou sur le serveur ?
J'aurais bien voulu faire quelques tests complémentaires mais j'ai
l'impression que ton serveur ne répond plus sur eth2, ni en IPv4 ni en
IPv6...
JKB a écrit :
eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.
eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.
Les deux liens sont du Nerim First.
Encore une question : la MTU est fixée sur les routeurs ou sur le serveur ?
J'aurais bien voulu faire quelques tests complémentaires mais j'ai
l'impression que ton serveur ne répond plus sur eth2, ni en IPv4 ni en
IPv6...
JKB a écrit :eth1 : IPv4, MTU 1500, modem Netopia 3346 en PPPoE (depuis que le
PPPoA ne fonctionne plus sur la ligne). Dans les temps anciens, il
me fallait une MTU de 1492 pour que ça fonctionne, mais là, avec une
MTU de 1500, ça passe. C'est de l'ADSL2+. Je suppose peut-être à
tort que le modem qui embarque un système de type Unix est assez gentil
pour modifier la MTU du lien côté PPPoE. Pas d'IPv6, le Netopia ne
le permet pas.
eth2 : IPv4 et IPv6 en VDSL2, MTU 1492, modem ZyXEL SBG3300.
Lorsqu'il est en IPv4 seul, il fonctionne parfaitement avec une MTU de
1500 et du PPPoE. Pour l'IPv6, la valeur max est une MTU de 1492.
Je viens de trouver la valeur maximal avec une dichotomie.
Les deux liens sont du Nerim First.
Encore une question : la MTU est fixée sur les routeurs ou sur le serveur ?
J'aurais bien voulu faire quelques tests complémentaires mais j'ai
l'impression que ton serveur ne répond plus sur eth2, ni en IPv4 ni en
IPv6...