Forum Linux.général Commande netcat

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
21
juil.
2016

Bonjour à tous !
J'avais une question assez délicate si quelqu'un pourrait m'éclairer.
Lorsque je lance en meme temps dans deux fenetres différentes depuis le terminal la commande netcat -p 2345 -l par exemple pour écouter sur le port 2345 , j'ai un message d'erreur : Can't grab 0.0.0.0:2345 with bind .
Par contre lorsque je lance netcat -p 2345 -l puis netcat localhost 2345 dans une deuxième fentre et que une fois la connexion établie entre le client et le serveur je refais netcat -p 2345 -l pour écouter sur le port 2345, cette fois je n'ai pas de message d'erreur.
De cette petite expérience j'aimerais savoir quelle pourrait etre donc la différence entre netcat -p port -l et netcat localhost port du point de vue des appels systèmes de manipulation des sockets ?

Merci d'avance !

  • # Le bind sur une interface particulière

    Posté par  (site web personnel) . Évalué à 3.

    Je dirais bien que le bind se fait sur toutes tes interfaces réseau avec le -p 2345 (y compris sur lo0) par défaut.

    Fais un netstat -nlapute (aucun rapport avec quelqu'un de connu) et regarde sur quoi il se bind ton netcat.

    • [^] # Re: Le bind sur une interface particulière

      Posté par  . Évalué à 1.

      Merci pour ton retour !

      J'ai tapé la commande, sur quelle colonne regarder sur quoi se bind mon netcat ? J'ai les colonnes suivantes: Proto, Recv-Q, Send-Q, Adresse locale, Adresse distante, Etat, User, Inode et PID/
      En fait ce qui m'importe le plus c'est de faire la nuance entre netcat -p port -l et netcat localhost port du point de vue des sockets, c'est donc sur cette nuance que je cherche à etre éclairé…

  • # différence d'appel a netcat

    Posté par  (site web personnel) . Évalué à 4.

    Un petit coup de ltrace pour confirmer ce que je pensais.

    TL;DR: netcat -p 2345 -l crée une socket serveur alors que netcat localhost 2345 crée une socket cliente

    Quand tu fais un netcat -p 2345 -l tu crée une socket d'écoute qui se connecte (bind) au port 2345.

    Un seul processus peut se connecter a un port. Donc quand tu relance un notre netcat -p 2345 -l, le deuxième processus te renvoie une erreur car il ne peut binder sur la même adresse.

    Les étapes suivantes d'une connexion sont listen et accept
    Avec listen le processus serveur signale au noyau que le processus serveur est à l'écoute des connexions entrantes.
    Cependant il n'est pas prêt a traiter une connexion. Pour cela il doit faire un accept qui bloquera jusqu'à ce qu'une connexion cliente arrive sur l'ordinateur.

    Maintenant le processus serveur est bloqué.

    C'est là que netcat localhost 2345 intervient. Il s'agit d'un processus client, c'est beaucoup plus simple.
    La seule chose que le client fait c'est un connect a l'adresse (localhost) et au port (2345) du serveur.

    Maintenant le serveur est prêt a être débloqué.

    accept renvoie une socket de connexion (différente de la socket d'écoute).

    connect coté client à son tour renvoie une socket de connexion.

    En règle générale, à ce stade un processus serveur fera un autre accept pour accueillir un nouveau client. Mais netcat ne gère qu'un seul client à la fois.

    Donc maintenant le processus serveur close la socket d'écoute.

    A ce stade le client et le serveur peuvent faire des read et des write sur les socket de connexion jusqu'à ce que l'un d'entre eux close la connexion.

    Mais maintenant la socket d'écoute est fermée

    donc plus rien ne bind sur le port 2345

    donc un autre serveur peut a son tour binder dessus. Et c'est pour quoi dans le premier cas tu as une erreur et pas dans le second.

    • [^] # Re: différence d'appel a netcat

      Posté par  . Évalué à 2.

      Merci Xavier, la nuance est très claire maintenant. Ca valait la peine, plusieurs zones d'ombre ont été éclairées pour mieux comprendre ce concept et le fonctionnement client serveur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.