It wasn't really necessary to hold pointers inside a slice (itself a
pointer to array) inside a struct with pointer-recever methods. It's
easier to understand and reason about like this
Signed-off-by: Anatole Denis <anatole@unverle.fr>
This resolves the issue where, when listening on a wildcard address or a
multicast address without binding to an interface, reply packets could
be sent on the wrong interface.
Fixes#52
Signed-off-by: Anatole Denis <anatole@unverle.fr>
This removes the use of dhcp/server{4,6}.Server from coredhcp (but keeps
the connection establishment from NewIpv?UDPConn); instead taking in the
serving logic.
This allows modifying the API between the socket and the handlers
easily, which we do to:
* Use `ipv4/6.PacketConn.ReadFrom`, to obtain additional info on the
packets, notably the incoming interface, to fix the outstanding bug
documented in #52
* Simplify the kludge of listening on multiple addresses
* Move the parsing of the DHCP packet into the per-request goroutine;
so that the routine listening on the connection only copies the bits
before going to the next packet
As a incidental bonus, we can rip out the big kitchen-sink Server struct
Signed-off-by: Anatole Denis <anatole@unverle.fr>
coredhcp.go is not the entrypoint of main (that's cmds/coredhcp) and
contains many tightly-coupled things that could be separated.
This separates the logic into:
* server/serve.go handles setting up connections
* server/handle.go handles parsing and entry into handlers (in
preparation of a larger rewrite)
* plugins/plugin.go gets plugin loading (and doesn't need to access the
Server struct either)
Signed-off-by: Anatole Denis <anatole@unverle.fr>
