Re: [OpenWrt-Devel] [PATCH luci 1/2] luci-mod-system: use "system" new "validate_firmware_image" ubus method

2019-09-25 Thread Rafał Miłecki 

On 25.09.2019 16:51, Rafał Miłecki wrote:

From: Rafał Miłecki 

This new ubus method provides more properly-formatted details about
firmware file. Use it to check if uploaded image is valid.

The old "sysupgrade --test" method is left for now to provide stderr
output.

Signed-off-by: Rafał Miłecki 


Missed part:

diff --git a/modules/luci-base/root/usr/share/rpcd/acl.d/luci-base.json 
b/modules/luci-base/root/usr/share/rpcd/acl.d/luci-base.json
index 31c154cbc..182f24988 100644
--- a/modules/luci-base/root/usr/share/rpcd/acl.d/luci-base.json
+++ b/modules/luci-base/root/usr/share/rpcd/acl.d/luci-base.json
@@ -44,6 +44,7 @@
"network.device": [ "status" ],
"network.interface": [ "dump" ],
"network": [ "get_proto_handlers" ],
+   "system": [ "validate_firmware_image" ],
"uci": [ "changes", "get" ]
},
"uci": [ "*" ]


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Suggestions] Streamline localization by using Weblate for the project, use LiberaPay or OpenCollective to enable people to donate

2019-09-25 Thread Scott via openwrt-devel 
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 ---
‐‐‐ Original Message ‐‐‐
On Tuesday, September 24, 2019 1:13 AM, Paul Spooren  wrote:


>
> I think that's a good idea! As it doesn't need to be directly integrated
> in any existing workflow nor requires privileges on any Git, it's
> basically just a fancy front-end with translation suggestions for .po
> files right?
>
> Out of curiosity I requested a libre account for a quick evaluation, if
> anyone is in serious doubt on evaluation it I'll instantly cancel the
> request. However I think this is in line with
> https://openwrt.org/meetings/hamburg2019/start#luci_translations
>

Correct, it needs no privileges to update Weblate's .po copy from the 
repository and if you want to commit the localization that has been made by 
contributors you can opt to have the Weblate commit automatically if you're 
feeling daring, or you can just opt to have manually triggered PR where someone 
with merge permission can review per usual contribution workflow. The 
Continuous Localization documentation documents the workflow and possibilities 
pretty well: https://docs.weblate.org/en/latest/admin/continuous.html

Yep, Weblate is largely a browser based localization tool frontend with a pinch 
of middleware components to update Weblate's copy, send out notifications, and 
make commits or PR's.

Thanks again for your time. If I can help pilot any, etc let me know!

-Scott


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

2019-09-25 Thread Tom Psyborg 
On 25/09/2019, Maxnet Support  wrote:
> I have attached iw phy phy0 info output. It shows only 2 antennas. Is this
> wrong? Qca9994 has 4 chains.
>
> On 25 Sep 2019, 22:51, at 22:51, supp...@maxnet.al wrote:
>>Hi,
>>
>>
>>
>>
>>
>>
>>In the beginning i was using 2 dishes on each side. They are ubiquiti
>>2x2 dual polarized dishes and i connected the chains of station in the
>>same way as AP and i still had issues. After that i thought the problem
>>might be because this card uses mimo multipath and AP ch0 should talk
>>with station ch  0 1 2 3. With 2x2 dishes that's not possible because
>>
>>
>>
>>
>>
>>
>>DISH 1
>>
>>
>>
>>
>>CH0 -H
>>
>>
>>
>>
>>CH1 -V
>>
>>
>>
>>
>>
>>
>>CH2 -H
>>
>>
>>
>>
>>CH3 -V
>>
>>
>>
>>
>>
>>
>>The station pigtails were connected in the same way as AP.
>>
>>
>>
>>
>>In this configuration AP ch0 whish is Horizontal can talk only with
>>station ch0 and ch2.
>>
>>
>>
>>
>>
>>
>>So i decided to go with Jiroues single polarity dishes on each side.
>>You think that single polarity might be the problem but why it doesn't
>>cause problems in routers when there are 4 omni antennas and still you
>>can get datarates 866Mbps by phone(my phone is 2x2). The testing
>>distance now is 5km but the distance where they will be installed is
>>13km. We also have dozens of ubiquiti and mikrotik links and 13km it's
>>not a big deal.
>>
>>
>>
>>
>>
>>
>>Today also i noticed something strange. The AP was openwrt and station
>>was ddwrt and i got  433/866 and after changing the station to openwrt
>>the datarates got worse. Ddwrt wasn't good either. It had datarates
>>problem.
>>
>>
>>
>>
>>
>>
>>Can it be something wrong with firmware antenna configuration? Why it
>>shows only two antennas iw phy phy0 info?
>>
>>
>>
>>
>>
>>
>>Thank you
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On Wed, Sep 25, 2019 at 6:34 PM +0200, "Koen Vandeputte"
>> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On 25.09.19 17:14, supp...@maxnet.al wrote:
>>> This is long distance, 5km with 4 dishes on each side. They are all
>>> vertical and all chains have signal range -60 to -65.
>>>
>>> I don't have omni antennas. Is there a problem that i am using
>>dishes?
>>>
>>>
>>I run dozens of long-range devices, and I'm seeing 2 issues in your
>>setup:
>>
>>1)
>>
>>- Ack-to issues kick in starting from roughly 1000m.  When you cannot
>>alter ack_to (coverage class), you will notice severe performance
>>issues
>>above 1000m
>>
>>2)
>>
>>- Using identical polarization on all chains is an absolute performance
>>
>>killer.
>>
>>I have 2 devices,  both 2x2 802.11n, HT40 SGI, which are only 150m
>>apart, all chains V polarized.
>>
>>When running speedtests, inspecting ath9k rate control shows it is
>>stuck
>>at the max speed for 1 chain (iso 2)
>>
>>In my case it means the absolute link rate is 130Mbit iso 270 in this
>>configuration.
>>
>>I can imagine using 4 chains will even reduce performance a lot more.
>>
>>You should really try to use use H + V+ (-45) + (+45).
>>
>>Also, ensure radio's at both sides have the chains on identical
>>polarization. (Chain0 - V,  Chain1 - H, ..)
>>
>>
>>Regards,
>>
>>Koen
>>
>>>
>>> On Wed, Sep 25, 2019 at 5:11 PM +0200, "Ben Greear"
>>> > wrote:
>>>
>>> Is this short distance or long?
>>>
>>> Please try short distance with omni antenna first to make sure
>>you are not hitting the delayed-ack issue
>>> or problems with your antenna.
>>>
>>> Change your antenna orientation so that they point in different
>>directions.
>>>
>>> Thanks,
>>> Ben
>>>
>>> On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
>>> > Hello,
>>> >
>>> > Today i managed to connect the station wds at 80MHz channel.
>>Signal is -56 and i have very low datarates. I have attached a photo.
>>> >
>>> >   When station was ddwrt and AP openwrt the datarates were
>>866/433. TX won't do more than VHT-NSS 1 although RX it's not good
>>either because it's a 4 chain
>>> > radio and it should do VHT-NSS4.
>>> >
>>> > Thank you,
>>> > Klevis
>>> >
>>> >
>>> >
>>> >
>>> > On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" > wrote: >
>>> Weeks or months or whenever I have time, and maybe
>>> sooner if someone > wants to sponsor it. Please understand I, and
>>> probably everyone else working > on OpenWRT, am busy with lots of
>>> other projects and community work often > gets pushed to the back
>>> burner. > > Thanks, > Ben > > On 9/23/19 8:18 AM,
>>> supp...@maxnet.al wrote: > > Hi Ben, > > > > When do you think
>>you
>>> might be able to make those changes to your driver? > > > >
>>> Thanks, > > Klevis. > > > > > > > > On 2019-09-20 13:00, Ben
>>> Greear wrote: > >> On 9/20/19 12:55 PM, Vincent Wiemann wrote: >
>>> >>> Hi Klevis, > >>> > >>> have you tried it with a short
>>> distance? > >>> If you did you should better ask Ben Greear
>>> directly. > >> > >> I asked him to post publicly so that others
>>> can help answer and that > >> my own answers

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

