Discussion :

[fourchette]

Bonjour,

je ne comprends pas quelque chose :

En gros, j'ai deux réseaux locaux isolés chacun ayant un serveur Ubuntu 10.04 posé dessus, chacun servant des baux DHCP et hébergeant un atftpd. Typiquement, coté install, je ne me suis pas pris la tête : apt-get install atftpd, ce qui créé un répertoire /srv/tftp dans lequel on peut mettre les fichiers en question. J'ai posé un petit fichier pour faire des tests (/srv/tftp/deleteme)

Je précise, je ne maitrise pas l'infra-réseau, mais je pense pour le moment qu'elle est hors de cause.

Pour effectuer mes tests, j'ai utilisé un Windows 7 32bits sur lequel j'ai posé Cygwin et notamment les paquets Curl et tftp (client). J'ai aussi Java dessus avec un petit programme qui fait client TFTP.

Avec ce laptop, lorsque je branche un câble Ethernet du réseau A
dans ma fenêtre Cygwin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ curl tftp://10.155.101.72/deleteme
Warning: Could not set SO_KEEPALIVE!
chaque jour suffit sa peine
c'est ainsi
et c'est tout
$

==> mis à part le warning curl que je ne comprends pas, c'est RAS. le fichier vient bien. j'ai testé avec le client tftp normal, idem RAS. Tout marche bien.

Sur le réseau B, lorsque je branche un câble Ethernet sur le laptop, dans Cygwin, ça donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ curl tftp://100.10.10.16/deleteme
Warning: Could not set SO_KEEPALIVE!
 
$

==> bug ! le programme rend la main au bout d'un certain temps, le fichier ne vient jamais.
j'ai essayé avec le client tftp ==> même comportement. (je précise les autres services, ssh / apache par exemple, fonctionnent comme attendu depuis ce win7)

À l'analyse wireshark, on voit que le client n'envoie jamais le paquet TFTP acknowledgment, le server continue a renvoyer périodiquement le 1er block de fichier (c'est-à-dire le fichier complet car il fait moins de 512 octets). J'ai viré le firewall de mon win7 (rien à voir mais on sait jamais), j'ai viré l'antivirus (idem).

Un collègue est venu avec son laptop Ubuntu 10.04, branche le même câble du réseau B, utilise les mêmes clients (en version native et pas Cygwin bien sûr) et tout se passe comme attendu.

Est-ce quelque chose dans ma conf' réseau sur Win7 bugue spécifiquement sur tftp avec réseau B ? Est-ce que la manière dont les baux DHCP sont envoyés par le serveur peut avoir pour effet qu'un client TFTP n'envoie jamais ses paquets ACK ?

Une remarque probablement hors sujet : le serveur diffuse massivement des requêtes ARP

Si quelqu'un a une idée, je suis preneur

[Invité]

Salut,

concernant le message s0_keepalive, c'est relatif à la RFC1122, paragraphe 4.2.3.6 sur les TCP Keep-Alives. C'est un mécanisme qui permet de maintenir une connection TCP "up" lors de gros transferts de données de plusieurs heures par exemple. Voir aussi

http://www.blacksheepnetworks.com/se...tml#peer_death

à ce sujet.

Tu parles de requêtes ARP du serveur. Quelle est l'adresse IP que le serveur essaie de résoudre ?

Si ton client n'envoie pas d'ACK, c'est comme s'il n'écoutait plus sur le port en question. Ca ressemble à un stack IP qui est devenu dingo, mais chez Windows 7, j'ai déjà vu ça plusieurs fois.

Avant de brancher ton laptop sur le réseau B, peux-tu faire un reset du stack IP de Windows dans une fenêtre de commande DOS :

netsh int ip reset c:\resetlog.txt

Puis tu redémarres ton PC...

Steph

[fourchette]

merci pour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

netsh int ip reset c:\resetlog.txt

j'ai tenté, avec reboot bien sur

ca n'influe pas sur le comportement observé.

au cas où je laisse deux traces wireshark si ca peut inspirer qqn (déjà filtrée sur tftp)

tftp_test.pcap ==> la trace avec le laptop sur le réseau A où tout fonctionne comme attendu
tftp_fail_win7.pcap ==> la trace où le meme laptop utilisant le meme client n'envoie pas son paquet ACK (réseau B)

qu'est-ce qui peut bien changer pour qu'un client tftp n'envoie pas de paquet ACK au server...?
est-ce que le paquet peut-etre envoyé mais comme jms reçu il n'apparait pas dans wireshark ? qqch empeche ce paquet d'etre expédié ? reçu ?

j'y comprends rien... :-|

[Invité]

Salut,

un rapide coup d'oeil...

Oui, tu utilises le même laptop avec le même client... Mais tu n'utilises pas le même serveur TFTP!

La trace qui fonctionne :

10.155.112.123 -- Read Request --> 10.155.101.72 All-HSRP-routers_70
10.155.101.72 -- Option ACK --> 10.155.112.123
10.155.112.123 -- TFTP ACK --> 10.155.101.72

a pour extrémités TFTP

10.155.112.123 AsustekC_0e:ca:39
10.155.101.72 Cisco_9d:d6:cf


La trace qui ne fonctionne pas :

199.99.128.68 -- Read Request --> 199.99.99.160
199.99.99.160 -- Option ACK --> 199.99.128.68

a pour extrémités TFTP

199.99.128.68 AsustekC_0e:ca:39
199.99.99.160 AsustekC_0d:df:27

Il faudrait en savoir plus sur le contexte de tes tests.

Tu essaies de faire un TFTP entre un Cisco et ton client ? As-tu essayé un transfert TFTP entre 199.99.128.68 et 10.155.101.72 ? TFTP est routable, ça devrait être possible s'il existe une interco IP entre ces réseaux.

Tu peux en dire plus sur cette adresse 199.99.99.160 ?

Steph

[fourchette]

oui tu as bien vu le souci dans la trame
AsustekC_0e:ca:39 (mon laptop win7) n'envoie jms le TFTP ACK client attendu par 199.99.99.160

effectivement il y a bien deux serveurs. et les deux éléments sont sur des réseaux physiquement et volontairement déconnectés

je n'ai pas vérifié la version exacte mais à priori le server en échec (199.99.99.160) est un ubuntu desktop 10.04 32bits. c'est sur la base de cette information que j'ai monté l'autre server pour lequel j'ai choisi ubuntu 10.04 32bits et qui ne me pose aucun souci
je dis server en échec, mais ca n'est pas tt à fait vrai. quand j'utilise un autre laptop sous ubuntu : je n'ai pas de souci avec 199.99.99.160. qd je mets une clé live ubuntu sur mon laptop win7 à "probleme" => ca marche aussi...

bizarre qd mm. j'avoue que je sèche

à l'occasion je prendrais une capture avec mon laptop win7 sous ubuntu pour voir

[Invité]

à l'occasion je prendrais une capture avec mon laptop win7 sous ubuntu pour voir

Oui, ce serait une bonne idée de prendre une trace vers le même serveur TFTP depuis ta station en client Win7 et en client Ubuntu !

Steph