Pi sourcing internet from Tethered iPhone

[Sassriverrat]

Good Evening,

I've been trying to "give" my Pi4 internet through my tethered iPhone. The Pi is headless, so here's what I've tried:

Method 1:

Share Internet Connection from "Apple Ethernet" to "Ethernet" (where the Pi is connected). I then used TFTPD64 to run a DHCP server (since windows wasn't doing it natively) and then once the pi was served an address, log into the Pi and run

Code: Select all

sudo apt update

for the first time. No avail.

Method 2:
Bridge "Apple Ethernet" to "Ethernet", use TFTPD64 to run a DHCP server that matched that of the IP given to the laptop, log into the pi with its assigned IP (that's on the same subnet), and then run the code.

Both times, I get a "failure" resolving 'ports.ubuntu.com' and always failing to fetch from the ubuntu.com repository. Anyone have some ideas or a workaround on this?

[fruitoftheloom]

Good Evening,

I've been trying to "give" my Pi4 internet through my tethered iPhone. The Pi is headless, so here's what I've tried:

Method 1:

Share Internet Connection from "Apple Ethernet" to "Ethernet" (where the Pi is connected). I then used TFTPD64 to run a DHCP server (since windows wasn't doing it natively) and then once the pi was served an address, log into the Pi and run

Code: Select all

sudo apt update

for the first time. No avail.

Method 2:
Bridge "Apple Ethernet" to "Ethernet", use TFTPD64 to run a DHCP server that matched that of the IP given to the laptop, log into the pi with its assigned IP (that's on the same subnet), and then run the code.

Both times, I get a "failure" resolving 'ports.ubuntu.com' and always failing to fetch from the ubuntu.com repository. Anyone have some ideas or a workaround on this?

You mention Windows and Ubuntu, confused.

If this unknown model of Raspberry Pi has built in Wireless and was running Raspbian Buster, would connect Wirelessly to your iPhone which had been set up as a Wireless Hotspot.

[epoch1970]

Internet Connection Sharing is a set of features where the device providing the service acts as a router.
The router starts, among other things, a DHCP server.
Remove your own DHCP server from the Pi.

Let the Pi connect as if it were connected to a regular Ethernet or WiFi network. In case the network interface created on the Pi doesn’t automatically get an IP address, you can explicitly start a DHCP client on it.

[Sassriverrat]

Sorry as I see there is a fair amount of confusion here.


The "host" is a windows 10 machine. It is acting as the DHCP server and is getting its internet via a tethered iphone. The windows 10 machine has TFTPD64 running to act as the DHCP server.

The pi should be getting internet but definitely refuses to let me run updates, giving me this
"Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 4397 (u nattended-upgr) - open (11: Resource temporarily unavailable)"

[rpdom]

That message say you have apt's unattended upgrades running in the background (probably as a cron job). That's not usually installed by default in Raspbian???

I suspect you don't have a route to the internet from your Pi through the Windows PC and iPhone.

You can check on the Pi with a few commands:

Code: Select all

ip addr
ip route
cat /etc/resolv.conf
ping -c 1 8.8.8
ping -c 1 google.com

Try running each of those in a terminal/on the command line, copy the results and paste the whole lot back here.

[Sassriverrat]

You're right, I don't think it's connected. Ideas here? In this connection scenario, I "shared' the connection, restarted the computer, and then ran TFTPD64 as a DHCP server for the Pi's LAN connection.

Code: Select all

ubuntu@ubuntu:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul                                                  t qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group defa                                                  ult qlen 1000
    link/ether dc:a6:32:25:af:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.137.2/24 brd 192.168.137.255 scope global dynamic eth0
       valid_lft 172480sec preferred_lft 172480sec
    inet6 fe80::dea6:32ff:fe25:af5d/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qle                                                  n 1000
    link/ether dc:a6:32:25:af:5e brd ff:ff:ff:ff:ff:ff
ubuntu@ubuntu:~$ ip route
default via 192.168.137.1 dev eth0 proto dhcp src 192.168.137.2 metric 100
192.168.137.0/24 dev eth0 proto kernel scope link src 192.168.137.2
192.168.137.1 dev eth0 proto dhcp scope link src 192.168.137.2 metric 100
ubuntu@ubuntu:~$ cat /etc/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 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
options edns0
ubuntu@ubuntu:~$ ping -c 1 8.8.8
PING 8.8.8 (8.8.0.8) 56(84) bytes of data.

--- 8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

ubuntu@ubuntu:~$ ping -c 1 google.com

[rpdom]

Ah, I didn't realise you were running Ubuntu, not Raspbian. It is always worth stating that fact as most Pi users run Raspbian.

Ubuntu also tends to run a local DNSMasq to cache DNS lookups. That is the 127.0.0.53 entry in /etc/resolv.conf

You appear to have a valid IP address of 192.168.137.2, which is good.

Your default gateway is 192.168.137.1, which I assume is the Windows PC's IP address. That's fine.

So it looks like the Windows PC isn't routing traffic from the Pi to the iPhone.

[Sassriverrat]

Probably right.

yes the 192.168.137.1 is the PC.

Any ideas on the PC routing....

[fruitoftheloom]

Probably right.

yes the 192.168.137.1 is the PC.

Any ideas on the PC routing....

You need to ensure Windows 10 Connection Sharing is correctly set up. Microsoft have Help Sections....


...though the following is what I have done years ago:

Phone WiFi Hotspot acting as DHCP Server - Windows 10 WiFi acting as DHCP Slave - Connection Sharing - Windows 10 Ethernet acting as DHCP Server - Ubuntu Raspberry Pi Ethernet acting as DHCP Client

The above should be set up automatically with no manual IP addressing etal.

[rpdom]

Sorry, no. I don't Windows.

[Sassriverrat]

Probably right.

yes the 192.168.137.1 is the PC.

Any ideas on the PC routing....

You need to ensure Windows 10 Connection Sharing is correctly set up. Microsoft have Help Sections....


...though the following is what I have done years ago:

Phone WiFi Hotspot acting as DHCP Server - Windows 10 WiFi acting as DHCP Slave - Connection Sharing - Windows 10 Ethernet acting as DHCP Server - Ubuntu Raspberry Pi Ethernet acting as DHCP Client

The above should be set up automatically with no manual IP addressing etal.

Well aware of this....the issue lies within the Windows OS...it's been setup "correctly".

I wish there was a free version of connectify as connectify can share ethernet to ethernet.

[Sassriverrat]

solved....and not so fun.

I ended up "sharing'" the phone/usb connection with the wifi connection on the laptop, and then forcing windows to bridge the wifi interface and LAN interface (Pi) while using TFTPD64 to serve DHCP addresses for the pi.