dhcpcd-discuss

Hi Roy,
hi list,

-<| Quoting Roy Marples <roy@xxxxxxxxxxxx>, on Monday, 2017-01-23 16:45:51 |>-
> Hi Philipp
> 
> On 23/01/2017 08:55, Philipp Gesang wrote:
> > Hi Roy,
> > 
> > thanks for your reply. Sorry for not answering sooner, I was out
> > of office for a week.
> > 
> > -<| Quoting Roy Marples <roy@xxxxxxxxxxxx>, on Sunday, 2017-01-15 14:24:41 |>-
> >> Hi Philipp
> >>
> >> Regarding ticket 5e9661e84e, you said:
> >>> dhcpcd will still remove addresses from other interfaces than eth8
> >>> if they clash with a lease. This is contrary to documented behavior
> >>> according to which dhcpcd will not touch other interfaces unless
> >>> running as master.
> >>
> >> I don't see this in dhcpcd documentation, all I have this this in dhcpcd(8):
> >>  If a list of interfaces are given on the command line, then dhcpcd only
> >> works with those interfaces, otherwise dhcpcd discovers avail‐
> >>      able Ethernet interfaces that can be configured.
> >>
> >> That does not imply that other interfaces will not be touched to achieve
> >> the desired result on the interface dhcpcd is running on.
> > 
> > Understood.
> > 
> >> As you even went out of your way to supply a patch, it implies this is a
> >> behavior you want. This is not the way dhcpcd has been designed (it's
> >> been designed to share the same IP on different interfaces and only have
> >> one "active"), so it's probably best to move it to a new option.
> > 
> > Sounds reasonable. (Though you might run out of option bits in
> > the process.)
> 
> I'm painfully aware I'm near the limit .....

Still one bit left! I’ll revise the patch to make this into an
option and resubmit.

> > To supply a little context: For my purposes I need dhcpcd to work
> > 
> >   a) only on the nic specified, and
> >   b) to not configure even that nic.
> > 
> > a) is the core of the ticket at hand; b) hasn’t come up yet but
> > it is essential nonetheless. I have a draft patch ready that adds
> > a “--noconfigure” option for b).
> > 
> > The point of all this is that our system does its own link
> > management. The role of dhcpcd is to talk to DHCP servers and
> > then pass on the information through the script callback (which
> > in our case is a binary communicating with the management engine
> > via custom IPC). The final decision as to whether a lease, the
> > gateways, static routes etc. are acceptable cannot be made by
> > dhcpcd because it has no idea about the rest of the system and
> > whether inconsistencies might arise elsewhere.
> 
> That's fair enough.
> 
> > I’ll attach the working draft of the patch for b). Note that I
> > lack familiarity with dhcpcd’s code base so this is likely to be
> > incomplete. My tests were mainly performed by sniffing Netlink
> > for events caused by dhcpcd: With the patch applied it is all
> > silent which is exactly what I need.
> 
> It is incomplete - there are no IPv6 alterations nor man page adjustments.

Indeed. The DHCP server and client used for testing don’t have
CONFIG_IPV6 defined. (Don’t ask.) Considering that the IPv6
handling is structured rather differently, I don’t think I’m in a
good position to extend the patch in that direction.

I will prepare a v2 patch that addresses the other points.

> Also, you may wish to consider that dhcpcd may adjust sysctl values to
> suit (for example disabling IPv6 RA handling in the kernel). I don't
> know how that affects your use case.

Regarding IPv4 this appears to be relevant for Linux only so I
added code that intercepts it in the platform specific part.

I also hadn’t noticed dhcpcd sets the link MTU via conventional
ioctl() so I prevented that as well.

> > I hope I could elucidate the purpose of the patch. Let me know
> > what you think about it. I’ve also subscribed to the mailing list
> > so I you prefer we can continue there.
> 
> One issue with this is that (for DHCPv4 at least) some operations
> require UNICAST which requires the IP address to be active.
> If the IP address is not present, RENEW operations will fail ...... this
> is OK because REBIND will work.

Our callback “script” treats REBIND events the same as RENEW so
in our case it does not make a difference in practise.

But in my understanding the link should be configured regardless,
just not by dhcpcd.

> FORCERENEW / RECONFIGURE messages won't work for similar reasons.
> 
> dhcpcd does try and work this out though so it may be ok.

Those weren’t tested.

Best,
Philipp

Attachment: signature.asc
Description: PGP signature