I see that more as setting a preferred lifetime with a relative time-span.
E.g. I will get a a preferred_lft of 120 from now, and I would set it like:
date '+%d %b %Y %T' --date="@$(($(date +%s)+120))"
So it does not need to be synced, since I'm only interested in the
timespan from now +
> Please use URL:=@OPENWRT instead of the full URL
Okay, done. Sorry, I messed up the message-id in the v2 patch so it
showed up as a new entry:
http://patchwork.ozlabs.org/project/openwrt/patch/20210206051118.641266-1-ilya.lipnits...@gmail.com/
Ilya
On Sat, Jan 30, 2021 at 5:33 PM Nick Hainke wrote:
>
> Until now it is not possible to give absolute timestamps in odhcpd.
> This means that on every new RA or request, the timestamp is renewed.
> Further, the valid and preferred lifetimes are not synced between all
> devices.
>
> There are
While this change is not required for 5.4, it will help when we enable
kernel v5.10.
With Linux 5.10 this driver cannot be built because we have two modules
with the same name and it leads to an error:
error: the following would cause module name conflict:
drivers/dma/mediatek/mtk-hsdma.ko
Hi,
> -Original Message-
> From: Andreas Ziegler [mailto:d...@andreas-ziegler.de]
> Sent: Samstag, 6. Februar 2021 19:23
> To: Adrian Schmutzler ; openwrt-
> de...@lists.openwrt.org
> Subject: Re: Initial flashing over "OEM-OpenWrt"
>
> Hi,
>
> wouldn't this solution stop to work as
Hi,
wouldn't this solution stop to work as soon as some OEM-OpenWrt is
rebased on OpenWrt and knows about compat_version?
If i'm wrong, please enlighten me.
Regards
Andreas
Adrian Schmutzler wrote on 06.02.21 17:42:
> Hi,
>
> when reviewing device-support PRs, I frequently encounter the
Hi,
when reviewing device-support PRs, I frequently encounter the case that initial
flashing means sysupgrading from an OEM-modified OpenWrt.
This obviously means that the config of this OEM-OpenWrt should be wiped to
prevent config-clashes, but since we only provide sysupgrade in this case we