summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)Author
2020-02-10Merge pull request #355 from 10000TB/davidhu-dhcpv6-fqdnPablo Mazzini
dhcpv6 fqdn: implements OptionFQDN option
2020-02-06hcpv6 fqdn: implements OptionFQDN optionXuehao (David) Hu
per https://tools.ietf.org/rfc/rfc4704.txt Signed-off-by: Xuehao (David) Hu <xuehaohu@google.com>
2020-01-24travis: disable go tipChris K
Signed-off-by: Chris Koch <chrisko@google.com>
2020-01-24Fix a compare in Serve() of IP4 Zero to use an IP4 addressRonald G. Minnich
Fixes, among other things, u-root pxeserver Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
2020-01-09interfaces: add support for AIXClément Chigot
Signed-off-by: Clément Chigot <clement.chigot@atos.net>
2020-01-02v6: give proper names to some common OptionCodesChris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2020-01-02Fix "conn" leaking, which eventually leads to thread exhaustion on machines ↵Leandro Martelli
with many NICs Signed-off-by: Leandro Martelli <martelli@epix.com.br>
2020-01-02v6: use time.Duration for duration fieldsChris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-12-12[netboot] Add support of BootfileParam to "netboot"Dmitrii Okunev
Signed-off-by: Dmitrii Okunev <xaionaro@fb.com>
2019-12-12[dhcpv6] Add option BootfileParam to DHCPv6 clientDmitrii Okunev
Added support of option OptBootFileParam. See RFC5970 section 3.2. Signed-off-by: Dmitrii Okunev <xaionaro@fb.com>
2019-12-03dhcpv4: add Client Identifier option; respect RFC 6842Chris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-12-03dhcpv4: add max lease timeChris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-11-29Merge pull request #336 from xaionaro-facebook/masterPablo Mazzini
Added option nclient4.WithHWAddr
2019-11-29Added option nclient4.WithHWAddrDmitrii Okunev
This option allows to receive answers DHCP with arbitrary client addresses Signed-off-by: Dmitrii Okunev <xaionaro@fb.com>
2019-11-29Merge pull request #335 from xaionaro-facebook/masterPablo Mazzini
Simplified porting from client4 to nclient4
2019-11-28Simplified porting from client4 to nclient4Dmitrii Okunev
Signed-off-by: Dmitrii Okunev <xaionaro@fb.com>
2019-11-20Add test for WithRelayAgentInfo modifier.kevin
Signed-off-by: kevin <kworm@missouri-telecom.com>
2019-11-20Update function name in NewReplyFromRequestkevin
Signed-off-by: kevin <kworm@missouri-telecom.com>
2019-11-20Remove dhcpv4 namespacekevin
Signed-off-by: kevin <kworm@missouri-telecom.com>
2019-11-20Rename function to WithRelayAgentInfokevin
Fix syntax nits Simplified function as suggested by @pmazzini Signed-off-by: kevin <kworm@missouri-telecom.com>
2019-11-20Add support for copying relay optionskevin
Signed-off-by: kevin <kworm@missouri-telecom.com>
2019-11-12[dhcpv6]Adding opt 16 when parsing vendor optionsAkshay Navale
Signed-off-by: Akshay Navale <navale@dhcp-172-27-23-219.dhcp.thefacebook.com>
2019-11-05Merge pull request #329 from Natolumin/4rdPablo Mazzini
dhcpv6: 4RD option support
2019-11-03dhcpv6: Add support for 4RD optionsAnatole Denis
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>
2019-11-03dhcpv6: Add all current option codes from IANAAnatole Denis
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>
2019-10-25Merge pull request #328 from Mantic/masterPablo Mazzini
Added additional DHCP4 Relay Agent Information sub options (as per various RFCs).
2019-10-25Added additional DHCP4 Relay Agent Information sub options (as per various ↵Mantic
RFCs). Signed-off-by: Mantic <mikey.whitaker@gmail.com>
2019-10-16Merge pull request #327 from Natolumin/homogenize_udpconn_v4v6Pablo Mazzini
server4: Allow listening on a non-wildcard IP address on v4
2019-10-15server4: Only allow IPv4 addressesAnatole Denis
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>
2019-10-15server4: Use port 0 in testsAnatole Denis
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>
2019-10-15server4: Respect listen addressAnatole Denis
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>
2019-10-11Merge pull request #325 from Natolumin/fuzz6Pablo Mazzini
dhcpv6: Basic fuzzing support and fixes for discovered bugs
2019-10-08iana: HWType is 16 bitsAnatole Denis
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>
2019-10-08dhcpv6: Add error checks to message parsersAnatole Denis
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>
2019-10-08dhcpv6: Reject empty messagesAnatole Denis
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>
2019-10-07dhcpv6: Add a fuzzing entrypoint for go-fuzzAnatole Denis
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>
2019-10-02Merge pull request #323 from Natolumin/return_concrete_type_from_conn_creationPablo Mazzini
server{4,6}: Return UDPConn from NewIPv*UDPConn
2019-10-01server{4,6}: Return UDPConn from NewIPv*UDPConnAnatole Denis
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>
2019-09-25dhcpv6: simplify boot file URLChris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-09-25server6: allow nil IP in addition to unspecifiedChris K
Signed-off-by: Chris Koch <chrisko@google.com>
2019-09-25dhcpv4: combine small filesChris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-09-24nclient6: copy & paste log infra to v6Chris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-09-23Merge pull request #316 from Natolumin/v6_multicast_fixPablo Mazzini
DHCPv6 Server multicast handling improvements
2019-09-18server6: Create UDP conn manually for more controlAnatole Denis
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>
2019-09-17dhcpv4: Move BindToInterface to interfaces packageAnatole Denis
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>
2019-09-17server6: Fix listening on multicast addressesAnatole Denis
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>
2019-09-16dhcpv4: Mark all options as requested absent PRL (#315)Anatole Denis
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>
2019-09-12Increase DHCPv4 IP TTL from 30 to 64 (#314)Ross Hanson
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>
2019-08-14Bind interface fix (#310)borna-blazevic
Added a bind to interface functionality.
2019-07-29server4: set peer to broadcast if client IP is zeroChris Koch
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 10:47:12 +0000