Re: [LEDE-DEV] ARM64 platform updates

[Christian Lamparter via Lede-dev]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hello,

On Tuesday, April 11, 2017 12:13:42 PM CEST Florian Fainelli wrote:
> I am planning on switch the arm64 multiplatform target to 4.9 and remove
> support for the ARM Foundation v8 model since QEMU is just nicer.
> 
> Any objections?
> 
No objections per se. But since you are already updating the arm64 target,
why not also do the same to armvirt? After all, both are mostly virtual 
targets and from what I can tell, it's just ARMv8 vs ARMv7
(or maybe can these be folded into one?)

Regards,
Christian

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] ARM64 platform updates

[Florian Fainelli]

Hi all,

I am planning on switch the arm64 multiplatform target to 4.9 and remove
support for the ARM Foundation v8 model since QEMU is just nicer.

Any objections?
-- 
Florian

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] shutting down a build server

[Dave Taht]

I am no longer in a position to keep

http://phase2.builds.lede-project.org/buildslaves/dave-builder

funded and operational, and would like to shut it down by
the end of the month.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Planning v17.01.1

[txt.file]

NACK for a RC. For reasons see what Hannu said.



kind regards
txt.file
--
This message is signed.

Hannu Nyman:
> On 9.4.2017 17.14, Jo-Philipp Wich wrote:
>> I'd like to start preparing the v17.01.1 release during the upcoming
>> week with the goal to release final binaries during the easter holidays
>> (~14.04. - 17.04.).
>> ...
>> Also, please reply with a quick ACK / NACK on whether you'd like to see
>> an -RC build before 17.01.1 final.
> 
> 
> The proposed timing for 17.01.1 sounds good.
> 
> NACK for rc.
> I see no need for rc1 as long as there is no last-minute rush to
> backport things on large scale. 17.01 builds have been so stable that
> there should be no major problems.
> 
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH odpcpd] dhcpv6: allow creating new bindings on REBIND

[Hans Dedecker]

On Mon, Apr 10, 2017 at 11:08 AM, Lubomir Rintel  wrote:
> There might be unassigned IAs among the options the client sends when it
> issues a REBIND. In fact, that's how the ISC dhclient reqests new IA_PDs
> to be assigned. However, odhcpd would just return the IA_PDs back
> without assigning a prefix:
>
>   $ dhclient -6 -d -lf $PWD/leases eth0 -N
>   XMT: Forming Solicit, 0 ms elapsed.
>   XMT:  X-- IA_NA 00:3b:dd:9d
>   RCV: Advertise message on eth2 from fe80::5054:ff:feba:444e.
>   RCV:  X-- IA_NA 00:3b:dd:9d
>   ^C
>   $ dhclient -6 -d -lf $PWD/leases eth0 -N -P
>   XMT: Forming Rebind, 0 ms elapsed.
>   XMT:  X-- IA_NA 00:3b:dd:9d
>   XMT:  X-- IA_PD 00:3b:dd:9d
>   RCV: Reply message on eth2 from fe80::5054:ff:feba:444e.
>   RCV:  X-- IA_NA 00:3b:dd:9d
>   RCV:  X-- IA_PD 00:3b:dd:9d
>   RCV:  | !-- Status code of no prefix, IA_PD discarded.
>
> That is neither too useful, nor consistent with what the ISC dhcpcd does,
> nor does it seem correct. Notably, it breaks NetworkManager's IPv6
> connection sharing that utilizes the ISC dhclient and needs to request the
> prefixes as-needed on networks with OpenWRT.
>
> The attached patch moves the REBIND handling to the branch that is able
> to add new bindings. It then, perhaps unnecessarily, also allows
> obtaining new IA_NAs this way.
>
> (While the patch fixes the issue for me, I'm not too familiar with the
> odhcpd code base, so a careful review is needed.)
>
> Signed-off-by: Lubomir Rintel 
> ---
>  src/dhcpv6-ia.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c
> index 09022a4..c3eecfe 100644
> --- a/src/dhcpv6-ia.c
> +++ b/src/dhcpv6-ia.c
> @@ -1093,8 +1093,9 @@ ssize_t dhcpv6_handle_ia(uint8_t *buf, size_t buflen, 
> struct interface *iface,
> uint16_t status = DHCPV6_STATUS_OK;
> if (a && a->managed_size < 0)
> return -1;
> -
> -   if (hdr->msg_type == DHCPV6_MSG_SOLICIT || hdr->msg_type == 
> DHCPV6_MSG_REQUEST) {
> +   if (hdr->msg_type == DHCPV6_MSG_SOLICIT ||
> +   hdr->msg_type == DHCPV6_MSG_REQUEST ||
> +   hdr->msg_type == DHCPV6_MSG_REBIND) {
Creation of an assignment when a rebind is received is allowed for
IA_PD according to RFC6704 but this change will also create an
assignment for IA_NA which is not allowed to RFC3315. On top the IA_PD
bindings present in the rebind messages need to be checked if they're
valid which is already done in append_reply
> bool assigned = !!a;
>
> if (!a && !iface->no_dynamic_dhcp) {
> @@ -1189,8 +1190,7 @@ ssize_t dhcpv6_handle_ia(uint8_t *buf, size_t buflen, 
> struct interface *iface,
> if (!a && hdr->msg_type != DHCPV6_MSG_REBIND) {
> status = DHCPV6_STATUS_NOBINDING;
> ia_response_len = append_reply(buf, buflen, 
> status, ia, a, iface, false);
> -   } else if (hdr->msg_type == DHCPV6_MSG_RENEW ||
> -   hdr->msg_type == DHCPV6_MSG_REBIND) {
> +   } else if (hdr->msg_type == DHCPV6_MSG_RENEW) {
Correct patch would be to create here an assignment when receiving a
rebind with an IA_PD

Hans
> ia_response_len = append_reply(buf, buflen, 
> status, ia, a, iface, false);
> if (a) {
> a->flags |= OAF_BOUND;
> --
> 2.9.3
>

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev