dhcp obtains IP but no connection to Internet after upgrade to Jessie from Wheezy

Question

Device : Raspberry-Pi 2 Model B

I upgraded from Wheezy 7.11 to Jessie 8.0

I upgraded using :

apt-get update
apt-get upgrade
apt-get dist-upgrade

I am connected to my eth0 (Wired LAN) when I was upgraded the distribution (Wheezy -> Jessie)

But once I had Jessie installed the same eth0 interface on which I was connected to the Internet started giving this Error:

ping www.google.de
connect: Network is unreachable

I have not configured anything new in my /etc/network/interface files which I have have kept to the default in Jessie as mentioned in the this Thread on Raspberry Pi StackExchange

Here is my /etc/network/interface file:


   # 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

Acquiring IPv4 on Pi

I used the following options:

 sudo ifup eth0

and also

 sudo dhclient -v eth0

I get the IPv4 address which I can see from ifconfig eth0


eth0      Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:ff

          inet addr:10.10.155.187  Bcast:10.10.155.255  Mask:255.255.255.0
          inet6 addr: fe80::aabb:ccff:fedd:eeff/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5390 errors:0 dropped:344 overruns:0 frame:0
          TX packets:100 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1613922 (1.5 MiB)  TX bytes:9856 (9.6 KiB)

I can ping other network devices from my Pi but I cannot connect to the Internet. Why?

I believe some subtleties with the configuration changed right before jessie: http://raspberrypi.stackexchange.com/a/37921/5538 — goldilocks, Aug 05 '16 at 16:05
none of them help @goldilocks because I used the same ethernet connection to upgrade from wheezy to jessie and the moment I want to add a package once I reboot the internet connectivity fails — Shan-Desai, Aug 05 '16 at 16:08
also I do not use a static ip, I just hot plug it into my university network and things worked perfectly in wheezy! — Shan-Desai, Aug 05 '16 at 16:08
If you had actually read that you would note it is not *just* about static IPs. Anyway, it's proven very popular as it seems to solved a lot of people's problems. I can't say much about the topic though as I always just disable auto configured networking and use a system of my own devising, lol. You could try the basics of that to get a DHCP based connection manually: http://raspberrypi.stackexchange.com/q/37594/5538 Note that's using `dhclient` and disabling `dhcpcd` completely. — goldilocks, Aug 05 '16 at 17:08
@goldilocks I read the static IP thing so in the post so I was getting it clear again! You know this exactly happened to my other Pi every time I upgrade to Jessie! Ironically `systemd` is suppose to make things simple but apparently not! Also I am adding some edits about the `dhcpcd` thing from my pi can you make something out of it? — Shan-Desai, Aug 05 '16 at 17:10
Try `sudo systemctl list-units | grep dhcp` to see if there is anything along those lines. — goldilocks, Aug 05 '16 at 17:46
well I actually don't have `dhcpcd` on the Pi. I checked using `sudo service dhcpcd status` . This shouldn't be a problem, should it? — Shan-Desai, Aug 05 '16 at 17:48
That's why I said search just for `dhcp`. I think there are a few different daemons that play this same role and they may not end in `cd`. As implied before, one of the first things I do is remove all this stuff. It dates back a long time to when I couldn't figure it out and found it easier using command-line tools manually, since then it's evolved but I've still never bothered to figure out the "proper" way. It seems to be near the top of the list headache wise for people here *and* at Unix & Linux SE. — goldilocks, Aug 05 '16 at 17:52
...Dunno why it takes such an elaborate system to do something that amounts to two or three commands in the end. — goldilocks, Aug 05 '16 at 17:52
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/43535/discussion-between-shan-desai-and-goldilocks). — Shan-Desai, Aug 05 '16 at 18:10

Shan-Desai · Accepted Answer · 2016-08-09T01:35:03.200

Some Networking Checks

If I can connect another device in the same IP pool and check if they can access the Internet, then I can do some comparison and figure out the problem on the Pi.

I can connect my Laptop on the same IP Pool as mentioned above 10.10.155.x. My Laptop can access the Internet and I can ping the Pi on the Network

 ping 10.10.155.187 # IP add of my Pi

I figured out the Gateway of my network using traceroute on my Laptop

traceroute www.google.de

The very first entry would be my Gateway of my network which was 10.10.155.250

I tried pinging the Gateway from my Pi and it was pinging, which means there was no problem connecting to the Gateway. However I could not still ping some DNS addresses in my /etc/resolv.conf

Note

In many general networks the /etc/resolv.conf would have the following:


nameserver 8.8.4.4
nameserver 4.4.4.4

but I have little different configuration. This file may vary depending on the User's Network configuration

Solution

The best way here is to check if your Pi was configured to a Default Gateway like the Laptop or not.

This could be checked using (on Laptop and Pi both):

 ip route # on Laptop

which gave the following output:


default via 10.10.155.250 dev eth0

10.10.155.0/24 dev eth0  proto kernel  scope link  src 10.10.155.169 
10.10.160.0/24 via 10.10.155.251 dev eth0 
169.254.0.0/16 dev eth0  scope link  metric 1000

Also another good hint is to check your kernel's Routing Table using:

 sudo route -n # on Laptop

 Kernel IP routing table
 Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
 0.0.0.0         10.10.155.250   0.0.0.0         UG    0      0        0  eth0
 10.10.155.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
 10.10.160.0     10.10.155.251   255.255.255.0   UG    0      0        0 eth0
 169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0

Comparison on the Pi:

 ip route # on Pi

 10.10.155.0/24 dev eth0  proto kernel  scope link  src 10.10.155.187  metric 202 
 10.10.160.0/24 via 10.10.155.251 dev eth0  metric 202 
 169.254.0.0/16 dev wlan0  proto kernel  scope link  src 169.254.252.15  metric 303

Clearly there way no default route set on Pi. This is how one figures out the Necessary route for accessing the Internet

This is what needs to be added on your Pi to set a default route / Default Gateway :

 sudo route add default gw 10.10.155.250

Now a pre-check to see if your Routing Table on your Pi has the same values as that of the Laptop using:

 sudo route -n # on Pi and compare with Laptop's table

If they are same your routes are set and you can now do :

 ping www.google.de

and you will be able to access the Internet on your Pi.

Inference

It is always good to compare a device on the same network if it is able to access the Internet.

Commands like:

ip route

and

sudo route -n

could give an idea if some entities are missing. And by adding appropriate networking parameters such as a default route would solve the problem.

a fresh Jessie Image was used here rather than the above mentioned command line distribution upgrade

score 0 · Answer 2 · answered Aug 09 '16 at 01:27

0

If you had followed the Foundation advice which is to do a clean install of Jessie none of this would have happened.

It is NOT possible to upgrade by the method you used. It is possible to upgrade, but involves a much more complex process, involving manually installing new components.

answered Aug 09 '16 at 01:27

Milliways

54,718
26
92
182

Did manual fresh update with the solution provided above. Manually. Though the default route is overwritten everytime the pi reboots though. – Shan-Desai Aug 09 '16 at 01:28