Re: [LEDE-DEV] Busybox weirdness

[Philip Prindeville]

> On Nov 1, 2017, at 8:36 PM, Philip Prindeville 
>  wrote:
> 
> Can someone else please try to reproduce this?
> 
> I’m using busybox’s wget on x86_64 hardware, and when I do a “wget” of 2 
> http: URI’s, it mangles the second URI’s derived filename:
> 
> 
> root@lede:/tmp/x# wget 
> http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
> http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
> Downloading 
> 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
> Connecting to 104.16.37.47:80
> Writing to 'GeoIPv6.csv.gz'
> GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 
> ETA
> Download completed (1532219 bytes)
> Connecting to 104.16.37.47:80
> Writing to ' z;'
> z;   100% |***|  2338k  0:00:00 ETA
> Download completed (2394696 bytes)
> root@lede:/tmp/x# ls
> z;??  GeoIPv6.csv.gz
> root@lede:/tmp/x# 
> 
> 
> What the heck?
> 
> -Philip


Well, I was selecting busybox’s wget, but it was silently being overwritten by 
something else:

root@lede:/tmp/x# ls -l /bin/wget
lrwxrwxrwx1 root root13 Nov  1 19:17 /bin/wget -> 
uclient-fetch
root@lede:/tmp/x#

so that’s the real culprit.


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

[LEDE-DEV] Busybox weirdness

[Philip Prindeville]

Can someone else please try to reproduce this?

I’m using busybox’s wget on x86_64 hardware, and when I do a “wget” of 2 http: 
URI’s, it mangles the second URI’s derived filename:


root@lede:/tmp/x# wget 
http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz 
http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip
Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz'
Connecting to 104.16.37.47:80
Writing to 'GeoIPv6.csv.gz'
GeoIPv6.csv.gz   100% |***|  1496k  0:00:00 ETA
Download completed (1532219 bytes)
Connecting to 104.16.37.47:80
Writing to ' z;'
 z;   100% |***|  2338k  0:00:00 ETA
Download completed (2394696 bytes)
root@lede:/tmp/x# ls
 z;??  GeoIPv6.csv.gz
root@lede:/tmp/x# 


What the heck?

-Philip


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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH v2] merge: add OpenWrt branding

[Hartmut Knaack]

Mike Baker wrote on 31.10.2017 04:46:

On 10/28/2017 4:52 PM, Hartmut Knaack wrote:


Philip Prindeville wrote on 28.10.2017 23:20:

Hi all,

Does it seem to anyone else that we’re making this more complicated
than it needs to be?

If one of the goals we’re going for from here on out is “equality”,
then a basic litmus test to be applied to any action might be “does
this get us closer to a level playing field, or further away”?

Since not everyone gets an @openwrt.org email address, I think the
answer to “can we use @openwrt.org email addresses in SOB’s?” is by
extension, “no, because it doesn’t get us closer to a level playing
field."

We don’t need to argue the finer points of the letter of the law if
the spirit of the law is already adequately clear.

-Philip



Full Ack!
And in addition, from my point of view, the openwrt mail service got
seriously tainted, when the early LEDE founders got their @openwrt.org
accounts deactivated without prior notice. What is it worth having such
an address in a SOB, if you can't trust that it will last?
Thanks,

Actually you've both hit the nail on the head, the email accounts were
disabled immediately after the LEDE announcement because it was
announced using an openwrt email address but without discussion, prior
knowledge or approval from the rest of the group.



This raises some more questions: which terms and conditions did people have
to approve to get an @openwrt.org address? Where can these terms and
conditions be found? Is every email sent from such an address supposed to
be discussed and approved by the group before it gets sent?
Furthermore: how many percent of "the group" needs to agree when it comes
to disabling someones address? 50% or 67%?


