Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH v2] merge: add OpenWrt branding
On 11/2/2017 1:44 PM, Hartmut Knaack wrote: I agree, that there were no warning signs on the public mailing list. As I said before, all history now; discussing it further serves no purpose. - Mike ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs
> On Nov 2, 2017, at 3:54 PM, Felix Fietkau wrote: > > On 2017-11-02 22:50, Philip Prindeville wrote: >> >> Okay, great. >> >> When will this show up in LEDE? > Pushed just now. > > - Felix Tested and confirmed! ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding
Hi, Zoltan HERPAI schrieb am 02.11.2017 um 13:20: > For the sake of full transparency, Imre and me was not part of the vote, > as that was sent to lede-adm, without including openwrt-hackers or > openwrt-devel. and your PATCH v2 didn't go to lede-adm. a suggestion from a simple community member: everyone subscribes to all of these four lists instead of complaining about "this was not in the correct list". such small things delaying the merge is really annoying to watch... Regards Andreas P.S.: no i'm not on all of these lists, but i have no voting rights, so it doesn't delay or block something. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs
On 2017-11-02 22:50, Philip Prindeville wrote: > >> On Nov 2, 2017, at 3:03 PM, Felix Fietkau wrote: >> >> On 2017-11-02 19:23, Philip Prindeville wrote: >>> From: Philip Prindeville >>> >>> When uclient-fetch is called with multiple URL's, it derives the >>> first filename based on the URL. When it then handles the 2nd and >>> subsequent URLs, it assumes that it was called with a -O filename >>> argument as the output file, because it tries to overload the >>> variable output_file to mean 2 different things. >>> >>> The fix is to use a bool to remember whether we were called with >>> an explicit output filename, i.e. with the -O argument, and not >>> overload output_file for this purpose. >>> >>> Signed-off-by: Philip Prindeville >> Thanks for debugging this. I've decided to fix this with a different >> approach instead. I've pushed a change that avoids the overloading issue >> entirely by renaming the global variable and overwriting a local >> variable only. >> >> - Felix > > > Okay, great. > > When will this show up in LEDE? Pushed just now. - Felix ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs
> On Nov 2, 2017, at 3:03 PM, Felix Fietkau wrote: > > On 2017-11-02 19:23, Philip Prindeville wrote: >> From: Philip Prindeville >> >> When uclient-fetch is called with multiple URL's, it derives the >> first filename based on the URL. When it then handles the 2nd and >> subsequent URLs, it assumes that it was called with a -O filename >> argument as the output file, because it tries to overload the >> variable output_file to mean 2 different things. >> >> The fix is to use a bool to remember whether we were called with >> an explicit output filename, i.e. with the -O argument, and not >> overload output_file for this purpose. >> >> Signed-off-by: Philip Prindeville > Thanks for debugging this. I've decided to fix this with a different > approach instead. I've pushed a change that avoids the overloading issue > entirely by renaming the global variable and overwriting a local > variable only. > > - Felix Okay, great. When will this show up in LEDE? Thanks. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs
On 2017-11-02 19:23, Philip Prindeville wrote: > From: Philip Prindeville > > When uclient-fetch is called with multiple URL's, it derives the > first filename based on the URL. When it then handles the 2nd and > subsequent URLs, it assumes that it was called with a -O filename > argument as the output file, because it tries to overload the > variable output_file to mean 2 different things. > > The fix is to use a bool to remember whether we were called with > an explicit output filename, i.e. with the -O argument, and not > overload output_file for this purpose. > > Signed-off-by: Philip Prindeville Thanks for debugging this. I've decided to fix this with a different approach instead. I've pushed a change that avoids the overloading issue entirely by renaming the global variable and overwriting a local variable only. - Felix ___ 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
Mike Baker wrote on 02.11.2017 16:59: On 11/1/2017 5:18 PM, Hartmut Knaack wrote: 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%? The issue is the use of an openwrt email address to make an announcement on behalf of openwrt stating that openwrt had become lede without ever discussing it. There were no warning signs, everybody from openwrt suddenly found out that there was a new project and they had been kicked out. - Mike I'm reading over Jows announcement over and over again, but can not see, where he would announce it on behalf of openwrt. He has been using his @openwrt.org, just like countless times before on the mailing list. I can also not find the claim, that LEDE would be the successor of openwrt, just that quite a lot of active developers would try to start a new project with a different focus on certain issues. I agree, that there were no warning signs on the public mailing list. But still, what have been the terms and conditions for project email addresses? How are sanctions decided? And if I pick up your statement, that using an openwrt email address implies that it is sent on behalf of openwrt (and thus, reviewed by the project members and acknowledged by the majority), there should just be one account for public relations (like version announcements, business communication on behalf of the project). I understand, that your feelings got hurt by the announcement, but your reaction was not professional. So, IMHO you messed up, now deal with it. Thanks, Hartmut ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 2/2] wifi: (80211r) add ft_over_ds support
It's now possibile choose if use FT over DS protocol or FT over the Air protocol for 80211r Signed-off-by: Lorenzo Santina --- modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua | 6 ++ 1 file changed, 6 insertions(+) diff --git a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua index 8528f8624..c64226931 100644 --- a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua +++ b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua @@ -801,6 +801,12 @@ if hwtype == "mac80211" or hwtype == "prism2" then reassociation_deadline.datatype = "range(1000,65535)" reassociation_deadline.rmempty = true + ft_protocol = s:taboption("encryption", ListValue, "ft_over_ds", translate("FT protocol")) + ft_protocol:depends({ieee80211r="1"}) + ft_protocol:value("1", translatef("FT over DS")) + ft_protocol:value("0", translatef("FT over the Air")) + ft_protocol.rmempty = true + ft_psk_generate_local = s:taboption("encryption", Flag, "ft_psk_generate_local", translate("Generate PMK locally"), translate("When using a PSK, the PMK can be generated locally without inter AP communications")) -- 2.14.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH 1/2] wifi: (80211r) add ft_psk_generate_local support
From: Lorenzo Santina If you are using PSK you can use ft_psk_generate_local to simplify 80211r configuration. Signed-off-by: Lorenzo Santina --- .../luasrc/model/cbi/admin_network/wifi.lua| 32 -- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua index f9a2dee6c..8528f8624 100644 --- a/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua +++ b/modules/luci-mod-admin-full/luasrc/model/cbi/admin_network/wifi.lua @@ -793,9 +793,22 @@ if hwtype == "mac80211" or hwtype == "prism2" then mobility_domain.datatype = "and(hexstring,rangelength(4,4))" mobility_domain.rmempty = true + reassociation_deadline = s:taboption("encryption", Value, "reassociation_deadline", + translate("Reassociation Deadline"), + translate("time units (TUs / 1.024 ms) [1000-65535]")) + reassociation_deadline:depends({ieee80211r="1"}) + reassociation_deadline.placeholder = "1000" + reassociation_deadline.datatype = "range(1000,65535)" + reassociation_deadline.rmempty = true + + ft_psk_generate_local = s:taboption("encryption", Flag, "ft_psk_generate_local", + translate("Generate PMK locally"), + translate("When using a PSK, the PMK can be generated locally without inter AP communications")) + ft_psk_generate_local:depends({ieee80211r="1"}) + r0_key_lifetime = s:taboption("encryption", Value, "r0_key_lifetime", translate("R0 Key Lifetime"), translate("minutes")) - r0_key_lifetime:depends({ieee80211r="1"}) + r0_key_lifetime:depends({ieee80211r="1", ft_psk_generate_local=""}) r0_key_lifetime.placeholder = "1" r0_key_lifetime.datatype = "uinteger" r0_key_lifetime.rmempty = true @@ -803,21 +816,13 @@ if hwtype == "mac80211" or hwtype == "prism2" then r1_key_holder = s:taboption("encryption", Value, "r1_key_holder", translate("R1 Key Holder"), translate("6-octet identifier as a hex string - no colons")) - r1_key_holder:depends({ieee80211r="1"}) + r1_key_holder:depends({ieee80211r="1", ft_psk_generate_local=""}) r1_key_holder.placeholder = "4f577274" r1_key_holder.datatype = "and(hexstring,rangelength(12,12))" r1_key_holder.rmempty = true - reassociation_deadline = s:taboption("encryption", Value, "reassociation_deadline", - translate("Reassociation Deadline"), - translate("time units (TUs / 1.024 ms) [1000-65535]")) - reassociation_deadline:depends({ieee80211r="1"}) - reassociation_deadline.placeholder = "1000" - reassociation_deadline.datatype = "range(1000,65535)" - reassociation_deadline.rmempty = true - pmk_r1_push = s:taboption("encryption", Flag, "pmk_r1_push", translate("PMK R1 Push")) - pmk_r1_push:depends({ieee80211r="1"}) + pmk_r1_push:depends({ieee80211r="1", ft_psk_generate_local=""}) pmk_r1_push.placeholder = "0" pmk_r1_push.rmempty = true @@ -827,8 +832,7 @@ if hwtype == "mac80211" or hwtype == "prism2" then "This list is used to map R0KH-ID (NAS Identifier) to a destination " .. "MAC address when requesting PMK-R1 key from the R0KH that the STA " .. "used during the Initial Mobility Domain Association.")) - - r0kh:depends({ieee80211r="1"}) + r0kh:depends({ieee80211r="1", ft_psk_generate_local=""}) r0kh.rmempty = true r1kh = s:taboption("encryption", DynamicList, "r1kh", translate("External R1 Key Holder List"), @@ -837,7 +841,7 @@ if hwtype == "mac80211" or hwtype == "prism2" then "This list is used to map R1KH-ID to a destination MAC address " .. "when sending PMK-R1 key from the R0KH. This is also the " .. "list of authorized R1KHs in the MD that can request PMK-R1 keys.")) - r1kh:depends({ieee80211r="1"}) + r1kh:depends({ieee80211r="1", ft_psk_generate_local=""}) r1kh.rmempty = true -- End of 802.11r options -- 2.14.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [LUCI] [PATCH 0/2] wifi: 80211r psk_generate_local and ft_ver_ds
When using a PSK, with ft_psk_generate_local the PMK is generate locally simplifing the configuration of 80211r. With ft_over_ds support the user can now choose if use FT over DS protocol or FT over the Air protocol. Lorenzo Santina (2): wifi: (80211r) add ft_psk_generate_local support wifi: (80211r) add ft_over_ds support .../luasrc/model/cbi/admin_network/wifi.lua| 38 ++ 1 file changed, 24 insertions(+), 14 deletions(-) -- 2.14.1 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH v1 1/1] uclient-fetch: correct filename w/ multple URLs
From: Philip Prindeville When uclient-fetch is called with multiple URL's, it derives the first filename based on the URL. When it then handles the 2nd and subsequent URLs, it assumes that it was called with a -O filename argument as the output file, because it tries to overload the variable output_file to mean 2 different things. The fix is to use a bool to remember whether we were called with an explicit output filename, i.e. with the -O argument, and not overload output_file for this purpose. Signed-off-by: Philip Prindeville --- uclient-fetch.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/uclient-fetch.c b/uclient-fetch.c index dff144b22b7b3cd2d5982a615b9c2d68deab5042..fb3ab45935d94dce4f40aeae9bea6d7f7edc1c37 100644 --- a/uclient-fetch.c +++ b/uclient-fetch.c @@ -51,6 +51,7 @@ static bool proxy = true; static bool default_certs = false; static bool no_output; static const char *output_file; +static bool saw_output_filename = false; static int output_fd = -1; static int error_ret; static off_t out_offset; @@ -106,12 +107,12 @@ static int open_output_file(const char *path, uint64_t resume_offset) else flags = O_WRONLY | O_TRUNC; - if (!cur_resume && !output_file) + if (!cur_resume && !saw_output_filename) flags |= O_EXCL; flags |= O_CREAT; - if (output_file) { + if (saw_output_filename) { if (!strcmp(output_file, "-")) { if (!quiet) fprintf(stderr, "Writing to stdout\n"); @@ -500,6 +501,16 @@ static int no_ssl(const char *progname) return 1; } +static int too_many_output_files(const char *progname) +{ + fprintf(stderr, + "%s: the -O output_file option can't be used for multiple " + "URLs unless its value is \"-\".\n", + progname); + + return 1; +} + enum { L_NO_CHECK_CERTIFICATE, L_CA_CERTIFICATE, @@ -616,6 +627,7 @@ int main(int argc, char **argv) break; case 'O': output_file = optarg; + saw_output_filename = true; break; case 'P': if (chdir(optarg)) { @@ -651,6 +663,12 @@ int main(int argc, char **argv) if (argc < 1) return usage(progname); + /* doesn't make sense to use -O with multiple URL's unless you're +* sending them all to stdout... +*/ + if (argc > 1 && saw_output_filename && strcmp(output_file, "-")) + return too_many_output_files(progname); + if (!ssl_ctx) { for (i = 0; i < argc; i++) { if (!strncmp(argv[i], "https", 5)) -- 2.7.4 ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] LEDE new image on gw5520
seems that ive lost my eth0 / eth1 interfeaces on a RECENT ... today image built for the gw5520 i do however see the ifb0 and ifb1 interfaces... any ideas? ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Busybox weirdness
> On Nov 2, 2017, at 4:24 AM, edgar.sol...@web.de wrote: > > hey Phillip, > > On 02.11.2017 03:36, Philip Prindeville wrote: >> Can someone else please try to reproduce this? > > yes, not exactly but wrong resulting file name nonetheless. it's obviously a > bug. looks like a variable reuse went awry as it always hit's the second > file, having fragments of the first file's name. i switched the files you > downloaded, just to test if there might be a server side influence. > > :/tmp# wget > http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip > http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz > Downloading > 'http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip' > Connecting to 2400:cb00:2048:1::6810:262f:80 > Writing to 'GeoIPCountryCSV.zip' > GeoIPCountryCSV.zip 100% |***| 2338k 0:00:00 > ETA > Download completed (2394696 bytes) > Connecting to 2400:cb00:2048:1::6810:252f:80 > Writing to 'w;o▒w;o▒ntryCSV.zip' > w;o▒w;o▒ntryCSV.zip 100% |***| 1496k 0:00:00 > ETA > Download completed (1532219 bytes) > > vs. > > :/tmp# 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 2400:cb00:2048:1::6810:262f:80 > Writing to 'GeoIPv6.csv.gz' > GeoIPv6.csv.gz 100% |***| 1496k 0:00:00 > ETA > Download completed (1532219 bytes) > Connecting to 2400:cb00:2048:1::6810:252f:80 > Writing to 'w▒o▒w▒o▒csv.gz' > w▒o▒w▒o▒csv.gz 100% |***| 2338k 0:00:00 > ETA > Download completed (2394696 bytes) > > this is on a Lede 17.01-SNAPSHOT, r3535+35-ee32de4 with '/bin/wget -> > uclient-fetch' on an Ubiquiti Loco M2. > > ..ede Thank you both for looking into this. I poked around the code last night after sending out that email, and found that “output_file” was being overloaded and this was causing some side-effects. I have a tentative fix which I’ll send out. -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
On 11/1/2017 5:18 PM, Hartmut Knaack wrote: 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%? The issue is the use of an openwrt email address to make an announcement on behalf of openwrt stating that openwrt had become lede without ever discussing it. There were no warning signs, everybody from openwrt suddenly found out that there was a new project and they had been kicked out. - Mike ___ 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 - LEDE version numbers?
On 11/01/2017 12:15 PM, Hannu Nyman wrote: > At the first glance LEDE r5217-098afa1e1b compiled with 1.1.18 booted ok and > got normally a DHCP wan address, hostapd started etc.. Excuse me what?! "LEDE r5217-098afa1e1b"? Why does that look like a "release 5217" and a SHA prefix "098afa1e1b"? So what - does LEDE have two completely different versioning systems? Is LEDE switching over to the openwrt versioning system? From where comes the "r5217"? Is that "r5217" a strictly reproducible LEDE version? Somebody, please clue me in here. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding
Hi Hauke, Hauke Mehrtens wrote: On 10/26/2017 09:05 PM, Dave Taht wrote: Hannu Nyman writes: Zoltan HERPAI kirjoitti 26.10.2017 klo 18:41: + - + * 2 oz. Orange Juice Combine all juices in a + * 2 oz. Pineapple Juice tall glass filled with + * 2 oz. Grapefruit Juice ice, stir well. + * 2 oz. Cranberry Juice + - Still promoting the drink recipe although the voting is clearly going against release names and also all given feedback about drinks has been negative? I incidentally have always liked the in-your-face anti-establishment flair of using codenames based on alcoholic beverages. The drink meme beats the hell out of corporate blandness with selecting codenames out of a marketing jar - "Project Olympus!", and is easier to remember than 17.X.Y. "Blurry fish butt" I think was (until recently) a codename for the linux kernel. and I've joked elsewhere that I'd like a codename named "green goddess". https://www.allbud.com/marijuana-strains/sativa-dominant-hybrid/green-goddess Please get rid of it. It makes the whole thing looks adolescent. And replace it with what? (where was the voting?) The vote happened here: http://lists.infradead.org/pipermail/lede-adm/2017-October/000636.html I am also for removing this, without the code names it does not makes any sense. This banner is the first thing companies change to add they own brand. If you want to annoy them, use this license in some important part: ;-) WTFPL (Do What the Fuck You Want To Public License) Fine, then please advise where else this needs to be removed from, before I send the v3. $ grep RELEASE include/version.mk RELEASE:=Reboot VERSION_NICK:=$(if $(VERSION_NICK),$(VERSION_NICK),$(RELEASE)) For the sake of full transparency, Imre and me was not part of the vote, as that was sent to lede-adm, without including openwrt-hackers or openwrt-devel. Regards, Zoltan H ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding
On 10/26/2017 09:05 PM, Dave Taht wrote: > Hannu Nyman writes: > >> Zoltan HERPAI kirjoitti 26.10.2017 klo 18:41: >>> + - >>> + * 2 oz. Orange Juice Combine all juices in a >>> + * 2 oz. Pineapple Juice tall glass filled with >>> + * 2 oz. Grapefruit Juice ice, stir well. >>> + * 2 oz. Cranberry Juice >>> + - >> >> >> Still promoting the drink recipe although the voting is clearly going against >> release names and also all given feedback about drinks has been negative? > > I incidentally have always liked the in-your-face anti-establishment > flair of using codenames based on alcoholic beverages. The drink meme > beats the hell out of corporate blandness with selecting codenames out > of a marketing jar - "Project Olympus!", and is easier to remember than > 17.X.Y. > > "Blurry fish butt" I think was (until recently) a codename for the linux > kernel. > > and I've joked elsewhere that I'd like a codename named "green goddess". > > https://www.allbud.com/marijuana-strains/sativa-dominant-hybrid/green-goddess > >> Please get rid of it. It makes the whole thing looks adolescent. > > And replace it with what? (where was the voting?) The vote happened here: http://lists.infradead.org/pipermail/lede-adm/2017-October/000636.html I am also for removing this, without the code names it does not makes any sense. This banner is the first thing companies change to add they own brand. If you want to annoy them, use this license in some important part: ;-) WTFPL (Do What the Fuck You Want To Public License) Hauke ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Busybox weirdness
hey Phillip, On 02.11.2017 03:36, Philip Prindeville wrote: > Can someone else please try to reproduce this? yes, not exactly but wrong resulting file name nonetheless. it's obviously a bug. looks like a variable reuse went awry as it always hit's the second file, having fragments of the first file's name. i switched the files you downloaded, just to test if there might be a server side influence. :/tmp# wget http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPCountryCSV.zip' Connecting to 2400:cb00:2048:1::6810:262f:80 Writing to 'GeoIPCountryCSV.zip' GeoIPCountryCSV.zip 100% |***| 2338k 0:00:00 ETA Download completed (2394696 bytes) Connecting to 2400:cb00:2048:1::6810:252f:80 Writing to 'w;o▒w;o▒ntryCSV.zip' w;o▒w;o▒ntryCSV.zip 100% |***| 1496k 0:00:00 ETA Download completed (1532219 bytes) vs. :/tmp# 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 2400:cb00:2048:1::6810:262f:80 Writing to 'GeoIPv6.csv.gz' GeoIPv6.csv.gz 100% |***| 1496k 0:00:00 ETA Download completed (1532219 bytes) Connecting to 2400:cb00:2048:1::6810:252f:80 Writing to 'w▒o▒w▒o▒csv.gz' w▒o▒w▒o▒csv.gz 100% |***| 2338k 0:00:00 ETA Download completed (2394696 bytes) this is on a Lede 17.01-SNAPSHOT, r3535+35-ee32de4 with '/bin/wget -> uclient-fetch' on an Ubiquiti Loco M2. ..ede ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Busybox weirdness
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 --- On 02/11/2017 09:42, Philip Prindeville wrote: 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# c 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 I can reproduce partially (17.01.4), here I get garbled filename that seems due to charset mismatch: wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz http://geolite.maxmind.com/download/geoip/da tabase/GeoIPCountryCSV.zip Downloading 'http://geolite.maxmind.com/download/geoip/database/GeoIPv6.csv.gz' Connecting to 2400:cb00:2048:1::6810:262f:80 Writing to 'GeoIPv6.csv.gz' GeoIPv6.csv.gz 100% |***| 1496k 0:00:00 ETA Download completed (1532219 bytes) Connecting to 2400:cb00:2048:1::6810:252f:80 Writing to '��csv.gz' ��csv.gz 100% |***| 2338k 0:00:00 ETA Download completed (2394696 bytes) It also misbehaves if the download is somehow redirected over https, for example while downloading wrtbwmon i get: wget https://github.com/Kiougar/luci-wrtbwmon/releases/download/v0.6.0/luci-wrtbwmon_0.6.0_all.ipk Downloading 'https://github.com/Kiougar/luci-wrtbwmon/releases/download/v0.6.0/luci-wrtbwmon_0.6.0_all.ipk' Connecting to 192.30.253.112:443 Redirected to /77686685/247a31e2-494d-11e7-818a-29601f00a0dc?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20171102%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20171102T073145Z&X-Amz-Expires=300&X-Amz-Signature=fc898a693aeb4664ba1bc51de9ae2d2f791707e50829d7fb9b4ceaae4d99bd53&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dluci-wrtbwmon_0.6.0_all.ipk&response-content-type=application%2Foctet-stream on github-production-release-asset-2e65be.s3.amazonaws.com Writing to '247a31e2-494d-11e7-818a-29601f00a0dc?X-Amz-Algorithm=AWS4-HMAC-SHA256' 247a31e2-494d-11e7-8 100% |***| 5245 0:00:00 ETA Download completed (5245 bytes) None of this happens with plain wget (and ca-certificates) installed. --- End Message --- ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev