systemd-network no IP on unplugged cable

zx · 2018-01-19 21:08:08

Hi,

What I have to add into /etc/systemd/network/eth0.network file to have IP address always set.
I saw that if cable is unplugged then IP address is not set. But I need it all the time, I don't care if cable is there or not.

I'm trying figuring out that problem but can't find it;/

Trilby · 2018-01-19 21:11:06

This sounds very much like an XY problem. What are you really trying to do?

Why would you need an IP address for your ethernet card if it's not connected? Nothing could use that address!

zx · 2018-01-19 21:20:56

I have a router builded on archlinux.
Sometimes I have to unplug cable from some reasons, and then for example dhcpd server will not up.
Overall some services may need IP address on device.

[edit] Maybe you are right, that is XY problem..

Last edited by zx (2018-01-19 21:34:16)

Trilby · 2018-01-19 21:36:20

Well that didn't answer much. What possible service could need the ip address of a device that is not even plugged in?

And if you are using dhcpcd then it doesn't have an IP address, the question makes even less sense if this is not a static IP configuration.

Lastly, your router runs archlinux? What kind of router is it? It's not archlinuxARM?

As for "some service may need ..." which services exactly? Do they actually need the IP address, or you just think they "may"? What error messages are you getting? What processes are failing?

Last edited by Trilby (2018-01-19 21:38:17)

zx · 2018-01-19 21:49:18

> Well that didn't answer much.

A little but yes, I found some changes in archwiki. I have an old configuraion files, and today I want to back my router.

> What possible service could need the ip address of a device that is not even plugged in?

dhcpd for example

> And if you are using dhcpcd then it doesn't have an IP address, the question makes even less sense if this is not a static IP configuration.

I'm using static IP addresses.

> Lastly, your router runs archlinux? What kind of router is it? It's not archlinuxARM?

It is not ARM, for now I have to use x86, some of the closed software which I have to use will not work on ARM;-/

> As for "some service may need ..." which services exactly? Do they actually need the IP address, or you just think they "may"? What error messages are you getting? What processes are failing?

For example I have my software which will start server over TCP. My software have to works all the time even if IP is not there.

Last edited by zx (2018-01-19 21:49:44)

Trilby · 2018-01-19 22:58:48

zx wrote:

> What possible service could need the ip address of a device that is not even plugged in?
dhcpd for example

That makes no sense at all. You can not get a lease for an ethernet connection with no wire.

zx wrote:

I'm using static IP addresses.

You just said you were using dhcp. Which is it?

zx wrote:

I have my software which will start server over TCP. My software have to works all the time even if IP is not there.

There is no systemd configuration that will give you magic TCP communication over an ethernet card that is not connected to anything.

As for your software, if it is crashing, then your software needs to be fixed.

But I'm not actually a dentist. So I'm done pulling teeth.

Tarqi · 2018-01-19 23:39:51

Use a bridge and add your ethernet card there. See https://systemd.network/systemd.network.html, example 3 at the bottom of the page.

Edit: Grammar

Last edited by Tarqi (2018-01-20 00:27:39)

amish · 2018-01-20 02:25:49

I have been asking for that option to systemd developers from many months now.

Poettering agreed and asked for pull request, which I did.

But one other developer is not giving approval. He wants certain limitation which breaks whole purpose of my pull request (wrt deletion of foreign config)

Please add weight to this pull request by me by adding a comment say - "Why you need this feature?"

https://github.com/systemd/systemd/pull/7403

If we can have more users asking for the feature may be it can land in systemd.

amish · 2018-01-20 02:40:19

Examples on why a software may want IP always configured

1) My software - works on License which is bound to IP address. It checks for existence of a particular IP configured on particular interface.
It stops working with invalid license when IP is lost on interface due to temporary cable removal.

2) Existing connections break unnecessarily when cable is removed temporarily for any reason. Then software times out and tries to reconnect. I want to avoid this situation. If cable is removed for about 1 min.. packets should remain in queue and wait till cable is connected (or timeout eventually)

