OVH Cloud OVH Cloud

script pour telnet

12 réponses
Avatar
Christophe PEREZ
Bonjour,

Je souhaite toujours piloter ma carte radio FM à distance ;-)

Avec l'aide d'Emmanuel, j'y parviens de la sorte :
$ telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
off
^] (CTRL-V+])

telnet> quit
Connection closed.
$

coupe bien la radio.

Par contre, je ne parviens pas à utiliser ça dans un script.
$ echo -e "off\n^]\nquit" | telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.

telnet> Connection closed.

n'a aucune action.

De plus, dans le premier mode, (telnet serveur 5000), je ne sais pas
comment récupérer l'information de retour.

Si quelqu'un peut/veut bien m'aider.
Merci d'avance.

--
Christophe PEREZ

10 réponses

1 2
Avatar
Pascal Bourguignon
Christophe PEREZ writes:

Bonjour,

Je souhaite toujours piloter ma carte radio FM à distance ;-)

Avec l'aide d'Emmanuel, j'y parviens de la sorte :
$ telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.
off
^] (CTRL-V+])

telnet> quit
Connection closed.
$

coupe bien la radio.

Par contre, je ne parviens pas à utiliser ça dans un script.
$ echo -e "offn^]nquit" | telnet serveur 5000
Trying 192.168.0.100...
Connected to serveur.novazur.fr (192.168.0.100).
Escape character is '^]'.

telnet> Connection closed.

n'a aucune action.

De plus, dans le premier mode, (telnet serveur 5000), je ne sais pas
comment récupérer l'information de retour.

Si quelqu'un peut/veut bien m'aider.
Merci d'avance.


telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.

Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:

echo off > /dev/tcp/192.168.0.100/5000

man, man bash, etc,

(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:

echo off > /dev/udp/192.168.0.100/5000
)

--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.

Avatar
Christophe PEREZ
Le Thu, 28 Aug 2003 22:39:23 +0200, Pascal Bourguignon a écrit:

telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.

Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:


Alors, je ne m'accrocherai pas à telnet ;-)

Mais nc, nous avions déjà essayé, et c'est pour sortir de la session que
ça coince, il me faut faire un CTRL-C pour couper le process, et là,
l'action est bien exécutée par le serveur.
Par contre, toujours aucune sortie (retour d'info)
$ echo "off" | nc serveur 5000
punt! (ici, un CTRL-C)
$

echo off > /dev/tcp/192.168.0.100/5000


Wahou, super !!
Alors ça, faut connaître !
Et comment je récupère l'info de retour avec ça ?

man, man bash, etc,


Bien sûr, dès que je saurai ce que je dois y chercher ;-)

