Re: [LEDE-DEV] [PATCH] ar71xx: change image version for ubiquiti devices
On 2017-04-05 23:44, Matthias Fritzsche wrote: > changes the image version from hardcoded OpenWrt to > $VERSION_DIST. AirOS shows a notification with the image version > during a firmware upgrade. > > fixes #582 > > Signed-off-by: Matthias Fritzsche > --- > target/linux/ar71xx/image/ubnt.mk | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/target/linux/ar71xx/image/ubnt.mk > b/target/linux/ar71xx/image/ubnt.mk > index b203d6a..056dced 100644 > --- a/target/linux/ar71xx/image/ubnt.mk > +++ b/target/linux/ar71xx/image/ubnt.mk > @@ -6,7 +6,7 @@ > # routerboard creates partitions out of the ubnt header > define Build/mkubntimage > -$(STAGING_DIR_HOST)/bin/mkfwimage \ > - -B $(UBNT_BOARD) -v > $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-OpenWrt-$(REVISION) \ > + -B $(UBNT_BOARD) -v > $(UBNT_TYPE).$(UBNT_CHIP).v0.0.0-$(VERSION_DIST)-$(REVISION) \ The Ubiquiti firmware web interface parses the version number, right? Did you do any tests to check how it reacts to the 0.0.0 version number? - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/3] Fix PTR questions handling
Signed-off-by: Cristian Morales Vega
---
dns.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/dns.c b/dns.c
index 61ea8e3..168cc13 100644
--- a/dns.c
+++ b/dns.c
@@ -378,15 +378,7 @@ parse_question(struct interface *iface, struct sockaddr
*from, char *name, struc
dns_reply_a(iface, to, announce_ttl);
service_announce_services(iface, to, announce_ttl);
} else {
- /* First dot separates instance name from the rest */
- char *dot = strchr(name, '.');
- /* Length of queried instance */
- size_t len = dot ? dot - name : 0;
-
- /* Make sure it's query for the instance name we use */
- if (len && len == strlen(mdns_hostname) &&
- !strncmp(name, mdns_hostname, len))
- service_reply(iface, to, dot + 1, announce_ttl);
+ service_reply(iface, to, name, announce_ttl);
}
break;
--
2.9.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 3/3] Ignore timeout in service_reply()
Signed-off-by: Cristian Morales Vega
---
service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/service.c b/service.c
index ca70274..e4cc4b5 100644
--- a/service.c
+++ b/service.c
@@ -148,7 +148,7 @@ service_reply(struct interface *iface, struct sockaddr *to,
const char *match, i
vlist_for_each_element(&services, s, node) {
if (!match || !strcmp(s->service, match))
- service_reply_single(iface, to, s, ttl, 0);
+ service_reply_single(iface, to, s, ttl, 1);
}
}
--
2.9.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/3] Handle SRV questions
Signed-off-by: Cristian Morales Vega
---
dns.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/dns.c b/dns.c
index d384f58..61ea8e3 100644
--- a/dns.c
+++ b/dns.c
@@ -390,6 +390,20 @@ parse_question(struct interface *iface, struct sockaddr
*from, char *name, struc
}
break;
+ case TYPE_SRV:
+ {
+ /* First dot separates instance name from the rest */
+ char *dot = strchr(name, '.');
+ /* Length of queried instance */
+ size_t len = dot ? dot - name : 0;
+
+ /* Make sure it's query for the instance name we use */
+ if (len && len == strlen(mdns_hostname) &&
+ !strncmp(name, mdns_hostname, len))
+ service_reply(iface, to, dot + 1, announce_ttl);
+ }
+ break;
+
case TYPE_:
case TYPE_A:
host = strstr(name, ".local");
--
2.9.3
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
> -Original Message- > From: Yousong Zhou [mailto:yszhou4t...@gmail.com] > Sent: Monday, April 24, 2017 5:15 PM > To: Y.B. Lu > Cc: John Crispin; lede-dev@lists.infradead.org; j...@mein.io; Wes Li; > Xiaobo Xie > Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > configured bridge mode in /etc/config/network > > On 24 April 2017 at 15:39, Y.B. Lu wrote: > > Hi John, > > > > Thank you very much. > > > > But I still feel it's strange the crash didn't happen if used brctl to > configure instead of /etc/config/network. > > Much memory(about 700MB) was consumed in UDP throughput test only when > used /etc/config/network. > > > > As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe > ethernet driver had this issue. > > I think maybe I should focus on deep studying in /etc/config/network. > But we had a deadline by this month to resolve it. > > > > Is there any possibility the issue was caused by OpenWrt? > > Thanks again. > > > > Most parts of /etc/config/network will be parsed and executed by netifd. > Comparing strace output of both brctl and netifd may reveal something > useful. > > The kernel is supposed to be resilient against whatever ways applications > may use its exposed userspace interface which is driver and device- > agnostic. If the driver fails, there is very likely an issue within the > driver itself. > > yousong [Lu Yangbo-B47093] Hi Yousong, thank you so much for your comments and suggestion. It's now very strange. The driver failed because of there was no enough memory. But this only happened with /etc/config/network bridge configure. Both ls1012a and ls1043a which had different ethernet drivers got this problem. I think your suggestion comparing strace output of both brctl and netifd probably is a good method. We will have a try. Thanks. - Yangbo Lu ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if configured bridge mode in /etc/config/network
> -Original Message- > From: Ben Greear [mailto:gree...@candelatech.com] > Sent: Tuesday, April 25, 2017 12:03 AM > To: Y.B. Lu; John Crispin; lede-dev@lists.infradead.org; j...@mein.io > Cc: Wes Li; Xiaobo Xie > Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > configured bridge mode in /etc/config/network > > On 04/24/2017 12:39 AM, Y.B. Lu wrote: > > Hi John, > > > > Thank you very much. > > > > But I still feel it's strange the crash didn't happen if used brctl to > configure instead of /etc/config/network. > > Much memory(about 700MB) was consumed in UDP throughput test only when > used /etc/config/network. > > > > As I know, both ls1043a with DPAA ethernet driver and ls1012a with ppfe > ethernet driver had this issue. > > I think maybe I should focus on deep studying in /etc/config/network. > But we had a deadline by this month to resolve it. > > > > Is there any possibility the issue was caused by OpenWrt? > > Thanks again. > > > > > > > > Best regards, > > Yangbo Lu > > > >> -Original Message- > >> From: John Crispin [mailto:j...@phrozen.org] > >> Sent: Monday, April 24, 2017 12:31 PM > >> To: Y.B. Lu; lede-dev@lists.infradead.org; j...@mein.io > >> Cc: Wes Li; Xiaobo Xie > >> Subject: Re: [LEDE-DEV] FW: UDP throughput caused kernel panic if > >> configured bridge mode in /etc/config/network > >> > >> Hi, > >> > >> this is most certainly a bug in the kernel. either the ethernet > >> driver blows up under load or some other memory allocation related > >> bug. it is very common for ethernet to kill boards under load by > triggering bugs. > >> > >> John > >> > >> On 24/04/17 05:49, Y.B. Lu wrote: > >>> Hi John and Jo-Philipp, > >>> > >>> Have you ever got similar problem, or known any possible reason > >>> about this, or known anyone who probably know this? > >>> > >>> I just found much memory would be consumed if I configured board as > >>> bridge mode in /etc/config/network and did UDP throughput test. > >>> But using brctl to configure bridge mode didn't consume memory. > >>> > >>> Thank you very much. > >>> > >>> > >>> Best regards, > >>> Yangbo Lu > >>> > >>> > -Original Message- > From: Y.B. Lu > Sent: Thursday, April 13, 2017 1:24 PM > To: 'lede-dev@lists.infradead.org' > Subject: UDP throughput caused kernel panic if configured bridge > mode in /etc/config/network > > Hi all, > > Recently I got below kernel panic when did UDP throughput test on > NXP LS1043ARDB board. I configured the bridge mode in > /etc/config/network. > But if I used 'brctl' to configure the bridge mode, this issue > would not happen. > I also noticed almost all memory was consumed(about 700MB) when > kernel crashed. > Anyone have any idea about this? Thank you very much. > > root@LEDE:/etc/fmc/config# [ 263.981540] ksoftirqd/3: page > allocation > failure: order:0, mode:0x2080020 [ 263.988339] CPU: 3 PID: 19 Comm: > ksoftirqd/3 Not tainted 4.4.52 #0 [ 263.994508] Hardware name: > > This looks like just a warning...did the system really panic and stop > working? > [Lu Yangbo-B47093] Hi Ben, yes... The system crashed and reboot. It's obvious that memory was consumed so much in the UDP throughput test with /etc/configs/network bridge mode setting. I ran a script to execute 'free' command every 0.5 sec to observe that. > Thanks, > Ben > > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] openssl: Remove RIPEMD-160 from OpenSSL
On 2017-03-28 00:26, Rosen Penev wrote: > The commit that removed no-ripemd stated that it was needed for openssh. > However with recent OpenSSH releases (7.4), RIPEMD-160 is run-time disabled. > I've verified this with ssh -vvv making no mention of RIPEMD-160 anywhere. Last time I tried to remove this, some other things in packages/ broke as well. If you really care about this, please do a full build with *all* feeds and all packages that use openssl enabled to ensure that this doesn't break anything. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [OpenWrt-Devel] Test results of OpenWrt 15.05.1 according to BSI test concept for home routers
On 04/08/2017 11:38 AM, Hauke Mehrtens wrote: > The German Bundesamt für Sicherheit in der Informationstechnik (short: > BSI, English: Federal Office for Information Security) published a > "Testkonzept für Breitband-Router (DSL-, Kabel-, SOHO-, CE-, CPE-Router, > IADs)" (English: Test concept for broadband routers). This test concept > is only available in German and most chapters are published in the > public by the BSI, chapter 4 and 5 are only available after signing a > NDA (Traffic Light Protocol) with the BSI: > https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Themen/Testkonzept-Breitbandrouter.pdf?__blob=publicationFile&v=5 > > Some unnamed organization tested OpenWrt 15.05.1 on a TP-Link TL-WR841N > V10.0 according to this test concept. Because I commented on the first > public draft of the test concept and said that I am active in the > OpenWrt project, the organization contacted me to check if their test > results are correct and provided me with the full test report under NDA. > > > OpenWrt 15.05.1 failed this test and LEDE will probably also fail this > test, because we failed on section 4.5.1 "Firewall-Bypass", which is a > criterion for exclusion (Ausschlusskriterium), see details below. > > The test concept focus on "normal" routers and only tests the web GUI > and also looks mostly on features normal home routers have. We are > missing some functionality like individual default password, for the web > GUI and the Wifi, the logging is not very good and so on. The tests > regarding DNS are interesting and more advanced, if someone wants to > look into that it would be very nice. > > The main problem is in section 4.5.1 "Firewall-Bypass". > OpenWrt and LEDE implement RFC4890 section 4.3.1: > --- > 4.3.1. Traffic That Must Not Be Dropped > >Error messages that are essential to the establishment and >maintenance of communications: > >o Destination Unreachable (Type 1) - All codes >o Packet Too Big (Type 2) >o Time Exceeded (Type 3) - Code 0 only >o Parameter Problem (Type 4) - Codes 1 and 2 only > >Appendix A.4 suggests some more specific checks that could be >performed on Parameter Problem messages if a firewall has the >necessary packet inspection capabilities. > >Connectivity checking messages: > >o Echo Request (Type 128) >o Echo Response (Type 129) > --- > > The BSI used RFC6092 (Recommended Simple Security Capabilities in > Customer Premises Equipment (CPE) for Providing Residential IPv6 > Internet Service) with this section as the base for the test: > --- > 3.2.1. Internet Control and Management > >Recommendations for filtering ICMPv6 messages in firewall devices are >described separately in [RFC4890] and apply to residential gateways, >with the additional recommendation that incoming "Destination >Unreachable" and "Packet Too Big" error messages that don't match any >filtering state should be dropped. > >REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination >Unreachable" and "Packet Too Big" messages containing IP headers that >do not match generic upper-layer transport state records. > --- > > > Attached are the results of this test of OpenWrt 15.05.1. The > information on how the tests from chapter 4 and 5 are done is redacted > from the document, if you want to work on these problems and would like > to get more details about the problems from chapter 4 and 5, please > contact me. I can also help you with translating the problem from German > to English. ;-) > > The "sensitive" informations are under the Traffic Light Protocol > classification "TLP AMBER", see these German information about the NDA: > https://mip.bsi.bund.de/Anlage_1_TLP-Merkblatt.pdf > > > I commented on the tests itself, because they are missing many important > stuff to test, most of the security problem of IoT devices and home > routers one hears about in the media are not covered here at all. > > > History: > 20.10.2015: I read this article https://heise.de/-2851354 and wrote some > comments to the BSI based on the first public draft. In this mail I > mentioned that I am activate in the OpenWrt project. > 23.10.2015: The BSI answered me and offered me the full draft when I > would sign an NDA, I did so and got the full document, but did not > comment on it again. > 23.2.2016: I got the full final draft from the BSI > 22.11.2016: I was told by the unnamed organization that they tested a > TP-Link device running OpenWrt 15.05.1 and if I could comment on their > results. I got the results under the NDA and commented in them. > 31.3.2017: I asked if I can publish at lest some parts of the results > again and got the OK that I am allowed to publish th
[LEDE-DEV] modules-boot.d question and indeterminate drive # assignment
Hi. I’m seeing something weird… I’ve been working on adding kexec/kdump support to LEDE, adding some scripts to make this turn-key, etc. and in the process I’ve uncovered something a little bizarre (and unsettling). If I have a box (in this case an x86 box with a CompactFlash [CF]) drive and try to use a USB thumb-drive for capturing dumps (because the image on the CF is about 256MB, but the box needs 32GB or more for crashdumps)… then sometimes the CF is probed as /dev/sda and sometimes the USB thumb-drive is. I was poking around the image trying to figure out the order in which modules are loaded (to see if I can force the modules to initialize in a deterministic order) and noticed a couple of things: /etc/modules-boot.d/usb-storage isn’t prefixed with a priority about what order it loads in… so when does it get loaded? Are all the drivers just sorted lexically, in which case it would load after just about everything else? And when is the /etc/modules-boot.d/ directory read? It doesn’t look like it gets read by any scripts that I can find… probably because it’s invoked even before scripting would be available. Is that correct? Anyone have any suggestions on how to impose determinism in how the ATA and USB drivers come up so that the ATA/CF card is always found (and registered) first? Thanks, -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH 1/3] Handle SRV questions
> On Apr 26, 2017, at 3:45 AM, Cristian Morales Vega
> wrote:
>
> Signed-off-by: Cristian Morales Vega
> ---
> dns.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/dns.c b/dns.c
> index d384f58..61ea8e3 100644
> --- a/dns.c
> +++ b/dns.c
> @@ -390,6 +390,20 @@ parse_question(struct interface *iface, struct sockaddr
> *from, char *name, struc
> }
> break;
>
> + case TYPE_SRV:
> + {
> + /* First dot separates instance name from the rest */
> + char *dot = strchr(name, '.');
> + /* Length of queried instance */
> + size_t len = dot ? dot - name : 0;
> +
> + /* Make sure it's query for the instance name we use */
> + if (len && len == strlen(mdns_hostname) &&
> + !strncmp(name, mdns_hostname, len))
> + service_reply(iface, to, dot + 1, announce_ttl);
> + }
> + break;
> +
> case TYPE_:
> case TYPE_A:
> host = strstr(name, ".local”);
Uh… What package is this for?
-Philip
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH ubox] Add template support to logread
Hi,
I would like to integrate logd to the cloud logging service. The
service only accepts special format of syslog, so then I make logread
support template.
Here's the usage:
logread -T "<%priority%> %source% %message% %timestamp%"
Currently supports 4 keywords: priority, source, message, timestamp.
The keywords should be surrounded by percent signs as showed above.
Regards,
Henry Chang
Signed-off-by: Henry Chang
---
log/logread.c | 129 ++
1 file changed, 102 insertions(+), 27 deletions(-)
diff --git a/log/logread.c b/log/logread.c
index edac1d9..ddb4f12 100644
--- a/log/logread.c
+++ b/log/logread.c
@@ -56,10 +56,22 @@ static const struct blobmsg_policy log_policy[] = {
[LOG_TIME] = { .name = "time", .type = BLOBMSG_TYPE_INT64 },
};
+static const char TP_FIELD_MESSAGE[] = "%message%";
+static const char TP_FIELD_PRIORITY[] = "%priority%";
+static const char TP_FIELD_SOURCE[] = "%source%";
+static const char TP_FIELD_TIMESTAMP[] = "%timestamp%";
+static const char *TP_FIELD_NAMES[] = {
+ TP_FIELD_MESSAGE,
+ TP_FIELD_PRIORITY,
+ TP_FIELD_SOURCE,
+ TP_FIELD_TIMESTAMP,
+};
+
static struct uloop_timeout retry;
static struct uloop_fd sender;
static regex_t regexp_preg;
static const char *log_file, *log_ip, *log_port, *log_prefix,
*pid_file, *hostname, *regexp_pattern;
+static const char *log_template;
static int log_type = LOG_STDOUT;
static int log_size, log_udp, log_follow, log_trailer_null = 0;
static int log_timestamp;
@@ -101,13 +113,16 @@ static int log_notify(struct blob_attr *msg)
struct blob_attr *tb[__LOG_MAX];
struct stat s;
char buf[512];
+ char buf2[512];
char buf_ts[32];
+ char buf_p[32];
uint32_t p;
- char *str;
+ char *str, *substr, *field;
time_t t;
uint32_t t_ms = 0;
char *c, *m;
int ret = 0;
+ int i, j;
if (sender.fd < 0)
return 0;
@@ -137,34 +152,83 @@ static int log_notify(struct blob_attr *msg)
regexec(®exp_preg, m, 0, NULL, 0) == REG_NOMATCH)
return 0;
t = blobmsg_get_u64(tb[LOG_TIME]) / 1000;
- if (log_timestamp) {
- t_ms = blobmsg_get_u64(tb[LOG_TIME]) % 1000;
- snprintf(buf_ts, sizeof(buf_ts), "[%lu.%03u] ",
- (unsigned long)t, t_ms);
- }
+ t_ms = blobmsg_get_u64(tb[LOG_TIME]) % 1000;
+ snprintf(buf_ts, sizeof(buf_ts), "[%lu.%03u] ", (unsigned long) t, t_ms);
c = ctime(&t);
p = blobmsg_get_u32(tb[LOG_PRIO]);
c[strlen(c) - 1] = '\0';
str = blobmsg_format_json(msg, true);
+ snprintf(buf_p, sizeof buf_p, "%u", p);
+
+ if (log_template) {
+ *buf = '\0';
+ *buf2 = '\0';
+ if ((j = strlen(log_template)) + 1 > sizeof buf) {
+ fprintf(stderr, "template is larger than the internal buffer\n");
+ return 1;
+ }
+ strncat(buf, log_template, j);
+ for (i = 0; i < sizeof TP_FIELD_NAMES / sizeof (char *); ++i) {
+ field = NULL;
+ if (!strcmp(TP_FIELD_NAMES[i], TP_FIELD_MESSAGE)) {
+ field = m;
+ } else if (!strcmp(TP_FIELD_NAMES[i], TP_FIELD_PRIORITY)) {
+ field = buf_p;
+ } else if (!strcmp(TP_FIELD_NAMES[i], TP_FIELD_SOURCE)) {
+ switch (blobmsg_get_u32(tb[LOG_SOURCE])) {
+ case SOURCE_KLOG:
+ field = "kernel";
+ break;
+ case SOURCE_SYSLOG:
+ field = "syslog";
+ break;
+ case SOURCE_INTERNAL:
+ field = "internal";
+ break;
+ default:
+ field = "-";
+ }
+ } else if (!strcmp(TP_FIELD_NAMES[i], TP_FIELD_TIMESTAMP)) {
+ field = buf_ts;
+ }
+ while (field && (substr = strstr(buf, TP_FIELD_NAMES[i]))) {
+ if (strlen(field) + strlen(buf) - strlen(TP_FIELD_NAMES[i]) + 1 >
+ sizeof buf) {
+ fprintf(stderr, "content to fill template is larger than buffer\n");
+ return 1;
+ }
+ *buf2 = '\0';
+ strncat(buf2, buf, substr - buf);
+ strncat(buf2, field, strlen(field));
+ strncat(buf2, substr + strlen(TP_FIELD_NAMES[i]),
+ strlen(buf) - (substr - buf) - strlen(TP_FIELD_NAMES[i]));
+ *buf = '\0';
+ strncat(buf, buf2, strlen(buf2));
+ }
+ }
+ }
+
if (log_type == LOG_NET) {
int err;
- snprintf(buf, sizeof(buf), "<%u>", p);
- strncat(buf, c + 4, 16);
- if (log_timestamp) {
- strncat(buf, buf_ts, sizeof(buf) - strlen(buf) - 1);
+ if (!log_template) {
+ snprintf(buf, sizeof(buf), "<%u>", p);
+ strncat(buf, c + 4, 16);
+ if (log_timestamp) {
+ strncat(buf, buf_ts, sizeof(buf) - strlen(buf) - 1);
+ }
+ if (hostname) {
+ strncat(buf, hostname, sizeof(buf) - strlen(buf) - 1);
+ strncat(buf, " ", sizeof(buf) - strlen(buf) - 1);
+ }
+ if (log_prefix) {
+ strncat(buf, log_prefix, sizeof(buf) - strlen(buf) - 1);
+ strncat(buf, ": ", sizeof(buf) - strlen(buf) - 1);
+ }
+ if (blobmsg_get_u32(tb[LOG_SOURCE]) == SOURCE_KLOG)
+ strncat(buf, "kernel: ", sizeof(buf) - strlen(buf) - 1);
+ strncat(buf, m, sizeof(buf) - strlen(buf) - 1);
}
- if (hostname) {
- strncat(buf, hostname, sizeof(buf) - strlen(buf) - 1);
- strncat(buf, " ", sizeof(buf) - strlen(buf) - 1);
- }
- if (log_prefix) {
- strncat(buf, log_prefix, sizeof(buf) - strlen(buf) - 1);
- strncat(buf, ": ", sizeof(buf) - strlen(buf) - 1);
- }
- if (blobmsg_get_u32(tb[LOG_SOURCE]) == SOURCE_KLOG)
- strncat(buf, "kernel: ", sizeof(buf) - strlen(buf) - 1);
Re: [LEDE-DEV] [RFC][17.01] ubox: bump to version 2017-03-10
On 25 April 2017 at 21:16, Yousong Zhou wrote: > Changes since current version > > 16f7e16 syslog: remove unnecessary sizeof struct between messages > 21a4bd0 kmodloader: modprobe: return 0 for loaded modules > 3dc78a4 kmodloader: don't store aliases info in struct module > c553354 cmake: fix typo > 8973576 kmodloader: fix not being able to find some modules > fce9382 cmake: Check for getrandom system call > ac2d43e kmodloader: support '-q' quiet option > f8d3d16 ubox: Add an option for more accurate timestamps in log > 14839f0 kmodloader: make insert_module() idempotent > 6e3c6dc kmodloader: add module alias awareness > 9371411 kmodloader: fix out-of-bound access when parsing .modinfo > a62c946 kmodloader: modprobe: skip possible command line arguments > 46a4b5f kmodloader: log to kmsg when loading directories of modules > eacc426 kmodloader: remove redundant glob wildcard char > 8488bb5 ubox: Initialize conditionally uninitialized variabled > db070f1 ubox: Fix some memory leaks > acc48b5 kmodloader: Fix typo in error message > > Size comparison on x86_64 host > > function old new delta > main21902344+154 > scan_module_folder 665 793+128 > alloc_module_node - 113+113 > .rodata 9461036 +90 > alloc_module 202 245 +43 > free_modules 77 119 +42 > load_modprobe209 237 +28 > scan_loaded_modules 241 265 +24 > avl_modcmp45 67 +22 > insert_module204 224 +20 > find_module 13 30 +17 > static.optind@@GLIBC_2 - 4 +4 > static.load_moddeps 118 117 -1 > scan_module_folders 55 54 -1 > > -- > (add/remove: 2/0 grow/shrink: 10/2 up/down: 685/-2) Total: 683 > bytes > > Fixes FS#684 with commit 21a4bd0 > > Signed-off-by: Yousong Zhou > --- > > Hi, I actually thought about opening a 17.01 branch for the ubox repo and > cherry-picking only bugfix commits there. What do you think? > Pushed: https://git.lede-project.org/2bc8d5eaf17823ddd319f5fd3e9fb880535ed696 regards, yousong ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