3) ip rules / ip routes added by me (but not by systemd) gets deleted on removing cable... but they are not re-added when cable is connected. This is most crazy thing systemd can do. (why delete rule / routes not added by self?). Which messes up my whole routing and also creates security issues.

Not being rude or blunt but please note - I do not want workaround solutions to my above problem. I know best solution in my case is to "keep address / rules / routes" as is.

ayekat · 2018-01-20 13:52:20

amish2 wrote:

1) My software - works on License which is bound to IP address. It checks for existence of a particular IP configured on particular interface.
It stops working with invalid license when IP is lost on interface due to temporary cable removal.

I would argue that that is a bug with that software, but given that it is proprietary, the chances of getting it fixed are close to zero, so I will refrain from bringing the usual "fix the software"

2) Existing connections break unnecessarily when cable is removed temporarily for any reason. Then software times out and tries to reconnect. I want to avoid this situation. If cable is removed for about 1 min.. packets should remain in queue and wait till cable is connected (or timeout eventually)

"Connections" are handled in TCP, the layer above, and they should not time out if the IP address is temporarily lost.

3) ip rules / ip routes added by me (but not by systemd) gets deleted on removing cable... but they are not re-added when cable is connected. This is most crazy thing systemd can do. (why delete rule / routes not added by self?).

Why not manage those routes with networkd?

Which messes up my whole routing and also creates security issues.

How exactly does this cause "security issues"...?

Don't get me wrong, I agree with you on that it is pretty annoying, and I would also rather have networkd only manage its own IP address configurations (and from a quick glance at that linked GitHub issue, it appears to have the capability to do so, but I haven't looked at it too closely). Then again, I have only said mean things to my computer because of networkd when I had to manually/temporarily fiddle around with my IP configuration; I have learned to simply disable networkd on that interface in such cases (by commenting out the relevant config—a "networkd profile handler" script is on my todo list). I think for static configuration, it does its job well.

Also, a personal opinion on that GitHub discussion: I think it's a mess. Neither of you two appear to convey your ideas particularly well, and I think it's going nowhere. Posting biased "summary" comments and asking people here to go and "add weight to the PR" is also not really collaborative behaviour.

Last edited by ayekat (2018-01-20 13:54:13)

amish · 2018-01-20 14:25:16

I do not know who you mean by "you two". I assume me and ssahani of github PR

What current systemd does is when cable is removed, it not only removes IP address / routes / rules added by itself (which they call as local config), it also removes IP address / routes / rules added manually using 'ip' command. (which they call as foreign config)

I am fine with that but except in my case where what I would like to do is - even if link is lost - it should not delete ANY IP address / route / rule. (be it local or foreign)

For which I created PR which allows administrator to do that and this PR does not change current default behavior unless IgnoreCarrierGainLoss is set to yes.

Now ssahani is ok with the feature - but he insists on partial implementation only.

i.e. what he insists is that if IgnoreCarrierGainLoss is set and link goes down then systemd will NOT delete local config but it will still go ahead and delete foreign config. i.e. it will go ahead and delete IP address / route / rules added manually by 'ip' command

This is where PR is stuck

I fail to understand why systemd should tamper with foreign config when I am specifically setting IgnoreCarrierGainLoss. If its not deleting Local config then dont delete foreign config too. i.e. just dont do anything.

Leonid.I · 2018-01-20 23:19:18

zx wrote:

Hi,
What I have to add into /etc/systemd/network/eth0.network file to have IP address always set.
I saw that if cable is unplugged then IP address is not set. But I need it all the time, I don't care if cable is there or not.
I'm trying figuring out that problem but can't find it;/

Speaking from my experience, use systemd-* tools as little as possible.

If your IP is static, use netctl or just write a 3 line script yourself. If you use DHCP protocol, use dhcpcd(1). It is much, much better and saner that systemd-networkd (read man 5 dhcpcd.conf - I think there is a "nolink" option that does what you want).

