USB tethering the Raspberry Pi 5 to Android Phone (no DNS)

  • Thread starter Thread starter Swamp Thing
  • Start date Start date
AI Thread Summary
The Raspberry Pi 5 does not seamlessly tether to a mobile phone for internet access like previous models. When connecting via USB, the new interface appears as "wwan0" instead of "usb0." After running the command "dhclient wwan0," a new network interface is created, allowing for successful pings to IP addresses like 8.8.8.8, but DNS resolution fails. The existing resolv.conf file already includes 8.8.8.8 as a nameserver, but it does not retain changes across reboots or when toggling Wi-Fi. Suggestions include adding the phone's gateway IP (192.168.25.1) to resolv.conf, although it won't persist. The issue may stem from the Pi 5 recognizing the phone as a hardware modem, which complicates management by NetworkManager. A potential solution is to avoid using dhclient and instead configure NetworkManager to manage the connection. However, the current workaround is functioning adequately.
Swamp Thing
Insights Author
Messages
1,028
Reaction score
763
My previous Raspberry Pi boards were able to tether to a mobile phone and access the shared internet connection without having to do anything special except enabling USB tethering on the phone after connecting the cable.

Now on the Pi 5, this doesn't happen seamlessly. So I tried the instructions given here.

There was one minor difference from the article: after plugging in the cable, iwconfig is supposed to show a new item called usb0 (or usb1 etc), according to the article. In my case, the new item was called "wwan0".

Anyway, I followed the next step which was dhclient wwan0 where I replaced usb(x) with wwan0.

After this, a new network interface appeared in the ifconfig output.
Code: 
wwan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.25.16  netmask 255.255.255.0  broadcast 192.168.25.255
        inet6 fe80::30f8:45ff:febd:6e9b  prefixlen 64  scopeid 0x20<link>
        ether 32:f8:45:bd:6e:9b  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

At this point I was able to ping 8.8.8.8 through the tethered phone. I was also able to ping servers whose IP I found using the WiFi connection. However, ping (and the web browser) could not resolve DNS through the tethered connection. ping: www.aldaily.com: Temporary failure in name resolution

How can I set this connection to use say 8.8.8.8 as its DNS server? (or to use the phone's IP, which I found using nmap, which presumabley offers DNS)? Or alternatively, is there an entirely different and better way to set the whole thing up?
 
Computer science news on Phys.org
I've had this problem a bunch of times before on compute 4. You can ping 8.8.8.8 or 1.1.1.1 or whatever but you aren't able to completely resolve hostnames. So if you tried ping google.com or ping github.com you'd be unable to reach either.

What normally fixes this issue for me is viming into /etc/resolv.conf and explictly adding the nameserver on the pi. Have you tried that?
 
QuarkyMeson said:
I've had this problem a bunch of times before on compute 4. You can ping 8.8.8.8 or 1.1.1.1 or whatever but you aren't able to completely resolve hostnames. So if you tried ping google.com or ping github.com you'd be unable to reach either.

What normally fixes this issue for me is viming into /etc/resolv.conf and explictly adding the nameserver on the pi. Have you tried that?

I just looked at resolv.conf -- 8.8.8.8 was in there already...

Code: 
# Generated by NetworkManager
nameserver 8.8.8.8
 
Hmmmm. Can you check Networkmanager.conf? Does that look right?

This is the problem I have with linux, there are too many ways to skin this cat. If you aren't actually using NetworkManager then none of this matters. I've only ever used NetworkManager though because it's the simplest to deal with.
 
My NetworkManager.conf ...
Code: 
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no
 
Ok, so NetworkManager isn't managing this connection, but its still generating the resolv.conf... Can you try this?

In resolv.conf can you add the nameserver 192.168.25.1?

Can you also run ls -l /etc/resolv.conf?

Could you also tell me whats in /etc/network/interfaces?
 
Code: 
$ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 26 May 28 18:54 /etc/resolv.conf

/etc/network doesn't have anything called interfaces...
Code: 
$ ls -l /etc/network
total 16
drwxr-xr-x 2 root root 4096 Nov 19  2024 if-down.d
drwxr-xr-x 2 root root 4096 Nov 19  2024 if-post-down.d
drwxr-xr-x 2 root root 4096 Nov 19  2024 if-pre-up.d
drwxr-xr-x 2 root root 4096 Nov 19  2024 if-up.d


QuarkyMeson said:
In resolv.conf can you add the nameserver 192.168.25.1?
I will try this later and report...
 
resolv.conf doesn't retain its contents across reboots; it even changes when you turn on/off Wireless LAN.

With the wireless lan turned off, there are no entries in it. With Wifi turned ON, it looks like this...

# Generated by NetworkManager
nameserver 182.237.9.10
nameserver 8.8.8.8
nameserver fe80::1%wlan0

In fact, the mousepad text editor reports that the file was changed and offers to reload the contents when you toggle the wifi :smile:
 
Yeah, resolv.conf is regenerated on reboots/when networkmanager sees changes.
Did it start working after it was recreated?
 
  • #10
QuarkyMeson said:
Yeah, resolv.conf is regenerated on reboots/when networkmanager sees changes.
Did it start working after it was recreated?
Sadly, no.
 
  • #11
Try adding in the nameserver 192.168.25.1(assuming its same ip) to resolv.conf. It won't persist, but it might need to use phone gateway as nameserver. If this works though, I think the real fix is not use dhclient and use NetworkManager.
 
Last edited:
  • #12
Found this by searching for "dhclient dns server" and looking at the lower-ranked results that I had missed before... https://superuser.com/questions/944...tax-for-the-dhclient-conf-supersede-statement

Uncomment this line in dhclient.conf:
# prepend domain-name-servers 127.0.0.1

and add 8.8.8.8 (comma separated).

It's working now.

-------------------

QuarkyMeson said:
the real fix is not use dhclient and use NetworkManager.
nmcli con doesn't show wwan0 in the list of network connections. So this doesn't work:
Code: 
$ nmcli con mod "wwan0" ipv4.dns "8.8.8.8"
Error: unknown connection 'wwan0'

Edit:

I think the problem with NetworkManager in my case is that the Pi-5 sees the phone as a hardware modem rather than as a raw IP-over-USB connection. That is why it is named "wwan0" rather than "usb0". And NetworkManager can manage usb0 type connections but not wwan0 type modem interfaces.

From what I could learn online, my Pi-5 is probably running PPP over a serial USB link to the phone.:oops:
 
Last edited:
  • #13
Ah you'd want to do nmcli device status, make sure its there. If its unmanaged (yes probably) you'd have to tell networkmanager to manage it. Then you can create a profile for it.

Not really important since you already have a solution thats working for you.
 

Similar threads

[ Raspberry Pi or Android ] --> WiFi Router --> USB printer
Replies
3
Views
2K

Hot Threads

Recent Insights

Back
Top