| Age | Commit message (Collapse) | Author |
|---|
|
No need to convert these types.
|
|
Now the CI will also run golangci-lint
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Signed-off-by: Christopher Koch <chrisko@google.com>
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
* dhcpv4: Add OptRootPath
Adds a root path option that supports DHCPv4 option 17
* Add root path parsing to giant option parsing switch
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add support for parsing option 124 which is Vendor-Identifying Vendor
Class which is defined in https://tools.ietf.org/html/rfc3925.
|
|
|
|
|
|
Added several DHCPv4 options
|
|
|
|
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
|
|
|