(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:

echo off > /dev/udp/192.168.0.100/5000


C'est bien mon cas, toujours un seul argument, mais pourtant ça ne
fonctionne pas.

Sinon, merci beaucoup.

--
Christophe PEREZ

Avatar
Pascal Bourguignon
Christophe PEREZ writes:

Le Thu, 28 Aug 2003 22:39:23 +0200, Pascal Bourguignon a écrit:

telnet (et ftp, et en général, tout les programmes interactifs) est
embêtant à utiliser dans un script. Si on insiste pour telnet, le
mieux est d'utiliser expect qui simule le rôle de l'utilisateur.

Mais dans ton cas, l'outil le plus approprié semble être netcat, où à
la limite, bash:


Alors, je ne m'accrocherai pas à telnet ;-)

Mais nc, nous avions déjà essayé, et c'est pour sortir de la session que
ça coince, il me faut faire un CTRL-C pour couper le process, et là,
l'action est bien exécutée par le serveur.
Par contre, toujours aucune sortie (retour d'info)
$ echo "off" | nc serveur 5000
punt! (ici, un CTRL-C)
$

echo off > /dev/tcp/192.168.0.100/5000


Wahou, super !!
Alors ça, faut connaître !
Et comment je récupère l'info de retour avec ça ?

man, man bash, etc,


Bien sûr, dès que je saurai ce que je dois y chercher ;-)


Faut tout lire! Voir par exemple, la section REDIRECTION.


Pour faire des essais comme le suivant, activer le service echo dans
inetd, et:

( while read -p 'comande: ' comande < /dev/tty ; do echo $comande ; read rep ; echo reponse: $rep >/dev/tty ; done ) 0<>/dev/tcp/localhost/echo 1>&0
comande: hello
reponse: hello
comande: titi
reponse: titi
comande: tata
reponse: tata
comande: tutu
reponse: tutu
comande:

Donc, un:

( echo off ; read rep ; echo reponse: $rep >/dev/tty ) 0<>/dev/tcp/192.168.0.100/5000 1>&0

devrait fonctionner...

(D'ailleurs, si les sessions de commande ne constituent toujours que
d'une seule commande, et donc d'un seul paquet, le serveur pourrait
trés bien utiliser plutôt udp, et alors ça donnerait sur bash:

echo off > /dev/udp/192.168.0.100/5000


C'est bien mon cas, toujours un seul argument, mais pourtant ça ne
fonctionne pas.


Avec bash, si on ne veut pas s'amuser (et s'embêter) avec des
sous-shells en parallèle, il vaut peut être mieux utiliser tcp que
udp, j'ai l'impression.

--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.


Avatar
Christophe PEREZ
Le Fri, 29 Aug 2003 03:41:37 +0200, Pascal Bourguignon a écrit:

Faut tout lire! Voir par exemple, la section REDIRECTION.


Outch ! JE ne suis pas prêt d'écouter la radio moi :-))

Pour faire des essais comme le suivant, activer le service echo dans
inetd, et:


Euh... j'ai donc mis disable à no dans /etc/xinetd.d/echo, relancé xinetd.

( while read -p 'comande: ' comande < /dev/tty ; do echo $comande ; read
rep ; echo reponse: $rep >/dev/tty ; done ) 0<>/dev/tcp/localhost/echo 1>&0
comande: hello
reponse: hello


ça fonctionne sur le serveur.

Donc, un:

( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...


Ne fonctionne que lorsque je fais CTRL-C pour quitter.
Toujours le même problème qu'avec nc et telnet d'ailleurs.

Avec bash, si on ne veut pas s'amuser (et s'embêter) avec des
sous-shells en parallèle, il vaut peut être mieux utiliser tcp que
udp, j'ai l'impression.


Ok, c'est noté.

Désolé d'être aussi largué, mais là, franchement, ça touche à quelque
chose que je ne connais pas du tout.
Mais c'est comme pour tout le reste, j'apprends au fur et à mesure.
Merci pour l'aide.

--
Christophe PEREZ

Avatar
Christophe PEREZ
Le Thu, 28 Aug 2003 22:43:19 -0400, Christophe PEREZ a écrit:

( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...


Ne fonctionne que lorsque je fais CTRL-C pour quitter.
Toujours le même problème qu'avec nc et telnet d'ailleurs.


A force d'investigation, j'en suis arrivé à la déduction que le problème
est évidemment ailleurs.
Si j'envoie 2 arguments, le premier est bien pris en compte
Ex: ( echo "off n-importe_quoi"; read rep ; ...
La commande "off est bien prise en compte.

Il faut donc que je précise quelques choses :
Emmanuel m'avait fait faire le /etc/xinetd.d/radio de la sorte, en
particulier sur xargs :
service radio
{
socket_type = stream
wait = no
user = root
log_on_success += USERID
log_on_failure += USERID
server = /usr/bin/xargs
server_args = -n 1 /usr/local/perso/radi
disable = no
group = audio
}

Je me rends compte qu'avec "-n 2" c'est 3 arguments qu'il faut que je
balance pour que le premier soit pris en compte :
Ex: ( echo "off n-importe_quoi1 n-importe_quoi2"; read rep ; ...

Or, "-n 0" n'est pas possible.

Où est donc l'astuce ?

Je pense qu'en fait, lorsque ce problème sera résolu, tout le reste
fonctionnera comme cela devrait.

--
Christophe PEREZ


Avatar
Christophe PEREZ
Le Fri, 29 Aug 2003 07:12:58 +0000, Laurent Wacrenier a écrit:

Lire le manuel de *votre* commande.


Ma commande ?
Ben, c'est juste un script bash qui traite l'entrée $1.

--
Christophe PEREZ

Avatar
Laurent Wacrenier
Christophe PEREZ écrit:
Lire le manuel de *votre* commande.


Ma commande ?
Ben, c'est juste un script bash qui traite l'entrée $1.


Et tout le monde est sensé savoir ce qu'il en fait alors que vous, son
auteur, ne le savez pas.


Avatar
Pascal Bourguignon
Christophe PEREZ writes:

Le Thu, 28 Aug 2003 22:43:19 -0400, Christophe PEREZ a écrit:

( echo off ; read rep ; echo reponse: $rep >/dev/tty )
0<>/dev/tcp/192.168.0.100/5000 1>&0
devrait fonctionner...
[...]


Où est donc l'astuce ?

Je pense qu'en fait, lorsque ce problème sera résolu, tout le reste
fonctionnera comme cela devrait.


Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.
Ainsi, tu pourras éviter d'utiliser xargs dans la configuration
xinetd: directement le script serveur. (Rien n'empêche le script
d'accepter des arguments, mais de lire l'entrée standard s'il n'y en a
pas).

Par exemple:

[ pascal]$ cat server
#!/bin/bash
read command args
# telnet envoi des CRLF, elevons les CR.
command=$(echo "$command"|tr -d '15')
args=$(echo "$args"|tr -d '15')
#
case "$command" in
on) echo "200 Mise en route avec les arguments $args" ;;
off) echo "201 Extinction avec les arguments $args" ;;
station)
case "x${args//[0-9]}x" in
xx) echo "200 Passage à la station $args" ;;
*) echo "411 Invalide station $args" ;;
esac
;;
*) echo "421 Invalide commande $command" ;;
esac
exit 0

