cher forum,
aujourd'hui j'ai un petit problème qui j'avoue me pose problème :
j'ai un logiciel qui ne sait ouvrir que des connections X réseaux (sur le portable de mes parents, en wifi)
Et là c'est le drame.
J'ai permis à X d'ouvrir le port tcp mais impossible de se connecter à ce port.
Je me suis dis tant pis il doit y avoir une protection inconnue (malgré que j'ai fait un xhost +)
j'utilise donc socat après.
Et la c'est le drame à nouveau.
strace socat -d -d TCP4-LISTEN:6000,fork,reuseaddr,bind=192.168.37.21 UNIX-CONNECT:/tmp/.X11-unix/X0
le strace permet de s'assurer que j'ai bien un bind, et il s'arrêt bien à l'accept.
munmap(0x7f783eb37000, 4096) = 0
write(2, "2013/01/10 21:52:04 socat[19497]"..., 722013/01/10 21:52:04 socat[19497] N listening on AF=2 192.168.37.21:6000
) = 72
accept(3,
bon je vérifie une nième fois et il apparait bien dans netstat :
netstat -planet
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 192.168.37.21:6000 0.0.0.0:* LISTEN 0 201232 -
Bon il écoute bien non ?
Et ben nmap me dis "filtered"
nmap -sT -T5 -Pn 192.168.37.21 -p 6000
Starting Nmap 6.00 ( http://nmap.org ) at 2013-01-10 22:08 CET
Nmap scan report for 192.168.37.21
Host is up.
PORT STATE SERVICE
6000/tcp filtered X11
Nmap done: 1 IP address (1 host up) scanned in 0.58 seconds
netcat pas beaucoup mieux :
nc -w 3 -z -v 192.168.37.21 6000
nc: connect to 192.168.37.21 port 6000 (tcp) timed out: Operation now in progress
bien entendu j'ai vérifié iptables
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
( nat et mangle sont aussi désespérement vide)
Il n'y a rien dans dmesg non plus.
Bref, est ce qu'il y a un truc dans /proc/sys/net ou autre qui pourrait expliquer ?
Est ce que quelqu'un à une idée ?
# TCP
Posté par Xaapyks . Évalué à 3.
sur beaucoup de distrib X est lancé avec -no-tcp ou un truc comme ça.
Je pense qu'un simple 'ps aux | grep X' te permettra de voir si le switch est là.
Après tu le vois quand même dans netstat donc je sais pas, mais c'est la seule chose qui me vient à l'esprit…
[^] # Re: TCP
Posté par briaeros007 . Évalué à 2.
voui c'était le cas, mais je l'ai désactivé dans lightdm.conf et j'ai vérifié qu'il n'était plus.
Mais comme ça marchait toujours pas, j'ai essayé la méthode socat… sans plus de succès.
J'ai l'impression qu'il ouvre bien les ports mais ne permet pas de s'y connecter.
Si j'avais des règles iptables je pourrais comprendre, mais là ?
[^] # Re: TCP
Posté par Xaapyks . Évalué à 2.
hosts.deny /hosts.allow ?
[^] # Re: TCP
Posté par briaeros007 . Évalué à 2.
bonne idée je n'y avais pas pensé, mais non rien dans les fichier
[^] # Re: TCP
Posté par Xaapyks . Évalué à 2.
C'est à dire ? Tu as un allow all ?
Ces fichiers ont toujours été une plaie pour moi à configurer…
[^] # Re: TCP
Posté par briaeros007 . Évalué à 2.
aucune entrée ni dans l'un, ni dans l'autre, donc il ne s'en occupe pas.
# tcpdump, topologie?
Posté par neologix . Évalué à 2.
Déjà un tcpdump sur la machine cible te permettra de voir si le SYN arrive.
Ensuite, tu ne précises pas: tu as un switch, un routeur, une box?
Non parce que ça ressemble furieusement à un paquet droppé entre les deux…
[^] # Re: tcpdump, topologie? - WiFi, FAIbox merdique ?
Posté par Grunt . Évalué à 2.
Je lis dans la présentation que le portable cible (serveur) est connecté en WiFi.
Attention, il y a des problèmes avec certaines "box" défectueuses. De mémoire, certaines Freebox refusent de laisser les machines du LAN amorcer des connexions vers les machines du LAN connectées en WiFi.
Donc, oui, tcpdump, ou bien un test tout simple avec netcat et telnet.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: tcpdump, topologie? - WiFi, FAIbox merdique ?
Posté par briaeros007 . Évalué à 2.
j'ai du mal m'exprimer, les connexions se font sur la même machine.
le test netcat -> il a été fait (commande nc)
je viens de faire tcpdump sur l'interface "any" et comme je m'y attendais, comme on est sur la même machine , on ne vois aucun paquet passer :'(
[^] # Re: tcpdump, topologie? - WiFi, FAIbox merdique ?
Posté par neologix . Évalué à 2.
Non, même si c'est sur la même machine, ce n'est pas normal.
Que renvoient
ip6tables -L
et
route -n
Tu arrives à pinger ?
[^] # Re: tcpdump, topologie? - WiFi, FAIbox merdique ?
Posté par briaeros007 . Évalué à 3.
ip6tables est vide (filter ou mangle).
route -n est correct :
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.37.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.37.254 0.0.0.0 UG 0 0 0 wlan0
par contre effectivement je ne peux pas pinger sur mes propres interfaces.
(par contre pinger les autres éléments réseaux comme le routeur ou autre ça ne pose aucun problème).
C'est une debian installé debootstrap donc normalement il ne devrait pas y avoir des un firewall/hooks spécifique niveau réseau.
Mise à jour, après le problème du ping j'ai regardé et visiblement mon interface "lo" était mal initialisé (elle était en down), qui empêchait toute connexions aux ports locaux, même si les autres interfaces étaient bien configuré et fonctionnelle.
après un ifconfig pour la remettre d'aplomb tout remarche
problème idiot n'est ce pas ?
En tout cas , merci beaucoup :)
# faut preciser ce que tu veux faire
Posté par NeoX . Évalué à 3.
tu parles d'un logiciel qui ne sait ouvrir que des connections X réseaux
sans preciser lequel,
puis tu parles de port 6000 et de probleme pour te connecter dessus.
si tu nous precises le logiciel que tu veux utiliser, et pourquoi tu veux te connecter au port 6000 qui semble ouvert par X11
[^] # Re: faut preciser ce que tu veux faire
Posté par briaeros007 . Évalué à 2.
le logiciel c'est du mono (bouh pas bien).
et mono pour se connecter en X (en tout cas avec la version installé) il ouvre une connexion en AF_INET (trouvé avec un strace) d'où ma tentative de passer par le socket réseau et pas le socket unix.
(debian squeeze avec paquet testing)
[^] # Re: faut preciser ce que tu veux faire
Posté par Marotte ⛧ . Évalué à 2.
C'est un logiciel que tu as honte d'utiliser à ce point que tu ne dédaignes le citer ?
[^] # Re: faut preciser ce que tu veux faire
Posté par briaeros007 . Évalué à 2.
c'est surtout que le logiciel n'est pas lié à mon problème.
Il m'a fait détecter ce problème, mais comme il est reproductible avec netcat, mono n'est pas le problème.
[^] # Re: faut preciser ce que tu veux faire
Posté par NeoX . Évalué à 2.
ca n'empeche que si tu precisais on pourrait tester de notre coté.
il me semble que desormais en plus (ou en remplacement) de
xhost +il y a un systeme d'autentification de la connexiondu coup ce serait pour ca que tout le monde se fait jeter.
[^] # Re: faut preciser ce que tu veux faire
Posté par briaeros007 . Évalué à 2.
certes,
m'ai aupravant j'eusse testé sur une autre debian et l'ensemble fonctionna correctement.
Le problème fut détecté par neologix, où j'ai oublié les tests les plus simples (ping…)
le problème était l'interface lo mal configuré.
par contre, dans mon cas, pas besoin de quelque chose en plus que xhost+ pour le faire fonctionner après ça.
[^] # Re: faut preciser ce que tu veux faire
Posté par NeoX . Évalué à 2.
ah oui, probleme de localhost non activée,
ca me l'a fait une fois ou deux,
je ne sais plus comment j'avais resolu ca de maniere perenne vu que tout était correct (/etc/network/interfaces par ex)
[^] # Re: faut preciser ce que tu veux faire
Posté par Xaapyks . Évalué à 2.
il me semble que "xhost +" désactive xauth et les magic cookies. Sinon ouai peut-être à voir de ce côté, mais chez moi, j'ai un X avec xauth, et un xhost + permet bien à n'importe qui d'utiliser le DISPLAY.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.