Comment puis-je diriger des commandes vers un netcat qui restera en vie?
32
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.
C'est bien, car cela fonctionne sur un système embarqué très dépouillé, où Netcat manque de toutes les options sophistiquées.
SF.
{ echo command; cat;}ferait la même chose et pourrait être considéré comme plus facile à comprendre.
G-Man dit 'Réintégrez Monica'
1
À mon avis, la netcatcommande maintiendra la socket ouverte jusqu'à la fin de la saisie. Tous ces exemples le démontrent sans vraiment dire pourquoi . Je suis en interaction avec le serveur en utilisant pendant une période prolongée tout en utilisant: . SocketTest est un outil pratique pouvant écouter ou servir sur n’importe quel port TCP ou UDP. SocketTestnetcatcat - | nc localhost 8063
-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 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
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 .
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.
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).
Réponses:
Cela fonctionne avec la
nc
commande sur OS X (en supposant que la commande que vous voulez envoyer se trouve dans un fichier):(Essentiellement,
cat
vide 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:
la source
{ echo command; cat;}
ferait la même chose et pourrait être considéré comme plus facile à comprendre.netcat
commande maintiendra la socket ouverte jusqu'à la fin de la saisie. Tous ces exemples le démontrent sans vraiment dire pourquoi . Je suis en interaction avec le serveur en utilisant pendant une période prolongée tout en utilisant: . SocketTest est un outil pratique pouvant écouter ou servir sur n’importe quel port TCP ou UDP.SocketTest
netcat
cat - | nc localhost 8063
Avec
nc
sur Ubuntu:De la page de manuel Ubuntu
nc
:Notez que les
nc
options disponibles varient beaucoup d’une distribution à l’autre, il est donc possible que cela ne fonctionne pas sur la vôtre (OpenSUSE).la source
Je l'ai trouvé:
Mon collègue le savait. Je ne le vois pas du tout dans la documentation.
la source
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 source
La connexion est-elle fermée à l’autre extrémité de la prise?
Par défaut,
nc
ferme la connexion une fois la connexion terminée, si vous ne lui dites pas explicitement de rester à l'écoute (avec l'-k
option):Voir
man nc.1
.Je réussis à diffuser des données entre deux machines comme ceci:
expéditeur:
receveur:
la source
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.
Comme rien n’écrit dans le fifo, le fichier est
cat
suspendu indéfiniment après la sortie du fichier .la source
socat
L'shut-none
option devrait aider ici: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:Donc, une commande telle que:
gardera la prise ouverte pendant 10 secondes après l'envoi du message "blah".
la source
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).
la source