Re: [OpenWrt-Devel] [PATCH] ath79: add support for Enterasys WS-AP3705i

2020-05-20 Thread mail 
Hi David,

> + label-mac-device = 

this only works if you set mtd-mac-address in DTS.

In your case, you need to add

label_mac=$(mtd_get_mac_ascii u-boot-env0 ethaddr)

to the mac address section of 02_network.

Despite, is there a need for the DT labels flash0, flash1 and ath9k? If no, I'd 
drop them.

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] fstools: fix mount_root overlay comments

2020-05-20 Thread sean-m-miller 
Sysupgrades that preserve volatile files ('sysupgrade -c ...') replace
the 0xDEADCODE marker at the rootfs/rootfs_data boundary with the tar
bundle of preserved files. The 0xDEADCODE marker is moved to the start
of the next erase block.

Upon the subsequent first boot, the mount_root utility reads a valid
jffs2 file in the first block of rootfs_data, concludes that the
partition has already been formatted, and summons the jffs2 driver.
The jffs2 driver finds the 0xDEADCODE marker after the tar file
and assumes that now is a safe time to format the rootfs_data
partition and launch the jffs2 overlay.

This is a bug, since preinit_main hangs while the jffs2 driver
formats the partition, which can cause fatal soft lockups on systems
with weak cpu and large rootfs_data partitions. The intended behavior
for a first boot is to have mount_root kick off an intermediate tmpfs
overlay, deferring the jffs2 switch until the /etc/init.d/done call.

Patching this bug would lead to the preserved files being lost
during upgrades or downgrades to or from the fixed build, so it is
probably best to leave it as is. Fortunately, the preinit_main hang
is survivable on most current systems. This bug should be described in
comments for the sake of maintaining accurate descriptions of the system.

Signed-off-by: Sean Miller 
---
 .../patches/010-mount_root-overlay-bug.patch | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
package/system/fstools/patches/010-mount_root-overlay-bug.patch

diff --git a/package/system/fstools/patches/010-mount_root-overlay-bug.patch 
b/package/system/fstools/patches/010-mount_root-overlay-bug.patch
new file mode 100644
index 00..c2d72e3d9b
--- /dev/null
+++ b/package/system/fstools/patches/010-mount_root-overlay-bug.patch
@@ -0,0 +1,16 @@
+--- a/mount_root.c
 b/mount_root.c
+@@ -75,6 +75,13 @@ start(int argc, char *argv[1])
+   case FS_F2FS:
+   case FS_JFFS2:
+   case FS_UBIFS:
++  /*
++   * Filesystem is in a valid state so we can go ahead and mount
++   * the target overlay, or this is the first boot after an 
upgrade
++   * that preserved files, so we hang preinit_main while we format
++   * the partition (oops... this is undesired) and then launch the
++   * target overlay (skip the intermediate tmpfs step).
++   */
+   mount_overlay(data);
+   break;
+ 
-- 
2.20.1 (Apple Git-117)


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

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-20 Thread Vincent Wiemann 
Hi Sebastian,

On 20.05.20 15:00, Sebastian Gottschall wrote:
> 
> Am 20.05.2020 um 12:40 schrieb Vincent Wiemann:
>> Hi Sebastian,
>>
>> I don't know why it was dropped, but I can say that the LED control code was 
>> kind of
>> annoying me. Even when the LED was turned of, it "flickered" when it was set 
>> disabled.
>> Unfortunately I didn't have time to look into it, yet.

> the led code will just be used if you set a trigger. otherwise it doesnt 
> touch the gpios.
> the code itself was written to make use of the led's builtin to several 
> routers. if you dont set a led trigger, nothing will happen
> 

Thank you for your quick response... I'll try to reproduce the issue without 
your patch.
Maybe it's unrelated and a firmware-specific issue (official QCA9887).

One thing I've seen with your patch is that if I set the ath10k GPIO "steady 
on" it sometimes
(quite randomly) turns it off for a fraction of a second. It happens about 3 
times a minute.
It's not a big deal. But maybe it's related to the flickering
I've observed and possibly also a firmware issue...

Best,

Vincent


>> Best,
>>
>> Vincent
>>
>> On 20.05.20 09:39, Sebastian Gottschall wrote:
>>> this code is not in use in its original form for ipq4019.
>>> i have seen that his patch is also dropped from ath.git but is still in use 
>>> by openwrt.
>>> could somone clarify the state here and why it was dropped?
>>> the original patch i wrote does exclude the soc chipsets, but the patch was 
>>> later reorganized and some part have been rewritten
>>> so i'm not sure if it covers the scenario mentioned here, which i did take 
>>> care of
>>>
>>> Sebastian
>>>
>>> Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
 On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
