Enhancement or Question - Support for sub-interfaces

[ColinMcInnes]

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:18:48:20:10:94 brd ff:ff:ff:ff:ff:ff
    inet 169.254.0.2/24 scope host eth0:si0               <<<< statically assigned through CLI
       valid_lft forever preferred_lft forever
    inet 169.254.1.2/24 scope host eth0:si1               <<<< statically assigned through CLI
       valid_lft forever preferred_lft forever
    inet6 ...

When I restart dhcpcd, it takes down and brings back eth0, and this wipes eth0:si0 and eth0:si1. I would like to add them to the dhcpcd.conf, but

denyinterfaces eth0:si0 eth0:si1

does not seem to "take". Am I doing it wrong, or is this something dhcpcd does not yet support (interface labels).

For now, I'm using "persistent"

[rsmarples]

In this case the "interface label" was used in the past I think because ifconfig only handles one ipv4 address per interface. In the modern world it's just a label for an address - IFA_LABEL.

I suppose the better question is why do we blanket remove any pre-existing IPv4LL addresses? Well, dhcpcd will likely remove the subnet route for them as well rendering them pretty useless.

So the only correct solutions are to disable ipv4ll in dhcpcd or use something other than link-local addresses on the interface. OR if you want to get really funky create a slap eth0 into a bridge with a virtual interface and assign the link-local addresses to that interface.

[ColinMcInnes]

I will retest with 10.2.2 and noipv4ll

I do like the virtual interface idea though. I might try that too. I tried not using LL for the label, but the device I'm using it for hard-codes it on their end so I can't assign a different range.

[ColinMcInnes]

10.2.4 with noipv4ll, persistent, and static "LL" addresses. release is releasing static LL addresses in spite of the noipv4ll flag. exit command does not release LL addresses. so it's possible release code block is just skipping over the check that exit is respecting.

/sbin/dhcpcd --debug --config /etc/dhcp/dhcpcd.conf --release eth0
Jun 24 13:14:18 dhcpcd[3593]: control command: /sbin/dhcpcd --debug --config /etc/dhcp/dhcpcd.conf --release eth0
Jun 24 13:14:18 dhcpcd[3593]: eth0: removing interface
Jun 24 13:14:18 dhcpcd[3593]: eth0: multicasting RELEASE6 (xid 0x994a8d), next in 1.1 seconds
Jun 24 13:14:18 dhcpcd[3593]: eth0: executing: /usr/libexec/dhcpcd-run-hooks SEND6_RELEASE6
Jun 24 13:14:18 dhcpcd[3593]: eth0: deleting address 2001:192:168:226::119/128
Jun 24 13:14:18 dhcpcd[3593]: eth0: executing: /usr/libexec/dhcpcd-run-hooks RELEASE6
Jun 24 13:14:18 dhcpcd[3593]: eth0: deleting IP address 169.254.0.2/24
Jun 24 13:14:18 dhcpcd[3593]: eth0: deleting IP address 169.254.1.2/24
Jun 24 13:14:18 dhcpcd[3593]: eth0: executing: /usr/libexec/dhcpcd-run-hooks IPV4LL
Jun 24 13:14:18 dhcpcd[3593]: eth0: releasing lease of 192.168.226.119
Jun 24 13:14:18 dhcpcd[3593]: eth0: sending RELEASE with xid 0x1115552f

I will look into this further.

[ColinMcInnes]

In the meantime I'm going to use --disable-ipv4ll, because we don't use it anyway.

[rsmarples]

Hmmmm, the IPv4LL addresses should not be removed at release. I'm also looking at #510 which also touches IPv4LL. I did have a small patch for that but have been distracted by other things.