Le TFTP ne passe pas les switchs

Support Debian
#1

Bonjour,

Depuis quelques temps, j’ai un problème que je ne comprend pas : le protocole TFTP ne passe pas les switchs. J’ai cherché sur Internet, mais je n’ai aucun sujet dessus.
J’ai essayé avec un switch manageable de la marque Netgear (que j’ai briqué car je pensais que le problème venait du firmware) et un switch classique de la marque TP-Link. Quand je connecte directement le serveur au client avec un câble, ça fonctionne, mais quand je met un switch au milieu, ça ne fonctionne plus.

Fait encore plus surprenant, quand je connecte un autre ordinateur en wifi (le point d’accès wifi est relié à ce switch), cet ordinateur peut faire des requêtes TFTP sans aucun problème.

J’ai changé les ports, redémarré le serveur, le client, le switch, la box, rien n’y fait.

J’ai lancé une capture de paquets avec tcpdump, le serveur ne reçoit pas les paquets du client (alors que le DHCP a bien fonctionné).

Edit : je viens de tester avec un autre ordinateur car j’ai soupçonné la carte réseau, ça fait exactement la même chose, ça fonctionne rarement et ça ne fonctionne pas la plupart du temps.

#2

Il peux y avoir plusieurs causes, les premières à vérifier :

  • la partie dhcp fonctionne ? ton hôte cible reçoit t’il une ip ?
  • la gateway/réseaux de la partie tftp sont-elles les mêmes que l’hôte cible (question bête mais dès fois que) ?
  • la conf de la patte du switch pour le wifi a t’elle une conf identique à celles testées ?
  • vérifie que le port 69 udp soit accessible depuis l’hôte cible et qu’accessoirement l’udp puisse passer.
#3

Oui, l’hôte cible obtient une adresse IP sans problème.

Je n’ai qu’un seul réseau et le serveur TFTP est aussi le routeur.

Le switch n’est pas manageable, du coup, je pense que oui, mais je n’ai pas moyen de vérifier.

J’ai réussi à lancer un système sur l’hôte cible, j’ai fait des requêtes TFTP et ça répond sans problème.

#4

Comment utilises-tu TFTP ? Avec quels OS et logiciels clients et serveurs, quelle commande ?
Tu as fait une capture de trafic sur le poste client et sur le serveur en même temps ?
Tu as essayé avec d’autres types de trafic (ping, ssh…) ?
La résolution ARP fonctionne ?

Le protocole TFTP n’a rien de particulier tant qu’il n’y a pas de NAT ni de filtrage IP sur le chemin. Il utilise des paquets UDP en unicast dans les deux sens. Je ne vois aucune raison pour qu’il ne passe pas à travers un switch qui ne fait rien d’autre que de la commutation de trames classique.

#5

Woaw, trop de questions !

J’utilise TFTP pour un boot par le réseau. Le serveur TFTP est dnsmasq.

Non, que sur le serveur, le client n’a pas encore d’OS installé. Cependant, j’ai pu mettre un ordinateur entre le client TFTP et le switch, et les requêtes TFTP arrivent bien au switch, mais elle ne quittent pas le switch pour arriver au serveur.

Oui, tout le reste semble fonctionner.

Je vois le traffic ARP normal, il semble pas y avoir de perte de paquets à ce niveau-là.

Pareil, c’est pour ça que je demande ici, si quelqu’un ne verrait pas un truc que j’aurais oublié dans le concept de la « commutation de trames classique ».

#6

Donc le firmware de la machine (et ses bugs).
Et ça ?

« Hôte cible », c’est bien la même machine cliente ?

Hmm. Elles arrivent à la machine intermédiaire. Quant à savoir si elles arrivent vraiment au switch, sans port mirroring…
Tu as comparé les paquets TFTP envoyés par le firmware et par le système, jusqu’à la couche ethernet ?

#7

Bugs qui n’existe que quand un switch est à l’autre bout du câble. Je garde çe en tête parce que j’y crois moyen, comme toutes les autres hypothèses sur mon problème alors que ce sont les pistes les plus solides que j’ai.

Oui, c’est toi qui l’a appellé comme ça.

Le fonctionnement est le même avec ou sans la machine intermédiaire, du coup, je me dis que le problème ne vient pas de là. Quand au port mirroring, c’est dommage, j’ai briqué le switch qui aurait pu le faire.

Je n’ai pas compris ta question. Je n’ai pas de paquets à comparer, je n’ai que ceux envoyés par le client, n’en ai pas sur le serveur.

#8

Si j’ai bien compris, TFTP marche depuis un OS qui tourne sur la machine. Donc je suggère de comparer les trames ethernet contenant des paquets TFTP envoyées par le firmware lors du boot et celles envoyées par l’OS.

#9

Ce problème de TFTP et de switch attise ma curiosité et j’avoue ne pas avoir la moindre idée de ce qui pourrait provoquer de tels symptômes.

@Almtesh - Oserais-je demander si tu as progressé dans ta compréhension du problème ?

–
AnonymousCoward

#10

Non, pas du tout, pour le moment, j’ai installé un disque dur dans le client TFTP pour qu’il ne démarre plus par le réseau, mais c’est un vieux disque de récupération, je ne sais pas s’il va tenir longtemps. C’est pour ça que j’aimerai trouver l’origine du problème.
Après, j’ai acheté un nouveau PC, je ferai plus de tests quand je l’aurais reçu.

#11

Cela ne répond pas forcément à ton besoin mais as-tu déjà essayé iPXE ?

Pour éviter un téléchargement par TFTP, tu peux générer un fichier de démarrage d’un peu plus de 1 Mo que tu colles sur une clé USB avec un coup de dd et hop !

Les fichiers peuvent être téléchargés en HTTP(S), tu peux donc avoir un script PHP qui génère dynamiquement les directives de démarrage à iPXE.

Fonctionne même pour des Raspberry Pi 3/4.

–
AnonymousCoward