(J'ai utilisé éhontément le service radio:
radio 1595/tcp # radio
)

[ pascal]$ grep radio /etc/inetd.conf
radio stream tcp wait pascal /home/pascal/server

[ pascal]$ telnet localhost radio
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
on radio
200 Mise en route avec les arguments radio
Connection closed by foreign host.
[ pascal]$ telnet localhost radio
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
off radio
201 Extinction avec les arguments radio
Connection closed by foreign host.
[ pascal]$ telnet localhost radio
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
station 12d
station 12d
411 Invalide station 12d
Connection closed by foreign host.
[ pascal]$ telnet localhost radio
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
station 13221
station 13221
200 Passage à la station 13221
Connection closed by foreign host.
[ pascal]$ telnet localhost radio
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
hello
hello
421 Invalide commande hello
Connection closed by foreign host.
[ pascal]$ ( echo on toto ; read rep ; echo $rep >/dev/tty ) <>/dev/tcp/localhost/radio 1>&0
200 Mise en route avec les arguments toto
[ pascal]$ ( echo off radio ; read rep ; echo $rep >/dev/tty ) <>/dev/tcp/localhost/radio 1>&0
201 Extinction avec les arguments radio
[ pascal]$ ( echo station 231 ; read rep ; echo $rep >/dev/tty ) <>/dev/tcp/localhost/radio 1>&0
200 Passage à la station 231
[ pascal]$ ( echo station x231 ; read rep ; echo $rep >/dev/tty ) <>/dev/tcp/localhost/radio 1>&0
411 Invalide station x231
[ pascal]$ ( echo error? ; read rep ; echo $rep >/dev/tty ) <>/dev/tcp/localhost/radio 1>&0
421 Invalide commande error?


--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.



Avatar
Christophe PEREZ
Le Sun, 31 Aug 2003 04:40:27 +0200, Pascal Bourguignon a écrit:

Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.
Ainsi, tu pourras éviter d'utiliser xargs dans la configuration
xinetd: directement le script serveur. (Rien n'empêche le script
d'accepter des arguments, mais de lire l'entrée standard s'il n'y en a
pas).


Tout à fait.
Merci du conseil, et surtout de l'exemple, que je vais étudier à tête
reposée.

Merci beaucoup encore.

--
Christophe PEREZ

Avatar
Christophe PEREZ
Le Sun, 31 Aug 2003 04:40:27 +0200, Pascal Bourguignon a écrit:

Peut être qu'il serait mieux de concevoir le script comme un vrai
serveur, et qu'il prenne ses commandes sur l'entrée standard et ses
réponses sur la sortie standard, au lieu de passer par les arguments.


Après essais, c'est parfait.

Je n'ai eu dans mon script, en fait, qu'à remplacer un :
ARGS=$1

par :
read ARGS

Je suis même arrivé à la commande :
(
echo $CDE
while IFS= read -r REP ; do
echo "$REP" >/dev/tty
done
) 0<>/dev/tcp/192.168.0.100/5000 1>&0

Afin de récupérer les sorties "multi-lignes"

Maintenant, il ne me reste plus qu'à appliquer ça dans un script tcl ;-)

En tout cas, merci beaucoup pour toute cette aide qui m'a permis d'arriver
au résultat escompté, malgré toute mon incompétence.

J'ai encore appris plein de choses, que je ne manquerai pas d'appliquer.

--
Christophe PEREZ

1 2