Comment puis-je diriger des commandes vers un netcat qui restera en vie?

echo command | netcat host port

La commande est alors envoyée à l'hôte distant et certaines données sont relues. Mais après quelques secondes, la connexion se ferme. Le paramètre -w n'a rien changé. J'utilise netcat v1.10 sur SuSE 10.1.

Cela fonctionne avec la nccommande sur OS X (en supposant que la commande que vous voulez envoyer se trouve dans un fichier):

cat file - | nc host port

(Essentiellement, catvide le contenu du fichier sur stdout et vous attend ensuite sur stdin).

Par extension, si vous voulez envoyer la commande à partir du shell, vous pouvez faire ceci:

cat <(echo command) - | nc host port

Avec ncsur Ubuntu:

nc -q -1 host port

De la page de manuel Ubuntunc :

 -q seconds
         after EOF on stdin, wait the specified number of seconds and then quit. If seconds is negative, wait forever.

Notez que les ncoptions disponibles varient beaucoup d’une distribution à l’autre, il est donc possible que cela ne fonctionne pas sur la vôtre (OpenSUSE).

Je l'ai trouvé:

echo command | netcat host port -

Mon collègue le savait. Je ne le vois pas du tout dans la documentation.

Je ne pense pas que vous allez gérer cela avec netcat ou socat. Je viens de faire un bricolage intensif avec les deux, et Socat semblait le plus prometteur.

J'ai réussi à configurer socat pour qu'il se connecte au port TCP distant et écoute sur un socket de domaine unix local (en théorie, afin que le lien puisse être maintenu tout le temps), mais dès que le processus local s'est détaché du socket unix (un autre socat reliant le socket unix à stdin / out), il a fermé la session TCP socat.

Le problème ici est que chaque connexion via netcat / socat établit une nouvelle connexion de flux TCP vers le serveur et ferme cette session de flux TCP lorsque la fin locale se déconnecte.

Je pense que vous allez probablement devoir écrire un logiciel proxy personnalisé pour cela qui ouvre la connexion TCP à l'extrémité distante, puis écoute localement sur un socket / pipe / fifo ou autre chose, puis envoie simplement les données par le canal TCP existant. et renvoie les résultats.

La connexion est-elle fermée à l’autre extrémité de la prise?

Par défaut, ncferme la connexion une fois la connexion terminée, si vous ne lui dites pas explicitement de rester à l'écoute (avec l' -koption):

 -k    Forces nc to stay listening for another connection after its current
       connection is completed.  It is an error to use this option without the
       -l option.

Voir man nc.1.

Je réussis à diffuser des données entre deux machines comme ceci:

• expéditeur:

  while (true); do 
    echo -n "$RANDOM " | nc <host> <port>
  done
  

• receveur:

  nc -kl <port> 
  

La méthode de Georges fonctionne bien à partir d'un shell interactif, mais ne vous aidera pas avec les scripts, lorsque vous appelez votre script par exemple nohup ./script &.

J'ai trouvé que remplacer stdin par un fifo aide.

 mkfifo dummy
 cat command.txt dummy | nc host port

Comme rien n’écrit dans le fifo, le fichier est catsuspendu indéfiniment après la sortie du fichier .

socatL' shut-noneoption devrait aider ici:

Changes the (address dependent) method of shutting down the write part of a connection to not do anything.

Vous devrez probablement également remplacer le délai d'attente par défaut -t <timeout>, sinon le socket sera fermé après 0,5 seconde. Cette option annule le comportement par défaut, à savoir:

When one of the streams effectively reaches EOF, the closing phase begins. Socat transfers the EOF condition to the other stream, i.e. tries to shutdown only its write stream, giving it a chance to terminate gracefully. For a defined time socat continues to transfer data in the other direction, but then closes all remaining channels and terminates.

Donc, une commande telle que:

echo 'blah' | socat -t 10 stdio tcp:<addr>:<port>,shut-none

gardera la prise ouverte pendant 10 secondes après l'envoi du message "blah".

Votre commande se termine si l'hôte distant ferme la connexion (ou n'est pas accessible) ou la commande avant la fin du canal (alors que Netcat envoie toujours le reste de sa file d'attente d'entrée).