summaryrefslogtreecommitdiffhomepage
path: root/dhcpv4
AgeCommit message (Collapse)Author
2020-06-23- make changes based on discussion on PR #386 of insomniacslk/dhcpHu Jun
Signed-off-by: Hu Jun <hujun.work@gmail.com>
2020-06-23Merge branch 'master' of https://github.com/insomniacslk/dhcp into ↵Hu Jun
dhcpv4_release
2020-06-20dhcpv4: Fix a panic in parsing of route optionsAnatole Denis
When parsing a route option with a mask size >32, there would be a panic at option_routes.go:47 as user-supplied data is used without verification for a slice bound, causing a read of masksize/8, whic is possibly >4 bytes. Instead reject the invalid route Signed-off-by: Anatole Denis <natolumin@unverle.fr>
2020-06-20dhcpv4: Also write out 0-length optionsAnatole Denis
When there was a 0-length generic option, it would be omitted. Rapid commit (option 80) is a 0-length option with a length tag. There could also be 0-length options in the vendor extensions, and the RFC states that they should be written out: > Any options defined subsequent to this document should contain a > length octet even if the length is fixed or zero. Signed-off-by: Anatole Denis <natolumin@unverle.fr>
2020-06-20dhcpv4: Remove hlen parameter special case in ToBytes()Anatole Denis
There is a special case for when ClientHwAddr is empty, which seems to only apply when creating a packet with New(), which defaults to HWType==Ethernet but doesn't assign the ClientHwAddr field. All the other New*() constructors assign a hardware address and don't use this codepath Remove this special case and instead make New() generate an almost-correct packet in the first place, so that ToBytes() can stay more generic Signed-off-by: Anatole Denis <natolumin@unverle.fr>
2020-06-20dhcpv4: Avoid a panic in ToBytes() with long stringsAnatole Denis
When BootFileName is longer than 128 bytes or ServerHostName is longer than 64 bytes, trying to null-terminate the strings when writing out the packet causes a panic. Since the ToBytes() function cannot return errors, silently truncate the string instead (we do the same with ClientHWAddr if it is longer than 16 bytes for example) Signed-off-by: Anatole Denis <natolumin@unverle.fr>
2020-06-20dhcpv4: Consolidate identical tests into 1Anatole Denis
Those 2 tests did the exact same thing: check that an invalid packet raises an error when parsed. Merge them into the same test, so that we can easily add more test cases to the list Signed-off-by: Anatole Denis <natolumin@unverle.fr>
2020-06-20dhcpv4: Add go-fuzz endpointAnatole Denis
Signed-off-by: Anatole Denis <natolumin@unverle.fr>
2020-06-18fix some lint complains in example_lease_test.goHu Jun
Signed-off-by: Hu Jun <hujun.work@gmail.com>
2020-06-18- move the example to a separate file example_lease_test.goHu Jun
- fix a few more lint complains Signed-off-by: Hu Jun <hujun.work@gmail.com>
2020-06-17fix some lint errorsHu Jun
Signed-off-by: Hu Jun <hujun.work@gmail.com>
2020-06-17add lease&release support for nclient4Hu Jun
Signed-off-by: Hu Jun <hujun.work@gmail.com>
2020-03-28remove some testsPablo Mazzini
Signed-off-by: Pablo Mazzini <pmazzini@gmail.com>
2020-03-19Added support for a custom logger when instantiating the server4 orValerio Santinelli
server6 object Signed-off-by: Valerio Santinelli <santinelli@altralogica.it>
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>
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-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-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-10-25Added additional DHCP4 Relay Agent Information sub options (as per various ↵Mantic
RFCs). Signed-off-by: Mantic <mikey.whitaker@gmail.com>
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-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-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-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-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>
2019-07-22Fixed unnecessary conversions (#304)Christian Muehlhaeuser
No need to convert these types.
2019-07-22Fixed typos in dhcpv4 (#303)Christian Muehlhaeuser
Simple, nit-picky typo fixes.
2019-07-05v4 discover: don't ask for broadcastChris Koch
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>
2019-06-27dhcpv4: actually use random number timeoutChris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-06-19dhcpv4: make the short stringer more usefulChris Koch
Nobody gives a hoot about the hardware type. Signed-off-by: Chris Koch <chrisko@google.com>
2019-06-19nclient4: add logging optionsChris Koch
Signed-off-by: Chris Koch <chrisko@google.com>
2019-05-24Changing Arista cid regex forprepended bytes (#293)Akshay Navale
2019-05-22Ignore bytes after end of IP packet in BroadcastRawUDPConn.ReadFrom (#292)lprylli
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>
2019-05-15Adding Juniper EX pattern for circuit parsing (#291)Akshay Navale
2019-05-14Remove SHIFT IN character bytes from Circuit ID (#289)Akshay Navale
2019-05-14Improve compatibility with some ipv4 networks.Loic Prylli
- 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>
2019-05-09NewReplyFromRequest: copy gw ipPablo Mazzini
2019-05-09NewReplyFromRequest: copy gw ipPablo Mazzini
2019-05-09[dhcpv4] Do not Gateway IP address on packets sent by clients (#287)Marco Guerri
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.
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-09 09:13:43 +0000