Interagir sur un système linux avec une connexion telnet en JAVA

**grandthor** · 16/04/2009, 10h20

Bonjour,

Je crois que tout est dans le titre !! ^^

En fait j'ai un serveur linux qui gère des bornes wifi et j'utilise des petites radios pour me connecter à ce serveur.
Dès que je m'éloigne de trop d'une borne ou que la radio ce met en vielle, je perds la connexion.
Si je veux me reconnecter sur le serveur avec la même radio, je suis obliger de killer le processus de logon de cette radio.
Pour se faire, je suis sur ma machine window et je me connect en telnet sur le serveur linux et je kill le processus manuellement.

ps -fe | grep radioX
kill -9

Donc en fait je voudrais créer un petit programme en java qui se connect au serveur linux automatiquement, là je lui rentre le n° de la radio et il kill le processus.

Je suis encore dans la phase de recherche et je pense que le java est le meilleur language pour faire sa.

Si quelqu'un a une idée ou juste une remarque merci

**tchize_** · 16/04/2009, 10h50

ca existe encore de linux avec du telnet?

Telnet a l'avantage d'être un protocole simple. Soit tu te trouve une librairie qui fait déj) java / telnet, soit tu attaque directement la socket. T'as pratiquement qu'à te connecter sur le port telenet, lire ce qu'on t'envoie, et y envoyer ce qu'il faut y envoyer, en pur texte

**grandthor** · 16/04/2009, 11h22

Envoyé par tchize_

ca existe encore de linux avec du telnet?

Telnet a l'avantage d'être un protocole simple. Soit tu te trouve une librairie qui fait déj) java / telnet, soit tu attaque directement la socket. T'as pratiquement qu'à te connecter sur le port telenet, lire ce qu'on t'envoie, et y envoyer ce qu'il faut y envoyer, en pur texte

Okai merci

La connexion c'est pas le problème je vois comment faire.
Par contre c'est plus l'authentification automatique et surtout les commandes et leur résultat.

En fait ma question c'est plus tot comment exécuter la commande ps -fe | grep radioX et afficher le résultat de cette derniere pour récupérer l'ID du processus à killer tout sa en java !!!

Voila est-ce que c'est possible ??

Et encore Merci pour ta réponse

**nouknouk** · 16/04/2009, 11h32

salut,

si ton application est destinée à un système bien précis, tu peux faire quelque chose de très spécifique, donc:

1- tu fais une première version qui se connecte et qui te permet de taper les commandes au clavier. Cette première version enregistrera tout ce qui est reçu (donc ce que le serveur a écrit sur la console) et tout ce qui est émis (ce que tu as tapé au clavier).

2- tu peux ensuite faire une deuxième version qui enverra toute seule les commandes au clavier dès qu'elle aura reçu la chaine de caractères qui convient. Par exemple:

- lorsque ta socket recevra la chaine "login as: ", tu sauras qu'il faut automatiquement envoyer le login suivit d'un retour chariot.

- Puis tu attendras de recevoir la chaine "password: " pour envoyer le mot de passe

- Puis l'invite de commande "login@serverName:~$" pour envoyer la commande ps|grep qui va bien.
Dans le texte que tu vas petit à petit recevoir, tu vas attendre de retrouver l'invite de commande (pour déterminer quand ps|grep a terminé son exécution).
Et dans tout le texte qu'il y a avant, tu pourras extraire le PID du processus.

- etc...

**tchize_** · 16/04/2009, 11h50

pas besoin de se casser la nenette à ce point là

tu te connecte sur le port
tu lit jusqu'à plus soif (plus rien à lire quoi)
-- message d'intro du serveur fini, on est dans le login:
tu écrit le login (avc le retour chariot)
tu lit jsuqu'à plus soif
tu écrit le password (avec le retour)
tu lit jusqu'à plus soif
tu balance ta commande
tu lit jusque à plus soif et éventuellement tu affiche le résultat

tu quitte sauvagement la socket :p

**nouknouk** · 16/04/2009, 11h57

Envoyé par tchize_

pas besoin de se casser la nenette à ce point là

Hem, sauf erreur de ma part, j'ai l'impression que ta solution est identique à la mienne

tu lit jusqu'à plus soif

Sauf que le "jusqu'à plus soif" n'est pas détectable en soi, sachant que le texte envoyé par le serveur peut éventuellement avoir été scindé en plusieurs paquets TCP.
D'où l'idée d'une façon plus propre pour détecter la fin de l'envoi, avec la ré-apparition de la chaîne de caractères correspondant à l'invite de commandes par exemple.

**tchize_** · 16/04/2009, 12h04

l'inputstream reader n'a plus rien à lire au bout de 200ms?

Ca m'a l'air d'un bon critère pour le plus soif :p

**nouknouk** · 16/04/2009, 12h15

Envoyé par tchize_

l'inputstream reader n'a plus rien à lire au bout de 200ms?

Ca m'a l'air d'un bon critère pour le plus soif :p

AMHA il me semble plus simple d'implémenter un check sur l'ensemble des caractères qu'on a reçu plutôt que mettre en place un timer, du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
public class KillClass {
 
    public static enum State { LOGIN, PASSWORD, GREP, KILL };
 
    public static void main(String[] args) {
        Socket s = new Socket("123.456.123.456", 23);
        InputStreamReader in = new InputStreamReader(s.getInputStream());
 
        int character;
        String buffer = "";
        State currentState = State.LOGIN;
 
        while ( (character = in.read()) != -1) {
            buffer += (char)character;
            if (currentState.equals(State./*xxx*/) {
                /* blablabla */
            }
 
            /* else if etc... */
 
            else if (currentState.equals(State.GREP)) {
                if (buffer.endsWith("login@server:~$")) {
 
                        // on fait le traitement
                        // (récup' PID & envoi commande kill)
 
                        currentState = State.KILL; // prochaine étape.
                        buffer = ""; // on réinitialise le buffer pour la suite
                    } 
                    else {
                        // on ne fait rien, on attend la suite.
                    }
                }
            }
        }
    }
}

Et même si dans les faits la technique du timer devrait marcher dans la plupart des cas, c'est infiniment plus propre de rechercher l'invite de commande en fin de String.
En effet, rien ne garantit qu'au bout de 200ms on aura tout reçu : les réseaux IP étant basés sur le paradigme du best effort, aucune garantie de délai n'est fournie.

Après, c'est surtout de l'ordre du détail et grandthor choisira la solution avec laquelle il est le plus à l'aise.