| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: kevin <kworm@missouri-telecom.com>
|
|
Signed-off-by: Akshay Navale <navale@dhcp-172-27-23-219.dhcp.thefacebook.com>
|
|
dhcpv6: 4RD option support
|
|
IPv4 Residual Deployment (4RD) is a strategy for providing IPv4
connectivity in IPv6-only networks.
The standard includes autoconfiguration via DHCPv6, as described in
RFC7600. This adds support for the 3 options defined in that RFC
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
This updates the option codes list in dhcpv6/types.go to include all
published option codes as of today. For better formatting of the table,
replace comments indicating undefined options with assignments to the
throwaway variable `_`, which avoids resetting alignment formatting
compared to the comment option.
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
Added additional DHCP4 Relay Agent Information sub options (as per various RFCs).
|
|
RFCs).
Signed-off-by: Mantic <mikey.whitaker@gmail.com>
|
|
server4: Allow listening on a non-wildcard IP address on v4
|
|
IPv6 addresses would not cause a crash, but would silently listen on the
wildcard address instead of the passed address, which is surprising at
best. Instead check for the address family and reject non-v4 addresses
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
Tests use a randPort() workaround for not using port 0, as port 0 is not
usable with raw sockets.
We don't actually use raw sockets, so port 0 is fine, this makes use of
it which ensures we avoid port collisions.
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
NewIPv4UDPConn doesn't support listening on a specific address, only on
the wildcard address. This extends it to allow listening on an address,
and at the same time homogenizes the function signature with the
NewIPv6UDPConn server6 equivalent. It modifies NewServer() to pass the
full address given to it instead of just the port as well
Note that listening on a non-wildcard interface is seldom useful as the
socket won't receive broadcasts, so it is useless in a direct-attached
server. It can be useful in a server only used behind relays
This breaks API compatibility for NewIPv4UDPConn, which as far as I know
nobody uses (yet)
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
dhcpv6: Basic fuzzing support and fixes for discovered bugs
|
|
In both ARP and DHCPv6, the hwtype field is 16bits, and the IANA table
has allocated values >255.
(Bootp however uses 1byte so it can't represent everything)
This was discovered by fuzzing, as it causes round-trip mismatches; eg
with this packet (quoted string):
"0000\x00\x01\x00\x0e\x00\x01000000000000"
Input: 303030300001000e0001303030303030303030303030
Round-trip: 303030300001000e0001003030303030303030303030
^
The upper byte of the hwaddress is set
to 0
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
There were missing error checks in the Message and RelayMessage parsers,
so that truncated headers would be incorrectly accepted as valid
messages. For example the single byte "0" (0x30) would be accepted as a
valid message, then reserialized to 0x30,0x00,0x00,0x00,0x00
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
The uio library doesn't report errors on a per-operation basis, but
accumulates them so they can be checked after a batch of operations in a
separate Error() function. Unfortunately this makes it easy to forget,
thus parse incorrect messages
go-fuzz found immediately that an empty message would be parsed without
error, and reserialize to a different message (one with some bytes of
zeros)
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
This adds the required function for running
[go-fuzz](https://github.com/dvyukov/go-fuzz) on the dhcpv6 library.
It tests the following behaviour:
* Parsing messages doesn't crash
* Parsed messages are identical after being serialized and deserialized
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
server{4,6}: Return UDPConn from NewIPv*UDPConn
|
|
The concrete type under the interface is known here since we create the
connection in the same function. Since *net.UDPConn implements
net.PacketConn anyway, returning the concrete type here is more powerful
and less risky than having downstream users cast the value themselves
There should be no code change for downstream users, with the exception
of explicit casts (`udpc := conn.(*net.UDPConn)`), which can simply be
removed
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
DHCPv6 Server multicast handling improvements
|
|
Similar to server4 where the UDP connection is manually created using
the socket interfaces, this creates a connection with adequate options:
* SO_BINDTODEVICE or equivalent if an interface is requested
* V6ONLY when supported by the operating system
* Allows binding to a multicast address specifically instead of
falling back to wildcard
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
This moves the implementations of the BindToInterface to the interfaces/
package, since they aren't ipv4-specific.
The BindToInterface function remains in dhcpv4 (simply wraps the one in
interfaces) to keep backwards-compatibility
Additionally, fold bindtodevice_darwin into bindtodevice_bsd: darwin is
mostly a BSD, and happens to support IP_RECVIF, so use that instead of
IP_BOUND_IF, which only affects sends, not receives according to the
code comments in bsd/netinet/ip_output.c as well as being v4-only
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
Joining a multicast group with an address that can't be received on a
socket is ineffective, at least on linux.
This updates the logic of NewServer in a mostly backwards-compatible
way, to enable listening on arbitrary multicast addresses:
* Unicast addresses see no user-visible change, but don't join a
multicast group for which they don't receive traffic anyway
* Multicast addresses start actually receiving traffic for the group
they represent, and don't join the default group. **this is a
behaviour change**: previously they would receive traffic for the
default group if it was on the same port and **not** for the group
they represent. I consider that previous behaviour a bug
* Wildcard addresses, if on the proper port, will join both
AllDHCPRelayAgentsAndServers and AllDHCPServers **this is a behaviour
change**: previously only AllDHCPRelayAgentsAndServers was joined
* Wildcard addresses on another port: no visible change, same as
unicast case
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
|
|
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>
|
|
RFC 1700 recommends a value of 64 for the default IP time to live (TTL)
parameter. This is only necessary for the V4 client because it uses
the net.PacketConn, while the IPv6 implementation uses a net.UDPConn instead.
From https://tools.ietf.org/html/rfc1700:
IP TIME TO LIVE PARAMETER
The current recommended default time to live (TTL) for the
Internet Protocol (IP) [45,105] is 64.
Signed-off-by: Ross Hanson <rosshanson@google.com>
|
|
Added a bind to interface functionality.
|
|
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>
|