> From: Sebastian Gottschall 
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
> chipsets with on chipset connected led's using WMI Firmware API.  The LED
> device will get available named as "ath10k-phyX" at sysfs and can be 
> controlled
> with various triggers.  adds also debugfs interface for gpio control.
>
> Signed-off-by: Sebastian Gottschall 
> Reviewed-by: Steve deRosier 
> [kvalo: major reorg and cleanup]
> Signed-off-by: Kalle Valo 
 This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: 
 ath10k
 add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
 firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:

   [  221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout, 
 restarting hardware
   [  221.744056] ieee80211 phy0: Hardware restart was requested
   [  225.130829] ath10k_pci :01:00.0: failed to receive control 
 response completion, polling..
   [  226.170824] ath10k_pci :01:00.0: Service connect timeout
   [  226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
   [  226.252248] ath10k_pci :01:00.0: Could not init core: -110

 This was tested on an A62 with following wireless config:

   config wifi-device 'radio0'
   option type 'mac80211'
   option channel '36'
   option hwmode '11a'
   option path 
 'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
   option htmode 'VHT80'
   option disabled '0'
   option country US
    config wifi-device 'radio1'
   option type 'mac80211'
   option channel '11'
   option hwmode '11g'
   option path 'platform/soc/a00.wifi'
   option htmode 'HT20'
   option disabled '0'
   option country US
    config wifi-device 'radio2'
   option type 'mac80211'
   option channel '149'
   option hwmode '11a'
   option path 'platform/soc/a80.wifi'
   option htmode 'VHT80'
   option disabled '0'
   option country US
    config wifi-iface 'mesh0'
   option device 'radio0'
   option ifname 'mesh0'
   option network 'nwi_mesh0'
   option mode 'mesh'
   option mesh_id 'TestMesh'
   option mesh_fwding '1'
   option encryption 'none'
    config wifi-iface 'mesh1'
   option device 'radio1'
   option ifname 'mesh1'
   option network 'nwi_mesh1'
   option mode 'mesh'
   option mesh_id 'TestMesh'
   option encryption 'none'
     config wifi-iface 'mesh2'
   option device 'radio2'
   option ifname 'mesh2'
   option network 'nwi_mesh2'
   option mode 'mesh'
   option mesh_id

[OpenWrt-Devel] OpenWrt 19.07.3 service release

2020-05-20 Thread Baptiste Jonglez 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The OpenWrt community is proud to announce the third service release of
OpenWrt 19.07. OpenWrt 19.07.3 focuses on security, stability and device
support.

Selected highlights of this service release are:

 * reduce opkg memory usage
 * allow to configure WPA3 modes in the LuCI web interface
 * greatly improve loading performance when using LuCI with HTTPS
 * update core components (linux kernel, mac80211, etc)
 * many fixes and improvements for device support
 * fix security issues in umdns (CVE-2020-11750), relayd (CVE-2020-11752), and 
other external packages

Security fixes for packages can also be applied by upgrading only the
affected packages on running devices, without the need for a full firmware
upgrade to OpenWrt 19.07.3.
Nevertheless, we encourage all users to upgrade their devices to OpenWrt
19.07.3 whenever possible.

Full release notes and upgrade instructions are available at
https://openwrt.org/releases/19.07/notes-19.07.3

In particular, make sure to read the known issues before upgrading:
https://openwrt.org/releases/19.07/notes-19.07.3#known_issues

For a very detailed list of all changes since 19.07.2, refer to
https://openwrt.org/releases/19.07/changelog-19.07.3

- ---

For latest information about the 19.07 series, refer to the wiki at:
https://openwrt.org/releases/19.07/

To download a OpenWrt 19.07.3 firmware image for your device, head to the
Table of Hardware:
https://openwrt.org/toh/start

Or navigate directly in the list of firmware images:
https://downloads.openwrt.org/releases/19.07.3/targets/

As always, a big thank you goes to all our active package maintainers,
testers, documenters, and supporters.

Have fun!

The OpenWrt Community
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEjVflzZuxNlVFbt5QvgHsIqBOLkYFAl7FUvgACgkQvgHsIqBO
LkZphA/6AgbPY+hKZDuohZNaAkde1HMEu5y5aqEW91zAuQXR/NMJCs/5gdmvWwqL
FUz7SPNI6Qi5vDn3jQ0q0VdMAITJmw3+kljmUZL2bo1TJG6Kc5pC65LtjB1cw+Zv
6YOAdNw/9whlUH0NnzPRsgibgs3iEZBJqDQK1a+kgc9Dn7XRx5QP1iP0v+bHXKj4
/XaUTwq1FlksSrkLJMLwBPqNkzkvZ1crvPA0fOkkpJnSnny+AIn/ti4VhQ6BSm9a
mJHhgxb3sl05JN8NM+JbVBBzNUzj3PjXcaF+2fJcEl6J/xYyxnw1hSVZBdt9jHAv
K/wVHyZ4YLbSQ0kKPla2egQ7Z66xU3dVBNTCJvVvRHelIdKh+Dp0rmowLnyDvKeK
dCX2MLCT9CxDJL//0aFVlbXySysWUDKfHSew/jdnVhPZ6D5hyV3IwuJ/AjAK9Zmj
8YycVUEu3oSiJPjqctoXIoY6EaarPGaBAR2XGGU4TZlvdD1rmM6RCmk6zITSbtdy
kajISNPBemcQhQi7HpEgCnIZKyPjMmMK5P8PydC26YjHHXxg1osYsB66QCQU1IsX
apjanXLRzCeU6d6zVAJ4hmr7Y6MEHni6ECwXpd3JFIROvzCVfJEk9Wq3jUpBAAjh
XtvekmxMzkQ9AhX196vlzhL1HhZohEh8vTzCQsVxh7dpvo7TXNU=
=cpgp
-END PGP SIGNATURE-

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

Re: [OpenWrt-Devel] How am I supposed to change settings in /etc/config/network of default root file system of OpenWRT?

2020-05-20 Thread Magnus Kroken 

Hi

On 20.05.2020 02:01, Jeonghum Joh wrote:

Hello Magnus Kroken,

Thank you so much!
Your script works like a charm!

I'd like to use this script in our board. This board would be our 
customer's new product - 5G router.

We are Telesquare Inc. (www.telesquare.co.kr )

I'd like to write copyright to your name.
And I'd like you to clarify the license of this script.

Please let me know your opinion.

Thank you very much!
Jeonghum


Appreciate the consideration, although I'm not sure this snippet is 
substantial enough to be copyrightable. No matter I suppose - if it is 
copyrightable I can license it, if it is too simple to be copyrightable 
any claim of copyright is invalid and it can safely be used by anyone.


I have put a slightly clarified version as a Gist: 
https://gist.github.com/mkrkn/4ba4bef3f0d541aa1180bef4156b340c


Regards
Magnus Kroken

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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for Enterasys WS-AP3705i

2020-05-20 Thread David Bauer 
Hello Adrian,

On 5/20/20 3:41 PM, m...@adrianschmutzler.de wrote:
> Hi David,
> 
>> +label-mac-device = 
> 
> this only works if you set mtd-mac-address in DTS.
> 
> In your case, you need to add
> 
> label_mac=$(mtd_get_mac_ascii u-boot-env0 ethaddr)
> 
> to the mac address section of 02_network.
> 
> Despite, is there a need for the DT labels flash0, flash1 and ath9k? If no, 
> I'd drop them.

The first two are used for the mtd-concat hack and the PCIe card provides GPIO 
controller functionality.

Best wishes
David

> 
> Best
> 
> Adrian
> 

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

Re: [OpenWrt-Devel] [PATCH] ppd: add missing header

2020-05-20 Thread Rosen Penev 
On Wed, May 20, 2020 at 6:53 AM Petr Štetiar  wrote:
>
> Rosen Penev  [2020-03-29 21:44:34]:
>
> > sys/cdefs.h is needed for __P macro definition.
>
> Where? I mean, which combination triggers this issue? Perhaps upstream
> material?
It's a result of my musl update. See
https://github.com/openwrt/openwrt/pull/3004

I guess I forgot to add this patch to that PR...
>
> > Signed-off-by: Rosen Penev 
> > ---
> >  package/network/services/ppp/Makefile|  2 +-
> >  package/network/services/ppp/patches/800-cdefs.patch | 10 ++
> >  2 files changed, 11 insertions(+), 1 deletion(-)
> >  create mode 100644 package/network/services/ppp/patches/800-cdefs.patch
> >
> > diff --git a/package/network/services/ppp/Makefile 
> > b/package/network/services/ppp/Makefile
> > index 9e42cb7437..88b0a518e5 100644
> > --- a/package/network/services/ppp/Makefile
> > +++ b/package/network/services/ppp/Makefile
> > @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> >  include $(INCLUDE_DIR)/kernel.mk
> >
> >  PKG_NAME:=ppp
> > -PKG_RELEASE:=2
> > +PKG_RELEASE:=3
> >
> >  PKG_SOURCE_PROTO:=git
> >  PKG_SOURCE_URL:=https://github.com/paulusmack/ppp
> > diff --git a/package/network/services/ppp/patches/800-cdefs.patch 
> > b/package/network/services/ppp/patches/800-cdefs.patch
> > new file mode 100644
> > index 00..e361275a3c
> > --- /dev/null
> > +++ b/package/network/services/ppp/patches/800-cdefs.patch
> > @@ -0,0 +1,10 @@
> > +--- a/pppd/pppd.h
> >  b/pppd/pppd.h
> > +@@ -53,6 +53,7 @@
> > + #include  /* for encrypt */
> > + #include  /* for setkey */
> > + #include  /* for NGROUPS_MAX */
> > ++#include   /* for __P */
> > + #include   /* for MAXPATHLEN and BSD4_4, if 
> > defined */
> > + #include   /* for u_int32_t, if defined */
> > + #include/* for struct timeval */
> > --
> > 2.25.1
> >
> >
>
> --
> ynezz

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

[OpenWrt-Devel] [PATCH iwinfo] iwinfo: add device id for Atheros AR9287 PCIe wifi card

2020-05-20 Thread Pali Rohár 
This card is identified by lspci as:

  01:00.0 Network controller [0280]: Qualcomm Atheros AR9287 Wireless Network 
Adapter (PCI-Express) [168c:002e] (rev 01)
  Subsystem: Qualcomm Atheros Device [168c:30a4]

Signed-off-by: Pali Rohár 
---
 hardware.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hardware.txt b/hardware.txt
index 64ab708..262c69e 100644
--- a/hardware.txt
+++ b/hardware.txt
@@ -148,6 +148,7 @@
 0x168c 0x002d 0x168c 0x209a0  0  "Atheros"  "AR9287"
 0x168c 0x002e 0x1a3b 0x11210  0  "Atheros"  "AR9287"
 0x168c 0x002e 0x0777 0xe0a28  0  "Ubiquiti" "NanoStation Loco M2 (XM)" 
/* wrong offset! */
+0x168c 0x002e 0x168c 0x30a40  0  "Atheros"  "AR9287"
 0x168c 0x0030 0x168c 0x31140  0  "Atheros"  "AR9390"
 0x168c 0x0033 0x168c 0xa1200  0  "Atheros"  "AR9580"
 0x168c 0x0033 0x168c 0xa1360  0  "Atheros"  "AR9580"
-- 
2.20.1


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

[OpenWrt-Devel] [PATCH iwinfo] iwinfo: add device id for Marvell 88W8997 SDIO wifi card

2020-05-20 Thread Pali Rohár 
Signed-off-by: Pali Rohár 
---
 hardware.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hardware.txt b/hardware.txt
index 07f61b7..64ab708 100644
--- a/hardware.txt
+++ b/hardware.txt
@@ -174,6 +174,7 @@
 0x11ab 0x2a55 0x11ab 0x0  0  "Marvell"  "88W8864"
 0x02df 0x9135 0x 0x0  0  "Marvell"  "88W8887"
 0x11ab 0x2b40 0x11ab 0x0  0  "Marvell"  "88W8964"
+0x02df 0x9141 0x 0x0  0  "Marvell"  "88W8997"
 0x14c3 0x7603 0x14c3 0x76030  0  "MediaTek" "MT7603E"
 0x14c3 0x7610 0x14c3 0x76100  0  "MediaTek" "MT7610E"
 0x14c3 0x7612 0x14c3 0x76120  0  "MediaTek" "MT7612E"
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-20 Thread Sebastian Gottschall 


Am 20.05.2020 um 12:40 schrieb Vincent Wiemann:

Hi Sebastian,

I don't know why it was dropped, but I can say that the LED control code was 
kind of
annoying me. Even when the LED was turned of, it "flickered" when it was set 
disabled.
Unfortunately I didn't have time to look into it, yet.
the led code will just be used if you set a trigger. otherwise it doesnt 
touch the gpios.
the code itself was written to make use of the led's builtin to several 
routers. if you dont set a led trigger, nothing will happen



Best,

Vincent

On 20.05.20 09:39, Sebastian Gottschall wrote:

this code is not in use in its original form for ipq4019.
i have seen that his patch is also dropped from ath.git but is still in use by 
openwrt.
could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the patch was 
later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i did take care 
of

Sebastian

Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:

On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
chipsets with on chipset connected led's using WMI Firmware API.  The LED
device will get available named as "ath10k-phyX" at sysfs and can be controlled
with various triggers.  adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 
Reviewed-by: Steve deRosier 
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo 

This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:

  [  221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout, 
restarting hardware
  [  221.744056] ieee80211 phy0: Hardware restart was requested
  [  225.130829] ath10k_pci :01:00.0: failed to receive control 
response completion, polling..
  [  226.170824] ath10k_pci :01:00.0: Service connect timeout
  [  226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
  [  226.252248] ath10k_pci :01:00.0: Could not init core: -110

This was tested on an A62 with following wireless config:

  config wifi-device 'radio0'
  option type 'mac80211'
  option channel '36'
  option hwmode '11a'
  option path 
'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
  option htmode 'VHT80'
  option disabled '0'
  option country US
   config wifi-device 'radio1'
  option type 'mac80211'
  option channel '11'
  option hwmode '11g'
  option path 'platform/soc/a00.wifi'
  option htmode 'HT20'
  option disabled '0'
  option country US
   config wifi-device 'radio2'
  option type 'mac80211'
  option channel '149'
  option hwmode '11a'
  option path 'platform/soc/a80.wifi'
  option htmode 'VHT80'
  option disabled '0'
  option country US
   config wifi-iface 'mesh0'
  option device 'radio0'
  option ifname 'mesh0'
  option network 'nwi_mesh0'
  option mode 'mesh'
  option mesh_id 'TestMesh'
  option mesh_fwding '1'
  option encryption 'none'
   config wifi-iface 'mesh1'
  option device 'radio1'
  option ifname 'mesh1'
  option network 'nwi_mesh1'
  option mode 'mesh'
  option mesh_id 'TestMesh'
  option encryption 'none'
    config wifi-iface 'mesh2'
  option device 'radio2'
  option ifname 'mesh2'
  option network 'nwi_mesh2'
  option mode 'mesh'
  option mesh_id 'TestMesh'
  option mesh_fwding '1'
  option encryption 'none

Kind regards,
 Sven

___
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

Re: [OpenWrt-Devel] [PATCH] xfsprogs: update to 5.5

2020-05-20 Thread Petr Štetiar 
Rosen Penev  [2020-04-05 19:02:51]:

Missing commit description and BTW to me this looks like another candidate for
move into packages feed.

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH] ppd: add missing header

2020-05-20 Thread Petr Štetiar 
Rosen Penev  [2020-03-29 21:44:34]:

> sys/cdefs.h is needed for __P macro definition.

Where? I mean, which combination triggers this issue? Perhaps upstream
material?

> Signed-off-by: Rosen Penev 
> ---
>  package/network/services/ppp/Makefile|  2 +-
>  package/network/services/ppp/patches/800-cdefs.patch | 10 ++
>  2 files changed, 11 insertions(+), 1 deletion(-)
>  create mode 100644 package/network/services/ppp/patches/800-cdefs.patch
> 
> diff --git a/package/network/services/ppp/Makefile 
> b/package/network/services/ppp/Makefile
> index 9e42cb7437..88b0a518e5 100644
> --- a/package/network/services/ppp/Makefile
> +++ b/package/network/services/ppp/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>  include $(INCLUDE_DIR)/kernel.mk
>  
>  PKG_NAME:=ppp
> -PKG_RELEASE:=2
> +PKG_RELEASE:=3
>  
>  PKG_SOURCE_PROTO:=git
>  PKG_SOURCE_URL:=https://github.com/paulusmack/ppp
> diff --git a/package/network/services/ppp/patches/800-cdefs.patch 
> b/package/network/services/ppp/patches/800-cdefs.patch
> new file mode 100644
> index 00..e361275a3c
> --- /dev/null
> +++ b/package/network/services/ppp/patches/800-cdefs.patch
> @@ -0,0 +1,10 @@
> +--- a/pppd/pppd.h
>  b/pppd/pppd.h
> +@@ -53,6 +53,7 @@
> + #include  /* for encrypt */
> + #include  /* for setkey */
> + #include  /* for NGROUPS_MAX */
> ++#include   /* for __P */
> + #include   /* for MAXPATHLEN and BSD4_4, if 
> defined */
> + #include   /* for u_int32_t, if defined */
> + #include/* for struct timeval */
> -- 
> 2.25.1
> 
> 

-- 
ynezz

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

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-20 Thread Sebastian Gottschall 


Am 20.05.2020 um 21:05 schrieb Vincent Wiemann:

Hi Sebastian,

On 20.05.20 15:00, Sebastian Gottschall wrote:

Am 20.05.2020 um 12:40 schrieb Vincent Wiemann:

Hi Sebastian,

I don't know why it was dropped, but I can say that the LED control 
code was kind of
annoying me. Even when the LED was turned of, it "flickered" when it 
was set disabled.

Unfortunately I didn't have time to look into it, yet.
the led code will just be used if you set a trigger. otherwise it 
doesnt touch the gpios.
the code itself was written to make use of the led's builtin to 
several routers. if you dont set a led trigger, nothing will happen


Thank you for your quick response... I'll try to reproduce the issue 
without your patch.

Maybe it's unrelated and a firmware-specific issue (official QCA9887).

One thing I've seen with your patch is that if I set the ath10k GPIO 
"steady on" it sometimes
(quite randomly) turns it off for a fraction of a second. It happens 
about 3 times a minute.

It's not a big deal. But maybe it's related to the flickering
I've observed and possibly also a firmware issue...
my code only sets the gpio state based on the led trigger code. so 
basicly linux is handling it, my code just provides the code to access
the gpios. but i know that the firmware will reset the gpio state on 
certain events like channel reset/channel change.
but as i said. if you dont set a trigger, my code will not control the 
gpio of the chipset in any way and keeps it untouched.
so whatever you see, can only be caused by the firmware itself. what i 
can say is that on qca988x chipsets i have never seen
such a behaviour. the connected led on pin 1 is always off without a 
trigger and with a trigger its doing what it should do. and the 988x is 
basicly

identical to the qca9887, just the amount of antennas is different


Best,

Vincent



Best,

Vincent

On 20.05.20 09:39, Sebastian Gottschall wrote:

this code is not in use in its original form for ipq4019.
i have seen that his patch is also dropped from ath.git but is 
still in use by openwrt.

could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the 
patch was later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i 
did take care of


Sebastian

Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:

On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 
9984 based
chipsets with on chipset connected led's using WMI Firmware API.  
The LED
device will get available named as "ath10k-phyX" at sysfs and can 
be controlled
with various triggers.  adds also debugfs interface for gpio 
control.


Signed-off-by: Sebastian Gottschall 
Reviewed-by: Steve deRosier 
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo 
This patch was imported to OpenWrt in commit 61d57a2f88b9 
("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and 
QCA4019 (5GHz)

firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:

   [  221.620803] ath10k_pci :01:00.0: wmi command 36967 
timeout, restarting hardware

   [  221.744056] ieee80211 phy0: Hardware restart was requested
   [  225.130829] ath10k_pci :01:00.0: failed to receive 
control response completion, polling..
   [  226.170824] ath10k_pci :01:00.0: Service connect 
timeout
   [  226.170871] ath10k_pci :01:00.0: failed to connect 
htt (-110)
   [  226.252248] ath10k_pci :01:00.0: Could not init 
core: -110


This was tested on an A62 with following wireless config:

   config wifi-device 'radio0'
   option type 'mac80211'
   option channel '36'
   option hwmode '11a'
   option path 
'soc/4000.pci/pci:00/:00:00.0/:01:00.0'

   option htmode 'VHT80'
   option disabled '0'
   option country US
    config wifi-device 'radio1'
   option type 'mac80211'
   option channel '11'
   option hwmode '11g'
   option path 'platform/soc/a00.wifi'
   option htmode 'HT20'
   option disabled '0'
   option country US
    config wifi-device 'radio2'
   option type 'mac80211'
   option channel '149'
   option hwmode '11a'
   option path 'platform/soc/a80.wifi'
   option htmode 'VHT80'
   option disabled '0'
   option country US
    config wifi-iface 'mesh0'
   option device 'radio0'
   option ifname 'mesh0'
   option network 'nwi_mesh0'
   option mode 'mesh'
   option mesh_id 'TestMesh'
   option mesh_fwding '1'
   option encryption 'none'
    config wifi-iface 'mesh1'
   option device 'radio1'
 

Re: [OpenWrt-Devel] hostap commit 6c9543fcb breaks MESH-SAE with wolfssl

2020-05-20 Thread Daniel Golle 
Hi Jouni!

On Sat, May 16, 2020 at 11:54:55PM +0300, Jouni Malinen wrote:
> On Wed, May 13, 2020 at 05:34:31PM +0100, Daniel Golle wrote:
> > I've just built OpenWrt for MIPS malta (BE) with mac80211-hwsim and
> > hereby confirm the problem shows up there in exactly the same way.
> > Also on MIPS malta with mac80211-hwsim, mesh with SAE works with
> > WolfSSL up to and including hostapd git revision 2b84ca4dd work fine,
> > starting from revision 6c9543fcb7 don't.
> > 
> > As OpenWrt might not be what you want for QA, I've been following
> > https://markuta.com/how-to-build-a-mips-qemu-image-on-debian/
> > and ended up with a functional Debian install inside QEMU about 20
> > minutes later. (I had to replace kernel image vmlinux-4.9.0-6-4kc-malta
> > mentioned in that guide with vmlinux-4.19.0-9-4kc-malta which is the
> > current version and exists on Debian's download server)
> > This would allow to run the whole test-suite as-is on MIPS32 BE, maybe
> > even with buildbot.w1.fi...
> 
> Thanks for the pointer. That 20 minutes seemed a bit optimistic for the
> full setup, but I did get this running with buildroot-based cross
> compiler setup. Emulating a big endian MIPS processor with QEMU does not
> look exactly fast, though.. This can get the mac80211_hwsim test cases
> started, but significant portion of them fails due to various timeouts
> and it takes hours--or well, maybe days--to run through the full test
> set (but to be fair, I could run multiple VM instances in parallel to
> speed this up). Anyway, this can be quite useful to have available for
> manually testing some specific implementation details..

I was intrigued by how fast Debian installer went through and after
only a few minutes it booted with a working system, then installing
build-essentials, automake, autoconf, libtool and git.
The actual compile of wolfssl and wpa_supplicant then took several
hours...


> 
> As far as this issue with SAE is concerned, there is actually nothing
> wrong with the calculation results, i.e., all the values are correct and
> I was able to get SAE completed with the current snapshot.. However, it
> is really slow. To the point of taking close to a minute to complete
> authentication. I'd assume you are seeing timeouts from this or just
> giving up on waiting before the operation is completed.
> 
> While the current standard version of SAE is inconveniently slow on low
> end processors, it was not supposed to be this slow. It turned out that
> the real issue here is in not exactly ideal implementation of the
> wolfssl wrapper function crypto_bignum_rand(). This function is expected
> to return a random value between 0 and m-1. That is what the function
> did, but it did that by finding a random _prime_ double the maximum
> length of that range and then scaling to to the range which is
> significantly harder calculation (took around 40 times longer than
> needed in some of my tests) and completely unnecessary for this
> function. This commit fixes that issue:
> https://w1.fi/cgit/hostap/commit/?id=eb595b3e3ab531645a5bde71cf6385335b7a4b95

Thank you for finding the cause of the issue, fixing it and also for
the detailed explaination!
I can confirm that your commit does fix the issue on the QCA MIPS
devices which were previously affected, they now reliably connect
instantly now.


Cheers


Daniel

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

Re: [OpenWrt-Devel] How am I supposed to change settings in /etc/config/network of default root file system of OpenWRT?

2020-05-20 Thread Wes Turner 
Would it make sense to integrate support for a wwan interface and zone that
just no-ops when there's no wwan interface defined?

The case of a 4G/5G modem will likely be more popular in the future.

"[OpenWrt-Devel] RFI: OpenWRT for #DisasterRelief: LoRA: ClusterDuck, LTE,
5G, Mesh, Throttling"
https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg52055.html

> Are there other [OpenWRT-compatible] devices with LTE and/or LoRa that
> would be useful for disaster relief?
>
> "Table of Hardware: LTE Modem supported"
> https://openwrt.org/toh/views/toh_lte_modem_supported

>
> ## 5G
> Are there any 5G-compatible OpenWRT devices yet?
> Presumably, devices with Mini-PCIe are theoretically compatible given
built
modules.

How would you name interfaces / zones when there's also at least one LoRA
interface?

wan
wwan

wan0
wwan0
lora0 (?)

On Wed, May 20, 2020 at 8:12 PM Jeonghum Joh 
wrote:

> Hello Magnus Kroken,
>
> Thank you for clarifying the license.
> I will use this one in the github gist.
>
> Thank you so much!
> Jeonghum
>
> 2020년 5월 21일 (목) 오전 2:13, Magnus Kroken 님이 작성:
>
>> Hi
>>
>> On 20.05.2020 02:01, Jeonghum Joh wrote:
>> > Hello Magnus Kroken,
>> >
>> > Thank you so much!
>> > Your script works like a charm!
>> >
>> > I'd like to use this script in our board. This board would be our
>> > customer's new product - 5G router.
>> > We are Telesquare Inc. (www.telesquare.co.kr <
>> http://www.telesquare.co.kr>)
>> >
>> > I'd like to write copyright to your name.
>> > And I'd like you to clarify the license of this script.
>> >
>> > Please let me know your opinion.
>> >
>> > Thank you very much!
>> > Jeonghum
>>
>> Appreciate the consideration, although I'm not sure this snippet is
>> substantial enough to be copyrightable. No matter I suppose - if it is
>> copyrightable I can license it, if it is too simple to be copyrightable
>> any claim of copyright is invalid and it can safely be used by anyone.
>>
>> I have put a slightly clarified version as a Gist:
>> https://gist.github.com/mkrkn/4ba4bef3f0d541aa1180bef4156b340c
>>
>> Regards
>> Magnus Kroken
>>
> ___
> 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] wireguard: bump to 1.0.20200520

2020-05-20 Thread Jason A. Donenfeld 
This version has the various slew of bug fixes and compat fixes and
such, but the most interesting thing from an OpenWRT perspective is that
WireGuard now plays nicely with cake and fq_codel. I'll be very
interested to hear from OpenWRT users whether this makes a measurable
difference. Usual set of full changes follows.

This release aligns with the changes I sent to DaveM for 5.7-rc7 and were
pushed to net.git about 45 minutes ago.

* qemu: use newer iproute2 for gcc-10
* qemu: add -fcommon for compiling ping with gcc-10

These enable the test suite to compile with gcc-10.

* noise: read preshared key while taking lock

Matt noticed a benign data race when porting the Linux code to OpenBSD.

* queueing: preserve flow hash across packet scrubbing
* noise: separate receive counter from send counter

WireGuard now works with fq_codel, cake, and other qdiscs that make use of
skb->hash. This should significantly improve latency spikes related to
buffer bloat. Here's a before and after graph from some data Toke measured:
https://data.zx2c4.com/removal-of-buffer-bloat-in-wireguard.png

* compat: support RHEL 8 as 8.2, drop 8.1 support
* compat: support CentOS 8 explicitly
* compat: RHEL7 backported the skb hash renamings

The usual RHEL churn.

* compat: backport renamed/missing skb hash members

The new support for fq_codel and friends meant more backporting work.

* compat: ip6_dst_lookup_flow was backported to 4.14, 4.9, and 4.4

The main motivation for releasing this now: three stable kernels were released
at the same time, with a patch that necessitated updating in our compat layer.

Signed-off-by: Jason A. Donenfeld 
---
 package/network/services/wireguard/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/wireguard/Makefile 
b/package/network/services/wireguard/Makefile
index b856d82..ce91fbe 100644
--- a/package/network/services/wireguard/Makefile
+++ b/package/network/services/wireguard/Makefile
@@ -11,12 +11,12 @@ include $(INCLUDE_DIR)/kernel.mk
 
 PKG_NAME:=wireguard
 
-PKG_VERSION:=1.0.20200506
+PKG_VERSION:=1.0.20200520
 PKG_RELEASE:=1
 
 PKG_SOURCE:=wireguard-linux-compat-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=https://git.zx2c4.com/wireguard-linux-compat/snapshot/
-PKG_HASH:=98a99f2b825a82d57a7213e666f1ee4f7cc02bddb09bf4908b4b09447a8f121e
+PKG_HASH:=16e7ae4bef734b243428eea07f3b3c3d4721880c3ea8eb8f98628fd6ae5b77c3
 
 PKG_LICENSE:=GPL-2.0
 PKG_LICENSE_FILES:=COPYING
-- 
2.26.2


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

Re: [OpenWrt-Devel] How am I supposed to change settings in /etc/config/network of default root file system of OpenWRT?

2020-05-20 Thread Jeonghum Joh 
Hello Magnus Kroken,

Thank you for clarifying the license.
I will use this one in the github gist.

Thank you so much!
Jeonghum

2020년 5월 21일 (목) 오전 2:13, Magnus Kroken 님이 작성:

> Hi
>
> On 20.05.2020 02:01, Jeonghum Joh wrote:
> > Hello Magnus Kroken,
> >
> > Thank you so much!
> > Your script works like a charm!
> >
> > I'd like to use this script in our board. This board would be our
> > customer's new product - 5G router.
> > We are Telesquare Inc. (www.telesquare.co.kr <
> http://www.telesquare.co.kr>)
> >
> > I'd like to write copyright to your name.
> > And I'd like you to clarify the license of this script.
> >
> > Please let me know your opinion.
> >
> > Thank you very much!
> > Jeonghum
>
> Appreciate the consideration, although I'm not sure this snippet is
> substantial enough to be copyrightable. No matter I suppose - if it is
> copyrightable I can license it, if it is too simple to be copyrightable
> any claim of copyright is invalid and it can safely be used by anyone.
>
> I have put a slightly clarified version as a Gist:
> https://gist.github.com/mkrkn/4ba4bef3f0d541aa1180bef4156b340c
>
> Regards
> Magnus Kroken
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] RFI: OpenWRT for #DisasterRelief: LoRA: ClusterDuck, LTE, 5G, Mesh, Throttling

2020-05-20 Thread Wes Turner 
Bump.

On Wed, Apr 8, 2020 at 7:32 PM Wes Turner  wrote:

> A thread for discussing OpenWRT for #DisasterRelief: LoRA: ClusterDuck,
> LTE, Mesh
>
> (cc'ing and re-formatting from
> https://twitter.com/westurner/status/1238859774567026688 )
>
> Please LMK if the forums are the appropriate place for these questions.
>
> ## Project OWL ClusterDuck
> Homepage: http://clusterduckprotocol.org/
> GitHub: https://github.com/Code-and-Response/ClusterDuck-Protocol
>
> The Linux Foundation > Code and Response:
>   https://www.linuxfoundation.org/projects/code-and-response/
> GitHub:
>   https://github.com/code-and-response
>
> > Project OWL (Organization, Whereabouts, and Logistics) creates a mesh
> network of Internet of Things (IoT) devices called DuckLinks. These
> Wi-Fi-enabled devices can be deployed or activated in disaster areas to
> quickly re-establish connectivity and improve communication between first
> responders and civilians in need.
> >
> > In OWL, a central portal connects to solar- and battery-powered,
> water-resistant DuckLinks. These create a Local Area Network (LAN). In
> turn, these power up a Wi-Fi captive portal using low-frequency Long-range
> Radio (LoRa) for Internet connectivity. LoRA has a greater range, about
> 10km, than cellular networks.
> > [...]
> > You don't actually need a DuckLink device. The open-source OWL firmware
> can quickly turn a cheap wireless device into a DuckLink using the -- I
> swear I'm not making this up -- ClusterDuck Protocol. This is a mesh
> network node, which can hook up to any other near-by Ducks.
> >
> > OWL is more than just hardware and firmware. It's also a cloud-based
> analytic program. The OWL Data Management Software can be used to
> facilitate organization, whereabouts, and logistics for disaster response.
>
> ## LoRa + OpenWRT: ClusterDuck, ChirpStack
> A ClusterDuck opkg would make it possible to use WiFi/LTE routers with a
> LoRa transmitter/receiver connected over e.g. USB or Mini-PCIe.
>
> Is there anything special that would need to be done to create an opkg for
> ClusterDuck?
>
> > OpenWRT uses opkg packages:
> https://openwrt.org/docs/guide-user/additional-software/opkg
>
> I searched for "Lora" in OpenWRT/packages:
>
> - lora-gateway-hal opkg package:
> https://github.com/openwrt/packages/blob/master/net/lora-gateway-hal/Makefile
> - lora-packet-forwarder opkg package (w/ UCI integration):
> https://github.com/openwrt/packages/pull/8320
> - lora-feed: https://github.com/xueliu/lora-feed :
>
>   > Semtech packages and ChirpStack [(LoRaserver)] Network Server stack
> for OpenWRT
>
> ## Mesh architectures: ClusterDuck // B.A.T.M.A.N
> How does ClusterDuck compare to BATMAN and other mesh routing approaches?
>
> Is there a reference implementation with WiFi, LTE, and LoRa and IDK link
> prioritization?
>
> >> [In addition to providing node2node/2net connectivity, #batman-adv can
> bridge VLANs over a mesh (or link), such as for “trusted” client, guest,
> IoT, and mgmt networks. It provides an easy-to-configure alternative to
> other approaches to “backhaul”, […]]
> https://openwrt.org/docs/guide-user/network/wifi/mesh/batman
>
> ## LTE Routers, LTE Tethering
> LTE is useful for disaster relief scenarios.
>
> Tethering an OpenWRT router to an LTE phone over WiFi/USB/Bluetooth is one
> alternative to buying a router with an LTE modem, external LTE antennas,
> and one or more SIM card slots.
>
> I have no affiliation with either of these manufacturers. I have a few
> different [quad-core, MIMO] ARM devices without 4G. TIL about routers with
> LTE modems in them (and cell providers that allow adding additional SIMs
> that just draw from a shared bandwidth quota).
>
> > TIL that the @GLiNetWifi devices ship with OpenWRT firmware (and a
> mobile config app) and some have 1-2 (Mini-PCIe) 4G LTE w/ SIM slots.
> https://twitter.com/GLiNetWiFi
>
> > Also, @turris_cz has OpenWRT w/ LTE and LXC in the kernel build.
> https://t.co/Rz0Uu5uHJQ
> https://twitter.com/turris_cz
>
> Are there other [OpenWRT-compatible] devices with LTE and/or LoRa that
> would be useful for disaster relief?
>
> "Table of Hardware: LTE Modem supported"
> https://openwrt.org/toh/views/toh_lte_modem_supported
>
> ## 5G
> Are there any 5G-compatible OpenWRT devices yet?
> Presumably, devices with Mini-PCIe are theoretically compatible given
> built modules.
>
> ## Throttling
> In a disaster relief scenario, burning through the limited available
> bandwidth for certain media-heavy sites can be problematic.
>
> Is there a recommended way to e.g. throttle / traffic shape individual
> clients so that no one user can exhaust the bandwidth resources? AFAIU, SQM
> can be configured for individual VLANs, but that would require an SSID per
> user?
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-20 Thread Sebastian Gottschall 

this code is not in use in its original form for ipq4019.
i have seen that his patch is also dropped from ath.git but is still in 
use by openwrt.

could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the patch 
was later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i did 
take care of


Sebastian

Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:

On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
chipsets with on chipset connected led's using WMI Firmware API.  The LED
device will get available named as "ath10k-phyX" at sysfs and can be controlled
with various triggers.  adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 
Reviewed-by: Steve deRosier 
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo 


This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:

 [  221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout, 
restarting hardware
 [  221.744056] ieee80211 phy0: Hardware restart was requested
 [  225.130829] ath10k_pci :01:00.0: failed to receive control response 
completion, polling..
 [  226.170824] ath10k_pci :01:00.0: Service connect timeout
 [  226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
 [  226.252248] ath10k_pci :01:00.0: Could not init core: -110

This was tested on an A62 with following wireless config:

 config wifi-device 'radio0'
 option type 'mac80211'
 option channel '36'
 option hwmode '11a'
 option path 'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
 option htmode 'VHT80'
 option disabled '0'
 option country US
 
 config wifi-device 'radio1'

 option type 'mac80211'
 option channel '11'
 option hwmode '11g'
 option path 'platform/soc/a00.wifi'
 option htmode 'HT20'
 option disabled '0'
 option country US
 
 config wifi-device 'radio2'

 option type 'mac80211'
 option channel '149'
 option hwmode '11a'
 option path 'platform/soc/a80.wifi'
 option htmode 'VHT80'
 option disabled '0'
 option country US
 
 config wifi-iface 'mesh0'

 option device 'radio0'
 option ifname 'mesh0'
 option network 'nwi_mesh0'
 option mode 'mesh'
 option mesh_id 'TestMesh'
 option mesh_fwding '1'
 option encryption 'none'
 
 config wifi-iface 'mesh1'

 option device 'radio1'
 option ifname 'mesh1'
 option network 'nwi_mesh1'
 option mode 'mesh'
 option mesh_id 'TestMesh'
 option encryption 'none'
 
 
 config wifi-iface 'mesh2'

 option device 'radio2'
 option ifname 'mesh2'
 option network 'nwi_mesh2'
 option mode 'mesh'
 option mesh_id 'TestMesh'
 option mesh_fwding '1'
 option encryption 'none

Kind regards,
Sven


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

Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets

2020-05-20 Thread Vincent Wiemann 
Hi Sebastian,

I don't know why it was dropped, but I can say that the LED control code was 
kind of
annoying me. Even when the LED was turned of, it "flickered" when it was set 
disabled.
Unfortunately I didn't have time to look into it, yet.

Best,

Vincent

On 20.05.20 09:39, Sebastian Gottschall wrote:
> this code is not in use in its original form for ipq4019.
> i have seen that his patch is also dropped from ath.git but is still in use 
> by openwrt.
> could somone clarify the state here and why it was dropped?
> the original patch i wrote does exclude the soc chipsets, but the patch was 
> later reorganized and some part have been rewritten
> so i'm not sure if it covers the scenario mentioned here, which i did take 
> care of
> 
> Sebastian
> 
> Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
>> On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
>>> From: Sebastian Gottschall 
>>>
>>> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
>>> chipsets with on chipset connected led's using WMI Firmware API.  The LED
>>> device will get available named as "ath10k-phyX" at sysfs and can be 
>>> controlled
>>> with various triggers.  adds also debugfs interface for gpio control.
>>>
>>> Signed-off-by: Sebastian Gottschall 
>>> Reviewed-by: Steve deRosier 
>>> [kvalo: major reorg and cleanup]
>>> Signed-off-by: Kalle Valo 
>>
>> This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
>> add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
>> firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
>>
>>  [  221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout, 
>> restarting hardware
>>  [  221.744056] ieee80211 phy0: Hardware restart was requested
>>  [  225.130829] ath10k_pci :01:00.0: failed to receive control 
>> response completion, polling..
>>  [  226.170824] ath10k_pci :01:00.0: Service connect timeout
>>  [  226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
>>  [  226.252248] ath10k_pci :01:00.0: Could not init core: -110
>>
>> This was tested on an A62 with following wireless config:
>>
>>  config wifi-device 'radio0'
>>  option type 'mac80211'
>>  option channel '36'
>>  option hwmode '11a'
>>  option path 
>> 'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
>>  option htmode 'VHT80'
>>  option disabled '0'
>>  option country US
>>   config wifi-device 'radio1'
>>  option type 'mac80211'
>>  option channel '11'
>>  option hwmode '11g'
>>  option path 'platform/soc/a00.wifi'
>>  option htmode 'HT20'
>>  option disabled '0'
>>  option country US
>>   config wifi-device 'radio2'
>>  option type 'mac80211'
>>  option channel '149'
>>  option hwmode '11a'
>>  option path 'platform/soc/a80.wifi'
>>  option htmode 'VHT80'
>>  option disabled '0'
>>  option country US
>>   config wifi-iface 'mesh0'
>>  option device 'radio0'
>>  option ifname 'mesh0'
>>  option network 'nwi_mesh0'
>>  option mode 'mesh'
>>  option mesh_id 'TestMesh'
>>  option mesh_fwding '1'
>>  option encryption 'none'
>>   config wifi-iface 'mesh1'
>>  option device 'radio1'
>>  option ifname 'mesh1'
>>  option network 'nwi_mesh1'
>>  option mode 'mesh'
>>  option mesh_id 'TestMesh'
>>  option encryption 'none'
>>    config wifi-iface 'mesh2'
>>  option device 'radio2'
>>  option ifname 'mesh2'
>>  option network 'nwi_mesh2'
>>  option mode 'mesh'
>>  option mesh_id 'TestMesh'
>>  option mesh_fwding '1'
>>  option encryption 'none
>>
>> Kind regards,
>> Sven
> 
> ___
> 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] ath79: nand: disable images for glinet_gl-ar750s

2020-05-20 Thread Petr Štetiar 
Seems like kernel doesn't fit into 2M anymore. Fixes following build failures:

 WARNING: Image file glinet_gl-ar750s-nor-kernel.bin is too big
 WARNING: Image file glinet_gl-ar750s-nor-nand-kernel.bin is too big

Cc: Jeff Kletsky 
Cc: Chuanhong Guo 
Signed-off-by: Petr Štetiar 
---
 target/linux/ath79/image/nand.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 76fee34a90e1..a68f3900d16c 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -134,6 +134,7 @@ define Device/glinet_gl-ar750s-nor-nand
append-ubi | check-kernel-size (GL_UBOOT_UBI_OFFSET)
   IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata
   SUPPORTED_DEVICES += glinet,gl-ar750s-nor
+  DEFAULT := n
 endef
 TARGET_DEVICES += glinet_gl-ar750s-nor-nand
 
@@ -142,6 +143,7 @@ define Device/glinet_gl-ar750s-nor
   DEVICE_VARIANT := NOR
   BLOCKSIZE := 64k
   SUPPORTED_DEVICES += gl-ar750s glinet,gl-ar750s glinet,gl-ar750s-nor-nand
+  DEFAULT := n
 endef
 TARGET_DEVICES += glinet_gl-ar750s-nor
 

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