Socat, un outil en ligne de commande pour maîtriser vos sockets

Posté par  (site web personnel) . Édité par Pierre Jarillon et claudex. Modéré par Nÿco. Licence CC By‑SA.
Étiquettes :
39
7
déc.
2011
Ligne de commande

Socat est un outil en ligne de commande pour manipuler des sockets réseau, sous licence GPL. La version 1.7.2.0 vient de sortir avec les nouveautés suivantes :

  • prise en charge des interfaces tun/tap sans adresse IP ;
  • ajout des options openssl-compress et max-children ;
  • amélioration pour certaines plateformes, et notamment Mac OS X Lion, DragonFly et Android.

Rappelons que socat sert principalement à relayer deux flux de données de manière bidirectionnelle. Comme ces flux peuvent être de types très variés et acceptent de nombreuses options, il est possible d'utiliser socat pour des usages très divers. Voici quelques exemples :

socat -d -d READLINE,history=$HOME/.http_history TCP4:www.domain.org:www,crnl
# Vous pouvez saisir du texte avec la bibliothèque readline et il sera envoyé en TCP à www.domain.org sur le port 80 (www). Pratique pour simuler des requêtes HTTP à la main.

socat TCP4-LISTEN:www TCP4:www.domain.org:www
# C'est un simple transfert de données entre 2 flux TCP. Tout ce qui arrive sur le port 80 (www) de la machine locale est envoyé vers www.domain.org et inversement.

socat -u TCP4-LISTEN:3334,reuseaddr,fork OPEN:/tmp/in.log,creat,append
# Dans cet exemple, socat va écrire tout ce qu'il reçoit sur le port 3334 dans un fichier.

