Re: [Fwd: Re: [gulliver] envoyer messages entre 2 PC GNU Linux]

[François <francois dot joulaud at bzh dot net>]

Bonjour,

(l'idée intéressante pour le problème est à la toute fin du message)

On Le Thursday 05 July 2007, à 11:48:40, Patrick Lamaizière wrote:
> François a écrit :

> >> > mais ntalk n'est pas LISTEN c'est normal Docteur ?
> >>
> >> Oui c'est de l'UDP. Il n'y a pas de connexion contrairement à TCP.
> >
> > ????? et alors ?
> 
> Les sockets en LISTEN sont des sockets serveurs. Il n'y a pas de notion de
> socket "serveur" en UDP, ie en attente de connexion (y'a pas de
> connexion).

La terminologie employée m'a troublé (LISTEN pour «en attente de
connexion»). En fait ce n'est pas tant une distinction connecteur
(socket) serveur ou non mais plutôt le fait qu'un connecteur UDP n'a
pas d'état, donc netstat ne met rien dans la colonne «State» pour les
sockets UDP (normal) bien que les connecteurs UDP ouverts *écoutent*
le réseau.

La connexion semble donc bien configurée. Ensuite reste à voir si
inetd retransmet bien les paquets au logiciel qu'il faut.

...

Encore que...

Pierre a aussi dit :
> j'ai configuré comme indiqué dans la doc de Patrick, juste modifié
> 192.168.1.0/24 par 192.168.0.0/24
> http://www.vanemery.com/Linux/Ntalkd/ntalkd.html

l'exemple proposé affiche bien :

| [root at rat xinetd.d]# netstat -tua
| Active Internet connections (servers and established)
| Proto Recv-Q Send-Q Local Address           Foreign Address         State
| tcp        0      0 *:ssh                   *:*                     LISTEN
| tcp        0      0 *:http                  *:*                     LISTEN
| tcp        0      0 rat:smtp                *:*                     LISTEN
| udp        0      0 *:ntalk                 *:*                     LISTEN
| 
| [root at rat xinetd.d]# netstat -tuna
| Active Internet connections (servers and established)
| Proto Recv-Q Send-Q Local Address           Foreign Address         State
| tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
| tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
| tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN
| udp        0      0 0.0.0.0:518             0.0.0.0:*               LISTEN

ce qui contredirait mon analyse de netstat ci-dessus. 

> J'ai un retour sur la machine qui envoie mais pas sur l'autre et vice versa
> Le réseau ne marche sans doute pas
> Pourtant ssh marche !!!

Donc le réseau marche. A priori et sauf configuration réseau
bizarrement ésotérique, le problème vient de la configuration de talk
et xinetd.

J'ai de fortes présomptions là-dessus :

| # default: off
| # description: The ntalk server accepts ntalk connections, for chatting \
| #       with users on different systems.
| service ntalk
| {
|         flags                   = IPv4
|         disable                 = no
|         socket_type             = dgram
|         wait                    = yes
|         user                    = nobody
|         group                   = tty
|         server                  = /usr/sbin/in.ntalkd
|         only_from               = 127.0.0.0/8
| }

si le `only_from` est resté tel quel, cela signifie que inetd
n'accepte pour talk que ce qui vient de l'ordinateur local et pas du
réseau. Il faut remplacer 127.0.0.0/8 par 192.168.0.0/24.

François