Score:0

netplan networkd no ipv4 from dhcp

ke flag

I've been trying to have ubuntu server running on my MacBook Pro (15-inch, Late 2011) for the whole day, both 20.04 and 21.10, fighting with netplan and I cannot seem to be able to have ens9 (Thunderbolt 2 network adapter - seems to work fine from this post: Using Apple Thunderbolt 2 Ethernet adapter on Ubuntu 20.04) getting an ipv4 from the DHCP. I read tons of posts all over the place, it seems trivial but I still cannot get it to work :/

My /etc/netplan currently looks like this:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens9:
      dhcp4: true
      optional: true

But honestly, at this point, I've lost track of how many times I changed it. I pretty much tried everything I found searching for all the possible permutations of the words: ubuntu, server, 20.04, 21.10, dhcp, ipv4, -static, -NetworkManager, not working, not getting IP, -ipv6, MacBook pro, ens9, netplan, systemd-networkd.

Whenever I ip a it ens9 has only an ipv6 (for some reason, I don't use ipv6 in my network nor my DHCP assigns ipv6 addresses, so I've no idea where it comes from tbh) no routing table and no nameserver assigned, which makes me suspect is not even trying to "dhcp anything". Even if I add dhcp6: false I still get a fracking ipv6 but no ipv4 I kept a tail -f /var/log/syslog open for the whole time and nothing useful shows up.

If I run dhclient -r ens9 && dhclient ens9 the interface does get an ipv4 and the network starts working (for instance that's how I got it to work during the install process). I can ssh in it fine, even tho sometimes the network hangs (but honestly this is minor if at least I can get the DHCP config working ).

So even tho I do have a horrible workaround that I prefer not to use, I really want to understand why the default "Canonical" (pun intended) way is not working for me, and I'm currently out of options on where to knock my head.

I pretty much set off to reuse an old machine to have some fun, and I ended up being totally frustrated , kind of made me remember why I stopped using Linux as a desktop operating system.

Update:

  1. Testing with networkctl

this is the output after hours of running

link:ens9 type:ether operational:degraded setup:configuring

just after reboot it looks quite different:

link:ens9 type:ether operational:off setup:managed

but I suspect it's because of the optional parameter if I remove the optional

netplan generate && netplan apply I got back to the initial state of:

link:ens9 type:ether operational:degraded setup:configuring

rebooting without optional, after stalling at host and network name lookups gives me:

link:ens9 type:ether operational:degraded setup:configuring

if I run dhclient -r ens9 && dhclient ens9 it goes from degraded to routable

  1. I remembred this laptop also comes with an integrated ethernet port (it's so long since I've seen one that I didn't even remember they existed ), so I pulled the Thunderbolt Dongle, connected my cable directly to the build-in port, updated the config file with the new interface name, and when to the usual paces of generate, apply, even rebooting. Result: Nothing changes, same exact behavior in any way. From this, I would say it's def not an HW problem but a SW problem. The biggest one being: there are zero logs (as far as I can tell) explaining why netplan is not doing whatever it needs to do with the DHCP client. Even using the -d switch, or trying (netplan try) gives zero information.

  2. So I thought perhaps putting a server build on a laptop could be not the best idea, so I downloaded and tried Ubuntu Desktop 21.10. Same behavior.

  3. After a further investigation I found on the internet it might be a problem with firmware and/or kernel modules. I then proceeded with: apt-get install b43-fwcutter firmware-b43-installer and modprobe b43 but nothing changed, same exact behavior and the DHCP refusing to do its job if not manually stimulated :(

background: Linux has been my primary (and only) OS from 1994 to 2004 when I switched to OSX. I keep using it on servers but with the modern "lazy cloud platforms and docker" I haven't had to deal with network config issues for a long long time and, in full disclosure, I just found out today about netplan. While my personal opinion is that is a poor choice for a language to use white spaces as a means to define blocks, I am very familiar with yaml and paranoid in checking/counting those pesky whitespaces.

pasman pasmański avatar
mx flag
In stock config is `ethernets` instead of `ethernet`
ke flag
if I change it to `ethernet` when I run `netplan generate` it complains that the singular is invalid. So I guess the stock config is right?
ke flag
oh sorry, only now I see what you meant. Because of the lack of network, I copied the config instead of copy/pasting it, and being dyslexic doesn't help to see my typing errors. I'll fix the post. Thanks.
us flag
The configuration (with `ethernets`!) looks correct. If dhclient works, networkd should also work. Can you show the output of `networkctl` on this system?
ke flag
link:ens9 type:ether operational:degraded setup:configuring this is the output after hours of running just after reboot it looks quite different: link:ens9 type:ether operational:off setup:managed but I suspect it's because of the `optional` parameter if I remove the "optional" and `netplan generate && netplan apply` I got back to the initial state of: link:ens9 type:ether operational:degraded setup:configuring rebooting without `optional`, after stalling at `host and network name lookups` gives me: link:ens9 type:ether operational:degraded setup:configuring
ke flag
meh, sorry, posting removes my formatting. Long story short it's: degraded and configuring
ke flag
if I run `dhclient -r ens9 && dhclient ens9` it goes from `degraded` to `routable`
Score:0
ke flag

It's not much but at least I found out why those ipv6 addresses were showing up: apparently netplan takes the liberty to add extra steps to the network config during the generate command (not very cool if you ask me). The fix is:

  1. add link-local: [] to netplan's interface configuration and generate
  2. check your /run/systemd/network/ dir for the generated files

Idk, the more I dig the more I find this netplan pesky, confusing, not helpful, and worst of all completely against the *unix philosophy. It's just hiding stuff and making it more complicated, trying to fix something that wasn't broken...

Score:-1
ke flag

Admittedly out of frustration at the end I ended up making it work in the dirty way possible (the one I wanted to avoid):

Just running it through rc.local

This "works" as the interface is quite unstable, it almost looks like there's "something underneath" doing "something".

Setting a static IP solves the instability but well, it's not the point...

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.