| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Deomid "rojer" Ryabkov <rojer9@fb.com>
|
|
|
|
Signed-off-by: Pablo Mazzini <pmazzini@gmail.com>
|
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009
"Note that the dhcpv6 protocol doesn't have an option for a netmask. So
it is always /128 and routing is left to icmpv6 router advertisements."
RFC 5942 is a good read here as well:
An address could be acquired through the DHCPv6 identity association
for non- temporary addresses (IA_NA) option from [RFC3315] (which
does not include a prefix length), or through manual configuration
(if no prefix length is specified). The host incorrectly assumes an
invented prefix is on-link. This invented prefix typically is a /64
that was written by the developer of the operating system network
module API to any IPv6 application as a "default" prefix length when
a length isn't specified.
As DHCP developers, we *HAVE* to assume that no prefix is on-link. The
correct way to do that is to specify the netmask as /128.
The kernel will RA/RS their way around to figure out what prefixes are
indeed on-link.
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>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
Signed-off-by: Chris Koch <chrisko@google.com>
|
|
After adding the higher-level [rtnl package](https://github.com/jsimonetti/rtnetlink/pull/44)
let's switch to it.
Pending https://github.com/jsimonetti/rtnetlink/pull/50
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
Fixes #257
And saves ~100kb.
Signed-off-by: Andrea Barberio <insomniac@slackware.it>
|
|
dhcpv6.DHCPv6Message -> dhcpv6.Message
dhcpv6.DHCPv6Relay -> dhcpv6.RelayMessage
|
|
* Allow Unknowo OperState of the link interface
We hig a bug when Netconf library was failing to bring interface up
despite the fact that it was actually up. It turned out that it's oper
state was not set to UP, what is expected by the library.
According to kernel documentation it is ok proceed if interface state
is Up or Unknown:
```
Interface is in RFC2863 operational state UP or UNKNOWN. This is for
backward compatibility, routing daemons, dhcp clients can use this
flag to determine whether they should use the interface.
```
Also, resaon why operational state may remain Unknown:
```
IF_OPER_UNKNOWN (0):
Interface is in unknown state, neither driver nor userspace has set
operational state. Interface must be considered for user data as
setting operational state has not been implemented in every driver.
```
I modified our code to try DHCP transaction even if `IfUp` failed, but
the OperState was equal to Unknown - it worked perfectly.
* Skip rt7 test also with go 1.10 and 1.11
As per request from @pmazzini.
|
|
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}, ...))
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To appease linters
|
|
|
|
|
|
|
|
getter (#62)
|
|
Added netboot package
|
