Networkd: LinkLocalAddressing=fallback with MaxAttempts=infinity #13316

ratagupt · 2019-08-13T13:51:56Z

I came across a requirement why the link-local address exists with other IP addresses for IPv4.

Suppose if I enable the link-local address through systemd-networkd then as per the existing

behavior, link-local address(169.254..) will always exist on the interface irrespective of whether static/dynamic address exists or not.

The expectation is if either static/DHCP address exist then the zero-config address should not come even if the zeroconf functionality is enabled.

Is it correct expectation? is it aligned with other operating systems which is not using systemd-networkd as the network manager?

ssahani · 2019-08-13T17:16:05Z

seems you looking for fallback

https://www.freedesktop.org/software/systemd/man/systemd.network.html#LinkLocalAddressing=

ratagupt · 2019-08-13T18:36:56Z

@ssahani Thanks for quick response

As per the documentation If "fallback" or "ipv4-fallback" is specified, then an IPv4 link-local address is configured only when DHCPv4 fails.

what about if the interface is having Static IP address and DHCP is not enabled, even in that case link-local address should not be seen.

ssahani · 2019-08-13T19:02:28Z

what about if the interface is having Static IP address and DHCP is not enabled, even in that case link-local address should not be seen.

I do not follow . Please elaborate.

yuwata · 2019-08-18T16:06:32Z

what about if the interface is having Static IP address and DHCP is not enabled, even in that case link-local address should not be seen.

In that case, why do not you simply set no or ipv6 to LinkLocalAddressing=?

ratagupt · 2019-08-19T12:47:41Z

@ssahani : Suppose my network file is as below.

[Match]
Name=eth0
[Link]
MACAddress=70:e2:84:14:33:65
[Network]
LinkLocalAddressing=ipv4-fallback
Address=9.3.185.83/23
Gateway=9.3.185.1

The above network file works fine for me. It doesn't create the zerconf address if the static address(9.3.185.83) is there.

ratagupt · 2019-08-21T16:51:35Z

@yuwata > In that case, why do not you simply set no or ipv6 to LinkLocalAddressing=?

               Agree that will also work if I put the LinkLocalAddressing=no/ipv6.

I was looking for generic value which I don't need to change depends on the static/DHCP address configuration on the interface.

fallback serves the purpose.

ratagupt · 2019-10-04T11:19:05Z

@yuwata @ssahani : with the latest systemd-networkd "fallback" or "ipv4-fallback" doesn't work.
With the below network file, I don't have DHCP server configured in my network so system will not get the DHCP IP and I thought the system will come with link local address but that didn't happen.

systemctl --version
systemd 243 (243+)
+PAM -AUDIT -SELINUX -IMA -APPARMOR -SMACK +SYSVINIT -UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS -ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN -PCRE2 default-hierarchy=hybrid

My network file is as below.

[Match]
Name=eth0
[Link]
MACAddress=XX:XX:XX:XX:XX
[Network]
LinkLocalAddressing=fallback
IPv6AcceptRA=false
DHCP=true
[DHCP]
ClientIdentifier=mac
UseDNS=true
UseNTP=true
UseHostname=true
SendHostname=true

Did we make any change around this? Can you also verify this?

raviteja-b · 2019-10-09T08:13:52Z

I too faced same issue, "fallback" option did not work.

yuwata · 2019-10-09T08:34:55Z

Please try MaxAttempts= setting.

raviteja-b · 2019-10-09T17:20:30Z

I tried with MaxAttempts=1 setting, but did not work

ssahani · 2019-10-09T17:37:06Z

I just tested it .

Pretty sure what @yuwata said works

eth0: Received remembered route: dst: n/a, src: n/a, gw: 192.168.94.2, prefsrc: 192.168.94.177, scope: global, table: main, proto: dhcp, type: unicast
eth0: State changed: configuring -> configured
NDISC: Sent Router Solicitation, next solicitation in 3s
NDISC: Sent Router Solicitation, next solicitation in 3s
DHCP CLIENT (0x9dd5a63c): DISCOVER
DHCP CLIENT (0x9dd5a63c): STOPPED
veth99: DHCP client is stopped. Acquiring IPv4 link-local address
IPV4LL: Picked new IP address 169.254.4.219.
IPV4ACD: Probing 169.254.4.219
NDISC: Sent Router Solicitation, next solicitation in 7s
NDISC: Sent Router Solicitation, next solicitation in 7s
IPV4ACD: Probing 169.254.4.219
IPV4ACD: Probing 169.254.4.219
IPV4ACD: ANNOUNCE
veth99: IPv4 link-loca

