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

Posté par Bruno Michel (site web personnel) le 07 décembre 2011 à 08:52. Édité par Pierre Jarillon et claudex. Modéré par Nÿco. Licence CC By‑SA.

Étiquettes :

déc.

2011

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

Le site officiel de socat (4509 clics)
Exemples d'utilisation de socat (3160 clics)

# Idéal pour tester la communication série

Posté par philpep (site web personnel) le 07 décembre 2011 à 09:29. É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 Sylvain Goletto le 07 décembre 2011 à 13:20. É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 Anthony Jaguenaud le 07 décembre 2011 à 10:15. É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 Emmanuel C le 07 décembre 2011 à 10:45. É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 Guillaume Rousse (site web personnel) le 07 décembre 2011 à 11:32. É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 bilboa le 07 décembre 2011 à 17:08. É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 Volnai le 07 décembre 2011 à 12:21. É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 passant·e le 07 décembre 2011 à 15:31. É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 barmic le 07 décembre 2011 à 15:42. É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 Juke (site web personnel) le 07 décembre 2011 à 16:35. Évalué à 10.
      
      Le mercredi 07 décembre 2011 à 15:42 +0100, Barret Michel a écrit :
      > netcat mange des pipe :
      
      et il tail des pipes ?
      - [^] # Re: Par rapportàtelnet
        
        Posté par NeoX le 07 décembre 2011 à 16:38. Évalué à 3.
        
        netcat mange des pipe :
        
        et il tail des pipes ?
        
        c'est du joli :p
        
        [^] # Re: Par rapportàtelnet
        
        Posté par Larry Cow le 07 décembre 2011 à 18:10. Évalué à 2.
        
        C'est clair : quand on pense que cat suffit...
  - [^] # Re: Par rapport à telnet
    
    Posté par zerkman (site web personnel) le 07 décembre 2011 à 16:26. É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 barmic le 07 décembre 2011 à 15:09. É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 gouttegd le 07 décembre 2011 à 16:23. É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 NanoTech le 07 décembre 2011 à 19:54. É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 Enjolras le 07 décembre 2011 à 21:02. É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 gouttegd le 07 décembre 2011 à 22:02. É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 Enjolras le 08 décembre 2011 à 13:49. É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 BFG le 08 décembre 2011 à 14:26. É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 Enjolras le 08 décembre 2011 à 16:54. É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 gouttegd le 08 décembre 2011 à 15:03. É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 Enjolras le 08 décembre 2011 à 16:56. É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 geb le 08 décembre 2011 à 00:04. É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 calandoa le 08 décembre 2011 à 15:12. É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.
- [^] # Re: Envoyer un paquet en mode raw
  
  Posté par Kerro le 09 décembre 2011 à 23:49. Évalué à 2.
  
  je crois que hex n'est pas standard du tout mais on devrait pouvoir faire la même chose avec echo et xxd.
  
  printf: http://linuxfr.org/forums/astucesdivers/posts/wol-avec-netcat

Suivre le flux des commentaires

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