Score:0

Ubuntu - ipv4 mostly not working on new install

jp flag

I just did a clean install of Ubuntu 20.04 on a machine and have been having problems with it. IPV6 works fine across the board, but IPV4 isn't working, mostly.

[EDIT: I'll shorten the question in light of new discoveries]

In short, on the IPV6, all works fine. On the IPV4 side, with DHCP on automatic, it was assigned the loopback address of 127.0.1.1, so loopback ping worked. Nothing else IPV4 worked. [see update]

Ubuntu 20.04 with LAMP stack. Current software versions across the board.

Update OK, I feel like an idiot now. After sleeping on it and thinking carefully about the IPV4 address, I realized that 127.0.1.1 is a loopback address.

"Interim" fix: I reconfigured IPV4 to use a manually assigned IP address, and did the same on the router for the hostname. All on IPV4 and IPV6 seem to be working as expected now and there appear to be no conflicts.

So here's my new question: WHY doesn't the Ubuntu machine acquire a valid IPV4 address automatically when DHCP is on and all is set to automatic??? Why is it getting the loopback address instead?

I'd like to set it up so that it does function correctly for DHCP/dynamic address assignment for both IPV4 and IPV6.

Any ideas? ;-)

[2nd edit] As requested, the contents of /etc/netplan/01network-manager-all.yaml followed by ip addr output. Note that I've altered the ipv6 addresses slightly for security reasons.

/etc/netplan/01network-manager-all.yaml

# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 80:c1:6e:fa:9e:83 brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    inet 192.168.1.212/24 brd 192.168.1.255 scope global noprefixroute eno1
       valid_lft forever preferred_lft forever
    inet6 2600:wwww:zzzz:xxxx::4e0/128 scope global dynamic noprefixroute 
       valid_lft 2589401sec preferred_lft 602201sec
    inet6 2600:wwww:zzzz:xxxx:f5a5:beef:9843:4f07/64 scope global temporary dynamic 
       valid_lft 3085sec preferred_lft 3085sec
    inet6 2600:wwww:zzzz:xxxx:a495:1c3d:2aeb:1c47/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 3085sec preferred_lft 3085sec
    inet6 fe80::f94c:19e9:75d0:6b7/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

As I've said, I installed a static address, but still no idea why it wasn't setting up an IPV4 dynamic address or functionality.

Any new ideas???

zwets avatar
us flag
The only sensible explanation for a plain vanilla Ubuntu machine not getting an IP address is that the DHCP server isn't giving it one. If it were any different then 99% of Ubuntu users would never get online. Does the DHCP server work for other devices on the network?
zwets avatar
us flag
Also, no machine will ever receive a 127.0.1.1 address. Firstly the address isn't routable, as all addresses in the 127/8 network are defined to sit on the local machine's loopback interface, which by definition isn't connected to anything but itself, so how _could_ it receive anything? Secondly, every machine already _has_ address 127.0.1.1, as well as every other address in 127/8. Just try `ping 127.42.42.42` to verify. There is no use in looking at your loopback interface, what you should be looking at is the _physical_ interface that connects to the network with the DHCP server.
Thomas Aichinger avatar
cn flag
It woukd be of great help if you could post your /etc/netplan/*.yaml file here. Also please post output of 'ip addr'
Cliff B avatar
jp flag
Added requested info
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.