| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Allow the Options type to have getters for each specific options, in
order to avoid users having to cast options to their specific type.
This commit introduces a getter for exactly one option: the
ClientArchType.
i.e. users can replace
archTypes := msg.GetOneOption(OptionClientArchType).(*OptClientArchType)
with
archTypes := msg.Options.ArchTypes()
Because a few message types and options embed options (normal message,
relay message, IANA/IATA option) and each have a restricted set of
options that can be used inside them, we'll introduce at least 3 or more
Options subtypes:
- MessageOptions
- RelayOptions
- IdentityOptions
Perhaps others will join at a later time, such as VendorOptions or
AddressOptions for the IAAddress options field.
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
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>
|
|
Mostly for dead code and potentially wrong comparisons.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
NewReplyFromMessage creates a reply from a message. With this patch it
can handle Solicit messages with rapid-commit.
RFC3315 states that:
```
If the client has included a Rapid Commit option in its Solicit
message, the client terminates the waiting process as soon as a Reply
message with a Rapid Commit option is received.
```
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
IAID must be set by the client. This patch generates the IAID from the
MAC address of the interface. To do so, a new WithIAID modifier is
added, the interface of NewSolicitWithCID now requires a hwaddr
parameter, and NewAdvertiseFromSolicit copies the IA_NA option from the
solicit if present.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
This reverts commit b071bdc86a58037f6c745647c97fca202f3caef9.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
IAID must be set by the client. This patch generates the IAID from the
MAC address of the interface. To do so, a new WithIAID modifier is
added, the interface of NewSolicitWithCID now requires a hwaddr
parameter, and NewAdvertiseFromSolicit copies the IA_NA option from the
solicit if present.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Fixes #246
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
- Make members directly accessible.
|
|
dhcpv6.DHCPv6Message -> dhcpv6.Message
dhcpv6.DHCPv6Relay -> dhcpv6.RelayMessage
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To appease linters
|
|
Renames DHCPv6 constants for message types to CamelCase
|
|
add DecapsulateRelayIndex
|
|
|
|
|
|
|
|
|
|
Add a more generic NewReplyFromMessage to avoid code duplication.
This is one step closer towards fixing issue #73.
Leave NewReplyFromRequest, NewReplyFromRenew and NewReplyFromRebind
for backwards compatibility.
|
|
|
|
|
|
add NewAdvertiseFromSolicit
|
|
dhcpv6: added modifiers
Added support for packet modifiers, i.e. functions that can arbitrarily
manipulate a DHCPv6 packet. These modifiers are used by NewMessage,
NewSolicitForInterface, NewRequestForAdvertise, and can be used by other
packet creation functions.
A bunch of sample modifiers have been added under modifiers.go , too.
With the introduction of modifiers I also removed some options that
should not necessarily be in a standard DHCPv6 message.
|
|
|
|
|
|
implementations
|
|
|
