I installed Ubuntu 18.10 clean.
Connected to WIFI network.
The connection manager shows that a connection is established.
Next step is to login.
However, login page does not appear, as if there was no connection.
RDP over LAN, works well.
Realtek external adapter - same result.
Network proxy is off.
Connectivity checking has been disabled from the beginning.
Ubuntu 15, MINT 16, Debian, All Windows - XP, 7,8,10 work fine both in VM and on real hardware.
Tried installing to VMware. Used LAN as bridge - no luck. Directly connected USB adapter to VM - fail.
All the above steps - network connection established, DHCP addresses received.
All OS mentioned above tested on the very same hardware.
The problem resides in Ubuntu.
I tried UNITY 18.04 - no changes.
There was an information here about Captiva login problems in UBUNTU 17.
There is a chance, that the reason is common.
This network uses RADIUS server for authentication.
ping 8.8.8.8 (8.8.8.8) 56(84) bytes of data
From 192.168.11.1 icmp_sec=1 Destination Net Prohibited
......
ping 192.168.11.1 ends the same way
192.168.11.1 is the gateway and DNS
DNSMASQ installation did not make any difference.
I put 192.168.11.1 into the address bar. Windows replaced it with 'hotspot/login' and went on with the page opening.
Ubuntu 18 replaced IP with the same URL then stopped.
I made a virtual network with Windows 2008 R2 server as a router with NAT.
Connected Ubuntu to this network.
Made Win Server logged on to the network.
Only then I had internet connection in Ubuntu.
It was possible to open all other websites then.
But NOT the LOGIN PAGE
It displayed Google search results for ‘hotspot’ instead.
Windows behind this NAT displays the login page when the 2008 server is logged on, and when it is not.
UBUNTU does not display login page even when Server is logged on.
I saved LOGIN page in Windows.
Logged off.
Disabled WIFI.
Opened downloaded page in the browser - it did not look original - no styles etc.
Switched WIFI on.
Reloaded page.
There is a link to a LOCAL COPY of the page.
Page reloaded successfully.
I copied the page into UBUNTU.
Guess.
Right - it did not reload.
curl -v 192.168.11.1
Rebuilt URL to: 192.168.11.1/
*Trying 192.168.11.1...
* TCP_NODELAY set
*Connected to 192.168.11.1
(192.168.11.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.11.1
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 302 Hotspot redirect
< Cache-Control: no-cache
< Connection: Keep-Alive
< Content-Length: 123
< Content-Type: text/html
< Date: Thu, 21 Mar 2019 18:51:19 GMT
< Expires: 0
< Location: http://hotspot./login
<
<html>
<head><title>Error 302: Hotspot redirect</title></head>
<body>
<h1>Error 302: Hotspot redirect</h1>
</body>
</html>
* Connection #0 to host 192.168.11.1 left intact
KALI Linux output
*Trying 192.168.11.1...
* TCP_NODELAY set
*Connected to 192.168.11.1
(192.168.11.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.11.1
> User-Agent: curl/7.63.0
> Accept: */*
>
< HTTP/1.1 302 Hotspot redirect
< Cache-Control: no-cache
< Connection: Keep-Alive
< Content-Length: 123
< Content-Type: text/html
< Date: Thu, 21 Mar 2019 18:51:19 GMT
< Expires: 0
< Location: http://hotspot./login
<
<html>
<head><title>Error 302: Hotspot redirect</title></head>
<body>
<h1>Error 302: Hotspot redirect</h1>
</body>
</html>
* Connection #0 to host 192.168.11.1 left intact
Same, but it does show the login page
/etc/resolv.conf contents:
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through
the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different
way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes
of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
Replacing 127.0.0.53 with 192.168.11.1 or 8.8.8.8 solves the problem until reboot. When restarted 127.0.0.53 goes back.
Thanks to Ognjen.
Changing 'nameserver' to anything except 0.0.0.0 or 127.0.0..., even 192.168.0.1, which is not applicable for this network, makes system working.
resolvectl status
Global
LLMNR setting: no
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.11.1
DNS Servers: 192.168.11.1
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
.....
/run/systemd/resolve/resolv.conf
This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 192.168.11.1
As you see my DNS is in the system, but this does not help at all.
/etc/resolv.conf has been erased.
Static file has been created.
Following are the results after reboot.
# Generated by NetworkManager
search crew.local
nameserver 127.0.0.53
Debian 9.8 file contents
# Generated by NetworkManager
nameserver 192.168.11.1
It looks like this is the main cause of the problem.
nameserver 8.8.8.8
Thak you, @ognjen.
Your advice worked, but until reboot only. Another strange thing is that it does not matter what I put as 'nameserver' except 0.0.0.0 or 127.0.0... I have connection.
