Actuellement j'utilise mon portable par un "point d'accès mobile", il
est donc conecté au réseau par mon GSM.
Son IP est :
192.168.43.32
(d'habitude, derrière une freebox c'est 192.168.0.41)
j'ai un serveur sur ce portable (websocket) qui émet en 0.0.0.0 (port 8088).
je n'arrive pas à me connecter à ce websocket en :
ws://192.168.43.32:8088
(d'habitude, derrière la freebox, je m'y connecte en ws://192.168.0.41:8088)
j'aimerais bien régler ce problème, càd, pouvoir m'y connecter quelque
soit l'IP attribuée par le WiFi quand je suis en "point d'accès mobile"
via mon GSM ou bien en ethernet via le routeur de ma box.
Donc tu confirmes que le client et le serveur tournent bien tous les deux sur la même machine ?
ben oui. en réalité, ce n'est pas un pb lié à l'IP ni au fait que je suis en partage de connexion derrière un GSM : $ netstat -l -n | grep 8088 tcp4 0 0 192.168.43.32.8088 192.168.43.32.54609 ESTABLISHED tcp4 0 0 192.168.43.32.54609 192.168.43.32.8088 ESTABLISHED sur macOS on utilise plutôt lsof : $ lsof -i -n -P | grep TCP | grep 8088 ruby 495 yt 10u IPv4 0xe71fd9a1cb825d0f 0t0 TCP *:8088 (LISTEN) bon, cette ligne montre que ruby (le server websocket) écoute tous les IP (ie *) sur le port 8088 d'ailleurs il y a de multiples connections établies : ruby 495 yt 11u IPv4 0xe71fd9a1bfea8d0f 0t0 TCP 192.168.43.32:8088->192.168.43.32:49723 (ESTABLISHED) ruby 495 yt 13u IPv4 0xe71fd9a1bfda9417 0t0 TCP 192.168.43.32:8088->192.168.43.32:49842 (ESTABLISHED) ruby 495 yt 14u IPv4 0xe71fd9a1bfd8692f 0t0 TCP 192.168.43.32:8088->192.168.43.32:54222 (ESTABLISHED) le client principal est firefox (JavaScript d'une page HTML) : firefox 1525 yt 310u IPv4 0xe71fd9a1d3e2792f 0t0 TCP 192.168.43.32:54578->192.168.43.32:8088 (ESTABLISHED) firefox 1525 yt 311u IPv4 0xe71fd9a1d3e27037 0t0 TCP 192.168.43.32:54579->192.168.43.32:8088 (ESTABLISHED) firefox 1525 yt 312u IPv4 0xe71fd9a1d3e3d417 0t0 TCP 192.168.43.32:54580->192.168.43.32:8088 (ESTABLISHED) et d'autres clients en "com.apple", je ne sais pas ce qui les produit : com.apple 18282 yt 7u IPv4 0xe71fd9a1b1fd592f 0t0 TCP 192.168.43.32:54222->192.168.43.32:8088 (ESTABLISHED) com.apple 18282 yt 8u IPv4 0xe71fd9a1b1fd592f 0t0 TCP 192.168.43.32:54222->192.168.43.32:8088 (ESTABLISHED) com.apple 18282 yt 9u IPv4 0xe71fd9a1bfe2d92f 0t0 TCP 192.168.43.32:54406->192.168.43.32:8088 (ESTABLISHED) com.apple 18282 yt 11u IPv4 0xe71fd9a1bfe2d92f 0t0 TCP 192.168.43.32:54406->192.168.43.32:8088 (ESTABLISHED) avec telnet : .-[:~]-[17-08-08 03:59:10] '->$ telnet localhost 8088 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. .-[:~]-[17-08-08 04:01:54] '->$ telnet 192.168.43.32 8088 Trying 192.168.43.32... Connected to mbp. Escape character is '^]'. Connection closed by foreign host. .-[:~]-[17-08-08 04:27:27] '->$ je sais que le "::1: Connection refused" provient d'un bug dans "ruby" et le server websocket qui ne fonctionne pas en IPV6. mbp, c'est le nom de mon portable.
Le 07/08/2017 à 14:34, Nicolas George a écrit :
Donc tu confirmes que le client et le serveur tournent bien tous les
deux sur la même machine ?
ben oui.
en réalité, ce n'est pas un pb lié à l'IP ni au fait que je suis en
partage de connexion derrière un GSM :
$ netstat -l -n | grep 8088
tcp4 0 0 192.168.43.32.8088 192.168.43.32.54609
ESTABLISHED
tcp4 0 0 192.168.43.32.54609 192.168.43.32.8088
ESTABLISHED
bon, cette ligne montre que ruby (le server websocket) écoute tous les
IP (ie *) sur le port 8088 d'ailleurs il y a de multiples connections
établies :
Donc tu confirmes que le client et le serveur tournent bien tous les deux sur la même machine ?
ben oui. en réalité, ce n'est pas un pb lié à l'IP ni au fait que je suis en partage de connexion derrière un GSM : $ netstat -l -n | grep 8088 tcp4 0 0 192.168.43.32.8088 192.168.43.32.54609 ESTABLISHED tcp4 0 0 192.168.43.32.54609 192.168.43.32.8088 ESTABLISHED sur macOS on utilise plutôt lsof : $ lsof -i -n -P | grep TCP | grep 8088 ruby 495 yt 10u IPv4 0xe71fd9a1cb825d0f 0t0 TCP *:8088 (LISTEN) bon, cette ligne montre que ruby (le server websocket) écoute tous les IP (ie *) sur le port 8088 d'ailleurs il y a de multiples connections établies : ruby 495 yt 11u IPv4 0xe71fd9a1bfea8d0f 0t0 TCP 192.168.43.32:8088->192.168.43.32:49723 (ESTABLISHED) ruby 495 yt 13u IPv4 0xe71fd9a1bfda9417 0t0 TCP 192.168.43.32:8088->192.168.43.32:49842 (ESTABLISHED) ruby 495 yt 14u IPv4 0xe71fd9a1bfd8692f 0t0 TCP 192.168.43.32:8088->192.168.43.32:54222 (ESTABLISHED) le client principal est firefox (JavaScript d'une page HTML) : firefox 1525 yt 310u IPv4 0xe71fd9a1d3e2792f 0t0 TCP 192.168.43.32:54578->192.168.43.32:8088 (ESTABLISHED) firefox 1525 yt 311u IPv4 0xe71fd9a1d3e27037 0t0 TCP 192.168.43.32:54579->192.168.43.32:8088 (ESTABLISHED) firefox 1525 yt 312u IPv4 0xe71fd9a1d3e3d417 0t0 TCP 192.168.43.32:54580->192.168.43.32:8088 (ESTABLISHED) et d'autres clients en "com.apple", je ne sais pas ce qui les produit : com.apple 18282 yt 7u IPv4 0xe71fd9a1b1fd592f 0t0 TCP 192.168.43.32:54222->192.168.43.32:8088 (ESTABLISHED) com.apple 18282 yt 8u IPv4 0xe71fd9a1b1fd592f 0t0 TCP 192.168.43.32:54222->192.168.43.32:8088 (ESTABLISHED) com.apple 18282 yt 9u IPv4 0xe71fd9a1bfe2d92f 0t0 TCP 192.168.43.32:54406->192.168.43.32:8088 (ESTABLISHED) com.apple 18282 yt 11u IPv4 0xe71fd9a1bfe2d92f 0t0 TCP 192.168.43.32:54406->192.168.43.32:8088 (ESTABLISHED) avec telnet : .-[:~]-[17-08-08 03:59:10] '->$ telnet localhost 8088 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host. .-[:~]-[17-08-08 04:01:54] '->$ telnet 192.168.43.32 8088 Trying 192.168.43.32... Connected to mbp. Escape character is '^]'. Connection closed by foreign host. .-[:~]-[17-08-08 04:27:27] '->$ je sais que le "::1: Connection refused" provient d'un bug dans "ruby" et le server websocket qui ne fonctionne pas en IPV6. mbp, c'est le nom de mon portable.
Une B=c3=a9vue
Le 07/08/2017 à 15:44, Paul Aubrin a écrit :
si le client et le serveur tournent sur la même machine, le mieux est de se connecter par l'IP locale localhost 127.0.0.1 ex. ws:localhost:8088
oui, dans le cas de figure actuel.
Le 07/08/2017 à 15:44, Paul Aubrin a écrit :
si le client et le serveur tournent sur la même machine, le mieux est de
se connecter par l'IP locale localhost 127.0.0.1
ex. ws:localhost:8088
si le client et le serveur tournent sur la même machine, le mieux est de se connecter par l'IP locale localhost 127.0.0.1 ex. ws:localhost:8088
oui, dans le cas de figure actuel.
Doug713705
Le 07-08-2017, Une Bévue nous expliquait dans fr.comp.os.linux.configuration (<om8r49$62e$) :
Le 06/08/2017 à 18:42, Nicolas George a écrit :
Tu n'arrives pas à te connecter au portable depuis le portable lui-même ?
ben non, pour websocket recevant en : 0.0.0.0 sur le port 8088 et en tentant une connexion (JavaScript) par : ws://192.168.43.32:8088 ou par : ws://127.0.0.1:8088 sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est privée (je ne vois pas ce que ça signifie exactement).
Ça veut probablement dire que tu ne peux pas y accéder à partir du réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G. En gros, ton Android dispose d'une route par défaut qui ne peut pas atteindre cette adresse IP. Pour afiner le diagnostic, vérifie l'adresse de ton Android. Elle doit appartenir au même sous-réseau (ie: 192.168.43.0/24). Dans le cas contraire ton Android doit disposer d'une route vers une passerelle qui permet d'atteindre le dit sous-réseau. Bref, ton problème se situe probablement coté Android et pas coté PC. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 07-08-2017, Une Bévue nous expliquait dans
fr.comp.os.linux.configuration
(<om8r49$62e$1@shakotay.alphanet.ch>) :
Le 06/08/2017 à 18:42, Nicolas George a écrit :
Tu n'arrives pas à te connecter au portable depuis le portable
lui-même ?
ben non, pour websocket recevant en :
0.0.0.0 sur le port 8088
et en tentant une connexion (JavaScript) par :
ws://192.168.43.32:8088
ou par :
ws://127.0.0.1:8088
sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est
privée (je ne vois pas ce que ça signifie exactement).
Ça veut probablement dire que tu ne peux pas y accéder à partir du
réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G.
En gros, ton Android dispose d'une route par défaut qui ne peut pas
atteindre cette adresse IP.
Pour afiner le diagnostic, vérifie l'adresse de ton Android. Elle doit
appartenir au même sous-réseau (ie: 192.168.43.0/24). Dans le cas
contraire ton Android doit disposer d'une route vers une passerelle qui
permet d'atteindre le dit sous-réseau.
Bref, ton problème se situe probablement coté Android et pas coté PC.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 07-08-2017, Une Bévue nous expliquait dans fr.comp.os.linux.configuration (<om8r49$62e$) :
Le 06/08/2017 à 18:42, Nicolas George a écrit :
Tu n'arrives pas à te connecter au portable depuis le portable lui-même ?
ben non, pour websocket recevant en : 0.0.0.0 sur le port 8088 et en tentant une connexion (JavaScript) par : ws://192.168.43.32:8088 ou par : ws://127.0.0.1:8088 sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est privée (je ne vois pas ce que ça signifie exactement).
Ça veut probablement dire que tu ne peux pas y accéder à partir du réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G. En gros, ton Android dispose d'une route par défaut qui ne peut pas atteindre cette adresse IP. Pour afiner le diagnostic, vérifie l'adresse de ton Android. Elle doit appartenir au même sous-réseau (ie: 192.168.43.0/24). Dans le cas contraire ton Android doit disposer d'une route vers une passerelle qui permet d'atteindre le dit sous-réseau. Bref, ton problème se situe probablement coté Android et pas coté PC. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Une B=c3=a9vue
Le 08/08/2017 à 21:32, Doug713705 a écrit :
Bref, ton problème se situe probablement coté Android et pas coté PC.
ok merci
Le 08/08/2017 à 21:32, Doug713705 a écrit :
Bref, ton problème se situe probablement coté Android et pas coté PC.
je sais que le "::1: Connection refused" provient d'un bug dans "ruby" et le server websocket qui ne fonctionne pas en IPV6.
On peut voir plus haut que c'est une socket IPv4. Tu as écrit dans ton message initial qu'elle écoute sur 0.0.0.0, donc n'importe quelle adresse IPv4 locale. Il n'y a aucune raison qu'elle accepte des communications en IPv6. Les sockets IPv6 peuvent établir des connexions en IPv4 à certaines conditions, mais pas l'inverse.
Le 08/08/2017 à 04:31, Une Bévue a écrit :
$ netstat -l -n | grep 8088
tcp4 0 0 192.168.43.32.8088 192.168.43.32.54609 ESTABLISHED
tcp4 0 0 192.168.43.32.54609 192.168.43.32.8088 ESTABLISHED
Des sockets dans l'état ESTABLISHED affichées par netstat -l (qui est
censé n'afficher que les sockets dans l'état LISTEN) ? Etonnant.
je sais que le "::1: Connection refused" provient d'un bug dans "ruby"
et le server websocket qui ne fonctionne pas en IPV6.
On peut voir plus haut que c'est une socket IPv4. Tu as écrit dans ton
message initial qu'elle écoute sur 0.0.0.0, donc n'importe quelle
adresse IPv4 locale. Il n'y a aucune raison qu'elle accepte des
communications en IPv6. Les sockets IPv6 peuvent établir des connexions
en IPv4 à certaines conditions, mais pas l'inverse.
je sais que le "::1: Connection refused" provient d'un bug dans "ruby" et le server websocket qui ne fonctionne pas en IPV6.
On peut voir plus haut que c'est une socket IPv4. Tu as écrit dans ton message initial qu'elle écoute sur 0.0.0.0, donc n'importe quelle adresse IPv4 locale. Il n'y a aucune raison qu'elle accepte des communications en IPv6. Les sockets IPv6 peuvent établir des connexions en IPv4 à certaines conditions, mais pas l'inverse.
Pascal Hambourg
Le 08/08/2017 à 21:32, Doug713705 a écrit :
Le 07-08-2017, Une Bévue nous expliquait dans
sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est privée (je ne vois pas ce que ça signifie exactement).
Rien de pertient.
Ça veut probablement dire que tu ne peux pas y accéder à partir du réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G.
(...)
Bref, ton problème se situe probablement coté Android et pas coté PC.
N'importe quoi. C'est l'adresse IP de la machine elle-même, qui est donc une adresse locale du point de vue du système. Les communications avec une adresse locale ne sortent pas de la machine. Peu importe que cette adresse soit attribuée par un point d'accès Android ou n'importe quoi d'autre. D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de connectivité IP.
Le 08/08/2017 à 21:32, Doug713705 a écrit :
Le 07-08-2017, Une Bévue nous expliquait dans
sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est
privée (je ne vois pas ce que ça signifie exactement).
Rien de pertient.
Ça veut probablement dire que tu ne peux pas y accéder à partir du
réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G.
(...)
Bref, ton problème se situe probablement coté Android et pas coté PC.
N'importe quoi. C'est l'adresse IP de la machine elle-même, qui est donc
une adresse locale du point de vue du système. Les communications avec
une adresse locale ne sortent pas de la machine. Peu importe que cette
adresse soit attribuée par un point d'accès Android ou n'importe quoi
d'autre.
D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de
connectivité IP.
sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est privée (je ne vois pas ce que ça signifie exactement).
Rien de pertient.
Ça veut probablement dire que tu ne peux pas y accéder à partir du réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G.
(...)
Bref, ton problème se situe probablement coté Android et pas coté PC.
N'importe quoi. C'est l'adresse IP de la machine elle-même, qui est donc une adresse locale du point de vue du système. Les communications avec une adresse locale ne sortent pas de la machine. Peu importe que cette adresse soit attribuée par un point d'accès Android ou n'importe quoi d'autre. D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de connectivité IP.
Doug713705
Le 09-08-2017, Pascal Hambourg nous expliquait dans fr.comp.os.linux.configuration (<omfkgv$11d8$) :
Le 08/08/2017 à 21:32, Doug713705 a écrit :
Le 07-08-2017, Une Bévue nous expliquait dans
sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est privée (je ne vois pas ce que ça signifie exactement).
Rien de pertient.
Ça veut probablement dire que tu ne peux pas y accéder à partir du réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G.
(...)
Bref, ton problème se situe probablement coté Android et pas coté PC.
N'importe quoi. C'est l'adresse IP de la machine elle-même, qui est donc une adresse locale du point de vue du système.
Ce n'est pas comme ça que j'ai compris la chose. J'avais compris tant bien que mal qu'Une Bévue tentait de se connecter sur son portable depuis son appareil Android et que ce dernier lui disait que l'adresse IP qu'il tente d'atteindre était une adresse privée (genre de message d'erreur à la con pour dire "injoignable car non routable").
Les communications avec une adresse locale ne sortent pas de la machine. Peu importe que cette adresse soit attribuée par un point d'accès Android ou n'importe quoi d'autre.
On est bien d'accod mais du coup ça veut aussi dire que son problème n'est pas lié au fait qu'il soit connecté sur un AP. Le diagnostic de départ est donc faux (ça marche derrière ma freebox). S'il tente de se connecter sur sa machine depuis la même machine et que ça ne fonctionne pas derrière un AP Wifi, ça ne devrait pas non plus fonctionner derrière sa freebox.
D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de connectivité IP.
Je pense que les explications sont confuses et qu'il n'a pas *vraiment* été déterminé depuis quelle machine il tente de se connecter sur son portable. Il nous faudrait donc les sorties de ifconfig de: - la machine hébergeant le websocket serveur - la machine tentant de s'y connecter pour être sûrs Faire écouter le websocket sur l'interface locale (127.0.0.1) et tenter de s'y connecter depuis la machine hébergeant le websocket serveur permettrait également de déterminer si l'applicatif et/ou l'éventuel firewall est en cause. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 09-08-2017, Pascal Hambourg nous expliquait dans
fr.comp.os.linux.configuration
(<omfkgv$11d8$1@saria.nerim.net>) :
Le 08/08/2017 à 21:32, Doug713705 a écrit :
Le 07-08-2017, Une Bévue nous expliquait dans
sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est
privée (je ne vois pas ce que ça signifie exactement).
Rien de pertient.
Ça veut probablement dire que tu ne peux pas y accéder à partir du
réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G.
(...)
Bref, ton problème se situe probablement coté Android et pas coté PC.
N'importe quoi. C'est l'adresse IP de la machine elle-même, qui est donc
une adresse locale du point de vue du système.
Ce n'est pas comme ça que j'ai compris la chose. J'avais compris tant
bien que mal qu'Une Bévue tentait de se connecter sur son portable
depuis son appareil Android et que ce dernier lui disait que l'adresse
IP qu'il tente d'atteindre était une adresse privée (genre de message
d'erreur à la con pour dire "injoignable car non routable").
Les communications avec une adresse locale ne sortent pas de la machine.
Peu importe que cette adresse soit attribuée par un point d'accès Android
ou n'importe quoi d'autre.
On est bien d'accod mais du coup ça veut aussi dire que son problème
n'est pas lié au fait qu'il soit connecté sur un AP. Le diagnostic de
départ est donc faux (ça marche derrière ma freebox).
S'il tente de se connecter sur sa machine depuis la même machine et que
ça ne fonctionne pas derrière un AP Wifi, ça ne devrait pas non plus
fonctionner derrière sa freebox.
D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de
connectivité IP.
Je pense que les explications sont confuses et qu'il n'a pas *vraiment*
été déterminé depuis quelle machine il tente de se connecter sur son
portable.
Il nous faudrait donc les sorties de ifconfig de:
- la machine hébergeant le websocket serveur
- la machine tentant de s'y connecter pour être sûrs
Faire écouter le websocket sur l'interface locale (127.0.0.1) et tenter de s'y
connecter depuis la machine hébergeant le websocket serveur permettrait
également de déterminer si l'applicatif et/ou l'éventuel firewall est en cause.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 09-08-2017, Pascal Hambourg nous expliquait dans fr.comp.os.linux.configuration (<omfkgv$11d8$) :
Le 08/08/2017 à 21:32, Doug713705 a écrit :
Le 07-08-2017, Une Bévue nous expliquait dans
sur une liste Android, il m'est dit que l'adresse '192.168.43.32' est privée (je ne vois pas ce que ça signifie exactement).
Rien de pertient.
Ça veut probablement dire que tu ne peux pas y accéder à partir du réseau sur lequel est connecté ton android, typiquement le réseau 3G/4G.
(...)
Bref, ton problème se situe probablement coté Android et pas coté PC.
N'importe quoi. C'est l'adresse IP de la machine elle-même, qui est donc une adresse locale du point de vue du système.
Ce n'est pas comme ça que j'ai compris la chose. J'avais compris tant bien que mal qu'Une Bévue tentait de se connecter sur son portable depuis son appareil Android et que ce dernier lui disait que l'adresse IP qu'il tente d'atteindre était une adresse privée (genre de message d'erreur à la con pour dire "injoignable car non routable").
Les communications avec une adresse locale ne sortent pas de la machine. Peu importe que cette adresse soit attribuée par un point d'accès Android ou n'importe quoi d'autre.
On est bien d'accod mais du coup ça veut aussi dire que son problème n'est pas lié au fait qu'il soit connecté sur un AP. Le diagnostic de départ est donc faux (ça marche derrière ma freebox). S'il tente de se connecter sur sa machine depuis la même machine et que ça ne fonctionne pas derrière un AP Wifi, ça ne devrait pas non plus fonctionner derrière sa freebox.
D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de connectivité IP.
Je pense que les explications sont confuses et qu'il n'a pas *vraiment* été déterminé depuis quelle machine il tente de se connecter sur son portable. Il nous faudrait donc les sorties de ifconfig de: - la machine hébergeant le websocket serveur - la machine tentant de s'y connecter pour être sûrs Faire écouter le websocket sur l'interface locale (127.0.0.1) et tenter de s'y connecter depuis la machine hébergeant le websocket serveur permettrait également de déterminer si l'applicatif et/ou l'éventuel firewall est en cause. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Doug713705
Le 10-08-2017, Doug713705 nous expliquait dans fr.comp.os.linux.configuration (<omh4of$3s1$) :
Le 09-08-2017, Pascal Hambourg nous expliquait dans fr.comp.os.linux.configuration (<omfkgv$11d8$) : Ce n'est pas comme ça que j'ai compris la chose. J'avais compris tant bien que mal qu'Une Bévue tentait de se connecter sur son portable depuis son appareil Android et que ce dernier lui disait que l'adresse IP qu'il tente d'atteindre était une adresse privée (genre de message d'erreur à la con pour dire "injoignable car non routable").
Je viens de relire l'enfilade et effectivement il me manquait des informations. Si la connexion se fait avec telnet et pas avec le navigateur c'est probablement le navigateur qui est en cause. Ça pourrait ressembler à un problème de configuration de proxy. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 10-08-2017, Doug713705 nous expliquait dans
fr.comp.os.linux.configuration
(<omh4of$3s1$1@golgoth99.redatomik.org>) :
Le 09-08-2017, Pascal Hambourg nous expliquait dans
fr.comp.os.linux.configuration
(<omfkgv$11d8$1@saria.nerim.net>) :
Ce n'est pas comme ça que j'ai compris la chose. J'avais compris tant
bien que mal qu'Une Bévue tentait de se connecter sur son portable
depuis son appareil Android et que ce dernier lui disait que l'adresse
IP qu'il tente d'atteindre était une adresse privée (genre de message
d'erreur à la con pour dire "injoignable car non routable").
Je viens de relire l'enfilade et effectivement il me manquait des
informations.
Si la connexion se fait avec telnet et pas avec le navigateur c'est
probablement le navigateur qui est en cause. Ça pourrait ressembler à un
problème de configuration de proxy.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 10-08-2017, Doug713705 nous expliquait dans fr.comp.os.linux.configuration (<omh4of$3s1$) :
Le 09-08-2017, Pascal Hambourg nous expliquait dans fr.comp.os.linux.configuration (<omfkgv$11d8$) : Ce n'est pas comme ça que j'ai compris la chose. J'avais compris tant bien que mal qu'Une Bévue tentait de se connecter sur son portable depuis son appareil Android et que ce dernier lui disait que l'adresse IP qu'il tente d'atteindre était une adresse privée (genre de message d'erreur à la con pour dire "injoignable car non routable").
Je viens de relire l'enfilade et effectivement il me manquait des informations. Si la connexion se fait avec telnet et pas avec le navigateur c'est probablement le navigateur qui est en cause. Ça pourrait ressembler à un problème de configuration de proxy. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Sergio
Le 10/08/2017 à 10:24, Doug713705 a écrit :
Je viens de relire l'enfilade et effectivement il me manquait des informations. Si la connexion se fait avec telnet et pas avec le navigateur c'est probablement le navigateur qui est en cause. Ça pourrait ressembler à un problème de configuration de proxy.
...Ou d'acharnement du navigateur : Dans Chrome, par exemple, si je tape "192.168.1.1" (l'adresse de ma box...), il me lance la recherche gogol de 192.168.1.1. Si je lui précise "http://192.168.1.1", alors il m'insulte parce que la connexion n'est pas sécurisée, que le certificat n'est pas bon etc. -- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 10/08/2017 à 10:24, Doug713705 a écrit :
Je viens de relire l'enfilade et effectivement il me manquait des
informations.
Si la connexion se fait avec telnet et pas avec le navigateur c'est
probablement le navigateur qui est en cause. Ça pourrait ressembler à un
problème de configuration de proxy.
...Ou d'acharnement du navigateur : Dans Chrome, par exemple, si je tape "192.168.1.1" (l'adresse de ma box...), il me lance la
recherche gogol de 192.168.1.1. Si je lui précise "http://192.168.1.1", alors il m'insulte parce que la connexion n'est pas
sécurisée, que le certificat n'est pas bon etc.
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Je viens de relire l'enfilade et effectivement il me manquait des informations. Si la connexion se fait avec telnet et pas avec le navigateur c'est probablement le navigateur qui est en cause. Ça pourrait ressembler à un problème de configuration de proxy.
...Ou d'acharnement du navigateur : Dans Chrome, par exemple, si je tape "192.168.1.1" (l'adresse de ma box...), il me lance la recherche gogol de 192.168.1.1. Si je lui précise "http://192.168.1.1", alors il m'insulte parce que la connexion n'est pas sécurisée, que le certificat n'est pas bon etc. -- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Une B=c3=a9vue
Le 09/08/2017 à 20:33, Pascal Hambourg a écrit :
D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de connectivité IP.
je suis d'accord
Le 09/08/2017 à 20:33, Pascal Hambourg a écrit :
D'ailleurs telnet se connecte très bien. Ce n'est pas un problème de
connectivité IP.
