0

I have an (from what I can tell trying to Google solutions on my own) unusual network configuration that I'm having trouble reconciling with my RPI.

Some background: My desktop PC used powerline ethernet to receive its internet connection. Usually this is passed through my router with the typical 192.168.x.x namespace. Currently however, I am running an ethernet cable from my pc all the way to the wall to directly receive internet at a different IP address. This situation is bizarre, and deserves its own networking thread, but the main takeaway is that there is no router serving internet to my PC at the moment.

I am using an ethernet cable and a TP-Link ethernet-usb converter to have a connection between the desktop PC and the RPI. Originally I was using a laptop with an ethernet port and things were functioning fine. I implemented wpa_supplicant with the router SSID and password and things worked fine. This was annoying however, hence the migration to desktop. I have shared my ethernet connection with the RPI:

enter image description here

As it stands, I can ssh into the Pi just fine, and can even ping the docker containers externally using the inet address returned by ifconfig. However the Pi is unable to ping 8.8.8.8 as the Destination Host Unreachable messasge is returned. This means I also cannot upgrade or update or install any packages, nor can my docker application reach outside the Pi, only take instructions through HTTP.

Lots of things seem different from threads I have read through trying to fix things up and I'll provide as much as I can.

From the desktop PC ipconfig -all:


   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : TP-LINK Gigabit Ethernet USB Adapter
   Physical Address. . . . . . . . . : 60-A4-B7-58-E0-41
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::ce6:e525:4a6:e861%18(Preferred)
   Autoconfiguration IPv4 Address. . : 169.254.232.97(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCPv6 IAID . . . . . . . . . . . : 509650103
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-24-87-D6-25-74-D4-35-E5-97-09
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

From RPi $ ifconfig:

        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:4e:a3:3d:05  txqueuelen 0  (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

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.33.4  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::a85b:1841:93db:f539  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:5f:c4:62  txqueuelen 1000  (Ethernet)
        RX packets 5793  bytes 467427 (456.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2666  bytes 206664 (201.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1355  bytes 129014 (125.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1355  bytes 129014 (125.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

From $ cat /etc/resolv.conf:

nameserver 192.168.0.1
nameserver 8.8.8.8

From $ cat /etc/dhcpcd.conf:

# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.137.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

From $ route -n, which seems odd:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     202    0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     202    0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

EDIT: I am a fool! At some point I switched the ethernet cable while troubleshooting static IP problems and did not switch which ethernet connection was being shared. Thus the RPI was sharing its network to the PC and the router was doing the same, instead of the RPI receiving a shared network from the PC. Classic move.

1 Answer 1

1

At some point I switched the ethernet cable while troubleshooting static IP problems and did not switch which ethernet connection was being shared. Thus the RPI was sharing its network to the PC and the router was doing the same, instead of the RPI receiving a shared network from the PC.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.