Aller plus loin

  • # Idéal pour tester la communication série

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

    Je me sert beaucoup de socat pour développer des programmes utilisant le port série (RS232):

    socat PTY,link=/tmp/ttyS0,raw,echo=0 PTY,link=/tmp/ttyS1,raw,echo=0
    
    

    Il suffit alors de lancer un programme sur /tmp/ttyS0 et l'autre sur /tmp/ttyS1 et on a une communication bidirectionnelle série. Très pratique.

    • [^] # Re: Idéal pour tester la communication série

      Posté par  . Évalué à 7.

      Idem pour faire le transfert RS232 via TCP entre deux machine distantes :

      sur la machine distante (de mémoire) avec le port série physique (écran tactile, modem, ...):

      socat FILE:/dev/ttyS0,echo=0,raw,nonblock TCP:3334

      sur la machine client:

      socat PTY,link=/tmp/ttyS0 TCP:distante:3334

      Le processus client utilise alors /tmp/ttyS0 comme un vrai port série.
      J'ai utilisé en production pour traiter 3 écran tactiles distants sur une seule machine le tout sans tirer aucun câble RS232, uniquement par Ethernet.
      Remplace avantageusement des dongle RS232<->TCP assez chers à condition d'avoir une machine disponible avec les ports RS232.

  • # Par rapport à telnet

    Posté par  . Évalué à 2.

    Je suis vieux… quel est la différence avec telnet ?
    Ex :
    mail: telnet smtp 25
    web: telnet linuxfr.org 80

    • [^] # Re: Par rapport à telnet

      Posté par  . Évalué à 4.

      Je pense que la différence se situe dans la possibilité d'avoir accès à toutes les options (ioctl et autres) des sockets, avec une interface semble-t-il assez polyvalente sans avoir à passer non plus par les indirections du shell...

      Et puis quitte à choisir, je préfère netcat à telnet (qui n'a pas vraiment été conçu pour faire du TCP nu, il me semble...)

    • [^] # Re: Par rapport à telnet

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

      telnet permet juste d'envoyer du contenu à un serveur, pas de faire serveur lui-même pour relayer un flux envoyé depuis un autre client.

      • [^] # Re: Par rapport à telnet

        Posté par  . Évalué à 1.

        et surtout, de faire ca interprotocoles, et de propose quelque standards par dessus en surplu, style SOCKS.
        bref, socat fait (presque) tout, et ca c'est génial.

        par contre, le support SOCKS5 est incomplet il me semble, et la syntaxe (ou alors le man) ne sont pas très clairs.

    • [^] # Re: Par rapport à telnet

      Posté par  . Évalué à 4.

      Vu que tu ne voit pas la différence avec telnet, j'en déduit que tu es capable de reproduire les exemples de la dépêche avec ce dernier. Moi je ne sais pas faire, tu me montre ?

    • [^] # Re: Par rapport à telnet

      Posté par  . Évalué à 2.

      par rapport à netcat eût été une meilleure question

      réponse possible : socat permet de créer deux connexions à la fois et il mange n'importe quel type de flux.

      Je trolle dès quand ça parle business, sécurité et sciences sociales

      • [^] # Re: Par rapport à telnet

        Posté par  . Évalué à 3.

        netcat mange des pipe :

        netcat -l -p 8080 > sauvegarde.gz
        
        

        dd if=/dev/sdz | gzip | netcat myhost 8080
        
        

        Et ça vraiment ça rox.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Par rapport à telnet

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

        par rapport à netcat, socat permet d'écouter des datagrammes broadcastés par UDP, alors que netcat ne reconnaît que les datagrammes explicitement envoyés à l'IP de la machine qui écoute.

        et ça ça rox pour faire une console qui affiche les printf d'une appli de test sur playstation 3 sous psl1ght.

  • # netcat

    Posté par  . Évalué à 9.

    Les rares fois où je dois bidouiller du réseau j'ai tendance à me lancer plus naturellement vers netcat.

    J'aimerais bien mieux connaître les différences entre les deux ou disons pour quels usages choisir l'un plutôt que l'autre.

    J'ai des usages assez simples c'est probablement pour cela que je ne vois pas la différences. Enfin, je dis ça socat semble un outil de bien plus haut niveau, mais peut-il travailler avec les pipes ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: netcat

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

      J'aimerais bien mieux connaître les différences entre les deux ou disons pour quels usages choisir l'un plutôt que l'autre.

      socat peut travailler avec des sockets Unix, ce qui n’a pas l’air d’être le cas de netcat (d’après sa page de manuel en tout cas, où la seule mention du mot « unix » est dans la phrase « netcat is a simple unix utility »).

      Pour cette raison, il est par exemple beaucoup utilisé dans les scripts gravitant autour de uzbl-core, dans les cas où l’on a besoin d’une communication bi-directionnelle avec le navigateur (envoyer une commande et recevoir la réponse, ce qu’un tube nommé ne permet pas). Ça donne des petits bouts de shell script de ce genre :

      echo 'js document.documentElement.outerHTML' | \
            socat - unix-connect:$UZBL_SOCKET | \
            grep -v ^EVENT | \
            gvim -
      
      

      ($UZBL_SOCKET étant bien sûr le chemin vers la socket ouverte par uzbl-core)

      C’est d’ailleurs, en ce qui me concerne, ma seule utilisation de socat, que je ne connaissais pas avant de découvrir Uzbl.

      • [^] # Re: netcat

        Posté par  . Évalué à 1.

        socat est extrêmement polyvalent.

        Avec tun/tap, c'est très commode pour créer du tunneling IP sur une seule connexion TCP, à travers un pare-feu. En théorie, ça doit même marcher si on a juste un PROXY HTTP à disposition, du moment qu'il supporte l'option CONNECT.

        Je n'ai jamais essayé, mais avec SSL:, SSL-LISTEN: et PTY:, on doit pouvoir facilement créer quelque chose d'équivalent à SSH.

        En pratique, c'est aussi assez commode pour copier une install Linux sur une nouvelle machine, avec Schily's star qui crée la tarball d'un côté, socat qui copie via une simple connexion TCP nue, et star qui décomprime la tarball de l'autre côté. C'est plus simple qu'un point de montage NFS.

      • [^] # Re: netcat

        Posté par  . Évalué à 5.

        c'est parce qu'il ne faut pas utiliser GNU netcat, mais un netcat BSD qui lui les gère.

        • [^] # Re: netcat

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

          c'est parce qu'il ne faut pas utiliser GNU netcat

          Ça tombe bien, je ne sais pas quelle version j’utilise mais ce n’est sûrement pas une version issue du projet GNU :
          – pas de licence de 600 lignes (la chose qui se rapproche le plus d’une licence est une phrase en passant à la fin du README, « Netcat is freely available in full source form with no restrictions save an obligation to give credit where due ») ;
          – aucune mention de GNU nulle part ;
          – pas d’option --version ;
          – la preuve ultime : pas de page d’info.

          mais un netcat BSD qui lui les gère.

          Ou socat justement, qui les gère aussi…

          • [^] # Re: netcat

            Posté par  . Évalué à -1.

            Ou socat justement, qui les gère aussi…

            Oui on avait compris. Je disais juste que netcat savait utiliser les sockets UNIX, contrairement à tes allégations.

            -U Specifies to use UNIX-domain sockets.

            Ton commentaire semble contenir un pointe de troll envers GNU et GPL. Dis moi, quelle est la licence de socat ?

            • [^] # Re: netcat

              Posté par  . Évalué à 2.

              Je disais juste que netcat savait utiliser les sockets UNIX, contrairement à tes allégations.

              Il n'y a pas qu'un "netcat", on ne peut donc pas dire "netcat supporte les sockets UNIX" ni "netcat ne supporte pas les sockets UNIX".

              • [^] # Re: netcat

                Posté par  . Évalué à -1.

                GNU netcat est un clone de netcat 1.10

                En tout cas il y a un netcat sous licence BSD cloné du netcat original et un clone sous GPL. Donc, si.

            • [^] # Re: netcat

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 08 décembre 2011 à 15:04.

              Je disais juste que netcat savait utiliser les sockets UNIX, contrairement à tes allégations.

              Non, tu ne disais pas juste ça, tu essayais de me dire ce que je devais ou ne devais pas utiliser (« il ne faut pas utiliser GNU netcat »).

              Que le netcat de BSD supporte les sockets Unix est bon à savoir, mais ça ne m’empêchera pas d’utiliser socat qui fait lui aussi ce que je veux.

              Quant à mes « allégations », je pensais justement avoir fait preuve de prudence dans ma formulation (« ça n’a pas l’air d’être le cas, d’après sa page de manuel en tout cas », tu y vois vraiment une affirmation ?). OK, j’ai pêché par ignorance, j’ignorais qu’il y avait plusieurs versions de netcat en circulation et je supposais donc bêtement que la page de manuel de mon système était universellement valable. Mea culpa (cela dit, apparemment toi tu pensais qu’il n’avait que la version BSD et la version GNU, alors bon…).

              Ton commentaire semble contenir un pointe de troll envers GNU et GPL. Dis moi, quelle est la licence de socat ?

              GPLv2, tu crois que je ne le savais pas ? C’est d’ailleurs une des raisons qui me l’auraient fait préférer au netcat BSD, si j’avais eu à choisir entre les deux (choix que je n’ai pas eu à faire, puisque je ne connaissais pas le netcat BSD).

              où est le troll dans le fait de reconnaître que les licences GPL et assimilées sont plutôt longues, ou que les développeurs d’un projet GNU ne se contenteraient pas d’une malheureuse phrase perdue dans un README en guise de licence ?

              Où est le troll dans le fait que le mot GNU devrait bien apparaître quelque part dans l’archive d’un projet GNU ?

              Où est le troll dans le fait de dire qu’un programme GNU a toujours une option --version indiquant le… numéro de version et la licence utilisée ?

              Où est le troll dans le fait de dire que le projet GNU favorise les pages d’info en lieu et place des pages de manuel ?

              En revanche, moi j’ai cru déceler une pointe de troll GNU/BSD dans ton commentaire. Je n’y aurais d’ailleurs peut-être pas répondu sinon (ce qui veut dire, eh merde, que j’ai nourri le troll).

              • [^] # Re: netcat

                Posté par  . Évalué à 1.

                C'est incoyable comme tu aimes troller tout seul.

                J'ai jamais dit qu'il fallait utilise netcat à la place de socat ni même BSD netcat à la place de GNU netcat.

                j'ai dit que si tu veux des sockets unix, tu dois utiliser BSD netcat et pas le clone GNU. C'est tout. Ne t'enflammes pas tout seul.

    • [^] # Re: netcat

      Posté par  . Évalué à 1.

      J'aimerais bien mieux connaître les différences entre les deux ou disons pour quels usages choisir l'un plutôt que l'autre.

      L'empreinte mémoire ? :)

  • # Envoyer un paquet en mode raw

    Posté par  . Évalué à 3.

    hex 0090 4ca0 1bb3 0090 4cc5 3423 0800 4500 001d 0000 4000 4001 ad7f | socat - INTERFACE:tap0

    Notez que les 12 premiers octets sont l'entête Ethernet 2 (MAC dst + MAC src + type).

    Bon je crois que hex n'est pas standard du tout mais on devrait pouvoir faire la même chose avec echo et xxd.

Suivre le flux des commentaires

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