Re: [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding
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, Hartmut ___ 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
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
Re: [LEDE-DEV] [PATCH v2] merge: add OpenWrt branding
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 > On Oct 28, 2017, at 10:56 AM, p...@oranjevos.nl wrote: > > Dear Florian, > > Seems the discussion that was raised on using a personal openwrt address in a > SOB does not do much good so far and it is certainly not my intention to go > against rule #12; I would be sorry if I did. The question I raised is, > although about personal addresses, absolutely not aimed at anyone personally. > > Your thorough reading of the rules makes sense: the future tense of rule #10 > might be interpreted as to mean that existing addresses are exempted. But the > principal reason, equality, mentioned in that very same rule for not offering > (new) accounts under the openwrt domain, is by its sheer nature not > restricted to the future. The wording in the remerge rules tries to leave > some fair lapse for existing accounts, but using that space to the (maximum) > extend that a strict reading of the words would allow, does not seem right. > Usage for the purpose of (still) receiving mail is reasonable, using it > actively for sending mail is ... more complicated. > > On your question whether I purposely did not mention the restriction on > adherence to trademark policy and FOSS purpose, the answer is simple: it did > not seem relevant in this case (there is no reason to believe that the SOB > violated that rule). > > I do not think this issue warrants much more discussion as most that's > relevant has probably been said and the relevance is relative. > It's up to you guys to decide want you want, to weight the odds, regards from > a by-stander, > Paul ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Broken USB LED trigger on LEDE 17.01.4?
Hi, I recently updated my Netgear WNDR4300 to LEDE 17.01.4 and the only thing that appears broken is the USB LED trigger. The LED works fine and while the USB port is detected, functional, setting it as a trigger does not make the LED blink. Was there any fix not backported to the lede-17.01 branch? Thanks -- F-lorian ___ 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
Dear Florian, Seems the discussion that was raised on using a personal openwrt address in a SOB does not do much good so far and it is certainly not my intention to go against rule #12; I would be sorry if I did. The question I raised is, although about personal addresses, absolutely not aimed at anyone personally. Your thorough reading of the rules makes sense: the future tense of rule #10 might be interpreted as to mean that existing addresses are exempted. But the principal reason, equality, mentioned in that very same rule for not offering (new) accounts under the openwrt domain, is by its sheer nature not restricted to the future. The wording in the remerge rules tries to leave some fair lapse for existing accounts, but using that space to the (maximum) extend that a strict reading of the words would allow, does not seem right. Usage for the purpose of (still) receiving mail is reasonable, using it actively for sending mail is ... more complicated. On your question whether I purposely did not mention the restriction on adherence to trademark policy and FOSS purpose, the answer is simple: it did not seem relevant in this case (there is no reason to believe that the SOB violated that rule). I do not think this issue warrants much more discussion as most that's relevant has probably been said and the relevance is relative. It's up to you guys to decide want you want, to weight the odds, regards from a by-stander, Paul > Op 27 okt. 2017, om 21:54 heeft Florian Fainelli het > volgende geschreven: > > On 10/27/2017 02:34 AM, p...@oranjevos.nl wrote: >> Dear Imre, >> >> On the info for the version of the patch: my error, must have overlooked the >> included version info, it is indeed included. >> >> About the use of openwrt email addresses in the SOB: >> This has been discussed before, and the arguments against using an openwrt >> mail address as a personal address haven't vanished. >> The address in the SOB is meant to identify a contributor, most likely a >> natural person, not some entity of the openwrt project. Usage of an openwrt >> mail address suggests that the person using that address has another >> position in the project than those that use mail addresses not within the >> openwrt.org domain, which does not go well with LEDE rules. >> >> IIRC, during discussions on the remerge, the following compromis was >> reached: usage of personal openwrt addresses wasn't ruled out completely, >> but only in passive sense, as a means to keep receiving mail on the address >> and active usage for personal business is not allowed. John remerge proposal >> v3 states clearly: >> - mail addresses may under no conditions be used for any personal business, >> consultancy, applying for jobs, ... purposes > > Did you purposely omit the next bullet item that says? > > - any mail sent from an openwrt.org account needs to adhere the > trademark policy and should only be used for FOSS purposes > > Link: > http://lists.infradead.org/pipermail/lede-adm/2017-May/000517.html > >> >> As a mail address in a SOB is a personal address, is meant to be that, using >> an openwrt address in a SOB goes directly against the agreed on rules, and >> certainly against the spirit of the LEDE rules that have proven to be >> successful in making the project getting traction and commitment. > > LEDE project rule #10 does only stipulate that new email addresses will > not be given away on the premises of and privacy and equality: > > https://lede-project.org/rules > > 10. The project will not offer email accounts under its project domain > for privacy and equality reasons. > > > That sentence is written with the future tense, and therefore does not > try to impose or specify anything with respect to emails given before > (so in the past). > > Therefore, my reading of the LEDE project rules and the remerge proposal > makes me so inclined as to think that Imre is not in direct violation of > the LEDE project rules regarding the use of an @openwrt.org email > contributor for FOSS perspectives. > > Quite frankly, if the goal is just to give Zoltan and Imre a hard time > and nitpick on everything possible just to delay (purposely or not) the > remerge, then you are doing a great job at it, but this goes against > rule #12. > >> Paul >> >> >> >> >>> Op 26 okt. 2017, om 18:32 heeft Imre Kaloz het volgende >>> geschreven: >>> >>> Hi Paul, >>> >>> On 2017-10-26 18:16, p...@oranjevos.nl wrote: Please, could you add some info on what has changed with the new version of the patch ? And, it would be appreciated when the SOB would not use an openwrt.org mail address (assuming Imre has another suitable mail available). Paul > Op 26 okt. 2017, om 17:41 heeft Zoltan HERPAI > het volgende geschreven: > > Given that we've decided to sail under the same flag for > the benefit of the whole community, and acknowledge the > achi
[LEDE-DEV] TL-WR841N v13 LEDE git - txpower always 0dBm
Hi, I have a TL-WR841N v13 with LEDE git snapshot r5174-34958c8. With the same Hardware running on OEM firmware I had a working wireless link in the garden house (~15m away), since I flashed LEDE I can see the Basestation, but association/authentication fails due to timeout. https://pastebin.com/Ca2p2GxS While searching for the issue, I found that `iwinfo radio0 info` and `iwinfo radio0 txpower` would always report the txpower to be 0dBm. Even setting it explicity with `iw phy phy0 set txpower fixed 10dBm` would not change that. The regdom ist set do DE, but I also tried 00-World. https://pastebin.com/u9a6s7ZG To me that makes sense, because when I'm closer to the device, the Wifi association works and connection is quite stable. Is this a known issue? Are there workarounds? Is it possible to support in debugging this further? Thank you very much! Peter signature.asc Description: OpenPGP digital signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] openssl: Enable assembler optimizations for aarch64
The awesome AES performance was too good to be true: it seems to produce incorrect results when encrypting on the pine64 and decrypting on a x86_64 machine :( Possibly some assembler is optimized away by the compiler, which would explain why it's so fast. Please don't merge for now until I investigate. SHA does seem to give correct results though (and is really fast). On 27-10-17, Baptiste Jonglez wrote: > OpenSSL is built with the generic linux settings for most targets, > including aarch64. These generic settings are designed for 32-bit CPU and > provide no assembler optmization: this is widely suboptimal for aarch64. > > This patch simply switches to the aarch64 settings that are already > available in OpenSSL. > > Here is the output of "openssl speed" before the optimization, with > "(...)" representing build flags that didn't change: > > OpenSSL 1.0.2l 25 May 2017 > options:bn(64,32) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) > blowfish(ptr) > compiler: aarch64-openwrt-linux-musl-gcc (...) > > And after this patch, OpenSSL uses 64 bit mode and assembler optimizations: > > OpenSSL 1.0.2l 25 May 2017 > options:bn(64,64) rc4(ptr,char) des(idx,cisc,2,int) aes(partial) > blowfish(ptr) > compiler: aarch64-openwrt-linux-musl-gcc (...) -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM > > Here are some benchmarks on a pine64+ running latest LEDE master > r5142-20d363aed3: > > before# openssl speed sha aes blowfish > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes > sha1 3918.89k 9982.43k19148.03k24933.03k > 27325.78k > sha2564604.51k10240.64k17472.51k21355.18k > 22801.07k > sha5123662.19k14539.41k21443.16k29544.11k > 33177.60k > blowfish cbc 16266.63k16940.86k17176.92k17237.33k > 17252.35k > aes-128 cbc 19712.95k21447.40k22091.09k22258.35k > 22304.09k > aes-192 cbc 17680.12k19064.47k19572.14k19703.13k > 19737.26k > aes-256 cbc 15986.67k17132.48k17537.28k17657.17k > 17689.26k > > after# openssl speed sha aes blowfish > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes > sha1 6770.87k26172.80k86878.38k 205649.58k > 345978.20k > sha256 20913.93k74663.85k 184658.18k 290891.09k > 351032.66k > sha5127633.10k30110.14k50083.24k71883.43k > 82485.25k > blowfish cbc 16224.93k16933.55k17173.76k17234.94k > 17252.35k > aes-128 cbc 19425.74k21193.31k22065.74k22304.77k > 22380.54k > aes-192 cbc 17452.29k18883.84k19536.90k19741.70k > 19800.06k > aes-256 cbc 15815.89k17003.01k17530.03k17695.40k > 17746.60k > > For some reason AES and blowfish do not benefit, but SHA performance > improves between 1.7x and 15x. SHA256 clearly benefits the most from the > optimization (4.5x on small blocks, 15x on large blocks!). > > When using EVP (with "openssl speed -evp "): > > # Before, EVP mode > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes > sha1 3824.46k10049.66k19170.56k24947.03k > 27325.78k > sha2563368.33k 8511.15k16061.44k20772.52k > 22721.88k > sha5122845.23k11381.57k19467.69k28512.26k > 33008.30k > bf-cbc 15146.74k16623.83k17092.01k17211.39k > 17249.62k > aes-128-cbc 17873.03k20870.61k21933.65k22216.36k > 22301.35k > aes-192-cbc 16184.18k18607.15k19447.13k19670.02k > 19737.26k > aes-256-cbc 14774.06k16757.25k17457.58k17639.42k > 17686.53k > > # After, EVP mode > type 16 bytes 64 bytes256 bytes 1024 bytes 8192 > bytes > sha1 7056.97k27142.10k89515.86k 209155.41k > 347419.99k > sha2567745.70k29750.06k95341.48k 211001.69k > 332376.75k > sha5124550.47k18086.06k39997.10k65880.75k > 81431.21k > bf-cbc 15129.20k16619.03k17090.56k17212.76k > 17246.89k > aes-128-cbc 99619.74k 269032.34k 450214.23k 567353.00k > 613933.06k > aes-192-cbc 93180.74k 231017.79k 361766.66k 433671.51k > 461731.16k > aes-256-cbc 89343.23k 209858.58k 310160.04k 362234.88k > 380878.85k > > Blowfish does not seem to have assembler optimization at all, and SHA > still benefits (between 1.6x and 14.5x) but is generally slower than in > non-EVP mode. > > However, AES performance is improved between 5.5x and 27.5x, which is > really impressive! For aes-128-cbc on lar
