0

I am setting up Raspbian Jessie on a Raspberry Pi 2 B+ board and experiencing problems with configuring a static IP. At this point I've spent about half a day googling the problem and it would seem that I'm not the only one having issues with this. Unfortunately the responses to the posts I've found all seem to say the same thing; either don't modify /etc/network/interfaces and configure your static IP through /etc/dhcpcd.conf or disable dhcpcd and configure this through /etc/network/interfaces. I've tried both methods (for reference this article had the most complete instruction: How do I set up networking/WiFi/static IP address? ) and neither method works. Adding the static IP using either process results in a network setup that can access other machines on the same LAN segment but nothing past the gateway router. My question here is how do I resolve this problem so that I can use a static IP without loosing internet access?

Details:

If the network files (/etc/network/interfaces & /etc/dhcpcd.conf) are left alone after a clean install of Raspbian Jessie than the network connection works as expected using DHCP. Output from the ifconfig command showing this setup is below:

$ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:85:61:60
          inet addr:192.168.1.165  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::da73:8269:d6f0:5728/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28139 errors:0 dropped:0 overruns:0 frame:0
          TX packets:609 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2253500 (2.1 MiB)  TX bytes:127490 (124.5 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:200 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:16656 (16.2 KiB)  TX bytes:16656 (16.2 KiB)

Attempting to ping an internet address like google.com also works:

$ ping -c 3 google.com
PING google.com (172.217.12.78) 56(84) bytes of data.
64 bytes from dfw28s05-in-f14.1e100.net (172.217.12.78): icmp_seq=1 ttl=53 time=32.9 ms
64 bytes from dfw28s05-in-f14.1e100.net (172.217.12.78): icmp_seq=2 ttl=53 time=49.6 ms
64 bytes from dfw28s05-in-f14.1e100.net (172.217.12.78): icmp_seq=3 ttl=53 time=33.3 ms

--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 32.982/38.657/49.625/7.759 ms

Output from the route command at this time is as follows:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0

Also if I run the 'traceroute' command under this configuration I get the following (clipped to just the top few results for comparison with a later traceroute run):

$ traceroute google.com
traceroute to google.com (172.217.6.142), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.644 ms  0.426 ms  0.503 ms
 2  96.120.17.93 (96.120.17.93)  9.263 ms  15.719 ms  14.508 ms
 3  68.85.252.217 (68.85.252.217)  15.308 ms  15.187 ms  15.211 ms
 4  68.85.246.169 (68.85.246.169)  15.095 ms  14.974ms  14.995 ms
 5  68.85.87.245 (68.85.87.245)  16.865 ms  15.714 ms  16.622 ms 

Next I try to change the networking configuration to use a static IP. This is done by adding the lines below to the end of the /etc/dhcpcd.conf file (NO changes were made to /etc/network/interfaces):

interface eth0
static ip_address=192.168.1.20/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1

After making these changes I reboot the raspberry pi and upon restart I have a functioning network configuration that will ONLY allow connections to a computer on my LAN. Below is the ifconfig output after changing to use the static IP.

$ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:85:61:60
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::da73:8269:d6f0:5728/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:689 errors:0 dropped:0 overruns:0 frame:0
          TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:57073 (55.7 KiB)  TX bytes:12174 (11.8 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:72 errors:0 dropped:0 overruns:0 frame:0
          TX packets:72 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:6288 (6.1 KiB)  TX bytes:6288 (6.1 KiB)

Here I ping the gateway router (192.168.1.1) and another Debian machine on the same LAN segment (192.168.1.9); both machines can be reached:

$ ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.764 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.652 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.636 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2098ms
rtt min/avg/max/mdev = 0.636/0.684/0.764/0.056 ms

$ ping -c 3 192.168.1.9
PING 192.168.1.9 (192.168.1.9) 56(84) bytes of data.
64 bytes from 192.168.1.9: icmp_seq=1 ttl=64 time=1.06 ms
64 bytes from 192.168.1.9: icmp_seq=2 ttl=64 time=0.536 ms
64 bytes from 192.168.1.9: icmp_seq=3 ttl=64 time=0.532 ms

--- 192.168.1.9 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2012ms
rtt min/avg/max/mdev = 0.532/0.710/1.064/0.251 ms

However once I try to ping something that is on a different network segment (Google in this case) I can't reach it.

$ ping -c 3 google.com
PING google.com (172.217.6.142) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Destination Port Unreachable
From 192.168.1.1 icmp_seq=2 Destination Port Unreachable
From 192.168.1.1 icmp_seq=3 Destination Port Unreachable

--- google.com ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2053ms

The issue does not appear to be related to DNS as I can resolve host strings just fine:

$ nslookup google.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.12.78

Here are outputs from the 'route' and 'traceroute' commands. Notice that something funny is happening with traceroute as it only goes as far as the gateway router now:

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
192.168.1.0     *               255.255.255.0   U     202    0        0 eth0

$ traceroute google.com
traceroute to google.com (172.217.12.78), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.732 ms  0.581 ms  0.482 ms
 2  192.168.1.1 (192.168.1.1)  0.590 ms  0.497 ms  0.625 ms

The network configuration I added to /etc/dhcpcd.conf is also in use by two other Ubuntu machines that are on the same LAN segment; neither of these machines has any difficulty accessing the internet through the gateway router.

If anyone can shed some light on what is causing this issue and how I can resolve it I would appreciate their insight. Thanks!


Additional Info:

Raspbian Image: 2017-07-05-raspbian-jessie.zip

File: /etc/dhcpcd.conf (following static IP update):

# A sample configuration for dhcpcd.
# 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.
#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
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname

interface eth0
static ip_address=192.168.1.20/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1

File: /etc/network/interfaces:

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
0

Your DNS is fine, as your home router"s proxy DNS does resolve correctly, as does your RPi. You can see this from your ping attempt: it correctly resolves.

So, this puts the IP layer back in focus: please notice that the ping fails already at your home router. So this looks like your home router denies you access to the Internet. Could it be that it blocks traffic from IPs not assigned via DHCPv4? Can you check your home router configuration?

  • Ugh! Yes, this is absolutely correct. I had a firewall rule in effect that I had completely forgotten about which was responsible for blocking the traffic once a static IP was assigned. After modifying the rule to allow traffic for my pi I can access the internet without any issue. – James Hurley Jul 21 '17 at 12:28
  • Thanks BTW for calling out something I should've checked early on with this. I have two other Linux machines on the same LAN segment which both have static IPs and neither one has an issue connecting to the internet (the firewall rule of course allows both of these other machines). Since I was applying the same network settings I was focused in on this being a problem with the pi instead of double checking the router. – James Hurley Jul 21 '17 at 12:30
  • Never mind, you're welcome. And I've learned that there's another trap to check for in existing installations. – TheDiveO Jul 21 '17 at 14:02

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.