netcat n'imprime pas de réponse


12

J'essaie d'envoyer des commandes à un port TCP à l'aide de la netcatréponse et du canal
lorsque j'exécute netcatet tape ma commande, elle affiche la réponse correctement, mais lorsque je passe la commande à partir d'un canal, elle envoie la commande correctement mais n'imprime pas la réponse

Donc, cela fonctionne correctement:

netcat  localhost 9009

alors que cela envoie simplement une commande mais n'imprime pas de réponse:

echo 'my_command' | netcat  localhost 9009

Pourquoi?
Comment faire netcatpour imprimer un texte de réponse?


cela vous arrive probablement
Jeff Schaller

@JeffSchaller: non! malheureusement, l'utilisation de ces commandes n'aide pas! cette fois, il bloque pour toujours!
RYN

Quel netcat utilisez-vous? Malheureusement, il existe une douzaine de variantes différentes de l'outil netcat, et elles ne se comportent pas toutes de la même manière. Aussi, qu'est-ce qui se trouve à l'extrémité distante?
Patrick

@Patrick: mon netcat est une OpenBSD netcat (Debian patchlevel 1.105-7ubuntu1)version; et à l'extrémité distante est telegram-clisur la même machine.
RYN

Je pense que j'ai trouvé une page de manuel pour ce netcat, mais je ne vois aucun indicateur qui contrôlerait ce qui se passe. Je soupçonne qu'une fois netcatreçu l'EOF sur STDIN, qu'il arrête immédiatement les deux côtés de la prise au lieu de faire un demi-fermeture et d'attendre que le côté distant ferme son extrémité. Si socatc'est une option, je le recommande fortement à la place. Il n'y en a qu'un socat, donc vous n'avez pas de problèmes de portabilité avec une douzaine de versions différentes, il se comporte beaucoup plus sainement et est hautement configurable.
Patrick

Réponses:


8

Comme l'a dit @Patrick, ce problème est généralement dû à la netcatfermeture avant la réponse. Vous remédiez à cela en ajoutant -q 2à la ligne de commande, c'est- netcatà- dire, dites de suspendre environ 2 secondes après avoir détecté EOF sur l'entrée standard. De toute évidence, vous pouvez également faire attendre un autre nombre de secondes.


Merci; -q 2a fonctionné mais est-il fiable? il fait une requête web Je ne peux pas être sûr que 2s soit toujours suffisant! puis-je ?
RYN

1
Utilisez un nombre plus grand pour le faire attendre plus longtemps, ou un nombre négatif pour le faire attendre indéfiniment. Il y a aussi la -wpossibilité de jouer avec. Tout cela est man ncbien sûr dans la page.
Ralph Rönnquist

5
ça ditinvalid option -- 'q'
phil294

Je pense qu'une bonne question de suivi est la suivante: pourquoi ncquitte-t-il immédiatement au lieu d'attendre une réponse? Si la connexion est toujours ouverte, il devrait y avoir une option pour faire ncattendre qu'elle se ferme, pas seulement pour la fin de stdin
theferrit32

6

Utilisez ceci:

cat <(echo command) - | nc host port

Le problème est que ncla connexion se fermera immédiatement après la fermeture de stdin, ce qui est très rapide pour une simple my_commandchaîne et n'a donc jamais la chance de recevoir une réponse. (Si vous dirigez un fichier très volumineux, vous verrez qu'il pourrait obtenir une réponse avant l'envoi du fichier).

Entrez catavec -comme deuxième argument: il fait catécouter sur stdin pour plus de contenu à acheminer après avoir envoyé le contenu du premier argument. Le premier argument consiste simplement à passer la echocommande cat- il peut également s'agir d'un fichier avec vos commandes à la la cat < file - | ....

Sinon, procédez comme suit:

(echo command; while true; do sleep 0.01; echo -n "#"; done) | nc host port

Cela envoie un nombre illimité de #caractères sur la 2ème ligne de l'entrée. Utiliser des #travaux pour un bash comme remote qui ignorerait cela en tant que commentaire. J'ai choisi un petit temps d'attente de 10 millisecondes ici, donc il réagit plus rapidement à la fin de la connexion. YMMV.

L'inconvénient de cela peut être cela catou la whileboucle et nccontinuer à fonctionner jusqu'à ce que vous frappiez ^Cou ^Dsur la coque. Cela dépend vraiment de l'extrémité distante.

L'ajout d'un délai d'expiration à l'aide de -w 1(OSX netcat) ou -i 1(ncat de nmap) le fait fermer la connexion et ncaprès 1 seconde, mais catcontinuera de fonctionner jusqu'à ce que vous saisissiez un caractère et que le tuyau se brise (je pense).

Cependant, cela fonctionne si le côté distant ferme automatiquement la connexion après avoir reçu et traité la commande - cela mettra également fin au ncclient et au processus.

Cette réponse est basée sur cette cette réponse à une question de superutilisateur identique .


{ echo my_command; cat;}ferait de même et pourrait être considéré comme plus facile à comprendre.
G-Man dit `` Réintègre Monica ''

1

Différentes versions openbsd-netcat sont originales, nécessitant différentes combinaisons de -w <seconds>, -q <seconds>, -Net même besoin de différents arguments en fonction de ce qui est en cours d' exécution à l'autre bout de la connexion. L'utilisation d'options de délai d'attente avec certaines versions ou certains serveurs entraîne des retards, et leur non-utilisation peut entraîner un retard extrêmement long (infini?). Et je m'attendrais à des bizarreries différentes avec gnu netcat, mais je ne sais pas si elles sont différentes entre les versions.

Par exemple, la version 1.130_3 d'Archlinux prend extrêmement longtemps (pour toujours?) Quand je fais ceci:

$ echo response | nc -l 9999 &
[1] 15190

$ time echo request | nc localhost 9999
request
response

(wait forever possibly)

Mais cela fonctionne avec -N ajouté au serveur ou au client.


1

Je sais que c'est un peu vieux mais aucune autre réponse n'a fonctionné pour moi et cela a fonctionné:

echo 'test' | netcat -N $server $port

Remarquez -N:

fermez la prise réseau après EOF sur l'entrée. Certains serveurs en ont besoin pour terminer leur travail.

A travaillé pour moi sur Windows et Linux.

Remarque: Il s'agit d'un copier-coller de la réponse que j'ai publiée pour une question en double .

Je pense que cela pourrait être utile. Les mods se sentent libres de modifier / supprimer si cela est contraire à la politique ou à quelque chose.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.