Je suis désolé si cela semble être le dixième doublon, mais aucune des réponses fournies dans les autres cas n'a résolu mon problème.
J'essaie d'utiliser un WIFI public, comme je l'ai fait avec succès il y a deux jours. La procédure normale est la suivante:
Maintenant, je ne vais plus au-delà de l’étape 2. Je suis sur une machine à double démarrage. Je peux accéder à Internet très bien avec Widows 10, mais pas avec Ubuntu 18.04.
Sous Windows, je reçois :
SSID: SEC Wi-Fi
Protocol: 802.11n
Security type: Open
Network band: 2.4 GHz
Network channel: 6
IPv4 address: 192.168.33.154
IPv4 DNS servers: 192.168.0.1
192.168.0.1
Manufacturer: Intel Corporation
Description: Intel(R) Dual Band Wireless-AC 7260
Driver version: 17.15.0.5
Physical address (MAC): 0C-8B-FD-75-00-D5
Windows IP Configuration
Host Name . . . . . . . . . . . . : DESKTOP-G83LKQ1
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : fdxtended.com
Wireless LAN adapter Wi-Fi:
Connection-specific DNS Suffix . : fdxtended.com
Description . . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 7260
Physical Address. . . . . . . . . : 0C-8B-FD-75-00-D5
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::656c:ef48:d71c:420e%17(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.33.154(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.128.0
Lease Obtained. . . . . . . . . . : Wednesday, 13 June 2018 17:17:44
Lease Expires . . . . . . . . . . : Wednesday, 13 June 2018 23:18:53
Default Gateway . . . . . . . . . : 192.168.0.1
DHCP Server . . . . . . . . . . . : 192.168.0.1
DHCPv6 IAID . . . . . . . . . . . : 286034941
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-22-A4-A4-F1-A0-D3-C1-9C-CD-E0
DNS Servers . . . . . . . . . . . : 192.168.0.1
192.168.0.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Sous Linux, je reçois :
ifconfig
name__:
wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.33.154 netmask 255.255.128.0 broadcast 192.168.127.255
inet6 fe80::499:60a3:aae7:a075 prefixlen 64 scopeid 0x20<link>
ether 0c:8b:fd:75:00:d5 txqueuelen 1000 (Ethernet)
RX packets 33578 bytes 19389454 (19.3 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 23622 bytes 3363483 (3.3 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
systemd-resolve --status
:
Global
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 3 (wlo1)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.0.1
DNS Domain: fdxtended.com
curl -v example.com
:
* Rebuilt URL to: example.com/
* Could not resolve Host: example.com
* Closing connection 0
curl: (6) Could not resolve Host: example.com
Des astuces pour accéder à Internet? J'apprécierai vraiment cela.
Édite
Donc, en gros, Ubuntu bloque toutes les redirections. J'ai posé une question plus précise ici: La transmission DNS est bloquée dans un WIFI spécifique
(Un) Heureusement, je ne suis plus à la place du WIFI mentionné, ce qui signifie que pour le moment je ne peux pas tester et donc accepter aucune des réponses ci-dessous.
J'ai eu le même problème.
J'ai réussi à me connecter en visitant la page de connexion à l'adresse suivante: https://1.1.1.1/login.html
Une fois connecté, je me trouvais dans la même situation qu'avant, mais le problème n'était que DNS:
curl -v example.com
a renvoyé, après un certain temps, "Impossible de résoudre Host: example.com".ping 8.8.8.8
avec succès.J'ai ajouté 8.8.8.8 à la liste de serveurs DNS pour ma connexion WiFi, en procédant comme suit:
Sudo service network-manager restart
Et cela a fonctionné pour moi.
systemd-resolve --status
renvoie maintenant deux serveurs DNS pour la connexion WiFi, le premier est le DNS attribué par le réseau, le second est 8.8.8.8
J'espère que cela peut aider.
Internet was not working
Captive Login Page did not show up automatically. No browser shows that page.
Wifi icon was a question mark ( ? )
Ce qui suit m'a aidé à résoudre ce problème sur une installation standard d'Ubuntu 18.04.
Solution 1:
Paramètres> Confidentialité> Contrôle de la connectivité> Désactivé.
Ce qui précède est suffisant pour afficher la page de connexion captive de nombreux réseaux wifi. Cependant, certains (par exemple, le gwr sur le train wifi) aussi nécessitent la solution 2:
Paramètres> Wi-Fi> sélectionnez les paramètres (cliquez sur l'icône de rouage) pour le réseau que vous essayez d'atteindre. Sélectionnez l'onglet IPv6. Pour la méthode IPv6, sélectionnez "Automatique, DHCP uniquement" (au lieu du paramètre par défaut "Automatique"). Cliquez sur Appliquer.
Cela peut aussi aider à faire:
Paramètres> Réseau> Proxy réseau - Désactivé. (Cliquez sur le bouton de configuration avec l'icône du rouage.)
Le problème est dû au démon résolu introduit dans 17.04. Cela rompt la transmission dans les pages captatives wifi. La solution présentée ici ne repose PAS sur les serveurs de noms de Google. La solution est de remplacer résolue par dnsmasq, comme cela a été utilisé auparavant, et peut être trouvée ici:
Je me suis heurté à ce problème récemment et je ne suis pas sûr de ce qui l’a causé, mais la suggestion de naviguer sur le portail captif IP a fait perdre quelque chose à mon cerveau. Au début, j’ai tenté d’envoyer une IP externe à ping 8.8.8.8
, mais l’équipe de sécurité du réseau a correctement verrouillé cette adresse. Ensuite, j'ai couru ip route
pour voir quelle adresse IP m'avait été attribuée et essayé d'accéder à la passerelle par défaut via https, mais j'ai reçu un message indiquant qu'il y avait une réponse vide qui m'a au moins prouvé qu'il y avait un serveur en train d'écouter, et quand je suis passé à http m'a correctement renvoyé à la page de connexion au portail captif.
La méthode rapide pour essayer ceci est xdg-open http://$(ip --oneline route get 8.8.8.8 | awk '{print $3}')
. Celui-ci trouve la passerelle par défaut et l’imprime, puis essaie de l’ouvrir dans votre navigateur par défaut.