Re: [LEDE-DEV] odhcpd: possible regression in make DHCPv4 support compiletime configurable

[Dirk Brenken]

Hi,

from my perspective a toolchain bug in CMAKE-based packages like odhcpd
or uttpd, see FS#1189.

best regards
dirk

On Fr, 2017-11-24 at 12:57 -0500, Eric Luehrsen wrote:
> On 11/23/2017 03:54 AM, Hans Dedecker wrote:
> > Hi,
> > 
> > On Thu, Nov 23, 2017 at 6:38 AM, Eric Luehrsen  > com> wrote:
> > > FS#1188 has been raised due to problems for optional build
> > > recipes in
> > > "dhcpv4: make DHCPv4 support compiletime configurable"
> > > (d80621fea5cafcdca3f7fe762fede374a66e4b2) because no odhcpd-full
> > > package is
> > > build bot available. However, it also appears that conditionally
> > > compiling
> > > DHCPv4 back in does not work. This may be a rather significant
> > > regression.
> > 
> > I'm running odhcpd as DHCPv4 server in a CI setup and don't notice
> > any issue.
> > Please provide more info as requested in
> > https://bugs.lede-project.org/index.php?do=details_id=1188 to
> > facilitate trouble shooting as I'm unable to reproduce the issue.
> > 
> > Hans
> > > - Eric
> 
> It seems that it was something happening in 'make' (w/ CMake) build 
> avoidance. In an attempt to figure it out, I think I lost the rabbit.
> My 
> system works now as well.
> 
> - Eric
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

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

Re: [LEDE-DEV] WRT3200ACM crashes after mac80211 wireless-testing 2017-11-01

[Syrone Wong]

The comparison results as below, db2fw is the current one we are
using(aka the 'Not Applicable' patch), db2bin is the RFC patch.

You can see they generate files with different length.

command: diff -y <(xxd reg-db2fw) <(xxd reg-db2bin)

