Bonjour Tanguy, Un mail un peu long sur nos activités autour du projet industriel. Trois sujets : dailymotion inaccessible (en ip4 en passant par le B4), un bug dans le démon PCP, et les tous premiers essai avec libpcp/simple. * Dailymotion inaccessible hutch est une machine (Debian, sparc64) qui est derrière le B4. En utilisant hutch comme proxy pour Firefox (proxy SOCKS monté avec =ssh -D 8081 fperrin@hutch=), dailymotion.com n'est pas navigable : on obtient seulement une page blanche. FF n'indique pas de timeout DNS ni de connexion refusée, juste une page blanche. En utilisant lynx depuis hutch, la page d'accueil de dailymotion.com est affichée correctement. Après quelques analyses de trames, il semble que cela vient de l'AFTR, qui ne réassemble pas les paquets arrivant par le tunnel. Il y a peut-être un deuxième problème, qui est que le B4 fragmente les paquets ip6 qui doivent passer par le tunnel alors qu'il n'y en a pas besoin ; mais à part un fonctionnement non optimal, cela ne devrait pas causer de soucis. En effet, lorsqu'on visite dailymotion.com, on envoie dans la requête GET initiale un gros cookie ; la requête fait 1560 octets. hutch fragmente la requête en deux segments TCP, le premier pour les octets 1--1328 et le deuxième pour les octets 1329--1560. Ce deuxième segment TCP est correctement envoyé à l'AFTR puis à dailymotion, et est acquitté. Par contre, le premier segment génère du côté B4 un message ICMP /fragmentation needed/, mais est quand même envoyé à l'AFTR. Ce segment TCP est mis dans le tunnel, dans deux paquets ip6[1], et arrive correctement jusqu'à l'AFTR. L'AFTR reçoit bien ce segment. Dans la sortie de debug de =./aftr -g=, on voit « header6 (decap) », qui vient de la fonction qui décapsule les paquets ip6, lorsque cette fonction ne sait pas quoi faire des paquets ip6 reçus. Quand on pousse le niveau de debug plus haut, on voit que la fonction defrag6() est appelée. À cause du message ICMP du B4, hutch retransmet ce premier segment TCP, cette fois en diminuant de 100 octets la taille des paquets i.e. hutch renvoie deux segments TCP, l'un pour les octets 1--1228, le deuxième pour les octets 1229--1328. Ce dernier segment est bien envoyé, arrive jusqu'à dailymotion, et est acquitté. Par contre, le segment 1--1228 est envoyé dans le tunnel ip6 en deux paquets. Cette fois-ci, le B4 *n'envoie* *pas* d'ICMP /fragmentation needed/. Ce segment arrive jusqu'à l'AFTR, qui ne réussit pas à réassembler les deux paquets ip6 pour reconstruire le segment, et donc n'arrive pas jusqu'à dailymotion.com. Après 10 secondes, dailymotion.com en a assez et fermer la session TCP. [1] Le premier paquet ip6 fait 1232 octets ---alors que j'ai mesuré le MTU entre pessac168 et l'AFTR à 1452 octets. En d'autres termes, la configuration par défaut du B4, qui prévoit un MTU de 1280 octets pour ip6, est assez pessimiste. * Bug dans le démon PCP Dans la fonction new_natsrc(), i et maxport ont le même type uint16_t. Donc, dans le cas où maxport == UINT16_MAX, la boucle qui initialise les structures est infinie, finit par écrire sur de la mémoire qui ne lui appartient pas, et pcpd segfaulte. La correction est de déclarer i de type uint32_t. Également, le paramètre size est trop petit (maxport - minport au lieu de maxport - minport + 1). Patch attaché. Nous n'avons pas touché au binaire pcpd dans le dossier ~pcp/after sur l'AFTR ; le binaire pcpd+debug dans le même dossier contient notre correction et est compilé avec "gcc -g". * Utilisation de libpcp/simple On a compilé simple.c dans le dossier libpcp sur hutch. Première remarque, le code de libpcp, le draft "Proposed PCP Packet Format" et Wireshark utilisent trois formats de paquets différents :-). Ensuite, nous avons eu un peu de mal à savoir quels paramètres donner à pcpopen. En l'appelant de la façon suivante : ./pcpopen 192.108.119.176 192.168.1.133 61234 12345 tcp 999999
Le programme échoue avec « pcp_recvresponse: recv() syscall failed ». En regardant les paquets échangés avec Wireshark, il y a beaucoup de champs qui sont vides...