8: veth0@veth99: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether aa:bb:7a:85:bf:69 brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.1/24 brd 192.168.5.255 scope global veth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a8bb:7aff:fe85:bf69/64 scope link 
       valid_lft forever preferred_lft forever
19: veth99@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9a:aa:6a:a2:16:c0 brd ff:ff:ff:ff:ff:ff
    inet 169.254.4.219/16 brd 169.254.255.255 scope link veth99
       valid_lft forever preferred_lft forever
    inet6 fe80::98aa:6aff:fea2:16c0/64 scope link 
       valid_lft forever preferred_lft forever

[Match]
Name=veth99

[Network]
DHCP=ipv4
LinkLocalAddressing=fallback
[DHCPv4]
MaxAttempts=1

[Match]
Name=veth0

[Network]
Address=192.168.5.1/24

yuwata · 2019-10-09T18:12:26Z

Yeah, our CIs also test the functionality.

@raviteja-b Please provide your .network file.

raviteja-b · 2019-10-09T18:28:02Z

Ok. here is my .network file
[Match]
Name=eth0

[Network]
LinkLocalAddressing=fallback
DHCP=true

[DHCP]
MaxAttempts=1

yuwata · 2019-10-09T18:45:30Z

MaxAttempts= should be in [DHCPv4] section, not [DHCP] section.

ssahani · 2019-10-09T18:50:14Z

Yes because this is a new setting and we separated dhcp4 and dhcp6.

raviteja-b · 2019-10-11T05:24:47Z

yes it works if i keep 'MaxAttempts=' in [DHCPv4] section
what should be the optimum value for MaxAttempts if fallback is configured?
I observed it takes few secs to assign link local address based on MaxAttemts value

raviteja-b · 2019-10-18T06:39:56Z

I configured 'LinkLocalAddressing=fallback' and stop DHCP server configured in my network, i see link local address assigned, but i dont see DHCP address assigned after restarting DHCP server,
I think the system will get DHCP address once DHCP server starts running but that didn't happen.

[Network]
LinkLocalAddressing=fallback
DHCP=true

[DHCPv4]
MaxAttempts=2

yuwata · 2019-10-18T07:08:42Z

I think the system will get DHCP address once DHCP server starts running but that didn't happen.

To support this, MaxAttempts= must be infinity. So, unfortunately, that functionality cannot be achieved with LinkLocalAddressing=fallback, at least currently.

@ssahani Maybe, we need to add AttemptsToAssignFallbackLinkLocalAddress= in [DHCPv4].

ssahani · 2019-10-18T10:22:38Z

I think it's too complicated.

yuwata · 2019-10-18T10:37:15Z

I think it's too complicated.

Yeah...

raviteja-b · 2019-11-05T12:57:57Z

I think we should support fallback with maxAttempts= infinity, otherwise we can't use linkLocalAddressing fallback mechanism.
do we have plan to support this?

nahuel · 2020-02-06T13:31:49Z

@ssahani just a final thought, LinkLocalAddressing must be a boolean option, at least for ipv4.

LinkLocalAddressing=no => no LL at all.

LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all.

LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address.

LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes.

And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes?

rasmuspeders1 · 2020-06-04T06:17:00Z

I just encountered this issue on our embedded Linux platform. In our case it is important that the system "recovers" automatically from using the fallback linklocal address to using an address assigned by DHCP when possible. Therefore I just wanted express my relief that a solution is now scheduled for v246.

@nahuel: I appreciate your effort to thoroughly describe the problem and propose a solution, nice work.

poettering · 2020-06-08T17:48:47Z

@yuwata hmm, where are we with this?

poldi871 · 2020-09-25T14:44:59Z

