* handler: Fix documentation of plugin chaining
This condition was backwards: if the boolean is false, the next plugins
are called and any invalid or nil packet is very likely to cause crashes
in the next plugin. OTOH if true, we stop execution anyway and don't
send a message when resp == nil, so it's OK to be nil or invalid then
Signed-off-by: Anatole Denis <anatole@unverle.fr>
* plugins/file: Avoid nil returns to next plugin
`return nil, false` passes a nil dhcp message to the next plugin in
chain, which is almost guaranteed to crash or fail in some other way.
The proper way to ignore a valid message (because we don't know what to
do with it) is to return the resp argument. The ipv4 version of the
plugin already does so.
Add a note about file being a terminating plugin when a response is
chosen
Signed-off-by: Anatole Denis <anatole@unverle.fr>
* plugins/server_id: Uniformize error returns
`return resp, false` after a log.Fatal is misleading, since the program
will have crashed at this point. `return nil, true` is still dead code
but conveys the meaning of "abort here" better
Same thing for the DHCPv4 version of the code which was forgotten in the
original commit.
Remove the test for `resp == nil` since the previous commits in this
series removed the possibility of receiving a nil resp as argument
Fixes: 4a73abd6 ("plugins/server_id: Abort when ServerID is nil")
Signed-off-by: Anatole Denis <anatole@unverle.fr>