2019-09-25 Thread support 
Hi, 






In the beginning i was using 2 dishes on each side. They are ubiquiti 2x2 dual 
polarized dishes and i connected the chains of station in the same way as AP 
and i still had issues. After that i thought the problem might be because this 
card uses mimo multipath and AP ch0 should talk with station ch  0 1 2 3. With 
2x2 dishes that's not possible because 






DISH 1 




CH0 -H 




CH1 -V 






CH2 -H 




CH3 -V 






The station pigtails were connected in the same way as AP.  




In this configuration AP ch0 whish is Horizontal can talk only with station ch0 
and ch2. 






So i decided to go with Jiroues single polarity dishes on each side. You think 
that single polarity might be the problem but why it doesn't cause problems in 
routers when there are 4 omni antennas and still you can get datarates 866Mbps 
by phone(my phone is 2x2). The testing distance now is 5km but the distance 
where they will be installed is 13km. We also have dozens of ubiquiti and 
mikrotik links and 13km it's not a big deal.  






Today also i noticed something strange. The AP was openwrt and station was 
ddwrt and i got  433/866 and after changing the station to openwrt the 
datarates got worse. Ddwrt wasn't good either. It had datarates problem.  






Can it be something wrong with firmware antenna configuration? Why it shows 
only two antennas iw phy phy0 info? 






Thank you 









On Wed, Sep 25, 2019 at 6:34 PM +0200, "Koen Vandeputte" 
 wrote:











On 25.09.19 17:14, supp...@maxnet.al wrote:
> This is long distance, 5km with 4 dishes on each side. They are all 
> vertical and all chains have signal range -60 to -65.
>
> I don't have omni antennas. Is there a problem that i am using dishes?
>
>
I run dozens of long-range devices, and I'm seeing 2 issues in your setup:

1)

- Ack-to issues kick in starting from roughly 1000m.  When you cannot 
alter ack_to (coverage class), you will notice severe performance issues 
above 1000m

2)

- Using identical polarization on all chains is an absolute performance 
killer.

I have 2 devices,  both 2x2 802.11n, HT40 SGI, which are only 150m 
apart, all chains V polarized.

When running speedtests, inspecting ath9k rate control shows it is stuck 
at the max speed for 1 chain (iso 2)

In my case it means the absolute link rate is 130Mbit iso 270 in this 
configuration.

I can imagine using 4 chains will even reduce performance a lot more.

You should really try to use use H + V+ (-45) + (+45).

Also, ensure radio's at both sides have the chains on identical 
polarization. (Chain0 - V,  Chain1 - H, ..)


Regards,

Koen

>
> On Wed, Sep 25, 2019 at 5:11 PM +0200, "Ben Greear" 
> > wrote:
>
> Is this short distance or long?
>
> Please try short distance with omni antenna first to make sure you are 
> not hitting the delayed-ack issue
> or problems with your antenna.
>
> Change your antenna orientation so that they point in different 
> directions.
>
> Thanks,
> Ben
>
> On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
> > Hello,
> > 
> > Today i managed to connect the station wds at 80MHz channel. Signal is 
> -56 and i have very low datarates. I have attached a photo.
> > 
> >   When station was ddwrt and AP openwrt the datarates were 866/433. TX 
> won't do more than VHT-NSS 1 although RX it's not good either because it's a 
> 4 chain 
> > radio and it should do VHT-NSS4.
> > 
> > Thank you,
> > Klevis
> > 
> > 
> > 
> > 
> > On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" > wrote: > > Weeks 
> or months or whenever I have time, and maybe
> sooner if someone > wants to sponsor it. Please understand I, and
> probably everyone else working > on OpenWRT, am busy with lots of
> other projects and community work often > gets pushed to the back
> burner. > > Thanks, > Ben > > On 9/23/19 8:18 AM,
> supp...@maxnet.al wrote: > > Hi Ben, > > > > When do you think you
> might be able to make those changes to your driver? > > > >
> Thanks, > > Klevis. > > > > > > > > On 2019-09-20 13:00, Ben
> Greear wrote: > >> On 9/20/19 12:55 PM, Vincent Wiemann wrote: >
> >>> Hi Klevis, > >>> > >>> have you tried it with a short
> distance? > >>> If you did you should better ask Ben Greear
> directly. > >> > >> I asked him to post publicly so that others
> can help answer and that > >> my own answers might > >> help
> someone else. > >> > >> I have some patches that should enable
> coverage class settings for > >> wave-2, but I am too busy > >>
> with other things right now to port them to my ath10k-ct
> driver/firmware. > >> > >> Thanks, > >> Ben > >> > >>> > >>> By
> the way ath10k gen 2 chipsets don't work very well with long
> distance links without a > >>> special feature which
> implementation is only available to companies like Ubiquiti and
> very few > >>> people who have an own reverse-engineered
>

Re: [OpenWrt-Devel] [PATCH] ipq40xx: fix hw-crypto detection of qce driver

2019-09-25 Thread Eneas Queiroz 
This is meant for 19.07, as it's already in master.  I just now
realized it was missing from the subject line.  Sorry about that.

Eneas

On Wed, Sep 25, 2019 at 2:03 PM Eneas U de Queiroz
 wrote:
