Yes and appears to be using the proxy correctly, though the error message is a bit strange.
So if you’re getting DNS problems only on the phone, it could be a DHCP problem. Can you see your IP address, etcs and DNS host on the phone?
This is getting interesting.
So I’m using WiFi Monitor on my phone to stat my connection.
My pi is in vpn with:
- 89.36.224.11 as the assigned vpn ip
- 188.192.11.131 as the local ip
My phone says:
- external ip : 188.192.11.131 (so apparently no VPN…)
- internal ip : 192.168.1.2 (assigned by dhcp I assume)
- default gateway: 192.168.1.1 (ok I guess)
- dns1: 0.0.0.0
- dns2: 0.0.0.0
- dhcp server: 192.168.1.1 (ok I guess)
Looks like the dns servers are not set and the tunnelling through vpn is not working…
Update: After a couple of minutes, the external ip address in WiFi Monitor on my phone field went blank. Nothing is displayed.
The 188 number doesn’t make a lot of sense to me, but let’s stick with DNS for now.
The two DNS addresses are zeroed. Since this isn’t a routing table, it’s effectively blank. So it looks like DHCP isn’t doing its stuff. Clearly, the next step must be to try, if possible, to manually set a DNS IP address on the phone.
… works if I set up a static IP. This is already a major win, thank you.
But I would really like to get dhcp running, if possible. What else could we try?
EDIT: I mean dhcp still assigns a correct automatic IP (192.168.1.2). So at least that part works, right?
EDIT2: Seems like my external IP from my phone is the one from VPN! Awesome.
It’s already running. just sub-optimally. 
I’ll need to do a bit of research to see what’s happening in the background.
1 Like
But 188.192.11.131 is your real IP address, so how is it being seen?
I added the following content to /etc/resolv.conf:
nameserver 1.1.1.1
nameserver 8.8.8.8
It gets rewritten to nameserver 127.0.0.1 each time the vpn client connects.
I then tried:
➜ ~ sudo chattr +i /etc/resolv.conf
chattr: Operation not supported while reading flags on /etc/resolv.conf
➜ ~ sudo chattr +i "$(realpath /etc/resolv.conf)"
chattr: Inappropriate ioctl for device while reading flags on /run/resolvconf/resolv.con
If you’re using dnsproxy=yes, the comment in /etc/connman.prefs says that /etc/resolv.conf will be set to 127.0.0.1. So leave it as it is.
As we know, 127.0.0.1 on its own isn’t going to resolve anything, so something else must know what is/are the IP address(es) of the DNS resolver(s). That something has to be connman.
So we need to try a few things in connman:
connmanctl
services
You should see something listed for wifi and possibly something for tethering. We need to assign DNS addresses. First to wifi and, if that doesn’t work, try the tether service, assuming it exists.
config <service name> --nameservers 8.8.8.8 1.1.1.1
quit
You’ll probably need to restart things so that the new details are propagated.
Well, nothing for tether nor for wifi…
➜ dispatcher.d connmanctl
Error getting VPN connections: Unit connman-vpn.service not found.connmanctl> services
*AR Wired ethernet_b827eb543efd_cable
This is uncharted waters for me. Are you able to switch off tethering temporarily? Perhaps wifi will then appear.
I tried this, still no net on the phone using dhcp:
➜ ~ sudo bash -c "cat <<EOF >>/etc/resolvconf/resolv.conf.d/head
nameserver 8.8.8.8
nameserver 1.1.1.1
EOF"
➜ ~ sudo resolvconf -u
➜ ~ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 127.0.0.1
I turned off tethering. Now, the connmanctl services lists my neightbours’ wifis 
connmanctl> services
*AO Wired ethernet_b827eb543efd_cable
wifi_b827eb016ba8_hidden_managed_psk
KDG-EEBB4 wifi_b827eb016ba8_4b44472d4545424234_managed_psk
FRITZ!Box 7312 wifi_b827eb016ba8_465249545a21426f782037333132_managed_psk
FRITZ!Box 6490 Cable wifi_b827eb016ba8_465249545a21426f782036343930204361626c65_managed_psk
Vodafone Hotspot wifi_b827eb016ba8_566f6461666f6e6520486f7473706f74_managed_none
DIRECT-53-HP OfficeJet 3830 wifi_b827eb016ba8_4449524543542d35332d4850204f66666963654a65742033383330_managed_psk
WLAN-JN82KN wifi_b827eb016ba8_574c414e2d4a4e38324b4e_managed_psk
FRITZ wifi_b827eb016ba8_465249545a_managed_psk
As I said, you should leave /etc/resolv.conf alone. Connman is using a DNS proxy, so I’m guessing it won’t use /etc/resolv.conf.
Out of interest, how did/does the Pi get its DNS resolvers? From the router or are they statically configured on the Pi? If from the router, is the local DNS resolver the router itself?
Could you try the config <service name> --nameservers 8.8.8.8 1.1.1.1 for the ethernet interface?
I’m using a standard OSMC Kernel: 4.14.78-4-osmc, nothing custom.
My router had the DNS 1 & 2 resolvers both set to 0.0.0.0. I changed that to 8.8.8.8 and 1.1.1.1. Then rebooted. Nothing changed.
Also, this didn’t work:
connmanctl> config ethernet_b827eb543efd_cable --nameservers 8.8.8.8 1.1.1.1
EDIT: I mean my DHCP Primary & Secondary DNS were both 0.0.0.0.
EDIT2: The Pi is using DHCP from the router, so gets assigned an IP automatically.
Perhaps you misunderstood. The question was to do with how the Pi obtains its DNS resolvers (eg 1.1.1.1 and 8.8.8.8). Often people set these addresses only in the router and then, using DHCP, tell all local devices to use the router as ithe DNS resolver. Alternatively, perhaps you statically configured the Pi so that it already has the DNS resolvers. It’s not clear to me how the Pi obtains its DNS resolvers.
So are you saying that the Pi was using DNS addresses of 0.0.0.0?
You’ll need to reboot the pi and reconnect the phone for this to take effect.
My router has a Network tab which contains Primary and Secondary entries for the DNS. These are read-only and how they are set is a mystery to me.
The router also has a DHCP tab which contains separate entries for Primary and Secondary DNSes. It is these last two which I set to 8.8.8.8 and 1.1.1.1.
I also rebooted the pi, no luck. My WiFi Monitor app on the phone still says 0.0.0.0 for both DNS1 and DNS2.
Ok, one step at a time.
Without any tethering enabled, do you see nameservers 1.1.1.1 and 8.8.8.8 in /etc/resolv.conf – and nothing else?
Does running connmanctl services ethernet_b827eb543efd_cable show the two DNS resolvers listed under Nameservers.Configuration?
Returning to connmanctl does running enable wifi and scan wifi caused your wifi to appear when you run services?
These DNSes were added in reply #33. The 127.0.0.1 localhost get added automatically.
➜ ~ cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 127.0.0.1
➜ ~ connmanctl services ethernet_b827eb543efd_cable
/net/connman/service/ethernet_b827eb543efd_cable
Type = ethernet
Security = [ ]
State = online
Favorite = True
Immutable = False
AutoConnect = True
Name = Wired
Ethernet = [ Method=auto, Interface=eth0, Address=B8:27:EB:54:3E:FD, MTU=1500 ]
IPv4 = [ Method=dhcp, Address=192.168.0.101, Netmask=255.255.255.0, Gateway=192.168.0.1 ]
IPv4.Configuration = [ Method=dhcp ]
IPv6 = [ ]
IPv6.Configuration = [ Method=off ]
Nameservers = [ 8.8.8.8, 1.1.1.1 ]
Nameservers.Configuration = [ 8.8.8.8, 1.1.1.1 ]
Timeservers = [ ]
Timeservers.Configuration = [ ]
Domains = [ ]
Domains.Configuration = [ ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
mDNS = False
mDNS.Configuration = False
Provider = [ ]
➜ ~ connmanctl
connmanctl> enable wifi
Error wifi: Already enabled
connmanctl> scan wifi
Error /net/connman/technology/wifi: Device or resource busy
connmanctl> services
*AO Wired ethernet_b827eb543efd_cable
So it looks like it’s still being used by tethering. You probably need to switch off the dnsproxy setting and reset other tethering-related stuff, such as in /var/lib/connman/settings. Once that’s done, we need to see if the Pi is now picking up the DNS details from the router. You can easily test this by temporarily choosing two different IP addresses on the router and rebooting the Pi.
Unfortunately, I’m out of time for today.