| Age | Commit message (Collapse) | Author |
|---|
|
In DHCPv4, when the ParameterRequestList option is not present in a
request, it should be assumed that the client wants to receive all the
options that the server is able to send. This changes the
IsOptionRequested method of dhcpv4.DHCPv4 to return true for any request
in that situation.
The reasoning is based on this wording in
[RFC2131§3.5](https://tools.ietf.org/html/rfc2131#section-3.5):
> Not all clients require initialization of all parameters listed in
> Appendix A. Two techniques are used to reduce the number of
> parameters transmitted from the server to the client. [...] Second, in
> its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide
> the server with a list of specific parameters the client is interested
> in.
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
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>
|
|
- 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>
|
|
|
|
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>
|
|
|
|
From:
r := d.GetOneOption(OptionRouter).(*OptRouter).Routers
d.UpdateOption(&OptRouter{Routers: []net.IP{net.IP{192, 168, 0, 1}}})
To:
r := GetRouter(d.Options)
d.UpdateOption(OptRouter(net.IP{192, 168, 0, 1}, ...))
|
|
Removes AddOption and GetOption.
RFC 2131 specifies that options may only appear once (Section 4.1). If
an option does appear more than once, its byte values must be
concatenated.
RFC 3396 further specifies that to send options longer than 255 bytes,
one option may be split into multiple option codes, which must be
concatenated back together by the receiver.
Both of these are concerned with the byte representation of options.
Fact is, based on both RFCs one can say that an option may only appear
once, but may be composed of multiple values.
Because an option may appear only once logically in any case, we remove
the AddOption and GetOption functions and leave only UpdateOption and
GetOneOption.
Also remove all additions & checks of the End option - the marshaling
and unmarshaling code is exclusively responsible for that now.
|
|
|
|
|
|
option's codes and lengths were being parsed twice: once in ParseOption
and once in each option type's Parse implementation. Consolidate such
that it only happens once.
Additionally, only pass data to options that they should parse -- we
know the length before the Parse function is called, so the option only
gets to see the data it needs to see.
Also, use uio.Lexer to simplify parsing code in general. Easier to read
and reason about.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Added String methods for types
* Reverted change on bsdp.OptionCode
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Adds new `OptionGetter` interface that helps when asserting that certain
packets/vendor-specific opts contain specific options.
|
|
|
|
This refactors the input parameters for construction DISCOVER/INFORM*
packets so that it's easier to write unit tests for DHCPv4 and BSDP
methods. It also adds a bunch of unit tests for both packages and rounds out
their test coverage.
|
|
|
|
|
|
GetOption and GetOneOption are convenience methods for getting a DHCPv4
option from its Option Code.
GetOption returns a list of options that match since the DHCP RFC allows
for an option to be present multiple times with its values appended
together. (Note: I am not sure I've ever seen this done and it's not clear if
how option parsing would work for more complex values. Is appending
done at the byte level? )
GetOneOption will return the first found option that matches a code.
|
|
|
|
|
|
stretchr/testify/assert for nicer asserts
|
|
Adds support for constructing INFORM/ACK messages from Apple's Boot
Service Discovery Protocol for netbooting (pxebooting) Apple hardware.
The canonical reference for BSDP is: http://opensource.apple.com/source/bootp/bootp-198.1/Documentation/BSDP.doc
|
|
|