: 5247 4442  0014 3030 02ca 4144 034b  RGDB00 |
: 5247 4442  0014 3030 03c2 4144 0455  RGDB00
0010: 4145 032c 4146 0359 4149 0359 414c 0359  AE.,AF.YAI |
0010: 4145 0434 4146 0464 4149 0464 414c 0464  AE.4AF.dAI
0020: 414d 0312 414e 0359 4152 032c 4153 02c2  AM..AN.YAR |
0020: 414d 0414 414e 0464 4152 0434 4153 03b9  AM..AN.dAR
0030: 4154 02f2 4155 029b 4157 0359 415a 0370  AT..AU..AW |
0030: 4154 03f0 4155 038b 4157 0464 415a 0480  AT..AU..AW
0040: 4241 02f2 4242 0318 4244 02f9 4245 02f2  BA..BB..BD |
0040: 4241 03f0 4242 041a 4244 03f8 4245 03f0  BA..BB..BD
0050: 4246 032c 4247 0345 4248 02eb 424c 0359  BF.,BG.EBH |
0050: 4246 0434 4247 044d 4248 03e8 424c 0464  BF.4BG.MBH
0060: 424d 02c2 424e 02e4 424f 0334 4252 032c  BM..BN..BO |
0060: 424d 03b9 424e 03e0 424f 043c 4252 0434  BM..BN..BO
0070: 4253 0330 4254 0359 4259 0359 425a 0349  BS.0BT.YBY |
0070: 4253 0438 4254 0464 4259 0464 425a 0452  BS.8BT.dBY
0080: 4341 02c6 4346 034f 4348 02f2 4349 032c  CA..CF.OCH |
0080: 4341 03bd 4346 0459 4348 03f0 4349 0434  CA..CF.YCH
0090: 434c 02e4 434e 0361 434f 032c 4352 0337  CL..CN.aCO |
0090: 434c 03e0 434e 046f 434f 0434 4352 043f  CL..CN.oCO
00a0: 4355 0299 4358 0330 4359 02f2 435a 02be  CU..CX.0CY |
00a0: 4355 0389 4358 0438 4359 03f0 435a 03b5  CU..CX.8CY
00b0: 4445 02a7 444b 02f2 444d 02cf 444f 02cf  DE..DK..DM |
00b0: 4445 0399 444b 03f0 444d 03c8 444f 03c8  DE..DK..DM
00c0: 445a 0327 4543 0337 4545 02f2 4547 036d  DZ.'EC.7EE |
00c0: 445a 042d 4543 043f 4545 03f0 4547 047d  DZ.-EC.?EE
00d0: 4553 02ba 4554 0359 4649 0295 464d 02c2  ES..ET.YFI |
00d0: 4553 03b0 4554 0464 4649 0385 464d 03b9  ES..ET.dFI
00e0: 4652 02f2 4742 02f2 4744 02da 4745 02fb  FR..GB..GD |
00e0: 4652 03f0 4742 03f0 4744 03d5 4745 03fb  FR..GB..GD
00f0: 4746 0359 4748 032c 474c 0359 4750 0359  GF.YGH.,GL |
00f0: 4746 0464 4748 0434 474c 0464 4750 0464  GF.dGH.4GL
0100: 4752 02f2 4754 02cf 4755 02d2 4759 032a  GR..GT..GU |
0100: 4752 03f0 4754 03c8 4755 03cc 4759 0431  GR..GT..GU
0110: 484b 033b 484e 032c 4852 0295 4854 02c2  HK.;HN.,HR |
0110: 484b 0443 484e 0434 4852 0385 4854 03b9  HK.CHN.4HR
0120: 4855 02f2 4944 02e2 4945 02f2 494c 0315  HU..ID..IE |
0120: 4855 03f0 4944 03dd 4945 03f0 494c 0417  HU..ID..IE
0130: 494e 0302 4952 02f9 4953 02f2 4954 02f2  IN..IR..IS |
0130: 494e 0403 4952 03f8 4953 03f0 4954 03f0  IN..IR..IS
0140: 4a4d 032c 4a4f 030f 4a50 031b 4b45 0320  JM.,JO..JP |
0140: 4a4d 0434 4a4f 0411 4a50 041e 4b45 0424  JM.4JO..JP
0150: 4b48 0359 4b4e 02e7 4b50 02de 4b52 0366  KH.YKN..KP |
0150: 4b48 0464 4b4e 03e4 4b50 03d9 4b52 0474  KH.dKN..KP
0160: 4b57 0356 4b59 0330 4b5a 02f6 4c42 032c  KW.VKY.0KZ |
0160: 4b57 0461 4b59 0438 4b5a 03f4 4c42 0434  KW.aKY.8KZ
0170: 4c43 02e7 4c49 0359 4c4b 0337 4c53 0359  LC..LI.YLK |
0170: 4c43 03e4 4c49 0464 4c4b 043f 4c53 0464  LC..LI.dLK
0180: 4c54 02f2 4c55 02f2 4c56 02f2 4d41 0356  LT..LU..LV |
0180: 4c54 03f0 4c55 03f0 4c56 03f0 4d41 0461  LT..LU..LV
0190: 4d43 0359 4d44 0359 4d45 0359 4d46 0359  MC.YMD.YME |
0190: 4d43 0464 4d44 0464 4d45 0464 4d46 0464  MC.dMD.dME
01a0: 4d48 02c2 4d4b 02f2 4d4e 0330 4d4f 0308  MH..MK..MN |
01a0: 4d48 03b9 4d4b 03f0 4d4e 0438 4d4f 0409  MH..MK..MN
01b0: 4d50 02c2 4d51 0359 4d52 0359 4d54 02f2  MP..MQ.YMR |
01b0: 4d50 03b9 4d51 0464 4d52 0464 4d54 03f0  MP..MQ.dMR
01c0: 4d55 0330 4d56 02ab 4d57 0359 4d58 032c  MU.0MV..MW |
01c0: 4d55 0438 4d56 039e 4d57 0464 4d58 0434  MU.8MV..MW
01d0: 4d59 0341 4e47 0305 4e49 02c2 4e4c 0373  MY.ANG..NI |
01d0: 4d59 0449 4e47 0406 4e49 03b9 4e4c 0483  MY.ING..NI
01e0: 4e4f 02b5 4e50 02e4 4e5a 02fe 4f4d 0359  NO..NP..NZ |
01e0: 4e4f 03ab 4e50 03e0 4e5a 03ff 4f4d 0464  NO..NP..NZ
01f0: 5041 02cf 5045 032c 5046 0359 5047 032c  PA..PE.,PF |
01f0: 5041 03c8 5045 0434 5046 0464 5047 0434  PA..PE.4PF
0200: 5048 032c 504b 02f9 504c 02f2 504d 0359  PH.,PK..PL |
0200: 5048 0434 504b 03f8 504c 03f0 504d 0464  PH.4PK..PL
0210: 5052 02da 5054 02f2 5057 02c2 5059 0330  PR..PT..PW |
0210: 5052 03d5 5054 03f0 5057 03b9 5059 0438  PR..PT..PW
0220: 5141 02f9 5245 0359 524f 02f2 5253 02b2  QA..RE.YRO |
0220: 5141 03f8 5245 0464 524f 03f0 5253 03a7  QA..RE.dRO
0230: 5255 0323 5257 032c 5341 0359 5345 02f2  RU.#RW.,SA |
0230: 5255 0428 5257 0434 5341 0464 5345 03f0  RU.(RW.4SA
0240: 5347 02a0 5349 02f2 534b 02f2 534e 032c  SG..SI..SK |
0240: 5347 0390 5349 03f0 534b 03f0 534e 0434  SG..SI..SK
0250: 5352 0359 5356 030c 5359 033f 5443 0330  SR.YSV..SY |
0250: 5352 0464 5356 040d 

Re: [LEDE-DEV] WRT3200ACM crashes after mac80211 wireless-testing 2017-11-01

[Syrone Wong]

One more interesting thing is there are two patches upgrade the
firmware version code to 20.

What we are using is the one[0] already labeled as 'Not Applicable',
while there is another one[1] labeled as 'RFC'.

I don't understand the current state of the patch.


[0]: https://patchwork.kernel.org/patch/9992477/
[1]: https://patchwork.kernel.org/patch/9989569/
Best Regards,
Syrone Wong


On Thu, Nov 23, 2017 at 8:25 AM, Syrone Wong  wrote:
> Hi,
>
> 1. minor warning
>
> .config:5:warning: symbol value 'm' invalid for ATH_REG_DYNAMIC_USER_REG_HINTS
>
> The config entry is of type bool.
>
> config ATH_REG_DYNAMIC_USER_REG_HINTS
> bool "Atheros dynamic user regulatory hints"
> depends on CFG80211_CERTIFICATION_ONUS
> default n
> ---help---
>  Say N. This should only be enabled in countries where
>  this feature is explicitly allowed and only on cards that
>  specifically have been tested for this.
>
> 2. wireless-regdb
>
> python $(PKG_BUILD_DIR)/db2fw.py $(PKG_BUILD_DIR)/regulatory.db
> $(PKG_BUILD_DIR)/db.txt in Build/Compile assumes python is linked to
> python2 by default. But it's not the truth for bleeding edge distros,
> for example, Archlinux.
>
> It will fail on the system that links python to python 3.
>
>  File 
> "/home/wong/github/lede-1/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/wireless-regdb-2017-10-20-4343d359/db2fw.py",
> line 13
>
> print 'Usage: %s output-file input-file' % sys.argv[0]
>^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean
> print(int 'Usage: %s output-file input-file' % sys.argv[0])?
>
> The error got ignored silently.
>
> I propose following `tools/scons/files/pywrap.sh` way, find python2
> ourselves and call python2 explicitly.
>
> 3. About the crash
>
> It crashes in ~5mins after clients connected to the router. No warning
> or kernel panic messages at all, just rebooting.
>
> I tried to build new backports based on wt-2017-11-14, drop some
> patches already upstream, and still the same issue.
>
> After reverting
> 6a6dc94e0c9a0533eaa9819bf3c22128b009af56,
> 9247864b6ed933841ee3068dbd4add06babe7fbd,
> 2dc485250d516f1535eeaf53f0f2f5742e5f9e0c and
> f9fa266faf9a2fdea48cc2fb72fa5a7e52a527c0, the crash disappears.
>
> 4. My thoughts
>
> The big change has been made is switching from internal regdb to a
> self-built one.
>
> From net/wireless/Kconfig, there are several config entries are
> enabled by default.
>
> config CFG80211_REQUIRE_SIGNED_REGDB
> bool "require regdb signature" if CFG80211_CERTIFICATION_ONUS
> default y
> select SYSTEM_DATA_VERIFICATION
> help
>  Require that in addition to the "regulatory.db" file a
>  "regulatory.db.p7s" can be loaded with a valid PKCS#7
>  signature for the regulatory.db file made by one of the
>  keys in the certs/ directory.
>
> config CFG80211_USE_KERNEL_REGDB_KEYS
> bool "allow regdb keys shipped with the kernel" if CFG80211_CERTIFICATION_ONUS
> default y
> depends on CFG80211_REQUIRE_SIGNED_REGDB
> help
>  Allow the regulatory database to be signed by one of the keys for
>  which certificates are part of the kernel sources
>  (in net/wireless/certs/).
>
>  This is currently only Seth Forshee's key, who is the regulatory
>  database maintainer.
>
> config CFG80211_CRDA_SUPPORT
> bool "support CRDA" if EXPERT
> default y
> depends on CFG80211
> help
>  You should enable this option unless you know for sure you have no
>  need for it, for example when using internal regdb (above) or the
>  database loaded as a firmware file.
>
>  If unsure, say Y.
>
> We don't have CRDA installed and there is no signing key being
> installed. This might be the root cause. While I'm not familiar with
> this series of changes. I wonder if someone can dig into it.
>
> Best Regards,
> Syrone Wong

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

Re: [LEDE-DEV] odhcpd: possible regression in make DHCPv4 support compiletime configurable

[Eric Luehrsen]

On 11/23/2017 03:54 AM, Hans Dedecker wrote:

Hi,

On Thu, Nov 23, 2017 at 6:38 AM, Eric Luehrsen  wrote:

FS#1188 has been raised due to problems for optional build recipes in
"dhcpv4: make DHCPv4 support compiletime configurable"
(d80621fea5cafcdca3f7fe762fede374a66e4b2) because no odhcpd-full package is
build bot available. However, it also appears that conditionally compiling
DHCPv4 back in does not work. This may be a rather significant regression.

I'm running odhcpd as DHCPv4 server in a CI setup and don't notice any issue.
Please provide more info as requested in
https://bugs.lede-project.org/index.php?do=details_id=1188 to
facilitate trouble shooting as I'm unable to reproduce the issue.

Hans

- Eric
It seems that it was something happening in 'make' (w/ CMake) build 
avoidance. In an attempt to figure it out, I think I lost the rabbit. My 
system works now as well.


- Eric

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

Re: [LEDE-DEV] Using older kernel in 17.01.4

[Eric Luehrsen]

Hi Nishant -

As a possible alternate solution...

If you don't need the curvature feature of HFSC, then HTB will work just 
as well. It handles the hierarchy and bandwidth sharing. Some may 
express concern HTB is slower at high bandwidths. This isn't entirely 
true. The HTB parameters "burst" and "cburst" are the bucket(s). These 
two parameters need to be sized to hold about 0.5 [ms] of flow (or min. 
MTU+10%). Otherwise, each time the bucket is empty a software interrupt 
occurs. With whatever the router needs to do, this can hurt throughput. 
You can look at the sqm-scripts github history 
[https://github.com/tohojo/sqm-scripts] for some of the discussions 
comparing the different shapers.


- Eric

On 11/24/2017 12:43 AM, Nishant Sharma wrote:

Hi,

The bug in HFSC and SCH is big issue for us as we can't do QoS 
reliably. I had to rollback to OpenWrt 15.05.1 in order to resolve the 
issue.


Is there a way where I could specify an older kernel version while 
building the firmware using source of 17.01.4?


Thanks in advance for pointers.

Regards,
Nishant



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

[LEDE-DEV] [PATCH v2] ubox/logread: add re-connect capability

[Zefir Kurtisi]

When logd is restarted while 'logread -f' is running, the
logread process terminates, which cumbers debugging in
different use-cases.

This patch adds re-connect functionality to logread. In
follow mode, when the ustream to logd is disconnected,
instead of terminating, it tries to re-connect to logd
and re-issue the original request.

Signed-off-by: Zefir Kurtisi 
---
v2: in follow mode, don't exit if the initial
ubus lookup for logd fails

 log/logread.c | 143 +-
 1 file changed, 91 insertions(+), 52 deletions(-)

diff --git a/log/logread.c b/log/logread.c
index ad06f2a..8229c98 100644
--- a/log/logread.c
+++ b/log/logread.c
@@ -65,6 +65,10 @@ static int log_type = LOG_STDOUT;
 static int log_size, log_udp, log_follow, log_trailer_null = 0;
 static int log_timestamp;
 static int last_errno = 0;
+static struct ubus_context *ctx;
+static int lines;
+
+static void logread_reconnect_cb(struct uloop_timeout *timeout);
 
 static const char* getcodetext(int value, CODE *codetable) {
CODE *i;
@@ -268,29 +272,82 @@ static void logread_fd_data_cb(struct ustream *s, int 
bytes)
}
 }
 
+/*
+ * Reconnect Handling
+ * while following log
+ * - after logd removal
+ *   - destroy ustream
+ *   - cyclically try to re-connect to new logd object
+ *   - re-issue original request
+ *
+ * Note: if a re-connection appears while a 'logread -l' request is active, the
+ *   number of returned lines will not match (i.e. you get some lines from
+ *   the old instance plus the number of lines requested from the new one)
+ */
+
+/* flag to prevent printing error messages during reconnect cycles */
+static int object_reconnect_active;
+
+static void logread_restart_reconnect_timer(struct uloop_timeout *timeout)
+{
+   const int LOG_RECONNECT_TIMEOUT_MS = 250;
+   uloop_timeout_set(timeout, LOG_RECONNECT_TIMEOUT_MS);
+}
+
 static void logread_fd_state_cb(struct ustream *s)
 {
-   uloop_end();
+   static struct uloop_timeout ubus_timer;
+   /* force re-opening of stream */
+   s->free(s);
+
+   object_reconnect_active = 1;
+   ubus_timer.cb = logread_reconnect_cb;
+   logread_restart_reconnect_timer(_timer);
 }
 
 static void logread_fd_cb(struct ubus_request *req, int fd)
 {
static struct ustream_fd test_fd;
-
test_fd.stream.notify_read = logread_fd_data_cb;
test_fd.stream.notify_state = logread_fd_state_cb;
ustream_fd_init(_fd, fd);
 }
 
-int main(int argc, char **argv)
+static int logread_process(void)
 {
+   static struct blob_buf b;
static struct ubus_request req;
-   struct ubus_context *ctx;
uint32_t id;
+   int ret = ubus_lookup_id(ctx, "log", );
+   if (ret) {
+   if (!object_reconnect_active)
+   fprintf(stderr, "Failed to find log object\n");
+   return ret;
+   }
+   blob_buf_init(, 0);
+   blobmsg_add_u8(, "stream", 1);
+   if (lines)
+   blobmsg_add_u32(, "lines", lines);
+   else if (log_follow)
+   blobmsg_add_u32(, "lines", 0);
+
+   ubus_invoke_async(ctx, id, "read", b.head, );
+   req.fd_cb = logread_fd_cb;
+   ubus_complete_request_async(ctx, );
+
+   return 0;
+}
+
+static void logread_reconnect_cb(struct uloop_timeout *timeout)
+{
+   if (logread_process())
+   logread_restart_reconnect_timer(timeout);
+}
+
+int main(int argc, char **argv)
+{
const char *ubus_socket = NULL;
-   int ch, ret, lines = 0;
-   static struct blob_buf b;
-   int tries = 5;
+   int ch, ret;
 
signal(SIGPIPE, SIG_IGN);
 
@@ -354,58 +411,40 @@ int main(int argc, char **argv)
}
ubus_add_uloop(ctx);
 
-   /* ugly ugly ugly ... we need a real reconnect logic */
-   do {
-   ret = ubus_lookup_id(ctx, "log", );
-   if (ret) {
-   fprintf(stderr, "Failed to find log object: %s\n", 
ubus_strerror(ret));
-   sleep(1);
-   continue;
-   }
-
-   blob_buf_init(, 0);
-   blobmsg_add_u8(, "stream", 1);
-   blobmsg_add_u8(, "oneshot", !log_follow);
-   if (lines)
-   blobmsg_add_u32(, "lines", lines);
-   else if (log_follow)
-   blobmsg_add_u32(, "lines", 0);
-   if (log_follow) {
-   if (pid_file) {
-   FILE *fp = fopen(pid_file, "w+");
-   if (fp) {
-   fprintf(fp, "%d", getpid());
-   fclose(fp);
-   }
+   if (log_follow) {
+   if (pid_file) {
+   FILE *fp = fopen(pid_file, "w+");
+   if (fp) {
+   fprintf(fp, 

Re: [LEDE-DEV] [PATCH] base-files: do not backup unchanged files

[Matthias Schiffer]

On 11/24/2017 08:11 AM, Luiz Angelo Daros de Luca wrote:
>>> After applied, the list of files in backup in a fresh installation change 
>>> from:
>>> to:
>>>
>>> root at LEDE:~# sysupgrade  -l
>>> /etc/config/dhcp
>>> /etc/config/firewall
>>> /etc/config/network
>>> /etc/config/system
>>> /etc/dropbear/dropbear_rsa_host_key
>>>
>>
>> Hi,
>>
>> when I set up  new devices I usually do an export of the initial 
>> configuration to track
>> the changes I made externally in a git repo.
>> With this patch I would just get the five files mentioned above, thus an 
>> incomplete config and would not
>> be able to track my config changes.
> 
> Hi,
> 
> Yes, a diff between two backups will not show actually what has changed as 
> modified files will appear as new.
> 
> However, maybe a configuration backup is not the best way to keep track of 
> changes on configuration files.
> The list of "configuration file" can change as long as their configuration 
> are not listed in /lib/upgrade/keep.d.
> Backup consists of files listed in /etc/sysupgrade.conf, /lib/upgrade/keep.d 
> and changed config files (tracked by opkg).
> For example, /etc/firewall.user will not appear in backup if not modified (or 
> opkg is missing) because it is not mentioned in
> /lib/upgrade/keep.d. There are many more examples. Try yourself:
> 
> # find $(cat /lib/upgrade/keep.d/*) -type f -o type l 2>/dev/null | sort -u 
> >/tmp/a.txt
> # cat /usr/lib/opkg/info/*.conffiles | sort -u>/tmp/b.txt
> # diff -u /tmp/a.txt /tmp/b.txt  | grep +
> 
> So, even today, it is already expected that a backup after fresh installation 
> to have less files than a backup
> after some packages where installed. I just made the difference bigger.
> 
> BTW, the backup is broken whenever opkg is missing, as those files will never 
> get into backup. I don't know if it's worth it to try
> to fix backup without opkg.

I'll eventually get to it, as the LEDE-based Gluon mesh framework generally
ships without opkg, and without most of /usr/lib/opkg, on small (4MB)
devices. I plan to ship a minimal /usr/lib/opkg that just contains the
config hashes, and include a small replacement for `opkg
list-changed-conffiles` in sysupgrade).


> 
> I could add a new option for sysupgrade in order to keep all files listed, 
> even those untouched, in order to get the old behaviour.
> However, in order to use it, you'll need to call it using a terminal. In this 
> case, you could also retrieve those files using ssh+tar, or rsync if avaiable.
> Anyway, this option would only make sense if I grab also all config files 
> mentioned in any installed package, even those untouched.
> 
> I'm trying to make OpenWrt/LEDE upgrade process closer to what we get in a 
> normal Linux distribution. The inclusion of only
> modified files is a trick to reproduce the same logic rpm/deb uses for 
> configuration updates (replace what wasn't touched,
> keep what was modified). The current behaviour is already breaking 
> installations by, at least, propagating outdated /etc/profile.
> I'm trying to fix backup/upgrade process from now on, even if it could 
> "break" the use of backup for things not related to restore/upgrade.
> IMHO, it pays off.

As mentioned before, I don't like the idea of checking /rom to find out
what has changed. It will make sysupgrade behave differently on devices
that don't have an overlay and thus no /rom.

A better fix (that would also be closer to what "normal Linux
distributions" do) would be to reduce the use of /lib/upgrade/keep.d, and
instead rely on opkg's config hash tracking for a lot more files (we should
make this work without opkg itself first though). This would also work with
Moritz's usecase of initial config files supplied in the image build via
/files, as these files would not match the hashes known to opkg.

/lib/upgrade/keep.d should still be supported IMO, it is useful for adding
directories and files to the backups that generated dynamically (Gluon has
a few usecases for this, e.g. packages that clean up behind themselves by
adding cleanup scripts that remove old configuration on the first boot with
a new image that doesn't have the package using the configuration anymore).
As /lib/upgrade/keep.d would mostly be used for files that don't exist in
/rom anyways, we can keep the behaviour of backupping these files
unconditionally, and don't need to introduce (more) overlay-specific hacks.


> 
> I already have a patch v2 ready 
> https://github.com/luizluca/source/tree/better-backups_skip-unchanged.
> I'm just waiting because it is now based on the submitted "[PATCH] 
> base-files: fix sysupgrade -b/-l when -c is used".
> Or maybe I should just send already v2 including both.
> 
> Luiz


Thanks for bringing this up. I generally agree that our backup strategy
could use some mending, but I'd prefer to keep /rom hacks out of our
scripts as much as possible.

Matthias



signature.asc
Description: OpenPGP digital signature

Re: [LEDE-DEV] [PATCH odhcpd] dhcpv4: notify DHCP ack messages via ubus

[Kevin Darbyshire-Bryant]

> On 24 Nov 2017, at 10:56, Borja Salazar  wrote:
> 
> Signed-off-by: Borja Salazar 
> ---
> src/dhcpv4.c |  8 
> src/odhcpd.h |  1 +
> src/ubus.c   | 19 +++
> 3 files changed, 28 insertions(+)


I suspect people are going to want to see a patch description as well as a 
reason why this patch is needed ;-)

Cheers,

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

[LEDE-DEV] [PATCH odhcpd] dhcpv4: notify DHCP ack messages via ubus

[Borja Salazar]

Signed-off-by: Borja Salazar 
---
 src/dhcpv4.c |  8 
 src/odhcpd.h |  1 +
 src/ubus.c   | 19 +++
 3 files changed, 28 insertions(+)

diff --git a/src/dhcpv4.c b/src/dhcpv4.c
index 166582e..ad8d338 100644
--- a/src/dhcpv4.c
+++ b/src/dhcpv4.c
@@ -870,6 +870,14 @@ static void handle_dhcpv4(void *addr, void *data, size_t 
len,
req->chaddr[3],req->chaddr[4],req->chaddr[5],
inet_ntoa(dest.sin_addr));
 
+#ifdef WITH_UBUS
+   if (msg == DHCPV4_MSG_ACK) {
+   char mac_str[13];
+   memset(_str, 0, sizeof(mac_str));
+   odhcpd_hexlify(mac_str, reply.chaddr, ETH_ALEN);
+   ubus_event_bcast("dhcp.ack", mac_str, inet_ntoa(reply.yiaddr), 
hostname, iface->ifname);
+   }
+#endif
sendto(sock, , sizeof(reply), MSG_DONTWAIT,
(struct sockaddr*), sizeof(dest));
 }
diff --git a/src/odhcpd.h b/src/odhcpd.h
index 45badd3..73e5a49 100644
--- a/src/odhcpd.h
+++ b/src/odhcpd.h
@@ -296,6 +296,7 @@ int ubus_init(void);
 const char* ubus_get_ifname(const char *name);
 void ubus_apply_network(void);
 bool ubus_has_prefix(const char *name, const char *ifname);
+void ubus_event_bcast(const char *type, const char *mac, const char *ip, const 
char *name, const char *interface);
 #endif
 
 int netlink_add_netevent_handler(struct netevent_handler *hdlr);
diff --git a/src/ubus.c b/src/ubus.c
index 95eeff7..e988b8e 100644
--- a/src/ubus.c
+++ b/src/ubus.c
@@ -311,6 +311,25 @@ static const struct blobmsg_policy obj_attrs[OBJ_ATTR_MAX] 
= {
[OBJ_ATTR_PATH] = { .name = "path", .type = BLOBMSG_TYPE_STRING },
 };
 
+void ubus_event_bcast(const char *type, const char *mac, const char *ip, const 
char *name, const char *interface)
+{
+
+   if (!ubus)
+   return;
+
+   blob_buf_init(, 0);
+   if (mac)
+   blobmsg_add_string(, "mac", mac);
+   if (ip)
+   blobmsg_add_string(, "ip", ip);
+   if (name)
+   blobmsg_add_string(, "name", name);
+   if (interface)
+   blobmsg_add_string(, "interface", interface);
+
+   ubus_notify(ubus, _object, type, b.head, -1);
+
+}
 
 static void handle_event(_unused struct ubus_context *ctx, _unused struct 
ubus_event_handler *ev,
 _unused const char *type, struct blob_attr *msg)
-- 
2.11.0


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

[LEDE-DEV] [PATCH v1] wireguard: bump to 20171122

[Kevin Darbyshire-Bryant]

Bump to latest WireGuard snapshot release:

ed479fa (tag: 0.0.20171122) version: bump snapshot
efd9db0 chacha20poly1305: poly cleans up its own state
5700b61 poly1305-x86_64: unclobber %rbp
314c172 global: switch from timeval to timespec
9e4aa7a poly1305: import MIPS64 primitive from OpenSSL
7a5ce4e chacha20poly1305: import ARM primitives from OpenSSL
abad6ee chacha20poly1305: import x86_64 primitives from OpenSSL
6507a03 chacha20poly1305: add more test vectors, some of which are weird
6f136a3 compat: new kernels have netlink fixes
e4b3875 compat: stable finally backported fix
cc07250 qemu: use unprefixed strip when not cross-compiling
64f1a6d tools: tighten up strtoul parsing
c3a04fe device: uninitialize socket first in destruction
82e6e3b socket: only free socket after successful creation of new
df318d1 compat: fix compilation with PaX
d911cd9 curve25519-neon: compile in thumb mode
d355e57 compat: 3.16.50 got proper rt6_get_cookie
666ee61 qemu: update kernel
2420e18 allowedips: do not write out of bounds
185c324 selftest: allowedips: randomized test mutex update
3f6ed7e wg-quick: document localhost exception and v6 rule

Compile-tested-for: ar71xx
Run-tested-on: ar71xx Archer C7 v2

Signed-off-by: Kevin Darbyshire-Bryant 
---

Please cherry-pick for 17.01

 package/network/services/wireguard/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/wireguard/Makefile 
b/package/network/services/wireguard/Makefile
index 9c0e075a17..3551129c54 100644
--- a/package/network/services/wireguard/Makefile
+++ b/package/network/services/wireguard/Makefile
@@ -11,12 +11,12 @@ include $(INCLUDE_DIR)/kernel.mk
 
 PKG_NAME:=wireguard
 
-PKG_VERSION:=0.0.2017
+PKG_VERSION:=0.0.20171122
 PKG_RELEASE:=1
 
 PKG_SOURCE:=WireGuard-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=https://git.zx2c4.com/WireGuard/snapshot/
-PKG_HASH:=d9347786a9406ac276d86321ca64aadb1f0639cb0582c6e0519c634cf6e81157
+PKG_HASH:=c52f0694f4e11129a80b60a0d2fe75729f1ad39e3fe4e3ee569629ff21e3ed89
 
 PKG_LICENSE:=GPL-2.0 Apache-2.0
 PKG_LICENSE_FILES:=COPYING
-- 
2.13.6 (Apple Git-96)


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