C'est en gros un serveur de "chat" qui est censé écouter sur un port.
J'arrive à le lancer, mais mes connaissances personnelles limitées en
Java ne me permettent pas de résoudre le fait que les clients n'arrivent
pas à se connecter.
Sur un réseau local résidentiel de test, les clients arrivent à se
connecter.
J'ai en charge la mise en place du serveur, et n'ai pas de possibilité de
tester moi-même les clients. Je ne sais donc pas quels messages d'erreur
renvoient les clients qui n'arrivent pas à se connecter. D'ailleurs mon
collègue qui teste les clients me dit qu'il ne voit aucun message
d'erreur. Tous les clients auront à se connecter à se serveur le feront
à partir d'une ligne résidentielle.
J'ai une piste: le serveur écoute en IPv6 et pas en IPv4, car
Donc, il n'écoute pas en IPv4, d'après moi. Et comme IPv6 est loin
d'être répandu, ce n'est peut-être pas étonnant que ça ne communique
pas. Mais pourquoi est-ce que ça fonctionne sur un LAN?
Ma première réaction serait de modifier le serveur, dont on a les
sources, pour le forcer à y aller en IPv4. Le problème est que je n'ai
vu aucun passage du code qui spécifie le protocole ou le type de couche
à utiliser. Y a t il de meilleures façons de régler ce problème?
Dans la mesure ou ça peut aussi être un problème de support IPv6
quelquepart dans l'OS, je vais me permetttre un Xpost, mais en conservant
le fu2 sur fclj parceque ma première piste concerne fclj. Les solutions
propres à l'OS (Linux 2.6.8/Debian Testing) qui me seront proposées
peuvent éventuellement être continuées, je suis ouvert à tout fu2
ultérieur.
Merci d'avance :-).
--
Miroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
Si je ne m'abuse, une spécificité du noyau Linux est qu'un port ouvert en écoute en IPv6 écoute aussi en IPv4 si ce port n'est pas déjà utilisé en IPv4. Par contre une adresse IPv4 x.y.z.t peut être vue du processus serveur sous la forme IPv4-mapped IPv6, ::ffff:x.y.z.t. C'est à prendre en considération en cas d'ACL dans le serveur.
Salut,
[...]
J'ai une piste: le serveur écoute en IPv6 et pas en IPv4, car
Si je ne m'abuse, une spécificité du noyau Linux est qu'un port ouvert en
écoute en IPv6 écoute aussi en IPv4 si ce port n'est pas déjà utilisé en
IPv4. Par contre une adresse IPv4 x.y.z.t peut être vue du processus
serveur sous la forme IPv4-mapped IPv6, ::ffff:x.y.z.t. C'est à prendre
en considération en cas d'ACL dans le serveur.
Si je ne m'abuse, une spécificité du noyau Linux est qu'un port ouvert en écoute en IPv6 écoute aussi en IPv4 si ce port n'est pas déjà utilisé en IPv4. Par contre une adresse IPv4 x.y.z.t peut être vue du processus serveur sous la forme IPv4-mapped IPv6, ::ffff:x.y.z.t. C'est à prendre en considération en cas d'ACL dans le serveur.
Julien Salgado
a écrit :
Salut,
[...]
J'ai une piste: le serveur écoute en IPv6 et pas en IPv4, car
Si je ne m'abuse, une spécificité du noyau Linux est qu'un port ouvert en écoute en IPv6 écoute aussi en IPv4 si ce port n'est pas déjà utilisé en IPv4. Par contre une adresse IPv4 x.y.z.t peut être vue du processus serveur sous la forme IPv4-mapped IPv6, ::ffff:x.y.z.t. C'est à prendre en considération en cas d'ACL dans le serveur.
Ce n'est pas une spécificité de linux, c'est le cas sur tous les systèmes qui implémentent la compatibilité IPv4/IPv6...
-- Julien
Pascal@plouf a écrit :
Salut,
[...]
J'ai une piste: le serveur écoute en IPv6 et pas en IPv4, car
Si je ne m'abuse, une spécificité du noyau Linux est qu'un port ouvert en
écoute en IPv6 écoute aussi en IPv4 si ce port n'est pas déjà utilisé en
IPv4. Par contre une adresse IPv4 x.y.z.t peut être vue du processus
serveur sous la forme IPv4-mapped IPv6, ::ffff:x.y.z.t. C'est à prendre
en considération en cas d'ACL dans le serveur.
Ce n'est pas une spécificité de linux, c'est le cas sur tous les
systèmes qui implémentent la compatibilité IPv4/IPv6...
Si je ne m'abuse, une spécificité du noyau Linux est qu'un port ouvert en écoute en IPv6 écoute aussi en IPv4 si ce port n'est pas déjà utilisé en IPv4. Par contre une adresse IPv4 x.y.z.t peut être vue du processus serveur sous la forme IPv4-mapped IPv6, ::ffff:x.y.z.t. C'est à prendre en considération en cas d'ACL dans le serveur.
Ce n'est pas une spécificité de linux, c'est le cas sur tous les systèmes qui implémentent la compatibilité IPv4/IPv6...
-- Julien
Rakotomandimby (R12y) Mihamina
"jerome moliere" :
je t'ai extrait un court passage de la doc sun a ce sujet: How IPv6 Works on a Java Platform
The Java networking stack will first check whether IPv6 is supported on the underlying OS. If IPv6 is supported, it will try to use the IPv6 stack. More specifically, on dual-stack systems it will create an IPv6 socket. On separate-stack systems things are much more complicated. Java will create two sockets, one for IPv4 and one for IPv6 communication. For client-side TCP applications, once the socket is connected, the internet-protocol family type will be fixed, and the extra socket can be closed. For server-side TCP applications, since there is no way to tell from which IP family type the next client request will come, two sockets need to be maintained. For UDP applications, both sockets will be needed for the lifetime of the communication.
Ok au moins c'est clair.
Ce qui se passe c'est donc que mon OS n'est pas en dual stack. Faudra que je me documente à ce sujet. Quelqu'un à une idée de comment activer le "dual-stack" sous Debian/Linux 2.6.8 ?
"linux activate dual stack IPv4 IPv6" ne me donne pas de bon resultats, peut-etre n'ai je tout siplement pas les bons mots clés? j'ai pourtant repris ceux donnés par l'extrait de la doc Java.
a verifier: ta config de firewall cela serait ballot qu'il bloque les sockets non?
Aucune règle IPv6 de filtrage n'est appliquée, donc d'après ce que j'ai lu ça et là, les paquets ne sont pas filtrés.
Je repositionne le FU2 vers fcolc, puisque je pense que si je réussi à le faire binder en V4 et V6 ça devrait le faire. Ensuite mon collègue developpeur se débrouillera.
-- Miroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
"jerome moliere" <jmoliere@nerim.net> :
je t'ai extrait un court passage de la doc sun a ce sujet: How IPv6 Works
on a Java Platform
The Java networking stack will first check whether IPv6 is supported on
the underlying OS. If IPv6 is supported, it will try to use the IPv6
stack. More specifically, on dual-stack systems it will create an IPv6
socket. On separate-stack systems things are much more complicated. Java
will create two sockets, one for IPv4 and one for IPv6 communication. For
client-side TCP applications, once the socket is connected, the
internet-protocol family type will be fixed, and the extra socket can be
closed. For server-side TCP applications, since there is no way to tell
from which IP family type the next client request will come, two sockets
need to be
maintained. For UDP applications, both sockets will be needed for the
lifetime of the communication.
Ok au moins c'est clair.
Ce qui se passe c'est donc que mon OS n'est pas en dual stack.
Faudra que je me documente à ce sujet.
Quelqu'un à une idée de comment activer le "dual-stack" sous
Debian/Linux 2.6.8 ?
"linux activate dual stack IPv4 IPv6" ne me donne pas de bon resultats,
peut-etre n'ai je tout siplement pas les bons mots clés? j'ai pourtant
repris ceux donnés par l'extrait de la doc Java.
a verifier:
ta config de firewall cela serait ballot qu'il bloque les sockets non?
Aucune règle IPv6 de filtrage n'est appliquée, donc d'après ce que j'ai
lu ça et là, les paquets ne sont pas filtrés.
Je repositionne le FU2 vers fcolc, puisque je pense que si je réussi à
le faire binder en V4 et V6 ça devrait le faire. Ensuite mon collègue
developpeur se débrouillera.
--
Miroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)
je t'ai extrait un court passage de la doc sun a ce sujet: How IPv6 Works on a Java Platform
The Java networking stack will first check whether IPv6 is supported on the underlying OS. If IPv6 is supported, it will try to use the IPv6 stack. More specifically, on dual-stack systems it will create an IPv6 socket. On separate-stack systems things are much more complicated. Java will create two sockets, one for IPv4 and one for IPv6 communication. For client-side TCP applications, once the socket is connected, the internet-protocol family type will be fixed, and the extra socket can be closed. For server-side TCP applications, since there is no way to tell from which IP family type the next client request will come, two sockets need to be maintained. For UDP applications, both sockets will be needed for the lifetime of the communication.
Ok au moins c'est clair.
Ce qui se passe c'est donc que mon OS n'est pas en dual stack. Faudra que je me documente à ce sujet. Quelqu'un à une idée de comment activer le "dual-stack" sous Debian/Linux 2.6.8 ?
"linux activate dual stack IPv4 IPv6" ne me donne pas de bon resultats, peut-etre n'ai je tout siplement pas les bons mots clés? j'ai pourtant repris ceux donnés par l'extrait de la doc Java.
a verifier: ta config de firewall cela serait ballot qu'il bloque les sockets non?
Aucune règle IPv6 de filtrage n'est appliquée, donc d'après ce que j'ai lu ça et là, les paquets ne sont pas filtrés.
Je repositionne le FU2 vers fcolc, puisque je pense que si je réussi à le faire binder en V4 et V6 ça devrait le faire. Ensuite mon collègue developpeur se débrouillera.
-- Miroir de logiciels libres http://www.etud-orleans.fr Développement de logiciels libres http://aspo.rktmb.org/activites/developpement Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance (En louant les services de l'ASPO vous luttez contre la fracture numerique)
