[no subject]

2020-08-04 Thread SAn 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 ---
Hi Stefan and Daniel,

On 8/2/20 8:19 PM, Daniel Golle wrote:
> On Sun, Aug 02, 2020 at 07:49:40PM -0300, SAn via openwrt-devel wrote:
>> Subject: ath79 subtarget with cmdline from bootloader
>>
>> Hi! 
>>
>> The LibreRouter uses a dual-boot scheme that relies on the bootloader 
>> configuring the kernel cmdline. At ar71xx 18.06 it was possible to select 
>> per device if the cmdline from the bootloader has to be honored (using 
>> patch-cmdline).
>> AFAIK there is no such possibility on ath79.
>>
>> Would you consider accepting a patch that adds a new ath79 subtarget with 
>> CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)?
>>
>> It would be valuable for the people using LibreRouter devices to be able to 
>> use official OpenWrt 20.xx images with the dual-boot support. Currently 
>> there are multiple mips targets that use CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER 
>> (bcm47xx, octeon, malta, and a few more).
> 
> I don't think this justifies an extra subtarget just for the sake of
> having the kernel process cmdline arguments passed by an outdated
> (ie. non-DT, non-FIT) bootloader.
> If it really has to be that way (and eg. parsing uboot-env cannot be
> used instead and bootloader cannot be updated to properly pass this
.

Another bootloader can be used, but I am not aware of a newer one with QCA955x 
support, do you? The last time I checked u-boot there was upstream support to 
qca956x and qca953x. Adding support to 955x seemed to me a lot of work (there 
are thousands of undocumented constants everywhere in the code), but maybe I am 
mistaken?

I did not understand the "parsing uboot-env". Can you expand on this please? :)

> in dtb), I guess something along the lines of
> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE
> could work (would have to be implemented for MIPS first, obviously)

If there is no other viable way I would go this way..
Thanks Stefan for the pointers to the patches!

> Alternatively, as a quick-and-dirty workaround, just move the whole
> librerouter.dts into a .dtsi and then have two .dts files referecing
> them, each setting different cmdline. Then generate two images.
> That'd be the same effect as what patch-cmdline used to do on non-DT
> targets.
> 

I think this is too complicated for end users. Maybe a friendlier way could be 
to pack both images into a tarfile and then use the correct one from a 
userspace tool to perform the upgrade.

Thanks for the help!
SAn

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

[PATCH] bcm53xx: fix support for TP-Link Archer C5 v2 and C9 v1

2020-08-04 Thread Adrian Schmutzler 
As it appears, these devices just needed a resize of their os-image
partition. Increase it to 0x30, so we have some extra space left
for future kernels.

Note that this only adjusts the partioning scheme, but since I
do not own the device I cannot say whether the bootloader will
actually cope with os-image > 2 MiB.

Cc: John Crispin 
Cc: Rafał Miłecki 
Signed-off-by: Adrian Schmutzler 
---
 target/linux/bcm53xx/image/Makefile   |  2 -
 .../330-tplink-archer-increase-os-image.patch | 44 +++
 .../330-tplink-archer-increase-os-image.patch | 44 +++
 tools/firmware-utils/src/tplink-safeloader.c  |  8 ++--
 4 files changed, 92 insertions(+), 6 deletions(-)
 create mode 100644 
target/linux/bcm53xx/patches-4.19/330-tplink-archer-increase-os-image.patch
 create mode 100644 
target/linux/bcm53xx/patches-5.4/330-tplink-archer-increase-os-image.patch

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index a117e02a45..476ef785db 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -413,7 +413,6 @@ define Device/tplink-archer-c5-v2
   IMAGES := bin
   IMAGE/bin := append-rootfs | bcm53xx-tplink-safeloader
   TPLINK_BOARD := ARCHER-C5-V2
-  BROKEN := y
 endef
 TARGET_DEVICES += tplink-archer-c5-v2
 
@@ -425,7 +424,6 @@ define Device/tplink-archer-c9-v1
   IMAGES := bin
   IMAGE/bin := append-rootfs | bcm53xx-tplink-safeloader
   TPLINK_BOARD := ARCHERC9
-  BROKEN := y
 endef
 TARGET_DEVICES += tplink-archer-c9-v1
 
diff --git 
a/target/linux/bcm53xx/patches-4.19/330-tplink-archer-increase-os-image.patch 
b/target/linux/bcm53xx/patches-4.19/330-tplink-archer-increase-os-image.patch
new file mode 100644
index 00..57650e09a0
--- /dev/null
+++ 
b/target/linux/bcm53xx/patches-4.19/330-tplink-archer-increase-os-image.patch
@@ -0,0 +1,44 @@
+--- a/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
 b/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
