| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
From:
r := GetRouter(d.Options)
To:
r := d.Router()
|
|
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}, ...))
|
|
|
|
|
|
|
|
|
|
Also drop unnecessary return value of Modifier.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Interface'd OptionCodes can print the correct human string.
It sucks because option codes are just a byte, but depending on where
you use them, they are interpreted differently. BSDP option codes !=
DHCP option codes.
|
|
|
|
|
|
|
|
|
|
- Consolidate writing the option code and length to Options.Marshal
rather than doing it in each individual option.
- Use uio in marshaling code.
|
|
|
|
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.
|
|
|