Leonid.I · 2018-01-20 23:24:25

ayekat wrote:

Why not manage those routes with networkd?

Because systemd developers are about as predictable in their design decisions as earthquakes. In the past two months, my system was broken twice due to changes in systemd which were completely unwarranted (IP sandbox of logind and removal of uaccess tag on /dev/kvm while givin it 666 permissions).

Leonid.I · 2018-01-21 00:14:07

amish wrote:

Now ssahani is ok with the feature - but he insists on partial implementation only.
i.e. what he insists is that if IgnoreCarrierGainLoss is set and link goes down then systemd will NOT delete local config but it will still go ahead and delete foreign config. i.e. it will go ahead and delete IP address / route / rules added manually by 'ip' command
This is where PR is stuck
I fail to understand why systemd should tamper with foreign config when I am specifically setting IgnoreCarrierGainLoss. If its not deleting Local config then dont delete foreign config too. i.e. just dont do anything.

I didn't read that github PR discussion in detail (nor am I going to comment there because I don't have/need a github account) but from what you are describing, I'd agree with Susant Sahani. I mean, if you use a "foreign" config and then set that Ignore... flag, why would you use networkd at all? Maybe I'm missing something, but that's my HO.

As a sidenote, is it me or systemd config options are reaching their length limit? Typing IgnoreLinkStatusIfThisAndThatButNotKaboom=yes seems like a mockery to me...

Last edited by Leonid.I (2018-01-21 00:14:35)

amish · 2018-01-21 02:08:11

My question is simple - If systemd is not managing foreign config then why destroy foreign config? Or atleast let administrator decide if to destroy it or not.

Leonid.I wrote:

I didn't read that github PR discussion in detail (nor am I going to comment there because I don't have/need a github account) but from what you are describing, I'd agree with Susant Sahani. I mean, if you use a "foreign" config and then set that Ignore... flag, why would you use networkd at all? Maybe I'm missing something, but that's my HO.

Most of my config goes to systemd.network file. And I am happy about systemd. And also world seems to be moving towards it so I chose to jump in the ship too.

But sometimes you need to add route which keeps changing i.e. dynamic routes. Sometimes you need to add different route because some IP is not reachable by default gateway due to some routing issue but via other "standby" gateway it does.

Sometimes I need to assign a temporary IP address to system. Which I delete after a its use is done with.

I can not add them to systemd.network file. Because I do not want to restart /reload systemd-networkd everytime I want some specific changes.

So systemd should be atleast able to tolerate foreign config instead of destroying it completely.

Leonid.I wrote:

As a sidenote, is it me or systemd config options are reaching their length limit? Typing IgnoreLinkStatusIfThisAndThatButNotKaboom=yes seems like a mockery to me...

I had suggested shorter name IgnoreCarrier but developers were insisting on more precise name.

rsmarples · 2018-01-21 02:51:09

DISCLAIMER: I maintain dhcpcd and a NetBSD kernel developer so I'm somewhat biased.

From what I've read on the GitHub PR, the systemd devs are wrong.
But in their defence, so are the Linux kernel team.

If the link goes down, the kernel will helpfully delete all IPv6 addresses.
systemd is just mirroring this for IPv4.
And to be fair, on any other system than NetBSD-8, dhcpcd behaves the same by default.

But, as I said, this is wrong.
Consider you have "flappy" link. Dodgy Access point or cable/switch outside of your control.
Or maybe this is on your router and your ISP is pants.
So are these hardware issues? Maybe.
But why can't the client software play nice?
The TCP protocol is robust enough to stand a few seconds of the link being down. If it comes back reasonably fast all you notice is a little lag - everything else keeps working.

So why delete the IP addresses? Because you want to be a good network citizen and not posion ARP caches.
Consider you have the address 192.168.1.10/24.
Link goes down and comes back up.
It's possible that you could have changed networks - the system cannot know otherwise.
As such, if another host broadcasts for an ARP of the IP address you have, you answer. Even if another host also as the same IP address (ie, network changes and you now conflict).
So, this is bad, and this is why both the Linux kernel team and systemd devs have this approach.