@ssahani just a final thought, LinkLocalAddressing must be a boolean option, at least for ipv4.

LinkLocalAddressing=no => no LL at all.

I deeply agree! I have that problem on an embedded system at the moment. As far as I see it was scheduled as milestone for 246 and hope it will be solved with 247.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e8108. There is no special "fallback" mode now, so the check doesn't make sense anymore.

Fixes systemd#13316.

…lues They are not really boolean, because we have both ipv4 and ipv6, but for each protocol we have either unset, no, and yes. From systemd/systemd#13316 (comment): LinkLocalAddressing must be a boolean option, at least for ipv4: - LinkLocalAddressing=no => no LL at all. - LinkLocalAddressing=yes + Static Address => invalid configuration, warn and interpret as LinkLocalAddressing=no, no LL at all. (we check that during parsing and reject) - LinkLocalAddressing=yes + DHCP => LL process should be subordinated to the DHCP one, an LL address must be acquired at start or after a short N unsuccessful DHCP attemps, and must not stop DHCP to keeping trying. When a DHCP address is acquired, drop the LL address. If the DHCP address is lost, re-adquire a new LL address. (next patch will move in this direction) - LinkLocalAddressing=fallback has no reason to exist, because LL address must always be allocated as a fallback option when using DHCP. Having both DHCP and LL address at the same time is an RFC violation, so LinkLocalAdressing=yes correctly implemented is already the "fallback" behavior. The fallback option must be deprecated and if present in older configs must be interpreted as LinkLocalAddressing=yes. (removed) - And for IPv6, the LinkLocalAddress option has any sense at all? IPv6-LL address aren't required to be always set for every IPv6 enabled interface (in this case, coexisting with static or dynamic address if any)? Shouldn't be always =yes? (good question) This effectively reverts 29e81083bd2fcb2dbf83f67ef358c7d25adf7e9d. There is no special "fallback" mode now, so the check doesn't make sense anymore.

yuwata added needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer network labels Aug 18, 2019

ratagupt closed this as completed Aug 19, 2019

ratagupt reopened this Oct 4, 2019

yuwata added RFE 🎁 Request for Enhancement, i.e. a feature request and removed needs-reporter-feedback ❓ There's an unanswered question, the reporter needs to answer labels Oct 18, 2019

yuwata changed the title ~~Networkd: ZeroConf Address~~ Networkd: LinkLocalAddressing=fallback with MaxAttempts=infinity Oct 18, 2019

ratagupt mentioned this issue Dec 13, 2019

OpenBMC networking doesn't respect RFC3927 - Autoconfigured Link-Local address issue openbmc/phosphor-networkd#32

Closed

ratagupt mentioned this issue Jan 23, 2020

IP: Provide support for configurable Zeroconf ibm-openbmc/dev#476

Closed

yuwata added this to the v246 milestone Feb 6, 2020

yuwata modified the milestones: v246, v247 Jun 23, 2020

keszybz self-assigned this Oct 7, 2020

keszybz added a commit to keszybz/systemd that referenced this issue Oct 9, 2020

networkd: start ipv4ll when dhcp has trouble getting a lease

3b55658

Fixes systemd#13316.

keszybz removed their assignment Nov 17, 2020

yuwata pushed a commit to yuwata/systemd that referenced this issue Nov 23, 2020

networkd: start ipv4ll when dhcp has trouble getting a lease

e279685

Fixes systemd#13316.

yuwata mentioned this issue Nov 23, 2020

network: fold ipv4ll fallback modes into normal ipv4ll addressing #17692

Merged

yuwata pushed a commit to yuwata/systemd that referenced this issue Nov 23, 2020

networkd: start ipv4ll when dhcp has trouble getting a lease

500481a

Fixes systemd#13316.

yuwata pushed a commit to yuwata/systemd that referenced this issue Nov 23, 2020

networkd: start ipv4ll when dhcp has trouble getting a lease

897f526

Fixes systemd#13316.

keszybz modified the milestones: v247, v248 Nov 26, 2020

yuwata pushed a commit to yuwata/systemd that referenced this issue Nov 27, 2020

networkd: start ipv4ll when dhcp has trouble getting a lease

c6646db

Fixes systemd#13316.