+@@ -106,15 +106,15 @@
+   read-only;
+   };
+ 
+-  os-image@10 {
++  os-image@4 {
+   label = "os-image";
+-  reg = <0x04 0x20>;
++  reg = <0x04 0x30>;
+   compatible = "brcm,trx";
+   };
+ 
+-  rootfs@24 {
++  rootfs@34 {
+   label = "rootfs";
+-  reg = <0x24 0xc0>;
++  reg = <0x34 0xb0>;
+   };
+ 
+   nvram@ff {
+--- a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
 b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
+@@ -115,15 +115,15 @@
+   read-only;
+   };
+ 
+-  os-image@10 {
++  os-image@4 {
+   label = "os-image";
+-  reg = <0x04 0x20>;
++  reg = <0x04 0x30>;
+   compatible = "brcm,trx";
+   };
+ 
+-  rootfs@24 {
++  rootfs@34 {
+   label = "rootfs";
+-  reg = <0x24 0xc0>;
++  reg = <0x34 0xb0>;
+   };
+ 
+   nvram@ff {
diff --git 
a/target/linux/bcm53xx/patches-5.4/330-tplink-archer-increase-os-image.patch 
b/target/linux/bcm53xx/patches-5.4/330-tplink-archer-increase-os-image.patch
new file mode 100644
index 00..5d53dc34ab
--- /dev/null
+++ b/target/linux/bcm53xx/patches-5.4/330-tplink-archer-increase-os-image.patch
@@ -0,0 +1,44 @@
+--- a/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
 b/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
+@@ -105,15 +105,15 @@
+   read-only;
+   };
+ 
+-  os-image@10 {
++  os-image@4 {
+   label = "os-image";
+-  reg = <0x04 0x20>;
++  reg = <0x04 0x30>;
+   compatible = "brcm,trx";
+   };
+ 
+-  rootfs@24 {
++  rootfs@34 {
+   label = "rootfs";
+-  reg = <0x24 0xc0>;
++  reg = <0x34 0xb0>;
+   };
+ 
+   nvram@ff {
+--- a/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
 b/arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dts
+@@ -116,15 +116,15 @@
+   read-only;
+   };
+ 
+-  os-image@10 {
++  os-image@4 {
+   label = "os-image";
+-  reg = <0x04 0x20>;
++  reg = <0x04 0x30>;
+   compatible = "brcm,trx";
+   };
+ 
+-  rootfs@24 {
++  rootfs@34 {
+   l

RE: Fate of 4.14 targets / samsung odroid HC1 support

2020-08-04 Thread Adrian Schmutzler 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Andre Valentin
> Sent: Dienstag, 4. August 2020 17:48
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: Fate of 4.14 targets / samsung odroid HC1 support
> 
> Hi!
> 
> I've enabled support for the odoid HC1 in the samsung target a month ago, it
> only needs generic 5.4 kernel and is a subtarget.
> https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
> Only open thing is the boodloader on the sdcard, which is a binary for
> hardkernel.

Just had a look, samsung target seems to use a custom nand driver.

Based on what I remember from other targets, I don't think this will be fun to 
upgrade from 4.14 to 5.4 ...

And in particular, we would need somebody interested with a device to do that 
...


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

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

2020-08-04 Thread Rafał Miłecki 

On 04.08.2020 09:57, Jo-Philipp Wich wrote:

Regarding parsing events stream, event names with spaces seem to be OK:
https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream


To me it feels quirky to separate the path and the type of the event by space.

Personally I'd only report the type as "event:" and move the source path into
the JSON data portion,


This seems to break hierarchy. I see correct hierarchy as:
1. Object
2. Notification type
3. Notification data

If we put type in "event:" and object path and notification data in
"data:" it seems unnatural.


> or even omit it entirely.

I'm sure one may need to distinct notifications from wlan0 vs. wlan1.
That's probably not an option unless I missed something.



Considering the design of the client side API:

eventSource.addEventListener(type, handler);

Most use-cases probably want to register a handler for a specific event type,
e.g. "status", and not N handlers to handle the different object path
variations, so given the subscribe examples in the previous mail:

eventSource.addEventListener("status", (ev) => { ... })

instead of

eventSource.addEventListener("hostapd.wlan0 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan0-1 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan1 status", (ev) => { ... })
eventSource.addEventListener("hostapd.wlan1-1 status", (ev) => { ... })


I see how it simplifies JavaScript code though so I'm confused.

Should we maybe totally drop "event:" and just put everything (object
path, event type, data) in "data:"?



Granted, one could use the `onmessage` event to implement a catch-all handler
which is then filtering and dispatching according to the type, but even then
string operations like split(), indexOf(), regex matches or similar would be
required to match event types, that feels unelegant and not very performant.

I'm not sure if "message" event fires for *named* events (event: foo).

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

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

2020-08-04 Thread Rafał Miłecki 

On 04.08.2020 09:43, Andre Valentin wrote:

Am 03.08.20 um 07:49 schrieb Rafał Miłecki:

On 31.07.2020 13:02, Andre Valentin wrote:

this is really great stuff. It would help me to get forward with my wifi 
controller.
Could it be possible to subsribe to multiple sources to limit the connections 
to ubus?
2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand right.


I'm happy someone finds it useful!

If you mean hostapd.* objects, that's right. That would require you to
use:
/ubus/subscribe/hostapd.wlan0
/ubus/subscribe/hostapd.wlan0-1
/ubus/subscribe/hostapd.wlan1
/ubus/subscribe/hostapd.wlan1-1

For subscribing to multiple objects we would need to:
1. Stick to GET due to the way EventSource works
2. Pick some more generic URL
3. Adjust output format ("event" and "data" fields)

So my guess would be something like:

$ curl http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1


Good idea!


event: hostapd.wlan1 status
data: {"count":5}

event: hostapd.wlan0-1 status
data: {"count":5}

event: hostapd.wlan1 status
data: {"count":7}


Regarding parsing events stream, event names with spaces seem to be OK:
https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
field value can use any scalar value other than line break char.


Why do you need the status there, is it part of the standard?


That was meant to separate object name from notification name.



We should use some special character as separator of object name and
notification name. It must be something that ubus doesn't use in any of
them. Should space be OK? Or should we use some more fancy char? I
quickly tested space and it seems to work well in Firefox and Chromium.


Oh, I'm nut sure. But I think space is fine.

Did you use a special uhttpd version. I couldn't apply your patch to the uhttpd 
in openwrt master.


There are few more uhttpd pending patches that I sent, see:
https://patchwork.ozlabs.org/project/openwrt/list/?series=&submitter=5824&state=*&q=uhttpd&archive=&delegate=

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

RE: Fate of 4.14 targets / samsung odroid HC1 support

2020-08-04 Thread mail 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Andre Valentin
> Sent: Dienstag, 4. August 2020 17:48
> To: openwrt-devel@lists.openwrt.org
> Subject: Re: Fate of 4.14 targets / samsung odroid HC1 support
> 
> Hi!
> 
> I've enabled support for the odoid HC1 in the samsung target a month ago, it
> only needs generic 5.4 kernel and is a subtarget.
> https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
> Only open thing is the boodloader on the sdcard, which is a binary for
> hardkernel.

Well, at the moment the main issue is 5.4. If nobody sends 5.4 support for the 
target, it will be dropped.

Everything else can only happen after that.

Best

Adrian

> 
> If there is interest I could send a patch.
> 
> Otherwise I would keep it private.
> 
> Kind regards,
> 
> André
> 
> 
> 
> Am 04.08.20 um 16:43 schrieb m...@adrianschmutzler.de:
> > Hi together,
> >
> > with bcm47xx/bcm53xx bumped to 5.4 now (thanks!), we are left we the
> following targets that (most likely) won't be moved to 5.4 anymore:
> >
> > 4.19: cns3xxx
> > 4.14: ar71xx, at91, ath25, pistachio, rb532, samsung, uml
> >
> > Now, where 20.xx comes closer, I wonder whether we should remove the
> 4.14 targets _before_ branching.
> > Those are already two LTS kernel versions behind, the probability that
> somebody will bump them to an even newer kernel after 20.xx is quite small.
> > Despite, if we drop them before the branch, we only have to drop them
> > once. :-) After having reminded about the situation of the named targets
> several times, I don't think anything will change if we wait any longer with
> this step.
> >
> > The only remaining targets with 4.14 support would be ramips and arc770
> then.
> >
> > Thoughts/opinions?
> >
> > Best
> >
> > Adrian
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >
> 
> 
> --
> Mit freundlichen Grüßen
> André Valentin
> 
> Systemadministration - Projektkoordination
> 
> 
> --
> MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
> Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
> URL: http://www.marcant.net  |
> http://www.global-m2m.com 
> 
> Internet * Netzwerk * Mobile Daten
> 
> Vorstand:
> Thorsten Hojas (Vorsitzender)
> Marc-Henrik Delker
> Dr. Anja-Christina Padberg
> Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238
> 
> 
> 
> __
> _
> Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
> 17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
> gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
> mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
> Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
> Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.
> 
> 
> 


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

Re: Fate of 4.14 targets / samsung odroid HC1 support

2020-08-04 Thread Andre Valentin 
Hi!

I've enabled support for the odoid HC1 in the samsung target a month ago, it 
only needs generic 5.4 kernel and is a subtarget.
https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
Only open thing is the boodloader on the sdcard, which is a binary for 
hardkernel.

If there is interest I could send a patch.

Otherwise I would keep it private.

Kind regards,

André



Am 04.08.20 um 16:43 schrieb m...@adrianschmutzler.de:
> Hi together,
> 
> with bcm47xx/bcm53xx bumped to 5.4 now (thanks!), we are left we the 
> following targets that (most likely) won't be moved to 5.4 anymore:
> 
> 4.19: cns3xxx
> 4.14: ar71xx, at91, ath25, pistachio, rb532, samsung, uml
> 
> Now, where 20.xx comes closer, I wonder whether we should remove the 4.14 
> targets _before_ branching.
> Those are already two LTS kernel versions behind, the probability that 
> somebody will bump them to an even newer kernel after 20.xx is quite small.
> Despite, if we drop them before the branch, we only have to drop them once. 
> :-)
> After having reminded about the situation of the named targets several times, 
> I don't think anything will change if we wait any longer with this step.
> 
> The only remaining targets with 4.14 support would be ramips and arc770 then.
> 
> Thoughts/opinions?
> 
> Best
> 
> Adrian
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 


-- 
Mit freundlichen Grüßen
André Valentin

Systemadministration - Projektkoordination


--
MarcanT AG, Herforder Straße 163a, D - 33609 Bielefeld
Fon: +49 (521) 95945-0 | Fax: +49 (521) 95945-18
URL: http://www.marcant.net  | 
http://www.global-m2m.com 

Internet * Netzwerk * Mobile Daten

Vorstand:
Thorsten Hojas (Vorsitzender)
Marc-Henrik Delker
Dr. Anja-Christina Padberg
Handelsregister: AG Bielefeld, HRB 42260 USt-ID Nr.: DE 190203238



___
Ausserhalb unserer Geschäftszeiten (Montag bis Freitag von 8:30 Uhr bis
17:30 Uhr, ausgenommen gesetzliche Feiertage in NRW) stehen wir Ihnen
gemäß Ihrer jeweiligen Service-Level-Agreements unter der Ihnen
mitgeteilten Telefonnummer für Störungen und Notfälle zur Verfügung.
Sie können natürlich auch gerne jederzeit unter supp...@marcant.net ein
Ticket eröffnen, welches am nächsten Arbeitstag bearbeitet wird.

 




smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: Upcoming 19.07.4 and 18.07.9 stable releases

2020-08-04 Thread mail 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Baptiste Jonglez
> Sent: Donnerstag, 30. Juli 2020 20:58
> To: openwrt-devel@lists.openwrt.org
> Cc: Thomas Endt 
> Subject: Upcoming 19.07.4 and 18.07.9 stable releases
> 
> Hi,
> 
> New point releases for 19.07 and 18.06 are starting to be overdue, and I
> would like to help 19.07.4 and 18.06.9 get released somewhere around mid-
> August.
> 
> The main motivation are fixes for a libubox regression and for the musl
> synchronisation bug, as well as a LuCI regression (see "release goals"
> below).  But there are many other fixes, mostly device-related, that also
> motivate these new point releases.  If you have more fixes to backport,
> please consider doing so soon, especially for 18.06.9 which will likely be the
> last release for 18.06.

In addition to the stated goals, we should also do a kernel bump.
Currently we have 4.14.187 and 4.9.229.


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

Invert wpad selection for mt7621

2020-08-04 Thread mail 
Hi,

for ramips/mt7621, the wpad-basic package is not selected by default, but added 
for every device individually.

While this might be technically correct if the SoC does not come with a Wifi 
module, only 18 of 97 devices for that platform are set up _without_ wpad-basic 
currently.

Therefore, I wonder if it wouldn't be more convenient to add wpad-basic (or 
wpad-basic-wolfssl...) by default for the subtarget and then just remove it 
(-wpad-basic) for the 18 mentioned devices, instead of having to add it for 
about 60 times instead.
This would also match the behavior of the other subtargets, where it is added 
by default anyway.

Opinions?

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

Fate of 4.14 targets

2020-08-04 Thread mail 
Hi together,

with bcm47xx/bcm53xx bumped to 5.4 now (thanks!), we are left we the following 
targets that (most likely) won't be moved to 5.4 anymore:

4.19: cns3xxx
4.14: ar71xx, at91, ath25, pistachio, rb532, samsung, uml

Now, where 20.xx comes closer, I wonder whether we should remove the 4.14 
targets _before_ branching.
Those are already two LTS kernel versions behind, the probability that somebody 
will bump them to an even newer kernel after 20.xx is quite small.
Despite, if we drop them before the branch, we only have to drop them once. :-)
After having reminded about the situation of the named targets several times, I 
don't think anything will change if we wait any longer with this step.

The only remaining targets with 4.14 support would be ramips and arc770 then.

Thoughts/opinions?

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

[PATCH v4 2/2] treewide: use wpad-basic-wolfssl as default

2020-08-04 Thread Adrian Schmutzler 
From: Petr Štetiar 

In order to support SAE/WPA3-Personal in default images. Replaced almost
all occurencies of wpad-basic and wpad-mini with wpad-basic-wolfssl for
consistency. Keeping out ar71xx from the list in order to make the
backports easier.

Signed-off-by: Petr Štetiar 
[rebase]
Signed-off-by: Adrian Schmutzler 
---
 target/linux/apm821xx/image/sata.mk   |   2 +-
 target/linux/apm821xx/nand/target.mk  |   2 +-
 .../apm821xx/sata/profiles/00-default.mk  |   2 +-
 .../arc770/generic/profiles/00-default.mk |   2 +-
 .../archs38/generic/profiles/00-default.mk|   2 +-
 target/linux/ath25/Makefile   |   2 +-
 target/linux/ath79/generic/target.mk  |   2 +-
 target/linux/ath79/image/generic-ubnt.mk  |   2 +-
 target/linux/ath79/image/generic.mk   |   4 +-
 target/linux/ath79/mikrotik/target.mk |   2 +-
 target/linux/ath79/nand/target.mk |   2 +-
 target/linux/ath79/tiny/target.mk |   2 +-
 target/linux/bcm27xx/image/Makefile   |   8 +-
 .../generic/profiles/101-Broadcom-wl.mk   |   2 +-
 .../generic/profiles/105-Broadcom-none.mk |   2 +-
 .../generic/profiles/201-Broadcom-b44-wl.mk   |   2 +-
 .../generic/profiles/205-Broadcom-b44-none.mk |   2 +-
 .../generic/profiles/211-Broadcom-tg3-wl.mk   |   2 +-
 .../generic/profiles/215-Broadcom-tg3-none.mk |   2 +-
 .../generic/profiles/221-Broadcom-bgmac-wl.mk |   2 +-
 .../profiles/225-Broadcom-bgmac-none.mk   |   2 +-
 .../bcm47xx/generic/profiles/PS-1208MFG.mk|   2 +-
 target/linux/bcm47xx/generic/target.mk|   2 +-
 .../legacy/profiles/101-Broadcom-wl.mk|   2 +-
 target/linux/bcm47xx/legacy/target.mk |   2 +-
 .../mips74k/profiles/102-Broadcom-wl.mk   |   2 +-
 .../mips74k/profiles/103-Broadcom-none.mk |   2 +-
 target/linux/bcm47xx/mips74k/target.mk|   2 +-
 target/linux/bcm53xx/image/Makefile   |   2 +-
 target/linux/bcm63xx/image/Makefile   |  10 +-
 target/linux/bcm63xx/profiles/default.mk  |   2 +-
 target/linux/cns3xxx/Makefile |   2 +-
 target/linux/ipq40xx/Makefile |   2 +-
 target/linux/ipq806x/Makefile |   2 +-
 target/linux/kirkwood/image/Makefile  |   4 +-
 target/linux/kirkwood/profiles/00-default.mk  |   2 +-
 target/linux/lantiq/image/ar9.mk  |  18 +--
 target/linux/lantiq/image/danube.mk   |  24 ++--
 target/linux/lantiq/image/tp-link.mk  |   8 +-
 target/linux/lantiq/image/vr9.mk  |  30 ++--
 target/linux/lantiq/image/xway_legacy.mk  |  10 +-
 target/linux/malta/Makefile   |   2 +-
 target/linux/mediatek/mt7622/target.mk|   2 +-
 target/linux/mpc85xx/Makefile |   2 +-
 target/linux/mvebu/image/cortexa9.mk  |   4 +-
 target/linux/omap/profiles/00-default.mk  |   2 +-
 target/linux/oxnas/image/ox820.mk |   2 +-
 target/linux/ramips/image/mt7620.mk   |   2 +-
 target/linux/ramips/image/mt7621.mk   | 128 +-
 target/linux/ramips/mt7620/target.mk  |   2 +-
 target/linux/ramips/mt76x8/target.mk  |   2 +-
 target/linux/ramips/rt288x/target.mk  |   2 +-
 target/linux/ramips/rt305x/target.mk  |   2 +-
 target/linux/ramips/rt3883/target.mk  |   2 +-
 target/linux/rb532/Makefile   |   2 +-
 target/linux/sunxi/image/cortexa7.mk  |   8 +-
 target/linux/sunxi/profiles/00-default.mk |   2 +-
 target/linux/tegra/image/Makefile |   2 +-
 target/linux/uml/Makefile |   2 +-
 59 files changed, 175 insertions(+), 175 deletions(-)

diff --git a/target/linux/apm821xx/image/sata.mk 
b/target/linux/apm821xx/image/sata.mk
index 6fe8324b93..bcb612c22f 100644
--- a/target/linux/apm821xx/image/sata.mk
+++ b/target/linux/apm821xx/image/sata.mk
@@ -6,7 +6,7 @@ endef
 define Device/wd_mybooklive
   DEVICE_VENDOR := Western Digital
   DEVICE_MODEL := My Book Live Series (Single + Duo)
-  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-basic
+  DEVICE_PACKAGES := kmod-usb-dwc2 kmod-usb-ledtrig-usbport kmod-usb-storage 
kmod-fs-vfat wpad-basic-wolfssl
   SUPPORTED_DEVICES += mbl wd,mybooklive-duo
   BLOCKSIZE := 1k
   DTB_SIZE := 16384
diff --git a/target/linux/apm821xx/nand/target.mk 
b/target/linux/apm821xx/nand/target.mk
index 16475307d7..d40b0fbc19 100644
--- a/target/linux/apm821xx/nand/target.mk
+++ b/target/linux/apm821xx/nand/target.mk
@@ -1,7 +1,7 @@
 BOARDNAME:=Devices with NAND flash (Routers)
 FEATURES += nand pcie ramdisk squashfs usb
 
-DEFAULT_PACKAGES += kmod-ath9k swconfig wpad-basic
+DEFAULT_PACKAGES += kmod-ath9k swconfig wpad-basic-wolfssl
 
 define Target/Description
Build firmware images for APM821XX boards with NAND flash.
diff --git a/target/linux/apm821xx/sata/profiles/00-default.mk 
b/target/linux/apm821xx/sata/profiles/00-default.

[PATCH v4 1/2] hostapd: add wpad-basic-wolfssl variant

2020-08-04 Thread Adrian Schmutzler 
From: Petr Štetiar 

Add package which provides size optimized wpad with support for just
WPA-PSK, SAE (WPA3-Personal), 802.11r and 802.11w.

Signed-off-by: Petr Štetiar 
[adapt to recent changes, add dependency for WPA_WOLFSSL config]
Signed-off-by: Adrian Schmutzler 
---
 include/target.mk  |  2 +-
 package/network/services/hostapd/Config.in |  3 +++
 package/network/services/hostapd/Makefile  | 13 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/include/target.mk b/include/target.mk
index aba477e83b..6ed6565bda 100644
--- a/include/target.mk
+++ b/include/target.mk
@@ -56,7 +56,7 @@ endif
 DEFAULT_PACKAGES += $(DEFAULT_PACKAGES.$(DEVICE_TYPE))
 
 filter_packages = $(filter-out -% $(patsubst -%,%,$(filter -%,$(1))),$(1))
-extra_packages = $(if $(filter wpad-mini wpad-basic wpad nas,$(1)),iwinfo)
+extra_packages = $(if $(filter wpad-mini wpad-basic wpad-basic-wolfssl wpad 
nas,$(1)),iwinfo)
 
 define ProfileDefault
   NAME:=
diff --git a/package/network/services/hostapd/Config.in 
b/package/network/services/hostapd/Config.in
index 81a374c652..b211877fb3 100644
--- a/package/network/services/hostapd/Config.in
+++ b/package/network/services/hostapd/Config.in
@@ -13,6 +13,7 @@ config WPA_RFKILL_SUPPORT
   PACKAGE_wpad-openssl || \
   PACKAGE_wpad-wolfssl || \
   PACKAGE_wpad-basic || \
+  PACKAGE_wpad-basic-wolfssl || \
   PACKAGE_wpad-mini || \
   PACKAGE_wpad-mesh-openssl || \
   PACKAGE_wpad-mesh-wolfssl
@@ -32,6 +33,7 @@ config WPA_MSG_MIN_PRIORITY
   PACKAGE_wpad-openssl || \
   PACKAGE_wpad-wolfssl || \
   PACKAGE_wpad-basic || \
+  PACKAGE_wpad-basic-wolfssl || \
   PACKAGE_wpad-mini || \
   PACKAGE_wpad-mesh-openssl || \
   PACKAGE_wpad-mesh-wolfssl
@@ -49,6 +51,7 @@ config WPA_WOLFSSL
bool
default PACKAGE_wpa-supplicant-wolfssl ||\
PACKAGE_wpad-wolfssl ||\
+   PACKAGE_wpad-basic-wolfssl || \
PACKAGE_wpad-mesh-wolfssl ||\
PACKAGE_eapol-test-wolfssl
select WOLFSSL_HAS_AES_CCM
diff --git a/package/network/services/hostapd/Makefile 
b/package/network/services/hostapd/Makefile
index 44312db590..b3e93cb770 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -250,6 +250,17 @@ define Package/wpad-basic/description
  This package contains a basic IEEE 802.1x/WPA Authenticator and Supplicant 
with WPA-PSK, 802.11r and 802.11w support.
 endef
 
+define Package/wpad-basic-wolfssl
+$(call Package/wpad/Default,$(1))
+  TITLE+= (wolfSSL, 11r, 11w)
+  VARIANT:=wpad-basic-wolfssl
+  DEPENDS+=+libwolfssl
+endef
+
+define Package/wpad-basic-wolfssl/description
+ This package contains a basic IEEE 802.1x/WPA Authenticator and Supplicant 
with WPA-PSK, SAE (WPA3-Personal), 802.11r and 802.11w support.
+endef
+
 define Package/wpad-mini
 $(call Package/wpad/Default,$(1))
   TITLE+= (WPA-PSK only)
@@ -575,6 +586,7 @@ define Package/wpad/install
$(LN) wpad $(1)/usr/sbin/wpa_supplicant
 endef
 Package/wpad-basic/install = $(Package/wpad/install)
+Package/wpad-basic-wolfssl/install = $(Package/wpad/install)
 Package/wpad-mini/install = $(Package/wpad/install)
 Package/wpad-openssl/install = $(Package/wpad/install)
 Package/wpad-wolfssl/install = $(Package/wpad/install)
@@ -630,6 +642,7 @@ $(eval $(call BuildPackage,wpad))
 $(eval $(call BuildPackage,wpad-mesh-openssl))
 $(eval $(call BuildPackage,wpad-mesh-wolfssl))
 $(eval $(call BuildPackage,wpad-basic))
+$(eval $(call BuildPackage,wpad-basic-wolfssl))
 $(eval $(call BuildPackage,wpad-mini))
 $(eval $(call BuildPackage,wpad-openssl))
 $(eval $(call BuildPackage,wpad-wolfssl))
-- 
2.20.1


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

[PATCH] bcm53xx: use vendor_model scheme for device/image names

2020-08-04 Thread Adrian Schmutzler 
Most targets have been updated to consistently use the vendor_model
scheme for device definitions and thus, image names.

Apply this to bcm53xx as well. This does _not_ apply any other
specific naming changes.

Cc: Rafał Miłecki 
Signed-off-by: Adrian Schmutzler 
---
 target/linux/bcm53xx/image/Makefile | 114 ++--
 1 file changed, 57 insertions(+), 57 deletions(-)

diff --git a/target/linux/bcm53xx/image/Makefile 
b/target/linux/bcm53xx/image/Makefile
index a117e02a45..c490192b8a 100644
--- a/target/linux/bcm53xx/image/Makefile
+++ b/target/linux/bcm53xx/image/Makefile
@@ -125,7 +125,7 @@ USB3_PACKAGES := $(USB2_PACKAGES) kmod-usb3 
kmod-phy-bcm-ns-usb3
 define Device/Default
   # .dtb files are prefixed by SoC type, e.g. bcm4708- which is not included 
in device/image names
   # extract the full dtb name based on the device info
-  DEVICE_DTS := $(patsubst %.dtb,%,$(notdir $(wildcard $(if 
$(IB),$(KDIR),$(DTS_DIR))/*-$(1).dtb)))
+  DEVICE_DTS := $(patsubst %.dtb,%,$(notdir $(wildcard $(if 
$(IB),$(KDIR),$(DTS_DIR))/*-$(subst _,-,$(1)).dtb)))
   KERNEL := kernel-bin | append-dtb | lzma-d16
   KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts)
   KERNEL_INITRAMFS_SUFFIX := .trx
@@ -145,37 +145,37 @@ define Device/asus
   IMAGE/trx := append-ubi | trx-nand | asus-trx
 endef
 
-define Device/asus-rt-ac56u
+define Device/asus_rt-ac56u
   $(call Device/asus)
   DEVICE_MODEL := RT-AC56U
   DEVICE_PACKAGES := $(B43) $(USB3_PACKAGES)
   ASUS_PRODUCTID := RT-AC56U
 endef
-TARGET_DEVICES += asus-rt-ac56u
+TARGET_DEVICES += asus_rt-ac56u
 
-define Device/asus-rt-ac68u
+define Device/asus_rt-ac68u
   $(call Device/asus)
   DEVICE_MODEL := RT-AC68U
   DEVICE_PACKAGES := $(USB3_PACKAGES)
   ASUS_PRODUCTID := RT-AC68U
 endef
-TARGET_DEVICES += asus-rt-ac68u
+TARGET_DEVICES += asus_rt-ac68u
 
-define Device/asus-rt-ac87u
+define Device/asus_rt-ac87u
   $(call Device/asus)
   DEVICE_MODEL := RT-AC87U
   DEVICE_PACKAGES := $(USB3_PACKAGES)
   ASUS_PRODUCTID := RT-AC87U
 endef
-TARGET_DEVICES += asus-rt-ac87u
+TARGET_DEVICES += asus_rt-ac87u
 
-define Device/asus-rt-n18u
+define Device/asus_rt-n18u
   $(call Device/asus)
   DEVICE_MODEL := RT-N18U
   DEVICE_PACKAGES := $(USB3_PACKAGES)
   ASUS_PRODUCTID := RT-N18U
 endef
-TARGET_DEVICES += asus-rt-n18u
+TARGET_DEVICES += asus_rt-n18u
 
 # Buffalo devices have TFTP recovery mode which can work nicely with initramfs
 # kernels.
@@ -188,21 +188,21 @@ define Device/buffalo/Default
   KERNEL_INITRAMFS = $$(KERNEL)
 endef
 
-define Device/buffalo-wxr-1900dhp
+define Device/buffalo_wxr-1900dhp
   $(call Device/buffalo/Default)
   DEVICE_MODEL := WXR-1900DHP
   DEVICE_PACKAGES := $(USB3_PACKAGES)
 endef
-TARGET_DEVICES += buffalo-wxr-1900dhp
+TARGET_DEVICES += buffalo_wxr-1900dhp
 
-define Device/buffalo-wzr-600dhp2
+define Device/buffalo_wzr-600dhp2
   $(call Device/buffalo/Default)
   DEVICE_MODEL := WZR-600DHP2
   DEVICE_PACKAGES := $(B43) $(USB2_PACKAGES)
 endef
-TARGET_DEVICES += buffalo-wzr-600dhp2
+TARGET_DEVICES += buffalo_wzr-600dhp2
 
-define Device/buffalo-wzr-900dhp
+define Device/buffalo_wzr-900dhp
   $(call Device/buffalo/Default)
   DEVICE_MODEL := WZR-900DHP
   DEVICE_PACKAGES := $(B43) $(USB3_PACKAGES)
@@ -221,14 +221,14 @@ define Device/buffalo-wzr-900dhp
buffalo-tag-dhp WZR-900DHP2 JP jp | buffalo-enc-tag | \
buffalo-dhp-image
 endef
-TARGET_DEVICES += buffalo-wzr-900dhp
+TARGET_DEVICES += buffalo_wzr-900dhp
 
-define Device/buffalo-wzr-1750dhp
+define Device/buffalo_wzr-1750dhp
   $(call Device/buffalo/Default)
   DEVICE_MODEL := WZR-1750DHP
   DEVICE_PACKAGES := $(B43) $(USB3_PACKAGES)
 endef
-TARGET_DEVICES += buffalo-wzr-1750dhp
+TARGET_DEVICES += buffalo_wzr-1750dhp
 
 define Device/dlink
   DEVICE_VENDOR := D-Link
@@ -236,49 +236,49 @@ define Device/dlink
   IMAGE/bin := append-ubi | seama-nand
 endef
 
-define Device/dlink-dir-885l
+define Device/dlink_dir-885l
   DEVICE_MODEL := DIR-885L
   DEVICE_PACKAGES := $(BRCMFMAC_4366B1) $(USB3_PACKAGES)
   $(Device/dlink)
   SIGNATURE := wrgac42_dlink.2015_dir885l
 endef
-TARGET_DEVICES += dlink-dir-885l
+TARGET_DEVICES += dlink_dir-885l
 
 # Linksys devices are disabled due to problem with 2 TRX partitions
-define Device/linksys-ea6300-v1
+define Device/linksys_ea6300-v1
   DEVICE_VENDOR := Linksys
   DEVICE_MODEL := EA6300
   DEVICE_VARIANT := v1
   DEVICE_PACKAGES := $(B43) $(USB3_PACKAGES)
   BROKEN := y
 endef
-TARGET_DEVICES += linksys-ea6300-v1
+TARGET_DEVICES += linksys_ea6300-v1
 
-define Device/linksys-ea6500-v2
+define Device/linksys_ea6500-v2
   DEVICE_VENDOR := Linksys
   DEVICE_MODEL := EA6500
   DEVICE_VARIANT := v2
   DEVICE_PACKAGES := $(B43) $(USB3_PACKAGES)
 endef
-TARGET_DEVICES += linksys-ea6500-v2
+TARGET_DEVICES += linksys_ea6500-v2
 
-define Device/linksys-ea9200
+define Device/linksys_ea9200
   DEVICE_VENDOR := Linksys
   DEVICE_MODEL := EA9200
   DEVICE_VARIANT := v1
   DEVICE_PACKAGES := $(BRCMFMAC_43602A1) $(USB3_PACKAGES)
   BROKEN := y

Trouble with continuous link changes on the WAN port

2020-08-04 Thread pep3ts 

Hi,

I have a TP-Link TL-WR841N v13 with OpenWrt 19.07.3 connected to a HP 
switch trough the WAN port.

Very often there is the following trouble:


Tue Aug  4 14:35:52 2020 kern.info kernel: [ 5603.569886] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:35:54 2020 kern.info kernel: [ 5605.242987] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:35:54 2020 kern.info kernel: [ 5606.026566] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:35:56 2020 kern.info kernel: [ 5607.928938] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:35:58 2020 kern.info kernel: [ 5609.562730] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:30 2020 kern.info kernel: [ 5641.559235] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:32 2020 kern.info kernel: [ 5643.224169] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:33 2020 kern.info kernel: [ 5644.300661] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:34 2020 kern.info kernel: [ 5645.995625] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:36 2020 kern.info kernel: [ 5647.297871] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:37 2020 kern.info kernel: [ 5648.979818] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:37 2020 kern.info kernel: [ 5649.044793] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:41 2020 kern.info kernel: [ 5653.085291] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:44 2020 kern.info kernel: [ 5656.024048] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:46 2020 kern.info kernel: [ 5657.865833] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:46 2020 kern.info kernel: [ 5658.021050] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:48 2020 kern.info kernel: [ 5659.763305] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:50 2020 kern.info kernel: [ 5661.419369] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:50 2020 kern.info kernel: [ 5661.571592] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:52 2020 kern.info kernel: [ 5663.319914] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:36:52 2020 kern.info kernel: [ 5663.479754] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:36:56 2020 kern.info kernel: [ 5667.610474] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:37:09 2020 kern.info kernel: [ 5681.086312] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:37:14 2020 kern.info kernel: [ 5685.286249] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:39:36 2020 kern.info kernel: [ 5827.592833] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:39:38 2020 kern.info kernel: [ 5829.192294] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:44:26 2020 kern.info kernel: [ 6117.927355] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:44:28 2020 kern.info kernel: [ 6119.554914] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:44:37 2020 kern.info kernel: [ 6128.452988] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:44:38 2020 kern.info kernel: [ 6130.132320] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:45:01 2020 kern.info kernel: [ 6152.344435] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:45:02 2020 kern.info kernel: [ 6153.991008] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:45:02 2020 kern.info kernel: [ 6154.040795] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:45:04 2020 kern.info kernel: [ 6155.677027] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:45:08 2020 kern.info kernel: [ 6159.691580] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:45:10 2020 kern.info kernel: [ 6161.320033] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:45:18 2020 kern.info kernel: [ 6169.735283] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:45:20 2020 kern.info kernel: [ 6171.424353] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:57:44 2020 kern.info kernel: [ 6916.159492] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:57:46 2020 kern.info kernel: [ 6917.781587] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:58:23 2020 kern.info kernel: [ 6955.072411] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:58:27 2020 kern.info kernel: [ 6959.163475] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:59:05 2020 kern.info kernel: [ 6996.673298] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:59:07 2020 kern.info kernel: [ 6998.362964] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:59:07 2020 kern.info kernel: [ 6998.775681] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:59:09 2020 kern.info kernel: [ 7000.472146] rt3050-esw 
1011.esw: link changed 0x11
Tue Aug  4 14:59:09 2020 kern.info kernel: [ 7000.488117] rt3050-esw 
1011.esw: link changed 0x10
Tue Aug  4 14:59:10 2020 kern.info kernel: [ 7002.1533

[PATCH 1/2] mediatek: mt7623n-preloader: add preloader for Banana Pi R64

2020-08-04 Thread David Woodhouse 
We want to be able to make full system images for this system too, just
as we now can for the MT7623 platforms.

The package directory (mt7623n) is now a bit misnamed as it's overly
specific, but the precise set of platforms which we support this way
is evolving and we'll fix it up when the dust settles and we know what
nomenclature makes most sense.

Signed-off-by: David Woodhouse 
---
 package/boot/mt7623n-preloader/Makefile | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/package/boot/mt7623n-preloader/Makefile 
b/package/boot/mt7623n-preloader/Makefile
index 801c6d19b3..0faaf46d3f 100644
--- a/package/boot/mt7623n-preloader/Makefile
+++ b/package/boot/mt7623n-preloader/Makefile
@@ -30,6 +30,14 @@ define Download/BPI-R2-preloader-2k.img.gz
 endef
 $(eval $(call Download,BPI-R2-preloader-2k.img.gz))
 
+define Download/BPI-R64-preloader-2k.img.gz
+  FILE:=$(BPI_PRELOADER_PREFIX)-BPI-R64-preloader-2k.img.gz
+  URL:=$(BPI_PRELOADER_URL)
+  URL_FILE:=BPI-R64-preloader-2k.img.gz
+  HASH:=1a4b55da1717190aa4e790ce93850605e9b15aae4c3248bcf8734aac020ab0e4
+endef
+$(eval $(call Download,BPI-R64-preloader-2k.img.gz))
+
 
 define Package/mt7623n-preloader
   SECTION:=boot
@@ -43,10 +51,23 @@ define Package/mt7623n-preloader/description
   Preloader image for mt7623n based boards like Banana Pi R2.
 endef
 
+define Package/mt7622-preloader
+  SECTION:=boot
+  CATEGORY:=Boot Loaders
+  DEPENDS:=@TARGET_mediatek_mt7622
+  TITLE:=mt7622-preloader
+  DEFAULT:=y if TARGET_mediatek
+endef
+
+define Package/mt7622-preloader/description
+  Preloader image for mt7622 based boards like Banana Pi R64.
+endef
+
 define Build/Prepare
rm -rf $(PKG_BUILD_DIR)
mkdir -p $(PKG_BUILD_DIR)
cp 
$(DL_DIR)/$(BPI_PRELOADER_PREFIX)-BPI-R2-preloader-DDR1600-20191024-2k.img.gz 
$(PKG_BUILD_DIR)/mt7623n_bpir2-preloader.bin.gz
+   cp $(DL_DIR)/$(BPI_PRELOADER_PREFIX)-BPI-R64-preloader-2k.img.gz 
$(PKG_BUILD_DIR)/mt7622_bpir64-preloader.bin.gz
 endef
 
 define Build/Compile
@@ -59,3 +80,4 @@ define Build/InstallDev
 endef
 
 $(eval $(call BuildPackage,mt7623n-preloader))
+$(eval $(call BuildPackage,mt7622-preloader))
-- 
2.26.2


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

[PATCH 2/2] uboot-mediatek: resync patches with upstream

2020-08-04 Thread David Woodhouse 
Now that my patches have been merged into upstream U-Boot, resync the
cosmetic changes and the commit IDs from the final commits.

Signed-off-by: David Woodhouse 
---
 .../patches/006-mt7623-pinctrl-fix.patch  |  7 ++--
 .../patches/007-env-fat-use-bootdevice.patch  | 35 ---
 ...ix-mmc_get_boot_dev-for-platforms-wi.patch |  4 +--
 ...-Add-support-for-UniElec-U7623-board.patch | 26 +++---
 4 files changed, 49 insertions(+), 23 deletions(-)

diff --git a/package/boot/uboot-mediatek/patches/006-mt7623-pinctrl-fix.patch 
b/package/boot/uboot-mediatek/patches/006-mt7623-pinctrl-fix.patch
index c5a0cb9c6d..2e50717b72 100644
--- a/package/boot/uboot-mediatek/patches/006-mt7623-pinctrl-fix.patch
+++ b/package/boot/uboot-mediatek/patches/006-mt7623-pinctrl-fix.patch
@@ -1,6 +1,6 @@
-From eca387ea507bde160558a0e5301bf2e0f1985b3b Mon Sep 17 00:00:00 2001
+From e05fdd93645dab2217bb5bfabcc04845415cf7ed Mon Sep 17 00:00:00 2001
 From: David Woodhouse 
-Date: Fri, 19 Jun 2020 11:34:32 +0100
+Date: Fri, 19 Jun 2020 12:40:20 +0100
 Subject: [PATCH] pinctrl: mediatek: add PUPD/R0/R1 support for MT7623
 
 The pins for the MMC controller weren't being set up correctly because the
@@ -8,6 +8,7 @@ pinctrl driver only sets the GPIO pullup/pulldown config and 
doesn't
 handle the special cases with PUPD/R0/R1 control.
 
 Signed-off-by: David Woodhouse 
+Tested-by: Frank Wunderlich 
 ---
  drivers/pinctrl/mediatek/pinctrl-mt7623.c | 129 ++
  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |  19 ++-
@@ -162,7 +163,7 @@ index d58d840e08..0f5dcb2c63 100644
  
  static const struct mtk_pin_desc mt7623_pins[] = {
 diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
-index 5fdc150295..f5199fc574 100644
+index e8187a3780..6553dde45c 100644
 --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
 +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
 @@ -296,7 +296,7 @@ static const struct pinconf_param mtk_conf_params[] = {
diff --git 
a/package/boot/uboot-mediatek/patches/007-env-fat-use-bootdevice.patch 
b/package/boot/uboot-mediatek/patches/007-env-fat-use-bootdevice.patch
index 20b6620d71..a0236785d0 100644
--- a/package/boot/uboot-mediatek/patches/007-env-fat-use-bootdevice.patch
+++ b/package/boot/uboot-mediatek/patches/007-env-fat-use-bootdevice.patch
@@ -1,22 +1,28 @@
-From fb2810b2c7209d4ed690e48e5bffa52d1af2eda3 Mon Sep 17 00:00:00 2001
+From 6731bef6966ea2b26cdcfe0109ff5a950003fd03 Mon Sep 17 00:00:00 2001
 From: David Woodhouse 
-Date: Fri, 19 Jun 2020 22:57:04 +0100
+Date: Fri, 19 Jun 2020 23:07:17 +0100
 Subject: [PATCH] env/fat.c: allow loading from a FAT partition on the MMC boot
  device
 
 I don't want to have to specify the device; only the partition.
 
+This allows me to use the same image on internal eMMC or SD card for
+Banana Pi R2, and it finds its own environment either way.
+
 Signed-off-by: David Woodhouse 
+[trini: Add #if/#else/#endif logic around CONFIG_SYS_MMC_ENV_DEV usage,
+whitespace changes]
+Signed-off-by: Tom Rini 
 ---
  env/Kconfig |  4 
- env/fat.c   | 31 +--
- 2 files changed, 33 insertions(+), 2 deletions(-)
+ env/fat.c   | 32 ++--
+ 2 files changed, 34 insertions(+), 2 deletions(-)
 
 diff --git a/env/Kconfig b/env/Kconfig
-index 0d6f559b39..a2020a8661 100644
+index 38e7fadbb9..5784136674 100644
 --- a/env/Kconfig
 +++ b/env/Kconfig
-@@ -432,6 +432,10 @@ config ENV_FAT_DEVICE_AND_PART
+@@ -434,6 +434,10 @@ config ENV_FAT_DEVICE_AND_PART
   If none, first valid partition in device D. If no
   partition table then means device D.
  
@@ -28,17 +34,21 @@ index 0d6f559b39..a2020a8661 100644
string "Name of the FAT file to use for the environment"
depends on ENV_IS_IN_FAT
 diff --git a/env/fat.c b/env/fat.c
-index 1836556f36..1c32d17bd5 100644
+index 35a1955e63..63aced9317 100644
 --- a/env/fat.c
 +++ b/env/fat.c
-@@ -31,6 +31,33 @@
+@@ -29,6 +29,36 @@
  # endif
  #endif
  
 +#if defined(CMD_SAVEENV) || defined(CMD_LOADENV)
 +__weak int mmc_get_env_dev(void)
 +{
-+return CONFIG_SYS_MMC_ENV_DEV;
++#ifdef CONFIG_SYS_MMC_ENV_DEV
++  return CONFIG_SYS_MMC_ENV_DEV;
++#else
++  return 0;
++#endif
 +}
 +
 +static char *env_fat_device_and_part(void)
@@ -48,8 +58,7 @@ index 1836556f36..1c32d17bd5 100644
 +
 +  if (!part_str) {
 +  part_str = CONFIG_ENV_FAT_DEVICE_AND_PART;
-+  if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc")
-+  && part_str[0] == ':') {
++  if (!strcmp(CONFIG_ENV_FAT_INTERFACE, "mmc") && part_str[0] == 
':') {
 +  part_str = "0" CONFIG_ENV_FAT_DEVICE_AND_PART;
 +  part_str[0] += mmc_get_env_dev();
 +  }
@@ -65,7 +74,7 @@ index 1836556f36..1c32d17bd5 100644
  #ifdef CMD_SAVEENV
  static int env_fat_save(void)
  {
-@@ -46,7 +73,7 @@ static int env_fat_s

Re: [PATCH v2] busybox: fix fwmark and add fwmask support to ip rule

2020-08-04 Thread Paul Spooren 

Hi Rui,

On 03.08.20 22:14, Rui Salvaterra wrote:

BusyBox ip (rule) applet supports fwmark for policy routing (albeit through the
old and deprecated RTA_PROTOINFO message attribute), but fwmask is completely
unsupported. For this reason, mwan3 depends on ip(-tiny), which compiles to
over 280 kiB on MIPS32 (-mips16 -mtune=74kc -O2).

This pending [1] BusyBox patch modernises the fwmark implementation (using the
FRA_FWMARK attribute) and also implements fwmask (FRA_FWMASK) required by mwan3,
allowing it to drop its dependecy on ip.

Other potential candidates for dropping their ip dependency (relying only on
BusyBox ip) are shadowsocks-libev, strongswan and vpn-policy-routing.

[1] http://lists.busybox.net/pipermail/busybox/2020-July/088164.html

Signed-off-by: Rui Salvaterra 


Not run-time tested but seem to compile fine on multiple architectures!

Size increase is between 70-140B[1].

What do you think about the PROVIDES idea of Yousong?

[1]: https://gitlab.com/aparcar/openwrt/-/jobs/669753470


---
  package/utils/busybox/Makefile|  2 +-
  .../302-ip-rule-add-support-for-fwmask.patch  | 90 +++
  2 files changed, 91 insertions(+), 1 deletion(-)
  create mode 100644 
package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch

diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile
index 01441d1e87..baf375eb13 100644
--- a/package/utils/busybox/Makefile
+++ b/package/utils/busybox/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
  
  PKG_NAME:=busybox

  PKG_VERSION:=1.31.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
  PKG_FLAGS:=essential
  
  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2

diff --git 
a/package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch 
b/package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch
new file mode 100644
index 00..abdc309068
--- /dev/null
+++ b/package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch
@@ -0,0 +1,90 @@
+From f06ac1e49b4a5a57660c7b370a7ebd436981bd89 Mon Sep 17 00:00:00 2001
+From: Rui Salvaterra 
+Date: Fri, 31 Jul 2020 09:59:40 +0100
+Subject: [PATCH] ip rule: add support for fwmark/fwmask for policy routing
+
+This adds support for fwmark/fwmask in ip rule which is needed, for example, in
+OpenWrt's mwan3. Masks are supported since Linux 2.6.19.
+
+Fixes: https://bugs.busybox.net/show_bug.cgi?id=11621
+
+Signed-off-by: Rui Salvaterra 
+---
+ networking/ip.c|  2 +-
+ networking/libiproute/iprule.c | 31 +--
+ 2 files changed, 26 insertions(+), 7 deletions(-)
+
+diff --git a/networking/ip.c b/networking/ip.c
+index 034ee4fc8..bade93e62 100644
+--- a/networking/ip.c
 b/networking/ip.c
+@@ -257,7 +257,7 @@
+ //usage:#define iprule_trivial_usage
+ //usage:   "[list] | add|del SELECTOR ACTION"
+ //usage:#define iprule_full_usage "\n\n"
+-//usage:   " SELECTOR := [from PREFIX] [to PREFIX] [tos TOS] [fwmark 
FWMARK]\n"
++//usage:   " SELECTOR := [from PREFIX] [to PREFIX] [tos TOS] [fwmark 
FWMARK[/MASK] ]\n"
+ //usage:   " [dev IFACE] [pref NUMBER]\n"
+ //usage:   " ACTION := [table TABLE_ID] [nat ADDR]\n"
+ //usage:   " [prohibit|reject|unreachable]\n"
+diff --git a/networking/libiproute/iprule.c b/networking/libiproute/iprule.c
+index 0ce0dfeef..40a09a4ab 100644
+--- a/networking/libiproute/iprule.c
 b/networking/libiproute/iprule.c
+@@ -17,8 +17,10 @@
+ #include 
+
+ /* from : */
+-#define FRA_SUPPRESS_IFGROUP   13
+-#define FRA_SUPPRESS_PREFIXLEN 14
++#define FRA_FWMARK10
++#define FRA_SUPPRESS_IFGROUP  13
++#define FRA_SUPPRESS_PREFIXLEN14
++#define FRA_FWMASK16
+
+ #include "ip_common.h"  /* #include "libbb.h" is inside */
+ #include "rt_names.h"
+@@ -117,8 +119,18 @@ static int FAST_FUNC print_rule(const struct sockaddr_nl 
*who UNUSED_PARAM,
+   if (r->rtm_tos) {
+   printf("tos %s ", rtnl_dsfield_n2a(r->rtm_tos));
+   }
+-  if (tb[RTA_PROTOINFO]) {
+-  printf("fwmark %#x ", *(uint32_t*)RTA_DATA(tb[RTA_PROTOINFO]));
++
++  if (tb[FRA_FWMARK] || tb[FRA_FWMASK]) {
++  uint32_t mark = 0, mask = 0;
++
++  if (tb[FRA_FWMARK])
++  mark = *(uint32_t*)RTA_DATA(tb[FRA_FWMARK]);
++
++  if (tb[FRA_FWMASK] &&
++  (mask = *(uint32_t*)RTA_DATA(tb[FRA_FWMASK])) != 0x)
++  printf("fwmark %#x/%#x ", mark, mask);
++  else
++  printf("fwmark %#x ", mark);
+   }
+
+   if (tb[RTA_IIF]) {
+@@ -257,10 +269,17 @@ static int iprule_modify(int cmd, char **argv)
+   invarg_1_to_2(*argv, "TOS");
+   req.r.rtm_tos = tos;
+   } else if (key == ARG_fwmark) {
+-  uint32_t fwmark;
++  char *slash;
++  uint32_t fwmark, fwmask;
+

[PATCH v2] busybox: fix fwmark and add fwmask support to ip rule

2020-08-04 Thread Rui Salvaterra 
BusyBox ip (rule) applet supports fwmark for policy routing (albeit through the
old and deprecated RTA_PROTOINFO message attribute), but fwmask is completely
unsupported. For this reason, mwan3 depends on ip(-tiny), which compiles to
over 280 kiB on MIPS32 (-mips16 -mtune=74kc -O2).

This pending [1] BusyBox patch modernises the fwmark implementation (using the
FRA_FWMARK attribute) and also implements fwmask (FRA_FWMASK) required by mwan3,
allowing it to drop its dependecy on ip.

Other potential candidates for dropping their ip dependency (relying only on
BusyBox ip) are shadowsocks-libev, strongswan and vpn-policy-routing.

[1] http://lists.busybox.net/pipermail/busybox/2020-July/088164.html

Signed-off-by: Rui Salvaterra 
---
 package/utils/busybox/Makefile|  2 +-
 .../302-ip-rule-add-support-for-fwmask.patch  | 90 +++
 2 files changed, 91 insertions(+), 1 deletion(-)
 create mode 100644 
package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch

diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile
index 01441d1e87..baf375eb13 100644
--- a/package/utils/busybox/Makefile
+++ b/package/utils/busybox/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=busybox
 PKG_VERSION:=1.31.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 PKG_FLAGS:=essential
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
diff --git 
a/package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch 
b/package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch
new file mode 100644
index 00..abdc309068
--- /dev/null
+++ b/package/utils/busybox/patches/302-ip-rule-add-support-for-fwmask.patch
@@ -0,0 +1,90 @@
+From f06ac1e49b4a5a57660c7b370a7ebd436981bd89 Mon Sep 17 00:00:00 2001
+From: Rui Salvaterra 
+Date: Fri, 31 Jul 2020 09:59:40 +0100
+Subject: [PATCH] ip rule: add support for fwmark/fwmask for policy routing
+
+This adds support for fwmark/fwmask in ip rule which is needed, for example, in
+OpenWrt's mwan3. Masks are supported since Linux 2.6.19.
+
+Fixes: https://bugs.busybox.net/show_bug.cgi?id=11621
+
+Signed-off-by: Rui Salvaterra 
+---
+ networking/ip.c|  2 +-
+ networking/libiproute/iprule.c | 31 +--
+ 2 files changed, 26 insertions(+), 7 deletions(-)
+
+diff --git a/networking/ip.c b/networking/ip.c
+index 034ee4fc8..bade93e62 100644
+--- a/networking/ip.c
 b/networking/ip.c
+@@ -257,7 +257,7 @@
+ //usage:#define iprule_trivial_usage
+ //usage:   "[list] | add|del SELECTOR ACTION"
+ //usage:#define iprule_full_usage "\n\n"
+-//usage:   "  SELECTOR := [from PREFIX] [to PREFIX] [tos TOS] [fwmark 
FWMARK]\n"
++//usage:   "  SELECTOR := [from PREFIX] [to PREFIX] [tos TOS] [fwmark 
FWMARK[/MASK] ]\n"
+ //usage:   "  [dev IFACE] [pref NUMBER]\n"
+ //usage:   "  ACTION := [table TABLE_ID] [nat ADDR]\n"
+ //usage:   "  [prohibit|reject|unreachable]\n"
+diff --git a/networking/libiproute/iprule.c b/networking/libiproute/iprule.c
+index 0ce0dfeef..40a09a4ab 100644
+--- a/networking/libiproute/iprule.c
 b/networking/libiproute/iprule.c
+@@ -17,8 +17,10 @@
+ #include 
+ 
+ /* from : */
+-#define FRA_SUPPRESS_IFGROUP   13
+-#define FRA_SUPPRESS_PREFIXLEN 14
++#define FRA_FWMARK10
++#define FRA_SUPPRESS_IFGROUP  13
++#define FRA_SUPPRESS_PREFIXLEN14
++#define FRA_FWMASK16
+ 
+ #include "ip_common.h"  /* #include "libbb.h" is inside */
+ #include "rt_names.h"
+@@ -117,8 +119,18 @@ static int FAST_FUNC print_rule(const struct sockaddr_nl 
*who UNUSED_PARAM,
+   if (r->rtm_tos) {
+   printf("tos %s ", rtnl_dsfield_n2a(r->rtm_tos));
+   }
+-  if (tb[RTA_PROTOINFO]) {
+-  printf("fwmark %#x ", *(uint32_t*)RTA_DATA(tb[RTA_PROTOINFO]));
++
++  if (tb[FRA_FWMARK] || tb[FRA_FWMASK]) {
++  uint32_t mark = 0, mask = 0;
++
++  if (tb[FRA_FWMARK])
++  mark = *(uint32_t*)RTA_DATA(tb[FRA_FWMARK]);
++
++  if (tb[FRA_FWMASK] &&
++  (mask = *(uint32_t*)RTA_DATA(tb[FRA_FWMASK])) != 0x)
++  printf("fwmark %#x/%#x ", mark, mask);
++  else
++  printf("fwmark %#x ", mark);
+   }
+ 
+   if (tb[RTA_IIF]) {
+@@ -257,10 +269,17 @@ static int iprule_modify(int cmd, char **argv)
+   invarg_1_to_2(*argv, "TOS");
+   req.r.rtm_tos = tos;
+   } else if (key == ARG_fwmark) {
+-  uint32_t fwmark;
++  char *slash;
++  uint32_t fwmark, fwmask;
+   NEXT_ARG();
++  if ((slash = strchr(*argv, '/')) != NULL)
++  *slash = '\0';
+   fwmark = get_u32(*argv, keyword_fwmark);
+-  addattr32(&req.n, sizeof(req), RTA_PROTOINFO, fwm

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

2020-08-04 Thread Jo-Philipp Wich 
Hi,

> Regarding parsing events stream, event names with spaces seem to be OK:
> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream

To me it feels quirky to separate the path and the type of the event by space.

Personally I'd only report the type as "event:" and move the source path into
the JSON data portion, or even omit it entirely.

Considering the design of the client side API:

   eventSource.addEventListener(type, handler);

Most use-cases probably want to register a handler for a specific event type,
e.g. "status", and not N handlers to handle the different object path
variations, so given the subscribe examples in the previous mail:

   eventSource.addEventListener("status", (ev) => { ... })

instead of

   eventSource.addEventListener("hostapd.wlan0 status", (ev) => { ... })
   eventSource.addEventListener("hostapd.wlan0-1 status", (ev) => { ... })
   eventSource.addEventListener("hostapd.wlan1 status", (ev) => { ... })
   eventSource.addEventListener("hostapd.wlan1-1 status", (ev) => { ... })


Granted, one could use the `onmessage` event to implement a catch-all handler
which is then filtering and dispatching according to the type, but even then
string operations like split(), indexOf(), regex matches or similar would be
required to match event types, that feels unelegant and not very performant.


~ Jo



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

Re: [PATCH V2 uhttpd] ubus: add new RESTful API

2020-08-04 Thread Andre Valentin 
Hi!

Am 03.08.20 um 07:49 schrieb Rafał Miłecki:
> On 31.07.2020 13:02, Andre Valentin wrote:
>> this is really great stuff. It would help me to get forward with my wifi 
>> controller.
>> Could it be possible to subsribe to multiple sources to limit the 
>> connections to ubus?
>> 2 SSIDs with 2.4 ad 5GHz would me 4 concurrent channels if I understand 
>> right.
> 
> I'm happy someone finds it useful!
> 
> If you mean hostapd.* objects, that's right. That would require you to
> use:
> /ubus/subscribe/hostapd.wlan0
> /ubus/subscribe/hostapd.wlan0-1
> /ubus/subscribe/hostapd.wlan1
> /ubus/subscribe/hostapd.wlan1-1
> 
> For subscribing to multiple objects we would need to:
> 1. Stick to GET due to the way EventSource works
> 2. Pick some more generic URL
> 3. Adjust output format ("event" and "data" fields)
> 
> So my guess would be something like:
> 
> $ curl http://192.168.1.1/ubus/subscribe?path=hostapd.wlan0&path=hostapd.wlan1

Good idea!

> event: hostapd.wlan1 status
> data: {"count":5}
> 
> event: hostapd.wlan0-1 status
> data: {"count":5}
> 
> event: hostapd.wlan1 status
> data: {"count":7}
> 
> 
> Regarding parsing events stream, event names with spaces seem to be OK:
> https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream
> field value can use any scalar value other than line break char.

Why do you need the status there, is it part of the standard?


> We should use some special character as separator of object name and
> notification name. It must be something that ubus doesn't use in any of
> them. Should space be OK? Or should we use some more fancy char? I
> quickly tested space and it seems to work well in Firefox and Chromium.

Oh, I'm nut sure. But I think space is fine.

Did you use a special uhttpd version. I couldn't apply your patch to the uhttpd 
in openwrt master.

Kind regards,

André



smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: image size on 20.xx builds -- what about a new SMALL target

2020-08-04 Thread Bjoern Franke 

Hi,



Keep in mind master sets CONFIG_KERNEL_KALLSYMS whereas stable builds
do not. That alone makes a bit of a size difference (never checked how
much). Other than that, 5.4 needs more space than 4.14 does (again, how
much exactly I have not quantified).


Thanks for that hint. Disabling CONFIG_KERNEL_KALLSYMS and 
CONFIG_KERNEL_DEBUG_KERNEL saves around 100kb and 400kb uncompressed in 
case of the ArcherC50v1.


Regards



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

[PATCH] dnsmasq: abort when dnssec requested but not available

2020-08-04 Thread Yousong Zhou 
Before this commit, if uci option "dnssec" was set, we pass "--dnssec"
and friends to dnsmasq, let it start and decide whether to quit and
whether to emit message for diagnosis

  # dnsmasq --dnssec; echo $?
  dnsmasq: DNSSEC not available: set HAVE_DNSSEC in src/config.h
  1

DNSSEC as a feature is different from others like dhcp, tftp in that
it's a security feature.  Better be explicit.  With this change
committed, we make it so by not allowing it in the first in the
initscript, should dnsmasq later decides to not quit (not likely) or
quit without above explicit error (unlikely but less so ;)

So this is just being proactive.  on/off choices with uci option
"dnssec" are still available like before

Link: https://github.com/openwrt/openwrt/pull/3265#issuecomment-667795302
Signed-off-by: Yousong Zhou 
---
 package/network/services/dnsmasq/Makefile   | 2 +-
 package/network/services/dnsmasq/files/dnsmasq.init | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index 22ecd12f07..ab3f4fd8d0 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk
 PKG_NAME:=dnsmasq
 PKG_UPSTREAM_VERSION:=2.82
 PKG_VERSION:=$(subst test,~~test,$(subst rc,~rc,$(PKG_UPSTREAM_VERSION)))
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_UPSTREAM_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index 9288971426..932103d8b5 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -42,9 +42,13 @@ dnsmasq_ignore_opt() {
bootp-*|\
pxe-*)
[ -z "$dnsmasq_has_dhcp" ] ;;
-   dnssec-*|\
+   dnssec*|\
trust-anchor)
-   [ -z "$dnsmasq_has_dnssec" ] ;;
+   if [ -z "$dnsmasq_has_dnssec" ]; then
+   echo "dnsmasq: \"$opt\" requested, but dnssec 
support is not available" >&2
+   exit 1
+   fi
+   ;;
tftp-*)
[ -z "$dnsmasq_has_tftp" ] ;;
ipset)

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