Echanges TCP ou UDP impossibles

Bonjour,
j'ai repris des programmes d'échange UDP ou TCP écrits en python sous Ubuntu et PiOS.
Ils fonctionnent bien en local (émetteur/récepteur sur la même machine), mais les échanges ne se font plus lorsque l'émetteur et le récepteur sont sur des machines différentes.
Les messages sont alors bien émis et reçus au niveau machine (via tshark) mais ils ne remontent pas jusqu'au programme python.
Ainsi, dans le cas de TCP, le SYN et le ACK sont bien transmis et échangés, mais ça ne va pas plus loin.
Je crains que ce ne soit une grosse sottise, mais je ne vois pas où est le problème. Je n'ai pas de pare-feu.
Merci pour votre aide.

Bonjour,

Tout ça manque un peu de clarté pour moi. Il serait utile de décrire votre équipement et la topologie réseau.

Vous dites que vous avez fait tourner tshark sur la machine elle-même et les trames sont bien émises localement, mais il faudrait faire la même chose sur l'équipement de destination, pour voir si les trames arrivent ou non. Elles ne sont peut-être pas traitées à cause d'un problème applicatif.

Logiquement, sur l'équipement de destination il doit y avoir un applicatif qui est à l'écoute avec des ports ouverts pour traiter les flux entrants. Vous pourriez tester avec nmap au départ du client que les ports sont bien ouverts pour vous (au cas où un firewall sur la machine distante bloque le trafic).
D'après ce que vous dites, j'ai l'impression que TCP est OK, mais pas UDP. Ai-je bien compris ?
Vous devriez savoir quels sont les ports qui doivent être ouverts, alors testez par exemple sur la machine de destination avec cette commande:

Code:

---

netstat -antup

---

En gros et vu qu'on a aucun détail, ça peut-être un problème de firewall, ou bien un applicatif qui ne répond pas aux requêtes. Voire même un problème de routage.

Merci pour cet effort.
Je reconnais que ce n'est pas aisé, mais si j'avais trop détaillé, cela serait devenu un peu imbuvable.
Bien entendu, comme je le disais, de façon trop condensée peut-être, tshark fonctionnait sur les deux machines et les messages sont bien reçus par la machine, sur le bon port, avec les bonnes adresses.
Le serveur TCP est bien actif sur la machine serveur et le "bind" s'st bien passé.

J'ai le même problème avec UDP où le "serveur" ne reçoit pas au niveau applicatif les trames pourtant reçues au niveau réseau (tshark).
Je n'ai pas de pare-feu et les deux machines sont sur le même réseau local, et tshark montre qu'elles reçoivent bien, donc pas de pb de routage.
Je crains que le problème ne soit en fait une grosse bêtise de ma part.
Je reviendrai avec un exemple bâti sur des programmes aussi dépouillés que possible.
Merci encore

Salut,

Je réitère la demande précédente étant donné que selon l'information que vous apportez, il est pratiquement impossible que cela ne fonctionne pas ...
Il est donc préférable de s'assurer de la validité de chaque affirmation

Code:

---

1 2	netstat -tupen --listen

---

Merci pour l'incitation et désolé pour le délai.
Voici la réponse côté serveur (client pas lancé sur une autre machine) avec la porte 5005 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

netstat -tupen --listen (Tous les processus ne peuvent être identifiés, les infos sur les processus non possédés ne seront pas affichées, vous devez être root pour les voir toutes.) Connexions Internet actives (seulement serveurs) Proto Recv-Q Send-Q Adresse locale Adresse distante Etat Utilisatr Inode PID/Program name tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN 0 63285 - tcp 0 0 0.0.0.0:5005 0.0.0.0:* LISTEN 1000 148000 14450/python3 tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 65534 55325 - tcp 0 0 0.0.0.0:8084 0.0.0.0:* LISTEN 33 51949 - tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 36266 - tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 48827 - tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 33752 - tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN 0 63284 - tcp 0 0 127.0.0.1:2947 0.0.0.0:* LISTEN 0 19337 - tcp 0 0 0.0.0.0:902 0.0.0.0:* LISTEN 0 44849 - tcp6 0 0 :::1716 :::* LISTEN 1000 61582 3467/kdeconnectd tcp6 0 0 :::22 :::* LISTEN 0 48829 - tcp6 0 0 ::1:631 :::* LISTEN 0 33751 - tcp6 0 0 :::12865 :::* LISTEN 0 30544 - tcp6 0 0 ::1:2947 :::* LISTEN 0 14999 - tcp6 0 0 :::902 :::* LISTEN 0 44848 - udp 0 0 127.0.0.53:53 0.0.0.0:* 101 36265 - udp 0 0 0.0.0.0:68 0.0.0.0:* 0 49521 - udp 0 0 0.0.0.0:69 0.0.0.0:* 0 48742 - udp 0 0 0.0.0.0:631 0.0.0.0:* 0 33765 - udp 0 0 0.0.0.0:34221 0.0.0.0:* 1000 81746 9093/firefox udp 0 0 0.0.0.0:36594 0.0.0.0:* 116 19355 - udp 0 0 224.0.0.251:5353 0.0.0.0:* 1000 85403 9584/chrome udp 0 0 224.0.0.251:5353 0.0.0.0:* 1000 85401 9584/chrome udp 0 0 0.0.0.0:5353 0.0.0.0:* 116 19353 - udp 0 0 0.0.0.0:43511 0.0.0.0:* 1000 81801 9093/firefox udp 0 0 0.0.0.0:46035 0.0.0.0:* 1000 157722 9093/firefox udp6 0 0 :::69 :::* 0 48743 - udp6 0 0 :::1716 :::* 1000 61581 3467/kdeconnectd udp6 0 0 :::53518 :::* 116 19356 - udp6 0 0 :::5353 :::* 116 19354 -

---

Cordialement

Vu que la commande netstat n'a pas été exécutée en root, le résultat peut être incomplet, comme indiqué dans le message d'avertissement.
Mais ça semble confirmer qu'une application Python écoute bien le port 5005, et sur toutes les interfaces.
Si vous avez la preuve avec tshark que les trames arrivent bien du client vers le serveur et qu'il n'y a pas de blocage au niveau firewall, alors il faut peut-être envisager un problème côté applicatif. Votre programme génère-t-il un log ? Ce programme est censé répondre aux requêtes j'imagine, donc essayez de lui faire cracher ce qu'il reçoit. Vous dites que ça fonctionne si le client et le serveur sont sur la même machine, alors ça laisse supposer que l'application ne renvoie peut-être pas la réponse vers la bonne destination.

Merci beaucoup pour cette célérité.
Il y a quelque chose d'étrange ou de très stupide dans cette affaire.
Il m'était déjà arrivé d'écrire des programmes de ce type et ça marchait.

Je confirme que ça marche en local (client et serveur sur la même machine).
Pour le reste, ce serveur ne reçoit donc rien et ne peut rien 'recracher'.
Je vais m'y remettre un de ces jours...
Bonne soirée

Juste une remarque: si la trace netstat est complète (faites-le en root pour être sûr), le port 5005 est à l'écoute seulement en TCP, pas en UDP.
Donc votre application ne traitera pas de trames UDP sur le même port, s'il devait y en avoir. Elles seront ignorées s'il n'y a aucun listener pour les traiter.

oui bien sûr.
Là il s'agissait de TCP seulement.
Je ne me rappelle plus comment ça se passait en UDP. Je vais reprendre les essais dès que j'aurai un peu plus de temps.
Merci encore.

Code:

---

1 2	tcp 0 0 0.0.0.0:5005 0.0.0.0:* LISTEN 1000 148000 14450/python3

---

C'est parfait. Le service écoute bien sur toutes les interfaces.

Est ce que vous pouvez maintenant déposer ici une capture du coté serveur lorsque le client est actif ?

Bonjour,
je m'y suis remis, mais sur UDP d'abord.
Je soupçonnais un problème d'adresse et, effectivement, ça joue :

1. en local (envoi et réception sur le même PC) :
11. tshark voit tous les messages quand il filtre (-i interface) sur 127.0.0.1 (lo)
12. quand il filtre sur l"adresse ethernet il faudrait que je refasse les essais, mais là n'est pas l'important
13 le récepteur ne reçoit que lorsque émetteur et récepteur sont sur la même adresse (lo ou ethernet)

2. en distant (Ubuntu et PiOS) on observe quelque chose d'analogue :
21. si le récepteur attend sur l'adresse ethernet (via bind), ça marche
22. si le récepteur attend sur 127.0.0.1, il ne reçoit rien

Il doit y avoir une logique derrière tout cela, mais je m'attendais à ce que des messages reçus sur lo ou ethernet soient remis au destinataire dans les mêmes conditions. Il faudra que je regarde si c'est pareil sous Windows.

Cordialement

Ce que vous décrivez est parfaitement normal. Ça tient au routage en l'occurence.
SI vous voulez communiquer avec localhost/127.0.0.1, alors le trafic va passer par défaut par l'interface lookback, ce qui est la route la plus efficace.
En revanche, pour une communication de ou vers l'extérieur, ça passera via une de vos interfaces réseau en fonction de différent critères si vous en avez plusieurs, et de nouveau le routage et les métriques entrent en ligne de compte. Si vous n'avez qu'une seule interface, le choix ne se pose pas.
Donc si vous voulez que votre application reçoive dans tous les scénarios alors elle doit être à l'écoute (bind) de toutes les interfaces, ou au moins lo + eth/eno/ensXXX selon votre système.

Et quand vous lancez tshark/tcpdump sans spécifier quelle interface vous voulez sniffer, par défaut il va choisir en excluant lo:

Citation:

---

-i

Listen on interface. If unspecified, tcpdump searches the system interface list for the lowest numbered, configured up interface (excluding loopback). Ties are broken by choosing the earliest match.
On Linux systems with 2.2 or later kernels, an interface argument of ''any'' can be used to capture packets from all interfaces. Note that captures on the ''any'' device will not be done in promiscuous mode.

If the -D flag is supported, an interface number as printed by that flag can be used as the interface argument.

---

Source: doc: https://linux.die.net/man/8/tcpdump

Merci,
En fait je n'ai jamais trop compris le rôle de "lo" qui n'intervient jamais dans le 'routage' réseau, puisque cette plage d'adresses ne figure jamais dans les paquets IP en dehors des machines. Sans vraiment y avoir réfléchi, je pensais que, dans une machine, 'lo' voyait tout ce qui y entrait et sortait, que c'était une sorte de 'facilité' pour éviter d'avoir à préciser une interface physique, en réception.
Le plus amusant est que, dans mes bricolages passés, je ne sois jamais tombé sur ce sujet.
Merci encore.