As I said earlier, NetBSD-8 (not released, but RC versions are available) works differently because Duplicate Address Detection is built into the kernel for IPv4 addresses as well as IPv6.
This allows the kernel to keep the addresses on carrier down and just discard what they send until the addresses are re-validated after carrier comes back.
In a nutshell, this means that traffic is just beholden to TCP (or UDP) rules and things just work better.
IRC clients, web servers, ssh servers, etc don't get disconnected when the link flaps unless the L3 protocol (TCP, UDP, whatever) says so.

Obiovusly not everyone runs NetBSD, nor an unreleased version of it.
This is why dhcpcd allows you to break the rules slightly on other OS's.
If you know better than dhcpcd or the kernel, you can say "Keep config on carrier down".

Leonid.I · 2018-01-21 21:23:04

amish wrote:

My question is simple - If systemd is not managing foreign config then why destroy foreign config? Or atleast let administrator decide if to destroy it or not.
Most of my config goes to systemd.network file. And I am happy about systemd. And also world seems to be moving towards it so I chose to jump in the ship too.
But sometimes you need to add route which keeps changing i.e. dynamic routes. Sometimes you need to add different route because some IP is not reachable by default gateway due to some routing issue but via other "standby" gateway it does.
Sometimes I need to assign a temporary IP address to system. Which I delete after a its use is done with.
I can not add them to systemd.network file. Because I do not want to restart /reload systemd-networkd everytime I want some specific changes.
So systemd should be atleast able to tolerate foreign config instead of destroying it completely.

I think what you are asking is a particular case of a "oneshot" networkd config, similar to oneshot services without any ExecStop field. With such configs, networkd would set up the interface and just leave it alone. However, AFAIU (and this is supported by what Susant is saying) networkd persistently manages interfaces, kinda like NetworkManager.

Personally, I don't like such design, and that's why I don't use networkd or NM. For bridges, interfaces with static IPs I simply use netctl on archlinux or simple scripts on fedora. Your patches actually contradict the architecture of networkd and I think this is why your PR got stuck.

And I still don't understand your reasoning. You said yourself that IgnoreCarrierGainLoss is only meaningful for static IP addresses. But in this case, networkd is an overkill. Just write a 3-liner in bash -- you don't need to use systemd for everything.

This is also my answer to the OP: ditch networkd because it is not built for your usecase.

amish · 2018-01-22 02:44:39

I wish systemd-networkd had "oneshot" feature i.e. configure and exit. (unless I missed something?)

I was using netctl but then I do not recall why I switched to systemd-networkd.

I think mainly because I thought:
1) systemd-networkd will eventually replace netctl
2) I was happy with one package handing it all (easy solution)

I didnt realize about my issue until it was too late to reverse (many arch servers I manage use systemd-networkd). I will need to change scripts and configs everywhere.

I might reverse it eventually if PR is rejected. But just waiting for a while.

And I also believe that any code should not put restriction on use of other tools without any proper reason. Architecture should be as flexible as possible.

Or if systemd deletes foreign config on link down then it should also restore it when link is up. (either handle it completely or not handle it at all)

Last edited by amish (2018-01-22 02:51:57)

ayekat · 2018-01-22 07:55:15

amish wrote:

I wish systemd-networkd had "oneshot" feature i.e. configure and exit. (unless I missed something?)

So this?

[Service]
Type=oneshot
ExecStart=/usr/bin/ip address add 192.168.0.6/24 dev enp0s1
ExecStart=/usr/bin/ip address add 192.168.1.2/24 dev enp1s1
ExecStart=/usr/bin/ip route add default via 192.168.0.1 dev enp0s1
ExecStart=... and so on

I used to have something like this before networkd was a thing.