>
> This adds the CRYPTO_ALG_KERN_DRIVER_ONLY flag to Qualcomm crypto engine
> driver algorithms, so that openssl devcrypto can recognize them as
> hardware-accelerated.
>
> Signed-off-by: Eneas U de Queiroz 
>
> diff --git 
> a/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
>  
> b/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
> new file mode 100644
> index 00..58b0ebf5e7
> --- /dev/null
> +++ 
> b/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
> @@ -0,0 +1,31 @@
> +From: Eneas U de Queiroz 
> +Subject: [PATCH] crypto: qce - add CRYPTO_ALG_KERN_DRIVER_ONLY flag
> +
> +Set the CRYPTO_ALG_KERN_DRIVER_ONLY flag to all algorithms exposed by
> +the qce driver, since they are all hardware accelerated, accessible
> +through a kernel driver only, and not available directly to userspace.
> +
> +Signed-off-by: Eneas U de Queiroz 
> +
> +--- a/drivers/crypto/qce/ablkcipher.c
>  b/drivers/crypto/qce/ablkcipher.c
> +@@ -373,7 +373,7 @@ static int qce_ablkcipher_register_one(c
> +
> +   alg->cra_priority = 300;
> +   alg->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC |
> +-   CRYPTO_ALG_NEED_FALLBACK;
> ++   CRYPTO_ALG_NEED_FALLBACK | 
> CRYPTO_ALG_KERN_DRIVER_ONLY;
> +   alg->cra_ctxsize = sizeof(struct qce_cipher_ctx);
> +   alg->cra_alignmask = 0;
> +   alg->cra_type = _ablkcipher_type;
> +--- a/drivers/crypto/qce/sha.c
>  b/drivers/crypto/qce/sha.c
> +@@ -526,7 +526,7 @@ static int qce_ahash_register_one(const
> +   base = >halg.base;
> +   base->cra_blocksize = def->blocksize;
> +   base->cra_priority = 300;
> +-  base->cra_flags = CRYPTO_ALG_ASYNC;
> ++  base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY;
> +   base->cra_ctxsize = sizeof(struct qce_sha_ctx);
> +   base->cra_alignmask = 0;
> +   base->cra_module = THIS_MODULE;
> --
> 2.21.0
>

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq40xx: fix hw-crypto detection of qce driver

2019-09-25 Thread Eneas U de Queiroz 
This adds the CRYPTO_ALG_KERN_DRIVER_ONLY flag to Qualcomm crypto engine
driver algorithms, so that openssl devcrypto can recognize them as
hardware-accelerated.

Signed-off-by: Eneas U de Queiroz 

diff --git 
a/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
 
b/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
new file mode 100644
index 00..58b0ebf5e7
--- /dev/null
+++ 
b/target/linux/ipq40xx/patches-4.14/181-crypto-qce-add-CRYPTO_ALG_KERN_DRIVER_ONLY-flag.patch
@@ -0,0 +1,31 @@
+From: Eneas U de Queiroz 
+Subject: [PATCH] crypto: qce - add CRYPTO_ALG_KERN_DRIVER_ONLY flag
+
+Set the CRYPTO_ALG_KERN_DRIVER_ONLY flag to all algorithms exposed by
+the qce driver, since they are all hardware accelerated, accessible
+through a kernel driver only, and not available directly to userspace.
+
+Signed-off-by: Eneas U de Queiroz 
+
+--- a/drivers/crypto/qce/ablkcipher.c
 b/drivers/crypto/qce/ablkcipher.c
+@@ -373,7 +373,7 @@ static int qce_ablkcipher_register_one(c
+ 
+   alg->cra_priority = 300;
+   alg->cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC |
+-   CRYPTO_ALG_NEED_FALLBACK;
++   CRYPTO_ALG_NEED_FALLBACK | CRYPTO_ALG_KERN_DRIVER_ONLY;
+   alg->cra_ctxsize = sizeof(struct qce_cipher_ctx);
+   alg->cra_alignmask = 0;
+   alg->cra_type = _ablkcipher_type;
+--- a/drivers/crypto/qce/sha.c
 b/drivers/crypto/qce/sha.c
+@@ -526,7 +526,7 @@ static int qce_ahash_register_one(const
+   base = >halg.base;
+   base->cra_blocksize = def->blocksize;
+   base->cra_priority = 300;
+-  base->cra_flags = CRYPTO_ALG_ASYNC;
++  base->cra_flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_KERN_DRIVER_ONLY;
+   base->cra_ctxsize = sizeof(struct qce_sha_ctx);
+   base->cra_alignmask = 0;
+   base->cra_module = THIS_MODULE;
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

2019-09-25 Thread Koen Vandeputte 


On 25.09.19 17:14, supp...@maxnet.al wrote:
This is long distance, 5km with 4 dishes on each side. They are all 
vertical and all chains have signal range -60 to -65.


I don't have omni antennas. Is there a problem that i am using dishes?



I run dozens of long-range devices, and I'm seeing 2 issues in your setup:

1)

- Ack-to issues kick in starting from roughly 1000m.  When you cannot 
alter ack_to (coverage class), you will notice severe performance issues 
above 1000m


2)

- Using identical polarization on all chains is an absolute performance 
killer.


I have 2 devices,  both 2x2 802.11n, HT40 SGI, which are only 150m 
apart, all chains V polarized.


When running speedtests, inspecting ath9k rate control shows it is stuck 
at the max speed for 1 chain (iso 2)


In my case it means the absolute link rate is 130Mbit iso 270 in this 
configuration.


I can imagine using 4 chains will even reduce performance a lot more.

You should really try to use use H + V+ (-45) + (+45).

Also, ensure radio's at both sides have the chains on identical 
polarization. (Chain0 - V,  Chain1 - H, ..)



Regards,

Koen



On Wed, Sep 25, 2019 at 5:11 PM +0200, "Ben Greear" 
mailto:gree...@candelatech.com>> wrote:


Is this short distance or long?

Please try short distance with omni antenna first to make sure you are not 
hitting the delayed-ack issue
or problems with your antenna.

Change your antenna orientation so that they point in different directions.

Thanks,
Ben

On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
> Hello,
> 
> Today i managed to connect the station wds at 80MHz channel. Signal is -56 and i have very low datarates. I have attached a photo.
> 
>   When station was ddwrt and AP openwrt the datarates were 866/433. TX won't do more than VHT-NSS 1 although RX it's not good either because it's a 4 chain 
> radio and it should do VHT-NSS4.
> 
> Thank you,

> Klevis
> 
> 
> 
> 
> On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" > wrote: > > Weeks or months or whenever I have time, and maybe

sooner if someone > wants to sponsor it. Please understand I, and
probably everyone else working > on OpenWRT, am busy with lots of
other projects and community work often > gets pushed to the back
burner. > > Thanks, > Ben > > On 9/23/19 8:18 AM,
supp...@maxnet.al wrote: > > Hi Ben, > > > > When do you think you
might be able to make those changes to your driver? > > > >
Thanks, > > Klevis. > > > > > > > > On 2019-09-20 13:00, Ben
Greear wrote: > >> On 9/20/19 12:55 PM, Vincent Wiemann wrote: >
>>> Hi Klevis, > >>> > >>> have you tried it with a short
distance? > >>> If you did you should better ask Ben Greear
directly. > >> > >> I asked him to post publicly so that others
can help answer and that > >> my own answers might > >> help
someone else. > >> > >> I have some patches that should enable
coverage class settings for > >> wave-2, but I am too busy > >>
with other things right now to port them to my ath10k-ct
driver/firmware. > >> > >> Thanks, > >> Ben > >> > >>> > >>> By
the way ath10k gen 2 chipsets don't work very well with long
distance links without a > >>> special feature which
implementation is only available to companies like Ubiquiti and
very few > >>> people who have an own reverse-engineered
implementation. > >>> It works on IPQ401X, QCA9886 and QCA9888
based chips only. > >>> > >>> And it is not possible to set a
coverage class for gen 2 devices, yet as far as I know due to
missing > >>> documentation and implementation (correct me if that
information is outdated). > >>> Furthermore a high channel width
often results in problems > >>> due to lower receiver sensibility.
> >>> We have better experiences with lower channel widths and
sometimes get more throughput with that. > >>> > >>> Actually I
think this does not explain your connection issues as 13 km is not
that much. > >>> > >>> Regards, > >>> > >>> Vincent Wiemann > >>>
> >>> On 20.09.19 18:30, supp...@maxnet.al wrote: >  Hello
everyone, >  >  I am trying to setup a custom made outdoor
link with Apu2d2 board devices and QCA9994 cards from compex.
After i installed openwrt and ath10k ct driver, >  kmod ath10k
and board-2.bin the device can run a 80MHz channel in WDS AP. The
problem is that it won't run as station or station wds. It can
scan >  the SSIDs but won't connect them. >  >  Any
suggestion? >  >  Thank you! >  Klevis >  > >>> >
>>> ___ > >>>
openwrt-devel mailing list > >>> openwrt-devel@lists.openwrt.org >
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > >>>
> > > > > -- > Ben GreearCandela Technologies Inc
http://www.candelatech.com > -- Ben Greear Candela Technologies
Inc

[OpenWrt-Devel] [PATCH luci] luci-mod-system: check for sysupgrade with backup possibility

2019-09-25 Thread Rafał Miłecki 
From: Rafał Miłecki 

Some firmware images may not support preserving backup. In such cases
display a warning and disable relevant checkbox.
---
 .../resources/view/system/flash.js| 23 +--
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git 
a/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js 
b/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
index 1349fecd4..544deb279 100644
--- a/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
+++ b/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
@@ -359,10 +359,11 @@ return L.view.extend({
.then(function(res) { reply.push(res); 
return reply; });
}, this, ev.target))
.then(L.bind(function(btn, res) {
-   var keep = 
document.querySelector('[data-name="keep"] input[type="checkbox"]'),
+   var keep = E('input', { type: 'checkbox' }),
force = E('input', { type: 'checkbox' }),
is_valid = res[1].valid,
is_forceable = res[1].forceable,
+   allow_backup = res[1].allow_backup,
is_too_big = (storage_size > 0 && 
res[0].size > storage_size),
body = [];
 
@@ -370,8 +371,7 @@ return L.view.extend({
body.push(E('ul', {}, [
res[0].size ? E('li', {}, '%s: 
%1024.2mB'.format(_('Size'), res[0].size)) : '',
res[0].checksum ? E('li', {}, '%s: 
%s'.format(_('MD5'), res[0].checksum)) : '',
-   res[0].sha256sum ? E('li', {}, '%s: 
%s'.format(_('SHA256'), res[0].sha256sum)) : '',
-   E('li', {}, keep.checked ? 
_('Configuration files will be kept') : _('Caution: Configuration files will be 
erased'))
+   res[0].sha256sum ? E('li', {}, '%s: 
%s'.format(_('SHA256'), res[0].sha256sum)) : ''
]));
 
if (!is_valid || is_too_big)
@@ -390,6 +390,18 @@ return L.view.extend({
_('The uploaded image file does 
not contain a supported format. Make sure that you choose the generic image 
format for your platform.')
]));
 
+   if (!allow_backup)
+   body.push(E('p', { 'class': 
'alert-message' }, [
+   _('The uploaded firmware does 
not allow keeping current configuration.')
+   ]));
+   if (allow_backup)
+   keep.checked = true;
+   else
+   keep.disabled = true;
+   body.push(E('p', {}, E('label', { 'class': 
'btn' }, [
+   keep, ' ', _('Keep settings and retain 
the current configuration')
+   ])));
+
if ((!is_valid || is_too_big) && is_forceable)
body.push(E('p', {}, E('label', { 
'class': 'btn alert-message danger' }, [
force, ' ', _('Force upgrade'),
@@ -537,15 +549,12 @@ return L.view.extend({
 
o = s.option(form.SectionValue, 'actions', form.NamedSection, 
'actions', 'actions', _('Flash new firmware image'),
has_sysupgrade
-   ? _('Upload a sysupgrade-compatible image here 
to replace the running firmware. Check "Keep settings" to retain the current 
configuration (requires a compatible firmware image).')
+   ? _('Upload a sysupgrade-compatible image here 
to replace the running firmware.')
: _('Sorry, there is no sysupgrade support 
present; a new firmware image must be flashed manually. Please refer to the 
wiki for device specific install instructions.'));
 
ss = o.subsection;
 
if (has_sysupgrade) {
-   o = ss.option(form.Flag, 'keep', _('Keep settings'));
-   o.default = o.enabled;
-
o = ss.option(form.Button, 'sysupgrade', _('Image'));
o.inputstyle = 'action important';
o.inputtitle = _('Flash image...');
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

2019-09-25 Thread Ben Greear 

On 9/25/19 8:14 AM, supp...@maxnet.al wrote:

This is long distance, 5km with 4 dishes on each side. They are all vertical 
and all chains have signal range -60 to -65.

I don't have omni antennas. Is there a problem that i am using dishes?


I have no idea, but at the very least, you should document your setup when
complaining of bad throughput or any other problem.  Compare good vs bad 
situations to see what
is the difference.

That way someone who has actually tried this sort of thing might be able to
offer suggestions.

Thanks,
Ben





On Wed, Sep 25, 2019 at 5:11 PM +0200, "Ben Greear" mailto:gree...@candelatech.com>> wrote:

Is this short distance or long?

Please try short distance with omni antenna first to make sure you are not 
hitting the delayed-ack issue
or problems with your antenna.

Change your antenna orientation so that they point in different directions.

Thanks,
Ben

On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
> Hello,
> 
> Today i managed to connect the station wds at 80MHz channel. Signal is -56 and i have very low datarates. I have attached a photo.
> 
>   When station was ddwrt and AP openwrt the datarates were 866/433. TX won't do more than VHT-NSS 1 although RX it's not good either because it's a 4 chain 
> radio and it should do VHT-NSS4.
> 
> Thank you,

> Klevis
> 
> 
> 
> 
> On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear"  > wrote: > > Weeks or months or whenever I have time, and maybe sooner if someone > wants to sponsor it. Please understand I, and probably everyone else

working > on OpenWRT, am busy with lots of other projects and community work often > gets 
pushed to the back burner. > > Thanks, > Ben > > On 9/23/19 8:18
AM, supp...@maxnet.al wrote: > > Hi Ben, > > > > When do you think you might be able to make those 
changes to your driver? > > > > Thanks, > > Klevis. > > >
 > > > > > On 2019-09-20 13:00, Ben Greear wrote: > >> On 9/20/19 12:55 PM, Vincent Wiemann wrote: > 
>>> Hi Klevis, > >>> > >>> have you tried it with a
short distance? > >>> If you did you should better ask Ben Greear directly. > >> > 
>> I asked him to post publicly so that others can help answer and that >
 >> my own answers might > >> help someone else. > >> > >> I have some patches that 
should enable coverage class settings for > >> wave-2, but I am too busy
 > >> with other things right now to port them to my ath10k-ct driver/firmware. > >> > >> Thanks, > >> Ben 
> >> > >>> > >>> By the way ath10k gen 2 chipsets
don't work very well with long distance links without a > >>> special 
feature which implementation is only available to companies like Ubiquiti and very few
 > >>> people who have an own reverse-engineered implementation. > >>> It works on IPQ401X, QCA9886 
and QCA9888 based chips only. > >>> > >>> And it is not
possible to set a coverage class for gen 2 devices, yet as far as I know due to missing 
> >>> documentation and implementation (correct me if that
information is outdated). > >>> Furthermore a high channel width often results in problems > 
>>> due to lower receiver sensibility. > >>> We have better
experiences with lower channel widths and sometimes get more throughput with that. > 
>>> > >>> Actually I think this does not explain your connection issues
as 13 km is not that much. > >>> > >>> Regards, > >>> > >>> Vincent Wiemann > >>> > >>> On 
20.09.19 18:30, supp...@maxnet.al wrote: >  Hello everyone, >
  >  I am trying to setup a custom made outdoor link with Apu2d2 
board devices and QCA9994 cards from compex. After i installed openwrt and ath10k
ct driver, >  kmod ath10k and board-2.bin the device can run a 80MHz 
channel in WDS AP. The problem is that it won't run as station or station wds. It
can scan >  the SSIDs but won't connect them. >  >  Any suggestion? >  >  Thank you! >  
Klevis >  > >>> > >>>
___ > >>> openwrt-devel mailing list > >>> 
openwrt-devel@lists.openwrt.org > >>>
https://lists.openwrt.org/mailman/listinfo/openwrt-devel > >>> > > > > > -- > 
Ben GreearCandela Technologies Inc http://www.candelatech.com > -- Ben Greear
Candela Technologies Inc http://www.candelatech.com




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq806x: remove unsupported hw-crypto qce driver

2019-09-25 Thread Eneas U de Queiroz 
The following symbols, selected by the qce driver were removed:
CONFIG_CRYPTO_CBC
CONFIG_CRYPTO_CTR
CONFIG_CRYPTO_DES
CONFIG_CRYPTO_DEV_QCE
CONFIG_CRYPTO_ECB
CONFIG_CRYPTO_NULL
CONFIG_CRYPTO_SEQIV
CONFIG_CRYPTO_XTS

CONFIG_CRYPTO_GF128MUL was removed as well, since it is only needed by
some cipher modes (LRW, GCM), none of which are selected, and it is
packaged as a module.

Signed-off-by: Eneas U de Queiroz 

--

> The upstream qce crypto driver does not support the IPQ806x series.
> The ipq806x target used to host ipq40xx, so this driver was enabled as
> builtin back then.
> But since ipq40xx moved out, it's has become a symbol of "hope"
> That maybe some day
> the NSS support of the IPQ806x can make use of it
>
> So yeah, if you want to crush the hopes and dreams of the IPQ806X users,
> you can disable/remove the driver for the ipq806x target.
>
> Regards,
> Christian

My intention is not to "crush the hopes", but to avoid the frustration
when you find out something you thought was there not exist.

I did not remove CONFIG_CRYPTO_AEAD because it is already selected by
CONFIG_CRYPTO_PCRYPT=y in target/linux/generic/config-4.*, although I'm
not sure if I should not have dropped it anyway--it won't fail if I do.

Here is a dependency tree, showing only the removed symbols:

-CRYPTO_DEV_QCE
 \-CRYPTO_DES
 \-CRYPTO_ECB
 \-CRYPTO_CBC
 \-CRYPTO_XTS
 \-CRYPTO_CTR
   \-CRYPTO_SEQIV
 \-CRYPTO_AEAD*
 \-CRYPTO_NULL

Eneas

diff --git a/target/linux/ipq806x/config-4.14 b/target/linux/ipq806x/config-4.14
index 30736ae14e..38f5c94507 100644
--- a/target/linux/ipq806x/config-4.14
+++ b/target/linux/ipq806x/config-4.14
@@ -112,16 +112,10 @@ CONFIG_CRC16=y
 CONFIG_CRC32_SLICEBY8=y
 CONFIG_CRYPTO_AEAD=y
 CONFIG_CRYPTO_AEAD2=y
-CONFIG_CRYPTO_CBC=y
-CONFIG_CRYPTO_CTR=y
 CONFIG_CRYPTO_DEFLATE=y
-CONFIG_CRYPTO_DES=y
-CONFIG_CRYPTO_DEV_QCE=y
 CONFIG_CRYPTO_DRBG=y
 CONFIG_CRYPTO_DRBG_HMAC=y
 CONFIG_CRYPTO_DRBG_MENU=y
-CONFIG_CRYPTO_ECB=y
-CONFIG_CRYPTO_GF128MUL=y
 CONFIG_CRYPTO_HASH=y
 CONFIG_CRYPTO_HASH2=y
 CONFIG_CRYPTO_HMAC=y
@@ -130,15 +124,12 @@ CONFIG_CRYPTO_JITTERENTROPY=y
 CONFIG_CRYPTO_LZO=y
 CONFIG_CRYPTO_MANAGER=y
 CONFIG_CRYPTO_MANAGER2=y
-CONFIG_CRYPTO_NULL=y
 CONFIG_CRYPTO_NULL2=y
 CONFIG_CRYPTO_RNG=y
 CONFIG_CRYPTO_RNG2=y
 CONFIG_CRYPTO_RNG_DEFAULT=y
-CONFIG_CRYPTO_SEQIV=y
 CONFIG_CRYPTO_SHA256=y
 CONFIG_CRYPTO_WORKQUEUE=y
-CONFIG_CRYPTO_XTS=y
 CONFIG_DCACHE_WORD_ACCESS=y
 CONFIG_DEBUG_GPIO=y
 # CONFIG_DEBUG_UART_8250 is not set

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

2019-09-25 Thread support 
This is long distance, 5km with 4 dishes on each side. They are all vertical 
and all chains have signal range -60 to -65. 




I don't have omni antennas. Is there a problem that i am using dishes? 




On Wed, Sep 25, 2019 at 5:11 PM +0200, "Ben Greear"  
wrote:










Is this short distance or long?

Please try short distance with omni antenna first to make sure you are not 
hitting the delayed-ack issue
or problems with your antenna.

Change your antenna orientation so that they point in different directions.

Thanks,
Ben

On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
> Hello,
> 
> Today i managed to connect the station wds at 80MHz channel. Signal is -56 
> and i have very low datarates. I have attached a photo.
> 
>   When station was ddwrt and AP openwrt the datarates were 866/433. TX won't 
> do more than VHT-NSS 1 although RX it's not good either because it's a 4 
> chain 
> radio and it should do VHT-NSS4.
> 
> Thank you,
> Klevis
> 
> 
> 
> 
> On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" > wrote:
> 
> Weeks or months or whenever I have time, and maybe sooner if someone
> wants to sponsor it.  Please understand I, and probably everyone else 
> working
> on OpenWRT, am busy with lots of other projects and community work often
> gets pushed to the back burner.
> 
> Thanks,
> Ben
> 
> On 9/23/19 8:18 AM, supp...@maxnet.al wrote:
> > Hi Ben,
> > 
> > When do you think you might be able to make those changes to your 
> driver?
> > 
> > Thanks,
> > Klevis.
> > 
> > 
> > 
> > On 2019-09-20 13:00, Ben Greear wrote:
> >> On 9/20/19 12:55 PM, Vincent Wiemann wrote:
> >>> Hi Klevis,
> >>>
> >>> have you tried it with a short distance?
> >>> If you did you should better ask Ben Greear directly.
> >>
> >> I asked him to post publicly so that others can help answer and that
> >> my own answers might
> >> help someone else.
> >>
> >> I have some patches that should enable coverage class settings for
> >> wave-2, but I am too busy
> >> with other things right now to port them to my ath10k-ct 
> driver/firmware.
> >>
> >> Thanks,
> >> Ben
> >>
> >>>
> >>> By the way ath10k gen 2 chipsets don't work very well with long 
> distance links without a
> >>> special feature which implementation is only available to companies 
> like Ubiquiti and very few
> >>> people who have an own reverse-engineered implementation.
> >>> It works on IPQ401X, QCA9886 and QCA9888 based chips only.
> >>>
> >>> And it is not possible to set a coverage class for gen 2 devices, yet 
> as far as I know due to missing
> >>> documentation and implementation (correct me if that information is 
> outdated).
> >>> Furthermore a high channel width often results in problems
> >>> due to lower receiver sensibility.
> >>> We have better experiences with lower channel widths and sometimes 
> get more throughput with that.
> >>>
> >>> Actually I think this does not explain your connection issues as 13 
> km is not that much.
> >>>
> >>> Regards,
> >>>
> >>> Vincent Wiemann
> >>>
> >>> On 20.09.19 18:30, supp...@maxnet.al wrote:
>  Hello everyone,
> 
>  I am trying to setup a custom made outdoor link with Apu2d2 board 
> devices and QCA9994 cards from compex. After i installed openwrt and ath10k 
> ct driver, 
>  kmod ath10k and board-2.bin the device can run a 80MHz channel in 
> WDS AP. The problem is that it won't run as station or station wds. It can 
> scan
>  the SSIDs but won't connect them.
> 
>  Any suggestion?
> 
>  Thank you!
>  Klevis
> 
> >>>
> >>> ___
> >>> openwrt-devel mailing list
> >>> openwrt-devel@lists.openwrt.org
> >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >>>
> > 
> 
> 
> -- 
> Ben GreearCandela Technologies Inc http://www.candelatech.com
> 


-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com






___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

2019-09-25 Thread Ben Greear 

Is this short distance or long?

Please try short distance with omni antenna first to make sure you are not 
hitting the delayed-ack issue
or problems with your antenna.

Change your antenna orientation so that they point in different directions.

Thanks,
Ben

On 9/25/19 6:49 AM, supp...@maxnet.al wrote:

Hello,

Today i managed to connect the station wds at 80MHz channel. Signal is -56 and 
i have very low datarates. I have attached a photo.

  When station was ddwrt and AP openwrt the datarates were 866/433. TX won't do more than VHT-NSS 1 although RX it's not good either because it's a 4 chain 
radio and it should do VHT-NSS4.


Thank you,
Klevis




On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" mailto:gree...@candelatech.com>> wrote:

Weeks or months or whenever I have time, and maybe sooner if someone
wants to sponsor it.  Please understand I, and probably everyone else 
working
on OpenWRT, am busy with lots of other projects and community work often
gets pushed to the back burner.

Thanks,
Ben

On 9/23/19 8:18 AM, supp...@maxnet.al wrote:
> Hi Ben,
> 
> When do you think you might be able to make those changes to your driver?
> 
> Thanks,

> Klevis.
> 
> 
> 
> On 2019-09-20 13:00, Ben Greear wrote:

>> On 9/20/19 12:55 PM, Vincent Wiemann wrote:
>>> Hi Klevis,
>>>
>>> have you tried it with a short distance?
>>> If you did you should better ask Ben Greear directly.
>>
>> I asked him to post publicly so that others can help answer and that
>> my own answers might
>> help someone else.
>>
>> I have some patches that should enable coverage class settings for
>> wave-2, but I am too busy
>> with other things right now to port them to my ath10k-ct driver/firmware.
>>
>> Thanks,
>> Ben
>>
>>>
>>> By the way ath10k gen 2 chipsets don't work very well with long 
distance links without a
>>> special feature which implementation is only available to companies 
like Ubiquiti and very few
>>> people who have an own reverse-engineered implementation.
>>> It works on IPQ401X, QCA9886 and QCA9888 based chips only.
>>>
>>> And it is not possible to set a coverage class for gen 2 devices, yet 
as far as I know due to missing
>>> documentation and implementation (correct me if that information is 
outdated).
>>> Furthermore a high channel width often results in problems
>>> due to lower receiver sensibility.
>>> We have better experiences with lower channel widths and sometimes get 
more throughput with that.
>>>
>>> Actually I think this does not explain your connection issues as 13 km 
is not that much.
>>>
>>> Regards,
>>>
>>> Vincent Wiemann
>>>
>>> On 20.09.19 18:30, supp...@maxnet.al wrote:
 Hello everyone,

 I am trying to setup a custom made outdoor link with Apu2d2 board devices and QCA9994 cards from compex. After i installed openwrt and ath10k ct driver, 
 kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. The problem is that it won't run as station or station wds. It can scan

 the SSIDs but won't connect them.

 Any suggestion?

 Thank you!
 Klevis

>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
> 



-- 
Ben GreearCandela Technologies Inc http://www.candelatech.com





--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH luci 2/2] luci-mod-system: check if it's possible to force sysupgrade

2019-09-25 Thread Rafał Miłecki 
From: Rafał Miłecki 

Some validation errors may be critical enough to prevent sysupgrade.
Check the "forceable" property and disallow forcing sysupgrade if
applicable. It would fail anyway at the "sysupgrade" call.

Signed-off-by: Rafał Miłecki 
---
 .../htdocs/luci-static/resources/view/system/flash.js  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js 
b/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
index 784ec135b..1349fecd4 100644
--- a/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
+++ b/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
@@ -362,6 +362,7 @@ return L.view.extend({
var keep = 
document.querySelector('[data-name="keep"] input[type="checkbox"]'),
force = E('input', { type: 'checkbox' }),
is_valid = res[1].valid,
+   is_forceable = res[1].forceable,
is_too_big = (storage_size > 0 && 
res[0].size > storage_size),
body = [];
 
@@ -389,7 +390,7 @@ return L.view.extend({
_('The uploaded image file does 
not contain a supported format. Make sure that you choose the generic image 
format for your platform.')
]));
 
-   if (!is_valid || is_too_big)
+   if ((!is_valid || is_too_big) && is_forceable)
body.push(E('p', {}, E('label', { 
'class': 'btn alert-message danger' }, [
force, ' ', _('Force upgrade'),
E('br'), E('br'),
-- 
2.21.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH luci 1/2] luci-mod-system: use "system" new "validate_firmware_image" ubus method

2019-09-25 Thread Rafał Miłecki 
From: Rafał Miłecki 

This new ubus method provides more properly-formatted details about
firmware file. Use it to check if uploaded image is valid.

The old "sysupgrade --test" method is left for now to provide stderr
output.

Signed-off-by: Rafał Miłecki 
---
 .../resources/view/system/flash.js| 30 ---
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git 
a/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js 
b/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
index 9ad64dad4..784ec135b 100644
--- a/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
+++ b/modules/luci-mod-system/htdocs/luci-static/resources/view/system/flash.js
@@ -2,7 +2,7 @@
 'require form';
 'require rpc';
 
-var callFileStat, callFileRead, callFileWrite, callFileExec, callFileRemove;
+var callFileStat, callFileRead, callFileWrite, callFileExec, callFileRemove, 
callSystemValidateFirmwareImage;
 
 callFileStat = rpc.declare({
object: 'file',
@@ -38,6 +38,12 @@ callFileRemove = rpc.declare({
params: [ 'path' ]
 });
 
+callSystemValidateFirmwareImage = rpc.declare({
+   object: 'system',
+   method: 'validate_firmware_image',
+   params: [ 'path' ]
+});
+
 function pingDevice(proto, ipaddr) {
var target = '%s://%s%s?%s'.format(proto || 'http', ipaddr || 
window.location.host, L.resource('icons/loading.gif'), Math.random());
 
@@ -345,13 +351,17 @@ return L.view.extend({
E('span', { 'class': 'spinning' }, 
_('Verifying the uploaded image file.'))
]);
 
+   return 
callSystemValidateFirmwareImage('/tmp/firmware.bin')
+   .then(function(res) { return [ reply, 
res ]; });
+   }, this, ev.target))
+   .then(L.bind(function(btn, reply) {
return callFileExec('/sbin/sysupgrade', [ 
'--test', '/tmp/firmware.bin' ])
-   .then(function(res) { return [ reply, 
res ] });
+   .then(function(res) { reply.push(res); 
return reply; });
}, this, ev.target))
.then(L.bind(function(btn, res) {
var keep = 
document.querySelector('[data-name="keep"] input[type="checkbox"]'),
force = E('input', { type: 'checkbox' }),
-   is_invalid = (res[1].code != 0),
+   is_valid = res[1].valid,
is_too_big = (storage_size > 0 && 
res[0].size > storage_size),
body = [];
 
@@ -363,7 +373,7 @@ return L.view.extend({
E('li', {}, keep.checked ? 
_('Configuration files will be kept') : _('Caution: Configuration files will be 
erased'))
]));
 
-   if (is_invalid || is_too_big)
+   if (!is_valid || is_too_big)
body.push(E('hr'));
 
if (is_too_big)
@@ -371,15 +381,15 @@ return L.view.extend({
_('It appears that you are 
trying to flash an image that does not fit into the flash memory, please verify 
the image file!')
]));
 
-   if (is_invalid)
+   if (!is_valid)
body.push(E('p', { 'class': 
'alert-message' }, [
-   res[1].stderr ? res[1].stderr : 
'',
-   res[1].stderr ? E('br') : '',
-   res[1].stderr ? E('br') : '',
+   res[2].stderr ? res[2].stderr : 
'',
+   res[2].stderr ? E('br') : '',
+   res[2].stderr ? E('br') : '',
_('The uploaded image file does 
not contain a supported format. Make sure that you choose the generic image 
format for your platform.')
]));
 
-   if (is_invalid || is_too_big)
+   if (!is_valid || is_too_big)
body.push(E('p', {}, E('label', { 
'class': 'btn alert-message danger' }, [
force, ' ', _('Force upgrade'),
E('br'), E('br'),
@@ -389,7 +399,7 @@ return L.view.extend({
var cntbtn = E('button', {
'class': 'btn

[OpenWrt-Devel] [PATCH 3/3] kernel: trelay: log "started" and "stopped"

2019-09-25 Thread Ali MJ Al-Nasrawy 
It is informative especially when using multiple device pairs.

Signed-off-by: Ali MJ Al-Nasrawy 
---
 package/kernel/trelay/src/trelay.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/package/kernel/trelay/src/trelay.c 
b/package/kernel/trelay/src/trelay.c
index 0e3d85bfef..4c1cf706d7 100644
--- a/package/kernel/trelay/src/trelay.c
+++ b/package/kernel/trelay/src/trelay.c
@@ -20,6 +20,10 @@
 #include 
 #include 
 
+#define trelay_log(loglevel, tr, fmt, ...) \
+   printk(loglevel "trelay: %s <-> %s: " fmt "\n", \
+   tr->dev1->name, tr->dev2->name, ##__VA_ARGS__);
+
 static LIST_HEAD(trelay_devs);
 static struct dentry *debugfs_dir;
 
@@ -71,6 +75,8 @@ static int trelay_do_remove(struct trelay *tr)
netdev_rx_handler_unregister(tr->dev1);
netdev_rx_handler_unregister(tr->dev2);
 
+   trelay_log(KERN_INFO, tr, "stopped");
+
kfree(tr);
 
return 0;
@@ -183,6 +189,8 @@ static int trelay_do_add(char *name, char *devn1, char 
*devn2)
tr->dev2 = dev2;
list_add_tail(>list, _devs);
 
+   trelay_log(KERN_INFO, tr, "started");
+
tr->debugfs = debugfs_create_dir(name, debugfs_dir);
debugfs_create_file("remove", S_IWUSR, tr->debugfs, tr, _remove);
ret = 0;
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/3] kernel: trelay: fix deadlock on remove

2019-09-25 Thread Ali MJ Al-Nasrawy 
Upon writing to "remove" file, debugfs_remove_recursive() blocks while
holding rtnl_lock. This is because debugfs' file_ops callbacks are
executed in debugfs_use_file_*() context which prevents file removal.

Fix this by only flagging the device for removal and then do the cleanup
in file_ops.release callback which is executed out of that context.

Signed-off-by: Ali MJ Al-Nasrawy 
---
 package/kernel/trelay/src/trelay.c | 32 +-
 1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/package/kernel/trelay/src/trelay.c 
b/package/kernel/trelay/src/trelay.c
index 6d9d9cc14b..0e3d85bfef 100644
--- a/package/kernel/trelay/src/trelay.c
+++ b/package/kernel/trelay/src/trelay.c
@@ -27,6 +27,7 @@ struct trelay {
struct list_head list;
struct net_device *dev1, *dev2;
struct dentry *debugfs;
+   int to_remove;
char name[];
 };
 
@@ -60,13 +61,16 @@ static int trelay_do_remove(struct trelay *tr)
 {
list_del(>list);
 
+   /* First and before all, ensure that the debugfs file is removed
+* to prevent dangling pointer in file->private_data */
+   debugfs_remove_recursive(tr->debugfs);
+
dev_put(tr->dev1);
dev_put(tr->dev2);
 
netdev_rx_handler_unregister(tr->dev1);
netdev_rx_handler_unregister(tr->dev2);
 
-   debugfs_remove_recursive(tr->debugfs);
kfree(tr);
 
return 0;
@@ -106,23 +110,33 @@ static ssize_t trelay_remove_write(struct file *file, 
const char __user *ubuf,
   size_t count, loff_t *ppos)
 {
struct trelay *tr = file->private_data;
-   int ret;
-
-   rtnl_lock();
-   ret = trelay_do_remove(tr);
-   rtnl_unlock();
-
-   if (ret < 0)
-return ret;
+   tr->to_remove = 1;
 
return count;
 }
 
+static int trelay_remove_release(struct inode *inode, struct file *file)
+{
+   struct trelay *tr, *tmp;
+
+   /* This is the only file op that is called outside debugfs_use_file_*()
+* context which means that: (1) this file can be removed and
+* (2) file->private_data may no longer be valid */
+   rtnl_lock();
+   list_for_each_entry_safe(tr, tmp, _devs, list)
+   if (tr->to_remove)
+   trelay_do_remove(tr);
+   rtnl_unlock();
+
+   return 0;
+}
+
 static const struct file_operations fops_remove = {
.owner = THIS_MODULE,
.open = trelay_open,
.write = trelay_remove_write,
.llseek = default_llseek,
+   .release = trelay_remove_release,
 };
 
 
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 1/3] kernel: trelay: handle netdevice events correctly

2019-09-25 Thread Ali MJ Al-Nasrawy 
Since v3.11, netdevice notification data are of type
"struct netdev_notifier_info". Handle it as such!

This should fix a critical bug in which devices are unable get released
because trelay does not release resources in response to UNREGISTER
event spamming the log with something like:

unregister_netdevice: waiting for eth0.1 to become free. Usage count = 1

Signed-off-by: Ali MJ Al-Nasrawy 
---
 package/kernel/trelay/src/trelay.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/kernel/trelay/src/trelay.c 
b/package/kernel/trelay/src/trelay.c
index 581a5cfd2f..6d9d9cc14b 100644
--- a/package/kernel/trelay/src/trelay.c
+++ b/package/kernel/trelay/src/trelay.c
@@ -86,7 +86,7 @@ static struct trelay *trelay_find(struct net_device *dev)
 static int tr_device_event(struct notifier_block *unused, unsigned long event,
   void *ptr)
 {
-   struct net_device *dev = ptr;
+   struct net_device *dev = ((struct netdev_notifier_info *)ptr)->dev;
struct trelay *tr;
 
if (event != NETDEV_UNREGISTER)
-- 
2.23.0


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

2019-09-25 Thread support 
Hello,
Today i managed to connect the station wds at 80MHz channel. Signal is -56 and 
i have very low datarates. I have attached a photo.
 When station was ddwrt and AP openwrt the datarates were 866/433. TX won't do 
more than VHT-NSS 1 although RX it's not good either because it's a 4 chain 
radio and it should do VHT-NSS4.
Thank you,Klevis




On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear"  
wrote:










Weeks or months or whenever I have time, and maybe sooner if someone
wants to sponsor it.  Please understand I, and probably everyone else working
on OpenWRT, am busy with lots of other projects and community work often
gets pushed to the back burner.

Thanks,
Ben

On 9/23/19 8:18 AM, supp...@maxnet.al wrote:
> Hi Ben,
> 
> When do you think you might be able to make those changes to your driver?
> 
> Thanks,
> Klevis.
> 
> 
> 
> On 2019-09-20 13:00, Ben Greear wrote:
>> On 9/20/19 12:55 PM, Vincent Wiemann wrote:
>>> Hi Klevis,
>>>
>>> have you tried it with a short distance?
>>> If you did you should better ask Ben Greear directly.
>>
>> I asked him to post publicly so that others can help answer and that
>> my own answers might
>> help someone else.
>>
>> I have some patches that should enable coverage class settings for
>> wave-2, but I am too busy
>> with other things right now to port them to my ath10k-ct driver/firmware.
>>
>> Thanks,
>> Ben
>>
>>>
>>> By the way ath10k gen 2 chipsets don't work very well with long distance 
>>> links without a
>>> special feature which implementation is only available to companies like 
>>> Ubiquiti and very few
>>> people who have an own reverse-engineered implementation.
>>> It works on IPQ401X, QCA9886 and QCA9888 based chips only.
>>>
>>> And it is not possible to set a coverage class for gen 2 devices, yet as 
>>> far as I know due to missing
>>> documentation and implementation (correct me if that information is 
>>> outdated).
>>> Furthermore a high channel width often results in problems
>>> due to lower receiver sensibility.
>>> We have better experiences with lower channel widths and sometimes get more 
>>> throughput with that.
>>>
>>> Actually I think this does not explain your connection issues as 13 km is 
>>> not that much.
>>>
>>> Regards,
>>>
>>> Vincent Wiemann
>>>
>>> On 20.09.19 18:30, supp...@maxnet.al wrote:
 Hello everyone,

 I am trying to setup a custom made outdoor link with Apu2d2 board devices 
 and QCA9994 cards from compex. After i installed openwrt and ath10k ct 
 driver, 
 kmod ath10k and board-2.bin the device can run a 80MHz channel in WDS AP. 
 The problem is that it won't run as station or station wds. It can scan
 the SSIDs but won't connect them.

 Any suggestion?

 Thank you!
 Klevis

>>>
>>> ___
>>> openwrt-devel mailing list
>>> openwrt-devel@lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>>
> 


-- 
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com






___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [sdwalker/sdwalker.github.io] 4b1ac0: This week's update

2019-09-25 Thread Jan Pavlinec 
It would be nice to have watch file for mariadb and domoticz ?

Little off-topic question, is there any plan to create uscan page for
19.07 ?

J.P.

Dne 19. 09. 19 v 2:32 Stephen Walker napsal(a):
> No, they've always just been sitting in a local source tree. Do you
> have any specific packages in mind? I just created watch files for the
> measurement-kit, python-cachetools, python-cryptodomex,
> python-pyrsistent, tessdata and tesseract packages.
>
> On Wed, Sep 18, 2019 at 7:31 AM Jan Pavlinec  > wrote:
>
> Hi,
>
> is there any source of watch files for uscan where I can push missing
> package watch files?
>
> J.P.
>
> Dne 16. 09. 19 v 0:03 Stephen Walker napsal(a):
> >   Branch: refs/heads/master
> >   Home:   https://github.com/sdwalker/sdwalker.github.io
> >   Commit: 4b1ac0e52c1d0f0bac5b464e6a01d2bda1b97102
> >     
>  
> https://github.com/sdwalker/sdwalker.github.io/commit/4b1ac0e52c1d0f0bac5b464e6a01d2bda1b97102
> >   Author: Stephen Walker  >
> >   Date:   2019-09-15 (Sun, 15 Sep 2019)
> >
> >   Changed paths:
> >     M uscan/index-18.06.html
> >     M uscan/index.html
> >
> >   Log Message:
> >   ---
> >   This week's update
> >
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> 
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: harmonize device vendor Zbtlink

2019-09-25 Thread Adrian Schmutzler 
Spelling of Zbtlink varies across image definitions and DTS files.

This patch uses Zbtlink consistently and also updates the model
in DTS files to contain the vendor in all cases.

This patch is cosmetical, as there should be no dependencies on
device model name in ramips anymore.

Signed-off-by: Adrian Schmutzler 
---
 .../linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts |  2 +-
 .../linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts  |  2 +-
 .../linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts |  2 +-
 .../linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts |  2 +-
 .../linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts   |  2 +-
 target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts  |  2 +-
 target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts  |  2 +-
 target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts  |  2 +-
 .../linux/ramips/dts/mt7621_zbtlink_zbt-wg3526-16m.dts |  2 +-
 .../linux/ramips/dts/mt7621_zbtlink_zbt-wg3526-32m.dts |  2 +-
 target/linux/ramips/image/mt7621.mk| 10 +-
 target/linux/ramips/image/mt76x8.mk|  2 +-
 12 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
index e2eb5b6329..a05e8d4b47 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
@@ -37,7 +37,7 @@
 
 / {
compatible = "zbtlink,we1026-5g-16m", "ralink,mt7620a-soc";
-   model = "ZBT WE1026-5G (16M)";
+   model = "Zbtlink ZBT-WE1026-5G (16M)";
 };
 
  {
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts
index 70ad0f0b58..665dd5ba3c 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-ape522ii.dts
@@ -7,7 +7,7 @@
 
 / {
compatible = "zbtlink,zbt-ape522ii", "ralink,mt7620a-soc";
-   model = "ZBT-APE522II";
+   model = "Zbtlink ZBT-APE522II";
 
chosen {
bootargs = "console=ttyS0,115200";
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts
index 7f2b2646b2..d115b8a096 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-16m.dts
@@ -4,7 +4,7 @@
 
 / {
compatible = "zbtlink,zbt-we826-16m", "zbtlink,zbt-we826", 
"ralink,mt7620a-soc";
-   model = "ZBT-WE826 (16M)";
+   model = "Zbtlink ZBT-WE826 (16M)";
 };
 
  {
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
index e7cdcab5e9..94a67dd5de 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-32m.dts
@@ -4,7 +4,7 @@
 
 / {
compatible = "zbtlink,zbt-we826-32m", "zbtlink,zbt-we826", 
"ralink,mt7620a-soc";
-   model = "ZBT-WE826 (32M)";
+   model = "Zbtlink ZBT-WE826 (32M)";
 };
 
  {
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
index 243126125b..2496a16a29 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we826-e.dts
@@ -5,7 +5,7 @@
 
 / {
compatible = "zbtlink,zbt-we826-e", "zbtlink,zbt-we826", 
"ralink,mt7620a-soc";
-   model = "ZBT-WE826-E";
+   model = "Zbtlink ZBT-WE826-E";
 
/delete-node/ leds;
 
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts 
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts
index 819c851c73..d7c48c6d9f 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we1326.dts
@@ -7,7 +7,7 @@
 
 / {
compatible = "zbtlink,zbt-we1326", "mediatek,mt7621-soc";
-   model = "ZBT-WE1326";
+   model = "Zbtlink ZBT-WE1326";
 
aliases {
label-mac-device = 
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts 
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts
index 7973626fad..b1d3e4e812 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-we3526.dts
@@ -7,7 +7,7 @@
 
 / {
compatible = "zbtlink,zbt-we3526", "mediatek,mt7621-soc";
-   model = "ZBT-WE3526";
+   model = "Zbtlink ZBT-WE3526";
 
chosen {
bootargs = "console=ttyS0,115200";
diff --git a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts 
b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts
index ca2044f73e..1a2a89a31e 100644
--- a/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts
+++ b/target/linux/ramips/dts/mt7621_zbtlink_zbt-wg2626.dts
@@ -7,7 +7,7 @@
 
 / {
compatible =