Age | Commit message (Collapse) | Author |
|
Clients without an IP set their source address to 0.0.0.0, so the peer
returned by ReadFrom may not actually be the address to send to.
Clients without an IP should have their response broadcast.
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
No need to convert here.
|
|
No need to convert these types.
|
|
Simple, nit-picky typo fixes.
|
|
|
|
Usually this is used for clients that don't know how to receive any
other packets. We can deal with both a unicast or broadcast response
packet, so let's let the server decide on its own.
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
|
|
Nobody gives a hoot about the hardware type.
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
|
|
When reading raw packets from the network, it can happen that the raw
ethernet packet read has undefined bytes after the end of the ip
packet (either from the network or in some cases from the local
stack).
Those bytes should not be passed to the dhcp-receiver otherwise the
option parser which is picky about final padding byte will silently
discard the dhcp-reply.
Rename ipLen, udpLen variables with more explicit names to avoid
confusion between header, payload, total length possibly considered
in this function.
Tested: ast2500 bmc reproducing the issue + existing go test for coverage.
Signed-off-by: Loic Prylli <lprylli@netflix.com>
|
|
|
|
|
|
- dnsmasq has been seen to null-terminate the bootfile option,
similar treament can occur for tftp-servername (although
tftp-servername option usage is less common).
- for the gateway information to be present in final packet,
the Router option should be queried again in request as
in discover (which matches behavior of udhcpc/dhclient).
Tested: pxeboot with u-root on dnsmask/ipv4 client.
Signed-off-by: Loic Prylli <lprylli@netflix.com>
|
|
|
|
|
|
|
|
Relays might drop packets coming from clients if they have the
Gateway IP set. This modifier is supposed to be used by relays:
`WithReply` is used only by clients.
|
|
Now the CI will also run golangci-lint
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Mostly addressed missing error checking.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Mostly for dead code and potentially wrong comparisons.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
NewReplyFromMessage creates a reply from a message. With this patch it
can handle Solicit messages with rapid-commit.
RFC3315 states that:
```
If the client has included a Rapid Commit option in its Solicit
message, the client terminates the waiting process as soon as a Reply
message with a Rapid Commit option is received.
```
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
The current implementation has a bug, so that it always returns `nil`,
even when an error happened. This PR fixes it.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
The previous logic was wrong - there's no "listening" on multicast
address, the server should listen on the given address, and join the
multicast group. This PR fixes it.
Also moved the multicast addresses to a common package.
Tested with unit/integ tests, and with coredhcp.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
After adding the higher-level [rtnl package](https://github.com/jsimonetti/rtnetlink/pull/44)
let's switch to it.
Pending https://github.com/jsimonetti/rtnetlink/pull/50
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
IAID must be set by the client. This patch generates the IAID from the
MAC address of the interface. To do so, a new WithIAID modifier is
added, the interface of NewSolicitWithCID now requires a hwaddr
parameter, and NewAdvertiseFromSolicit copies the IA_NA option from the
solicit if present.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
This reverts commit b071bdc86a58037f6c745647c97fca202f3caef9.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
IAID must be set by the client. This patch generates the IAID from the
MAC address of the interface. To do so, a new WithIAID modifier is
added, the interface of NewSolicitWithCID now requires a hwaddr
parameter, and NewAdvertiseFromSolicit copies the IA_NA option from the
solicit if present.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Why did I ever think this would work??
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
Server6 and Server4 had Serve methods that return without reporting an
error, changed in this PR.
Serve now also closes the connection when done.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Fixes #257
And saves ~100kb.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
|
|
- RapidCommit solicits wait for Reply messages, not Advertise.
- Default recipient should be all relay agents and servers, not just
servers.
- Make New() and NewWithConn() interface same as in nclient4.
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
- Race-condition-averse.
- Supports multiple concurrent requests.
- Tested.
- Requires a fully compatible net.PacketConn.
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
Fixes #246
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
After investigation on DHCP relaying with BDCOM P3608 GPON OLT switches, i found that 'End' option is not always padded with 0x00, but for some packets is padded by the same 0xFF (End) option.
DHCPv4 fails to parse such type of packets and throws an "Invalid options" error. But Wireshark says that all is just fine with 0xFF padding.
This commit allows to use 0xFF/0x00 End option padding instead of strict 0x00. This allows BDCOM switches relaying mechanism to work with package.
|
|
|
|
|
|
Certain older DHCP servers and relay agents follow the RFC 951 BOOTP
standard in which BOOTP/DHCP messages have a 300 byte minimum length.
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
|
|
- Able to send UDP packets before interface is configured.
- Able to use any net.PacketConn.
- RFC2131-compliant retransmission logic.
- Tests.
- Race-condition-averse.
Previous clients (both mine and the ones here) are prone to race
condition errors.
Having one and only one place that calls receive on the socket
"continuously" without having to coordinate hand-offs makes the logic
way easier to follow, and allows for multiple requests in flux at a
time.
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
|
|
|
|
|
|
|
|
|