The dhcp server is systemd-networkd, and the dhcp
plugin can request an ip but can not renew it.
The systemd-networkd just ignore the renew request.
```
2024/09/14 21:46:00 no DHCP packet received within 10s
2024/09/14 21:46:00 retrying in 31.529038 seconds
2024/09/14 21:46:42 no DHCP packet received within 10s
2024/09/14 21:46:42 retrying in 63.150490 seconds
2024/09/14 21:47:45 98184616c91f15419f5cacd012697f85afaa2daeb5d3233e28b0ec21589fb45a/iot/eth1: no more tries
2024/09/14 21:47:45 98184616c91f15419f5cacd012697f85afaa2daeb5d3233e28b0ec21589fb45a/iot/eth1: renewal time expired, rebinding
2024/09/14 21:47:45 Link "eth1" down. Attempting to set up
2024/09/14 21:47:45 98184616c91f15419f5cacd012697f85afaa2daeb5d3233e28b0ec21589fb45a/iot/eth1: lease rebound, expiration is 2024-09-14 22:47:45.309270751 +0800 CST m=+11730.048516519
```
Follow the https://datatracker.ietf.org/doc/html/rfc2131#section-4.3.6,
following options must not be sent in renew
- Requested IP Address
- Server Identifier
Since the upstream code has been inactive for 6 years,
we should switch to another dhcpv4 library.
The new selected one is https://github.com/insomniacslk/dhcp.
Signed-off-by: Songmin Li <lisongmin@protonmail.com>
Now that libcni has the ability to print a version message, plumb it
through correctly.
While we're at it,
- fix import paths
- run gofmt
- add some more comments to sample
- add container runtime swappability for release
Updates the spec and plugins to return an array of interfaces and IP details
to the runtime including:
- interface names and MAC addresses configured by the plugin
- whether the interfaces are sandboxed (container/VM) or host (bridge, veth, etc)
- multiple IP addresses configured by IPAM and which interface they
have been assigned to
Returning interface details is useful for runtimes, as well as allowing
more flexible chaining of CNI plugins themselves. For example, some
meta plugins may need to know the host-side interface to be able to
apply firewall or traffic shaping rules to the container.
This takes some of the machinery from CNI and from the rkt networking
code, and turns it into a library that can be linked into go apps.
Included is an example command-line application that uses the library,
called `cnitool`.
Other headline changes:
* Plugin exec'ing is factored out
The motivation here is to factor out the protocol for invoking
plugins. To that end, a generalisation of the code from api.go and
pkg/plugin/ipam.go goes into pkg/invoke/exec.go.
* Move argument-handling and conf-loading into public API
The fact that the arguments get turned into an environment for the
plugin is incidental to the API; so, provide a way of supplying them
as a struct or saying "just use the same arguments as I got" (the
latter is for IPAM plugins).
Path rewriting causes too many problems when vendoring
vendored code. When CNI code is vendored into rkt,
godep has problems code already vendored by CNI.
The plugin binary actually functions in two modes. The first mode
is a regular CNI plugin. The second mode (when stared with "daemon" arg)
runs a DHCP client daemon. When executed as a CNI plugin, it issues
an RPC request to the daemon for actual processing. The daemon is
required since a DHCP lease needs to be maintained by periodically
renewing it. One instance of the daemon can server arbitrary number
of containers/leases.
