J'avais écrit 2 bout de prog C qui, l'un, serveur, créait
une socket() plus bind() plus listen() plus accept()
et l'autre client, qui créait une socket() + connect().
sur un port libre (20500)
Sans souci sur mon Linux 2.0.36 (SuSE 7.3)
Depuis, je l'ai ressorti et mes Debian (linux 2.4 ou 2.6)
me répondent un connexion refused lorsque le client est
distant.
En fait, lorsque le serveur est sur la vieille babasse,
ça passe.
Dès qu'il se trouve sur l'une des récentes, ça refuse.
Après avoir exploré les man des appels systèmes, puis les
howto networking, je vois pas qui bloque, et pourquoi.
C'est réellement un problème de config (et pas de langage C).
Michel SIMIAN wrote in message <44803839$0$20186$:
Quelqu'un a une idée ?
Fais les mêmes essais avec des outils éprouvés comme netcat ou socat, d'abord des deux côtés, puis seulement de l'un, puis seulement de l'autre.
Thierry Danis
Michel SIMIAN wrote:
Bonjour,
J'avais écrit 2 bout de prog C qui, l'un, serveur, créait une socket() plus bind() plus listen() plus accept() et l'autre client, qui créait une socket() + connect(). sur un port libre (20500)
Sans souci sur mon Linux 2.0.36 (SuSE 7.3)
Depuis, je l'ai ressorti et mes Debian (linux 2.4 ou 2.6) me répondent un connexion refused lorsque le client est distant.
En fait, lorsque le serveur est sur la vieille babasse, ça passe. Dès qu'il se trouve sur l'une des récentes, ça refuse.
Après avoir exploré les man des appels systèmes, puis les howto networking, je vois pas qui bloque, et pourquoi.
C'est réellement un problème de config (et pas de langage C).
Quelqu'un a une idée ?
Ne serait-ce pas une configuration iptable un peu restrictive ? A+, -- Thierry
Michel SIMIAN wrote:
Bonjour,
J'avais écrit 2 bout de prog C qui, l'un, serveur, créait
une socket() plus bind() plus listen() plus accept()
et l'autre client, qui créait une socket() + connect().
sur un port libre (20500)
Sans souci sur mon Linux 2.0.36 (SuSE 7.3)
Depuis, je l'ai ressorti et mes Debian (linux 2.4 ou 2.6)
me répondent un connexion refused lorsque le client est
distant.
En fait, lorsque le serveur est sur la vieille babasse,
ça passe.
Dès qu'il se trouve sur l'une des récentes, ça refuse.
Après avoir exploré les man des appels systèmes, puis les
howto networking, je vois pas qui bloque, et pourquoi.
C'est réellement un problème de config (et pas de langage C).
Quelqu'un a une idée ?
Ne serait-ce pas une configuration iptable un peu
restrictive ?
A+,
--
Thierry
J'avais écrit 2 bout de prog C qui, l'un, serveur, créait une socket() plus bind() plus listen() plus accept() et l'autre client, qui créait une socket() + connect(). sur un port libre (20500)
Sans souci sur mon Linux 2.0.36 (SuSE 7.3)
Depuis, je l'ai ressorti et mes Debian (linux 2.4 ou 2.6) me répondent un connexion refused lorsque le client est distant.
En fait, lorsque le serveur est sur la vieille babasse, ça passe. Dès qu'il se trouve sur l'une des récentes, ça refuse.
Après avoir exploré les man des appels systèmes, puis les howto networking, je vois pas qui bloque, et pourquoi.
C'est réellement un problème de config (et pas de langage C).
Quelqu'un a une idée ?
Ne serait-ce pas une configuration iptable un peu restrictive ? A+, -- Thierry
Michel SIMIAN
Thierry Danis wrote:
Michel SIMIAN wrote:
C'est réellement un problème de config (et pas de langage C).
Quelqu'un a une idée ?
Ne serait-ce pas une configuration iptable un peu restrictive ?
Donc, je ne pense pas. Qui peut interdire la connexion d'une socket _avant_ mon petit programme ?
il n'y a pas de host.deny, pas de host.allow (et ils ne sontr utilisés que par inetd, me semble t-il)
-- L'Amer Michel
Calimero
Michel SIMIAN wrote:
Donc, je ne pense pas. Qui peut interdire la connexion d'une socket _avant_ mon petit programme ?
Comme dit, le netcat a donné quoi ?
D'autre part (même si les infos que tu donnes ne suggèrent pas ca), on est d'accord que tu utilises un port > 1024 si tu exécutes ton serveur en tant que non-root ?
-- @+ Calimero
Michel SIMIAN wrote:
Donc, je ne pense pas. Qui peut interdire la connexion
d'une socket _avant_ mon petit programme ?
Comme dit, le netcat a donné quoi ?
D'autre part (même si les infos que tu donnes ne suggèrent pas ca), on
est d'accord que tu utilises un port > 1024 si tu exécutes ton serveur
en tant que non-root ?
Donc, je ne pense pas. Qui peut interdire la connexion d'une socket _avant_ mon petit programme ?
Comme dit, le netcat a donné quoi ?
D'autre part (même si les infos que tu donnes ne suggèrent pas ca), on est d'accord que tu utilises un port > 1024 si tu exécutes ton serveur en tant que non-root ?
-- @+ Calimero
Michel SIMIAN
Calimero wrote:
Michel SIMIAN wrote:
Donc, je ne pense pas. Qui peut interdire la connexion d'une socket _avant_ mon petit programme ?
L'option -o ne génère pas de traces (fichier vide)
D'autre part (même si les infos que tu donnes ne suggèrent pas ca), on est d'accord que tu utilises un port > 1024 si tu exécutes ton serveur en tant que non-root ?
oui (20500)
quels seraient les fichiers de conf network qui protégeraient (et qui seraient différents entre la vieille SuSE et les Debian ) -- L'Amer Michel
Calimero wrote:
Michel SIMIAN wrote:
Donc, je ne pense pas. Qui peut interdire la connexion
d'une socket _avant_ mon petit programme ?
L'option -o ne génère pas de traces (fichier vide)
D'autre part (même si les infos que tu donnes ne suggèrent pas ca), on
est d'accord que tu utilises un port > 1024 si tu exécutes ton serveur
en tant que non-root ?
oui (20500)
quels seraient les fichiers de conf network qui protégeraient
(et qui seraient différents entre la vieille SuSE et les Debian )
--
L'Amer Michel
L'option -o ne génère pas de traces (fichier vide)
D'autre part (même si les infos que tu donnes ne suggèrent pas ca), on est d'accord que tu utilises un port > 1024 si tu exécutes ton serveur en tant que non-root ?
oui (20500)
quels seraient les fichiers de conf network qui protégeraient (et qui seraient différents entre la vieille SuSE et les Debian ) -- L'Amer Michel
vincent.verdon
Bonjour,
Thierry Danis wrote:
il n'y a pas de host.deny, pas de host.allow (et ils ne sontr utilisés que par inetd, me semble t-il) Moi je crois bien que si !
Amicalement, Vincent Verdon
Bonjour,
Thierry Danis wrote:
il n'y a pas de host.deny, pas de host.allow
(et ils ne sontr utilisés que par inetd, me semble t-il)
Moi je crois bien que si !
il n'y a pas de host.deny, pas de host.allow (et ils ne sontr utilisés que par inetd, me semble t-il) Moi je crois bien que si !
Amicalement, Vincent Verdon
octane
J'avais écrit 2 bout de prog C qui, l'un, serveur, créait une socket() plus bind() plus listen() plus accept() et l'autre client, qui créait une socket() + connect(). sur un port libre (20500)
Sans souci sur mon Linux 2.0.36 (SuSE 7.3)
Depuis, je l'ai ressorti et mes Debian (linux 2.4 ou 2.6) me répondent un connexion refused lorsque le client est distant.
cela veut dire que sur un noyau recent, ca passe en
localhost?
En fait, lorsque le serveur est sur la vieille babasse, ça passe.
client sur noyau recent et serveur sur noyau ancien -> OK
Dès qu'il se trouve sur l'une des récentes, ça refuse.
client sur noyau recent, et serveur sur noyau recent -> KO?
un netstat -n -l te montre le port 20500 en LISTEN?
Après avoir exploré les man des appels systèmes, puis les howto networking, je vois pas qui bloque, et pourquoi.
C'est réellement un problème de config (et pas de langage C).
Si ca coince, ton programme n'est pas en cause. Si ca passe, c'est ta config qui est en cause.
J'avais écrit 2 bout de prog C qui, l'un, serveur, créait
une socket() plus bind() plus listen() plus accept()
et l'autre client, qui créait une socket() + connect().
sur un port libre (20500)
Sans souci sur mon Linux 2.0.36 (SuSE 7.3)
Depuis, je l'ai ressorti et mes Debian (linux 2.4 ou 2.6)
me répondent un connexion refused lorsque le client est
distant.
cela veut dire que sur un noyau recent, ca passe en
localhost?
En fait, lorsque le serveur est sur la vieille babasse,
ça passe.
client sur noyau recent et serveur sur noyau ancien -> OK
Dès qu'il se trouve sur l'une des récentes, ça refuse.
client sur noyau recent, et serveur sur noyau recent -> KO?
un netstat -n -l te montre le port 20500 en LISTEN?
Après avoir exploré les man des appels systèmes, puis les
howto networking, je vois pas qui bloque, et pourquoi.
C'est réellement un problème de config (et pas de langage C).
J'avais écrit 2 bout de prog C qui, l'un, serveur, créait une socket() plus bind() plus listen() plus accept() et l'autre client, qui créait une socket() + connect(). sur un port libre (20500)
Sans souci sur mon Linux 2.0.36 (SuSE 7.3)
Depuis, je l'ai ressorti et mes Debian (linux 2.4 ou 2.6) me répondent un connexion refused lorsque le client est distant.
cela veut dire que sur un noyau recent, ca passe en
localhost?
En fait, lorsque le serveur est sur la vieille babasse, ça passe.
client sur noyau recent et serveur sur noyau ancien -> OK
Dès qu'il se trouve sur l'une des récentes, ça refuse.
client sur noyau recent, et serveur sur noyau recent -> KO?
un netstat -n -l te montre le port 20500 en LISTEN?
Après avoir exploré les man des appels systèmes, puis les howto networking, je vois pas qui bloque, et pourquoi.
C'est réellement un problème de config (et pas de langage C).
Si ca coince, ton programme n'est pas en cause. Si ca passe, c'est ta config qui est en cause.
le serveur affiche "CA PASSE" :)
le client reste bloqué, c'est normal ?
oui. Un Ctrl-C pour lui signaler la fin de transmission.
Donc, config en cause. Mais quoi ?
Il n'y a pas eu du changement dans la prog systeme qui specifie de devoir ecouter les interfaces sur lesquelles on veut ecouter lorsqu'on lance un serveur?
Est-ce la même raison qui me refuse telnet par exemple ?
tout pareil. telnet, nc, meme combat.
client sur noyau recent, et serveur sur noyau recent -> KO?
un netstat -n -l te montre le port 20500 en LISTEN?
J'ai une ligne
tcp 0 0 127.0.0.1:20500 [.../..] listen
donc ca n'ecoute _que_ sur 127.0.0.1
Sur un noyau ancien, tu n'as pas:
*:20500 ?
(l'etoile signifiant que ca ecoute sur toutes les interfaces)
quand le serveur est sur accept().
Pour la config:
cote serveur:
nc -l -p 20500
verifie par un netstat -n -a que le port 20500 est bien en LISTEN
Si ca coince, ton programme n'est pas en cause.
Si ca passe, c'est ta config qui est en cause.
le serveur affiche "CA PASSE" :)
le client reste bloqué, c'est normal ?
oui. Un Ctrl-C pour lui signaler la fin de transmission.
Donc, config en cause. Mais quoi ?
Il n'y a pas eu du changement dans la prog systeme
qui specifie de devoir ecouter les interfaces sur lesquelles
on veut ecouter lorsqu'on lance un serveur?
Est-ce la même raison qui me refuse telnet par exemple ?
Si ca coince, ton programme n'est pas en cause. Si ca passe, c'est ta config qui est en cause.
le serveur affiche "CA PASSE" :)
le client reste bloqué, c'est normal ?
oui. Un Ctrl-C pour lui signaler la fin de transmission.
Donc, config en cause. Mais quoi ?
Il n'y a pas eu du changement dans la prog systeme qui specifie de devoir ecouter les interfaces sur lesquelles on veut ecouter lorsqu'on lance un serveur?
Est-ce la même raison qui me refuse telnet par exemple ?