yuwata pushed a commit to yuwata/systemd that referenced this issue Nov 30, 2020

networkd: start ipv4ll when dhcp has trouble getting a lease

0107b76

Fixes systemd#13316.

keszybz closed this as completed in #17692 Dec 1, 2020

pdmorrow pushed a commit to pdmorrow/systemd that referenced this issue Dec 3, 2020

networkd: start ipv4ll when dhcp has trouble getting a lease

c4c3c9d

Fixes systemd#13316.

aj-bagwell pushed a commit to aj-bagwell/systemd that referenced this issue Jan 7, 2021

networkd: start ipv4ll when dhcp has trouble getting a lease

51214e7

Fixes systemd#13316.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Networkd: LinkLocalAddressing=fallback with MaxAttempts=infinity #13316

Networkd: LinkLocalAddressing=fallback with MaxAttempts=infinity #13316

ratagupt commented Aug 13, 2019

ssahani commented Aug 13, 2019

ratagupt commented Aug 13, 2019 •

edited

Loading

ssahani commented Aug 13, 2019

yuwata commented Aug 18, 2019

ratagupt commented Aug 19, 2019 •

edited by keszybz

Loading

ratagupt commented Aug 21, 2019 •

edited

Loading

ratagupt commented Oct 4, 2019 •

edited

Loading

raviteja-b commented Oct 9, 2019

yuwata commented Oct 9, 2019

raviteja-b commented Oct 9, 2019

ssahani commented Oct 9, 2019

yuwata commented Oct 9, 2019

raviteja-b commented Oct 9, 2019

yuwata commented Oct 9, 2019

ssahani commented Oct 9, 2019

raviteja-b commented Oct 11, 2019

raviteja-b commented Oct 18, 2019 •

edited

Loading

yuwata commented Oct 18, 2019 •

edited

Loading

ssahani commented Oct 18, 2019

yuwata commented Oct 18, 2019

raviteja-b commented Nov 5, 2019 •

edited

Loading

nahuel commented Feb 6, 2020 •

edited

Loading

rasmuspeders1 commented Jun 4, 2020

poettering commented Jun 8, 2020

poldi871 commented Sep 25, 2020

Networkd: LinkLocalAddressing=fallback with MaxAttempts=infinity #13316

Networkd: LinkLocalAddressing=fallback with MaxAttempts=infinity #13316

Comments

ratagupt commented Aug 13, 2019

ssahani commented Aug 13, 2019

ratagupt commented Aug 13, 2019 • edited Loading

ssahani commented Aug 13, 2019

yuwata commented Aug 18, 2019

ratagupt commented Aug 19, 2019 • edited by keszybz Loading

ratagupt commented Aug 21, 2019 • edited Loading

ratagupt commented Oct 4, 2019 • edited Loading

raviteja-b commented Oct 9, 2019

yuwata commented Oct 9, 2019

raviteja-b commented Oct 9, 2019

ssahani commented Oct 9, 2019

yuwata commented Oct 9, 2019

raviteja-b commented Oct 9, 2019

yuwata commented Oct 9, 2019

ssahani commented Oct 9, 2019

raviteja-b commented Oct 11, 2019

raviteja-b commented Oct 18, 2019 • edited Loading

yuwata commented Oct 18, 2019 • edited Loading

ssahani commented Oct 18, 2019

yuwata commented Oct 18, 2019

raviteja-b commented Nov 5, 2019 • edited Loading

nahuel commented Feb 6, 2020 • edited Loading

rasmuspeders1 commented Jun 4, 2020

poettering commented Jun 8, 2020

poldi871 commented Sep 25, 2020

ratagupt commented Aug 13, 2019 •

edited

Loading

ratagupt commented Aug 19, 2019 •

edited by keszybz

Loading

ratagupt commented Aug 21, 2019 •

edited

Loading

ratagupt commented Oct 4, 2019 •

edited

Loading

raviteja-b commented Oct 18, 2019 •

edited

Loading

yuwata commented Oct 18, 2019 •

edited

Loading

raviteja-b commented Nov 5, 2019 •

edited

Loading

nahuel commented Feb 6, 2020 •

edited

Loading