But as I stated above, I fail to see the incentive: networkd shouldn't get in your way unless you simultaneously apply manual changes to the network configuration (and even there it apparently messes up things only if you it lose the link, and I hope you have at least some control over when that happens). For any regular usecase, networkd works fine¹.

As for "regular usecase":

I didnt realize about my issue until it was too late to reverse (many arch servers I manage use systemd-networkd). I will need to change scripts and configs everywhere.

I'm not sure how you spend your day, but in my case, manual network configuration changes are the exception, not the rule (especially on servers). As stated in that PR, if there is a usecase you're missing, make a feature request (note that fiddling around is not a "regular usecase" by any means, at least not for a network management system like networkd or NetworkManager).

I'm not claiming that networkd is the tool for everything, though. If you happen to be talking about some high-frequency network gateway node where the configuration has to be regularly changed on the fly in an automated way to adapt to various situations (who knows?, neither you nor OP have really explained your usecases²), networkd is quite probably the wrong tool, by design. But I think that those nodes should already be running a more adapted, customised and powerful network management system than networkd.

_____
¹ And yes, occasionally the systemd folks break things. Occasionally they also don't break things enough, I believe (when it comes to legacy baggage). But networkd has been pretty stable (at least in the past 2+ years that I've been using it on servers, laptops and network routers, be it for static addresses or with DHCP or with NAT or a combination of all).
² Except for that proprietary-software-that-requires-a-specific-IP-to-be-always-present thing, which I believe can be solved by setting up a bridge, as already mentioned by Tarqi in a previous post (because systemd devs are not know for implementing workarounds for bugs in other software, which I can get behind).

Last edited by ayekat (2018-01-22 07:58:39)

zx · 2018-01-23 09:32:39

Hi,

Thanks all for any sugestions and informations (good to have them).

Just to clarify:

My WAN IP address is dynamic, I'm ok with any address which I will take from ISP, ROUTER, what ever it is.
Unplugged cable is good for me here.

My LAN IP address is static, something like 192.168.1.1.
My LAN provides DNS, DHCP server, and else services which I want to have.
And problems are here, not on WAN.

BTW, yeah if software is my and I can fix it, then OK, I'm good and I love to have good software, but what if software is closed and fixing it is not possible?
Will reread all of your messages once again, but later today.

Arch Linux

#1 2018-01-19 21:08:08

systemd-network no IP on unplugged cable

#2 2018-01-19 21:11:06

Re: systemd-network no IP on unplugged cable

#3 2018-01-19 21:20:56

Re: systemd-network no IP on unplugged cable

#4 2018-01-19 21:36:20

Re: systemd-network no IP on unplugged cable

#5 2018-01-19 21:49:18

Re: systemd-network no IP on unplugged cable

#6 2018-01-19 22:58:48

Re: systemd-network no IP on unplugged cable

#7 2018-01-19 23:39:51

Re: systemd-network no IP on unplugged cable

#8 2018-01-20 02:25:49

Re: systemd-network no IP on unplugged cable

#9 2018-01-20 02:40:19

Re: systemd-network no IP on unplugged cable

#10 2018-01-20 13:52:20

Re: systemd-network no IP on unplugged cable

#11 2018-01-20 14:25:16

Re: systemd-network no IP on unplugged cable

#12 2018-01-20 23:19:18

Re: systemd-network no IP on unplugged cable

#13 2018-01-20 23:24:25

Re: systemd-network no IP on unplugged cable

#14 2018-01-21 00:14:07

Re: systemd-network no IP on unplugged cable

#15 2018-01-21 02:08:11

Re: systemd-network no IP on unplugged cable

#16 2018-01-21 02:51:09

Re: systemd-network no IP on unplugged cable

#17 2018-01-21 21:23:04

Re: systemd-network no IP on unplugged cable

#18 2018-01-22 02:44:39

Re: systemd-network no IP on unplugged cable

#19 2018-01-22 07:55:15

Re: systemd-network no IP on unplugged cable

#20 2018-01-23 09:32:39

Re: systemd-network no IP on unplugged cable

Board footer