(All history now, let's work on fixing things)


If we don't learn from our mistakes, history will repeat.



- Mike

___
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

[LEDE-DEV] [PATCH] libubus-req: add data_cb callback handling for ubus notifications

[John Crispin]

Signed-off-by: John Crispin 
---
 libubus-req.c | 13 +
 libubus.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/libubus-req.c b/libubus-req.c
index 0c7d589..92f80fa 100644
--- a/libubus-req.c
+++ b/libubus-req.c
@@ -253,6 +253,18 @@ ubus_notify_complete_cb(struct ubus_request *req, int ret)
nreq->complete_cb(nreq, 0, 0);
 }
 
+static void
+ubus_notify_data_cb(struct ubus_request *req, int type, struct blob_attr *msg)
+{
+   struct ubus_notify_request *nreq;
+
+   nreq = container_of(req, struct ubus_notify_request, req);
+   if (!nreq->data_cb)
+   return;
+
+   nreq->data_cb(nreq, type, msg);
+}
+
 static int
 __ubus_notify_async(struct ubus_context *ctx, struct ubus_object *obj,
const char *type, struct blob_attr *msg,
@@ -278,6 +290,7 @@ __ubus_notify_async(struct ubus_context *ctx, struct 
ubus_object *obj,
req->pending = 1;
req->id[0] = obj->id;
req->req.complete_cb = ubus_notify_complete_cb;
+   req->req.data_cb = ubus_notify_data_cb;
 
return 0;
 }
diff --git a/libubus.h b/libubus.h
index 4e45cb6..dc42ea7 100644
--- a/libubus.h
+++ b/libubus.h
@@ -56,6 +56,8 @@ typedef void (*ubus_fd_handler_t)(struct ubus_request *req, 
int fd);
 typedef void (*ubus_complete_handler_t)(struct ubus_request *req, int ret);
 typedef void (*ubus_notify_complete_handler_t)(struct ubus_notify_request *req,
   int idx, int ret);
+typedef void (*ubus_notify_data_handler_t)(struct ubus_notify_request *req,
+  int type, struct blob_attr *msg);
 typedef void (*ubus_connect_handler_t)(struct ubus_context *ctx);
 
 #define UBUS_OBJECT_TYPE(_name, _methods)  \
@@ -221,6 +223,7 @@ struct ubus_notify_request {
 
ubus_notify_complete_handler_t status_cb;
ubus_notify_complete_handler_t complete_cb;
+   ubus_notify_data_handler_t data_cb;
 
uint32_t pending;
uint32_t id[UBUS_MAX_NOTIFY_PEERS + 1];
-- 
2.11.0


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

Re: [LEDE-DEV] [PATCH] musl: update to 1.1.17

[Hannu Nyman]

Lucian Cristian wrote Wed Nov 1 2017

> Mainline - 1.1.18 is available
>

> on the first try, brief test, for dhcp wan, only issuing manual dhcpc 
worked, or maybe the tree wasn't clean enough



I tested compiling LEDE with musl 1.1.18 (using the patch here plus the 
1.1.18 version bump). And I cleaned the whole toolchain.


At the first glance LEDE r5217-098afa1e1b compiled with 1.1.18 booted ok and 
got normally a DHCP wan address, hostapd started etc..


So, 1.1.18 looks ok so far.



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

Re: [LEDE-DEV] [PATCH] ath10k-firmware: update QCA9888 and QCA4019 firmware

[Christian Lamparter]

On Monday, October 16, 2017 12:19:10 AM CET Hauke Mehrtens wrote:
> On 10/14/2017 05:35 PM, Christian Lamparter wrote:
> > On Saturday, October 14, 2017 11:24:24 AM CEST Hauke Mehrtens wrote:
> >> This updates the firmware files for the QCA9888 and QCA4019
> >> chips to a more recent version which is also used in the linux-firmware
> >> repository.
> >>
> >> Signed-off-by: Hauke Mehrtens 
> >> ---
> >>
> >> Could someone with a QCA4019 or QCA9888 device please test this.
> >> I do not have these deceives to test this myself.
> >>
> >>  package/firmware/ath10k-firmware/Makefile | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/package/firmware/ath10k-firmware/Makefile 
> >> b/package/firmware/ath10k-firmware/Makefile
> >> index 84889d9d29..5e0f41ea52 100644
> >> --- a/package/firmware/ath10k-firmware/Makefile
> >> +++ b/package/firmware/ath10k-firmware/Makefile
> >> @@ -223,7 +223,7 @@ define Package/ath10k-firmware-qca4019/install
> >>$(PKG_BUILD_DIR)/QCA4019/hw1.0/board-2.bin \
> >>$(1)/lib/firmware/ath10k/QCA4019/hw1.0/
> >>$(INSTALL_DATA) \
> >> -  
> >> $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.2.1/firmware-5.bin_10.4-3.2.1-00053 \
> >> +  
> >> $(PKG_BUILD_DIR)/QCA4019/hw1.0/3.4/firmware-5.bin_10.4-3.4-00082 \
> >>$(1)/lib/firmware/ath10k/QCA4019/hw1.0/firmware-5.bin
> >>  endef
> > The new IPQ4019 firmware isn't as stable as the old one. I do see hangs
> > from time to time (rx ring became corrupted). Whenever this is due to a
> > bug in the firmware or the firmware is pushing harder, I don't know.
> > 
> 
> Thank you for the information, so I will not upgrade the IPQ4019 firmware.
> 
> I also wanted to upgrade the QCA988X firmware first, but it was crashing
> directly after being loaded and now linux-firmeware ships the old one again:
> http://lists.infradead.org/pipermail/ath10k/2017-September/010138.html
> 

FYI: There's a new firmware now for the IPQ4019:

firmware-5.bin_10.4-3.2.1-00058

https://github.com/kvalo/ath10k-firmware/commit/476a2850b1e8582d51187799d7de209daf1a57b2

Regards,
Christian

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

Re: [LEDE-DEV] [PATCH] musl: update to 1.1.17

[Lucian Cristian]

On 01.11.2017 12:08, Lucian Cristian wrote:

On 29.10.2017 01:08, Christian Lamparter wrote:

On Sunday, October 22, 2017 12:02:07 AM CEST Hannu Nyman wrote:

Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017:
  > I think your problem is fixed in 
ec04d122f1182aeb91f39b0e80ae40c68e4d9605

  > fix regression in glob with literal . or .. path component

Based on musl mailing list, there will likely be a new musl release 
rather soon:


Rich Felker wrote in http://www.openwall.com/lists/musl/2017/10/21/3
  > > This was wrong and introduced a regression: literal . and .. 
in paths

passed into glob result in no results.
  > > ...
  > > Due to this and a couple small other bugs/regressions, I think 
it will
make sense to make another release right away, to have a solid 
"works out of
the box without patching" one as the latest. Please let me know if 
you spot

other regressions so fixes can be included.

Ok, so wait for the next release then, or should I just respin the patch
based on the current tree?

Regards,
Christian

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


Mainline - 1.1.18 is available


Regards


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


on the first try, brief test, for dhcp wan, only issuing manual dhcpc 
worked, or maybe the tree wasn't clean enough


Regards


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

Re: [LEDE-DEV] [PATCH] musl: update to 1.1.17

[Lucian Cristian]

On 29.10.2017 01:08, Christian Lamparter wrote:

On Sunday, October 22, 2017 12:02:07 AM CEST Hannu Nyman wrote:

Hauke Mehrtens wrote on Sat Oct 21 12:26:04 PDT 2017:
  > I think your problem is fixed in ec04d122f1182aeb91f39b0e80ae40c68e4d9605
  > fix regression in glob with literal . or .. path component

Based on musl mailing list, there will likely be a new musl release rather soon:

Rich Felker wrote in http://www.openwall.com/lists/musl/2017/10/21/3
  > > This was wrong and introduced a regression: literal . and .. in paths
passed into glob result in no results.
  > > ...
  > > Due to this and a couple small other bugs/regressions, I think it will
make sense to make another release right away, to have a solid "works out of
the box without patching" one as the latest. Please let me know if you spot
other regressions so fixes can be included.

Ok, so wait for the next release then, or should I just respin the patch
based on the current tree?

Regards,
Christian

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


Mainline - 1.1.18 is available


Regards


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