dhcpcd.git, branch dhcpcd-7.0.4 DHCP / IPv4LL / IPv6RA / DHCPv6 client Release dhcpcd-7.0.4 2018-05-02T21:49:11+00:00 Roy Marples roy@marples.name 2018-05-02T21:49:11+00:00 8fa3e436e443c358034b7e095f2fcb96c7481110 






dhcp6: Softwire Address and Port-Mapped Clients, RFC7598
2018-05-02T21:28:31+00:00

Roy Marples
roy@marples.name

2018-05-02T21:28:31+00:00

cce54a1d8a3a9908f417d6b3028a8197abbf01bf

Add support for these options.
Untested, should work aside from the documented issue, patches welcome.





Add support for these options.
Untested, should work aside from the documented issue, patches welcome.







ipv6nd: use bools here
2018-05-02T21:03:25+00:00

Roy Marples
roy@marples.name

2018-05-02T21:03:25+00:00

2aca3a18d87c837b594b126b895c799185c5712f












ipv6nd: warn if router lifetime is set to zero
2018-05-02T21:01:18+00:00

Roy Marples
roy@marples.name

2018-05-02T21:01:18+00:00

c15437c10472402bbf5b42f020d51b6539be480f












Don't abort if recv returns an error.
2018-05-01T18:55:02+00:00

Roy Marples
roy@marples.name

2018-05-01T18:55:02+00:00

bd1d84215cbc5b70f78838956660deb1c3fe9ba0












auth: allow different tokens for send and receive
2018-04-29T20:38:58+00:00

Roy Marples
roy@marples.name

2018-04-29T20:38:58+00:00

32945b618c1456aa23755d0a540495309dcfc41c

It was silly of me to assume that the same key would be used for
both sending and receiving. Because token protocol is not digested,
replace the digest argument with 0x123/0x456 where 0x123 is the
sending key and 0x456 is the receiving key.
Receiving key defaults to sending key, sending key defaults to zero.
This should allow existing configurations to work as is.





It was silly of me to assume that the same key would be used for
both sending and receiving. Because token protocol is not digested,
replace the digest argument with 0x123/0x456 where 0x123 is the
sending key and 0x456 is the receiving key.
Receiving key defaults to sending key, sending key defaults to zero.
This should allow existing configurations to work as is.







auth: allow zero value replay detection data
2018-04-29T20:28:15+00:00

Roy Marples
roy@marples.name

2018-04-29T20:28:15+00:00

5b0fec0584b2eda14f9a3ab8c7c18e91c1e7be39

It seems one ISP doesn't use Replay Data and always sets it to zero.
See the comment in the commit as to why this is technically legal,
even if it goes against the intent of the RFC.





It seems one ISP doesn't use Replay Data and always sets it to zero.
See the comment in the commit as to why this is technically legal,
even if it goes against the intent of the RFC.







dhcpcd(8): document some servers might filter based on ClientID
2018-04-29T08:31:18+00:00

Roy Marples
roy@marples.name

2018-04-29T08:31:18+00:00

fb0a2abbcdda8eb7cec3ef1f8ae8122ed7296e06

Note that the DUID file might need to be edited as well.





Note that the DUID file might need to be edited as well.







RFC 3315 21.4.4.1 says that SOLICT and DELAYED authentication
2018-04-26T18:35:43+00:00

Roy Marples
roy@marples.name

2018-04-26T18:35:43+00:00

ef6dbd0facc331c2ab71c8d091baf1e8965d14cc

should set RDM and replay data to zero.
draft-ietf-dhc-dhcpv6-clarify-auth-01 (expired) suggests that
INFORMATION REQ should be zero in this case as well.

As it's coming from a very similar angle, I agree.





should set RDM and replay data to zero.
draft-ietf-dhc-dhcpv6-clarify-auth-01 (expired) suggests that
INFORMATION REQ should be zero in this case as well.

As it's coming from a very similar angle, I agree.







logerr -> logerrx
2018-04-19T20:44:41+00:00

Roy Marples
roy@marples.name

2018-04-19T20:44:41+00:00

276b09d9454701805dfff3319615af9498c4ed40