Re: [OpenWrt-Devel] [PATCH fstools] blockd: don't unmount device when removing it from the list
On 2018-12-06 08:24, John Crispin wrote: On 05/12/2018 13:39, Rafał Miłecki wrote: On 2018-12-05 13:31, Paul Oranje wrote: Op 4 dec. 2018, om 12:32 heeft Rafał Miłecki het volgende geschreven: From: Rafał Miłecki Device gets removed from the list (vlist_delete()) when block calls "hotplug" method of blockd using ubus. Right after that block unmounts that device on its own. blockd shouldn't care about unmounting on its own for following reasons: 1) To avoid code/behavior duplication with blockThe chicken or the eggThe chicken or the egg 2) To keep behavior consistent with mounting (blockd doesn't mount) 3) To allow implementing more features in block (e.g. hotplug.d events) The design should be to: 1) Have block handle (un)mounting 2) Use blockd for providing devices/mounts state (using ubus) 3) Have blockd handle autofs and call block when needed Can this cause a transition into a state where a device is (still) mounted but removed from the list, and if so, is that a valid, an admissible state ? Shouldn't block be required to first unmount before calling blockd's hotplug entry ? The chicken or the egg? ;) We don't have any mutex/semaphore mechanism in place right now. So unless that gets implemented, we have to chooce what's better. I believe the correct order would be to: 1) Stop reporting mounted device 2) Notify all users about unmounting (hotplug.d event I work on) 3) Unmount That's the safest way that will stop applications from trying to access device due to blockd incorrectly reporting it as mounted. please update the description before pushing Acked-by: John Crispin Pushed with updated commit message https://git.openwrt.org/?p=project/fstools.git;a=commit;h=f6a96865da9162f45ea1d482c794fe14b26ecfe1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade
Em 05/12/2018 21:20, Thomas Endt escreveu: Auftrag von Henrique de Moraes Holschuh Do we have a wiki table somewhere that has the device name, ar71xx info and ath79 info, which could be expanded with ar71xx->ath79 status (no, yes but unverified, yes verified to be complete)? That would be really useful to direct efforts on adding ath79 support to something that is still ar71xx-only, as well as adding ar71xx->ath79 support to targets of interest (i.e. those one happens to know what changes are required for the migration, really). I suppose one would also add any remarks about ath79 support being incomplete or any regressions for each target one knows about, too. That would help steering the ar71xx deprecation. There is a table that documents the ath79 status in the OpenWrt forum: https://forum.openwrt.org/t/ath79-target-status/18614/9 The place to put this into the wiki would be: https://openwrt.org/docs/techref/targets/ath79 We can define a new target "ar71xx-ath79" for the dataentries, which would then give us these 3 options: 1) "ar71xx" # device is ar71xx only 2) "ath79" # device is ath79 only 3) "ar71xx-ath79"# device is migrated (and working, if nothing in "Unsupported Functions") ---> devices will automatically show up on the ath79 and/or ar71xx wikipage (slight modifications necessary). For "ath79 WIP" devices, we can set the "Unsupported Functions" datafield (that's where WIP usually is found) to "ath79 WIP, see forum". Any detailed discussion or description of incomplete support should happen elsewhere, i.e. either in the forum or on the respective devicepages. Please let me know if this meets your requirements. Yes, this would do it nicely, provided that we take care to describe in the web pages what ar71xx-ath79 means. Note that my answer assumes "migrated" (i.e. ar71xx-ath79) means the glue to migrate and convert low-level config (LEDs, etc) when updating from ar71xx -> ath79 is in place on the ath79 port. If it just does ar71xx _and_ ath79, BUT one has to manually adjust configuration when migrating from ar71xx to ath79, it would have to be flagged as WIP or something like that, even if all of its functions are fully implemented and working in ath79. Thanks! -- Henrique de Moraes Holschuh Analista de Projetos Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações (Ceptro.br) +55 11 5509-3537 R.:4023 INOC 22548*625 www.nic.br ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox] hotplug: add hotplug_call() helper
From: Rafał Miłecki
This new function imlements common code needed to run /etc/hotplug.d/
listeners. It allows specifying subsystem and environment strings as
commonly used in the hotplug.d.
Signed-off-by: Rafał Miłecki
---
CMakeLists.txt | 2 +-
hotplug.c | 35 +++
hotplug.h | 8
3 files changed, 44 insertions(+), 1 deletion(-)
create mode 100644 hotplug.c
create mode 100644 hotplug.h
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 57804cf..aa54499 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -15,7 +15,7 @@ IF(JSONC_FOUND)
INCLUDE_DIRECTORIES(${JSONC_INCLUDE_DIRS})
ENDIF()
-SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c
base64.c)
+SET(SOURCES avl.c avl-cmp.c blob.c blobmsg.c uloop.c usock.c ustream.c
ustream-fd.c vlist.c utils.c safe_list.c runqueue.c md5.c kvlist.c ulog.c
base64.c hotplug.c)
ADD_LIBRARY(ubox SHARED ${SOURCES})
ADD_LIBRARY(ubox-static STATIC ${SOURCES})
diff --git a/hotplug.c b/hotplug.c
new file mode 100644
index 000..f3298fa
--- /dev/null
+++ b/hotplug.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: ISC
+/*
+ * hotplug - helpers for hotplug.d events
+ *
+ * Copyright (C) 2018 Rafał Miłecki
+ */
+
+#include "hotplug.h"
+
+#include
+#include
+#include
+#include
+
+int hotplug_call(char *subsystem, char * const *envp)
+{
+ pid_t pid;
+
+ pid = fork();
+ if (!pid) {
+ char * const argv[] = { "hotplug-call", subsystem, NULL };
+
+ execve("/sbin/hotplug-call", argv, envp);
+ exit(-1);
+ } else if (pid > 0) {
+ int status;
+
+ waitpid(pid, &status, 0);
+ if (WEXITSTATUS(status))
+ return WEXITSTATUS(status);
+ return 0;
+ } else {
+ return -errno;
+ }
+}
diff --git a/hotplug.h b/hotplug.h
new file mode 100644
index 000..224a764
--- /dev/null
+++ b/hotplug.h
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: ISC
+
+#ifndef __LIBUBOX_HOTPLUG_H
+#define __LIBUBOX_HOTPLUG_H
+
+int hotplug_call(char *subsystem, char * const *envp);
+
+#endif
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi! proxy 于2018年12月6日周四 下午3:31写道： ... > > I'm a user from the Third World. Since devices with 64MB of RAM or Seriously? :) > more are a little expensive for us. > I bought many devices with 1MB flash and 8MB ram, mainly ar9331 qca9533. > Then update the RAM to 64MB, and solder a simple sop8 socket to it, > and use 4MB 8MB 16MB of flash for it. > All works well. These kinds of device modifications isn't the topic discussed here. OpenWrt never accepts device supports that requires any hardware modifications and supports for modified routers usually stays in third-party repositories. Several ar71xx images works on modified TP-LINK routers because: 1. ar71xx has the ability to auto-detect memory and flash size for TP-LINK partition table. 2. TP-LINK sells different products inside China and some routers happens to have a similar board design (except flash/ram) as products they sells worldwide.> > > > > > I'm not sure whether the topic qualifies for a formal voting, hence the > > > RFC. > > > > Thanks for bringing up this topic. > > > > -- > > Cheers, > > Piotr > > > > ___ > > 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2 fstools] block: generate hotplug.d mount events
From: Rafał Miłecki
With this change block generates 2 "mount" hotplug.d subsystem events:
1) "add" when block device gets mounted
2) "remove" when block device gets unmounted
This allows e.g. controlling USB storage dependant software using
hotplug.d listeners.
A very similar solution was implemented in mountd which was replaced by
blockd.
Signed-off-by: Rafał Miłecki
---
V2: Use hotplug_call() helper. It requires
[PATCH libubox] hotplug: add hotplug_call() helper
---
block.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/block.c b/block.c
index 46050b4..99e02b0 100644
--- a/block.c
+++ b/block.c
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -880,6 +881,24 @@ static int exec_mount(const char *source, const char
*target,
return err;
}
+static int hotplug_call_mount(const char *action, const char *device)
+{
+ char actionenv[] = "ACTION=xx";
+ char deviceenv[32];
+ char *envp[] = { actionenv, deviceenv, NULL };
+ int err;
+
+ snprintf(actionenv, sizeof(actionenv), "ACTION=%s", action);
+ snprintf(deviceenv, sizeof(deviceenv), "DEVICE=%s", device);
+
+ err = hotplug_call("mount", envp);
+ if (err) {
+ ULOG_ERR("hotplug-call call failed: %d\n", err);
+ }
+
+ return err;
+}
+
static int handle_mount(const char *source, const char *target,
const char *fstype, struct mount *m)
{
@@ -1079,6 +1098,8 @@ static int mount_device(struct probe_info *pr, int type)
handle_swapfiles(true);
+ hotplug_call_mount("add", device);
+
return 0;
}
@@ -1091,6 +1112,8 @@ static int umount_device(char *path)
if (!mp)
return -1;
+ hotplug_call_mount("remove", basename(path));
+
err = umount2(mp, MNT_DETACH);
if (err)
ULOG_ERR("unmounting %s (%s) failed (%d) - %m\n", path, mp,
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] firewall3: link zone_loopback_helper chain through an OUTPUT rule
From: Alin Nastac
Locally-generated packets are passing through OUTPUT chain, not
PREROUTING.
Signed-off-by: Alin Nastac
---
zones.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/zones.c b/zones.c
index 505ab20..8c3daef 100644
--- a/zones.c
+++ b/zones.c
@@ -557,22 +557,24 @@ print_interface_rule(struct fw3_ipt_handle *handle,
struct fw3_state *state,
}
else if (handle->table == FW3_TABLE_RAW)
{
+ bool loopback_dev = (dev != NULL && !dev->any && !dev->invert
&& strcmp(dev->name, "lo") == 0);
+
if (has(zone->flags, handle->family, FW3_FLAG_HELPER))
{
- r = fw3_ipt_rule_create(handle, NULL, dev, NULL, sub,
NULL);
+ r = fw3_ipt_rule_create(handle, NULL, loopback_dev ?
NULL : dev, NULL, sub, NULL);
fw3_ipt_rule_comment(r, "%s CT helper assignment",
zone->name);
fw3_ipt_rule_target(r, "zone_%s_helper", zone->name);
fw3_ipt_rule_extra(r, zone->extra_src);
- fw3_ipt_rule_replace(r, "PREROUTING");
+ fw3_ipt_rule_replace(r, loopback_dev ? "OUTPUT" :
"PREROUTING");
}
if (has(zone->flags, handle->family, FW3_FLAG_NOTRACK))
{
- r = fw3_ipt_rule_create(handle, NULL, dev, NULL, sub,
NULL);
+ r = fw3_ipt_rule_create(handle, NULL, loopback_dev ?
NULL : dev, NULL, sub, NULL);
fw3_ipt_rule_comment(r, "%s CT bypass", zone->name);
fw3_ipt_rule_target(r, "zone_%s_notrack", zone->name);
fw3_ipt_rule_extra(r, zone->extra_src);
- fw3_ipt_rule_replace(r, "PREROUTING");
+ fw3_ipt_rule_replace(r, loopback_dev ? "OUTPUT" :
"PREROUTING");
}
}
}
--
2.7.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v5 1/2] Evaluate board names in alphabetical order
---
target/linux/octeon/base-files/lib/upgrade/platform.sh | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh
b/target/linux/octeon/base-files/lib/upgrade/platform.sh
index cd49c0da36..6d258dbb0f 100755
--- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
+++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
@@ -62,12 +62,12 @@ platform_do_upgrade() {
[ -b "${rootfs}" ] || return 1
case "$board" in
- erlite)
- kernel=sda1
- ;;
er)
kernel=mmcblk0p1
;;
+ erlite)
+ kernel=sda1
+ ;;
*)
return 1
esac
@@ -82,8 +82,8 @@ platform_check_image() {
local board=$(board_name)
case "$board" in
- erlite | \
- er)
+ er | \
+ erlite)
local tar_file="$1"
local kernel_length=`(tar xf $tar_file sysupgrade-$board/kernel
-O | wc -c) 2> /dev/null`
local rootfs_length=`(tar xf $tar_file sysupgrade-$board/root
-O | wc -c) 2> /dev/null`
--
2.12.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v5 0/2] Allow sysupgrade restore on ER
This is a very simple patch that completes sysupgrade functionality on UBNT ER8. Default layout leaves about 128MB free on the kernel partition so there is plenty of space for temporary config backups. Jonathan Thibault (2): Evaluate board names in alphabetical order Allow sysupgrade restore on ER --- v2: checks board name in alphabetical order v3: used git send-email to avoid patch mangling v4: split into two patches v5: get rid of code reduncancy Jonathan Thibault (2): Evaluate board names in alphabetical order Allow sysupgrade restore on ER .../octeon/base-files/lib/preinit/79_move_config | 15 ++--- .../octeon/base-files/lib/upgrade/platform.sh | 25 +++--- 2 files changed, 29 insertions(+), 11 deletions(-) -- 2.12.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v5 2/2] Allow sysupgrade restore on ER
---
target/linux/octeon/base-files/lib/preinit/79_move_config | 15 ---
target/linux/octeon/base-files/lib/upgrade/platform.sh| 15 ---
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/target/linux/octeon/base-files/lib/preinit/79_move_config
b/target/linux/octeon/base-files/lib/preinit/79_move_config
index ec63d9f5ff..8c379a3276 100644
--- a/target/linux/octeon/base-files/lib/preinit/79_move_config
+++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
@@ -1,14 +1,23 @@
#!/bin/sh
# Copyright (C) 2014 OpenWrt.org
+er_move_config() {
+ local dev="$1"
+
+ mount -t vfat "$dev" /mnt
+ [ -f /mnt/sysupgrade.tgz ] && mv -f /mnt/sysupgrade.tgz /
+ umount /mnt
+}
+
move_config() {
. /lib/functions.sh
case "$(board_name)" in
+ er)
+ er_move_config /dev/mmcblk0p1
+ ;;
erlite)
- mount -t vfat /dev/sda1 /mnt
- [ -f /mnt/sysupgrade.tgz ] && mv -f /mnt/sysupgrade.tgz
/
- umount /mnt
+ er_move_config /dev/sda1
;;
esac
}
diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh
b/target/linux/octeon/base-files/lib/upgrade/platform.sh
index 6d258dbb0f..a38a2a362a 100755
--- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
+++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
@@ -21,12 +21,21 @@ platform_get_rootfs() {
fi
}
+er_platform_copy_config() {
+ local dev="$1"
+
+ mount -t vfat "$dev" /mnt
+ cp -af "$CONF_TAR" /mnt/
+ umount /mnt
+}
+
platform_copy_config() {
case "$(board_name)" in
+ er)
+ er_platform_copy_config /dev/mmcblk0p1
+ ;;
erlite)
- mount -t vfat /dev/sda1 /mnt
- cp -af "$CONF_TAR" /mnt/
- umount /mnt
+ er_platform_copy_config /dev/sda1
;;
esac
}
--
2.12.2
___
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 Ubiquity
Petr Štetiar [2018-11-20 00:28:50]: Hi Joe, > > cd openwrt.git > > git remote add github-ynezz https://github.com/ynezz/openwrt.git > > git fetch github-ynezz > > git checkout -b nanostation-m-xw github-ynezz/wip/nanostation-m-xw > > echo -e > > "CONFIG_TARGET_ath79=y\nCONFIG_TARGET_ath79_generic=y\nCONFIG_TARGET_ath79_generic_DEVICE_ubnt_nano-m-xw=y" > > > .config > > make defconfig world -j$(nproc) could you please retest it on your M5 and tell me if it's better now? Commit history of my wip/nanostation-m-xw branch should look like this now: 6db71cf WIP: ath79: Add support for Ubiquiti Nanostation M (XW) a947035 ath79: ag71xx: Ensure that appending of CRC to frames is always disabled 434aa86 ath79: gmac: ar934x: Add parser for mii-gmac0-slave 9329548 ath79: ubnt-bullet-m-xw: Move common DTS bits into XW include file 86a97ee ath79: ubnt-xw: Add LED aliases for diag and status LED support ad759fb ath79: ag71xx: Unify debug output with ar71xx and make debugging easier 7855bae ar71xx: ag71xx: Replace duplicate debugging code with simple function call ffa5538 ramips: fix dtc compiler warnings Thanks! -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] redirects: properly handle src_dport in SNAT rules
In case of SNAT rules the src_dport parameter is used both as a rewrite parameter as well as a matching parameter which is not the expected behavior. The latter is caused by port_redir being set to src_dport in case dest_port parameter is not. As this logic is in place to mimic the old shell script based firewall behavior for DNAT only set port_redir in case the redirect rule is a DNAT rule. Signed-off-by: Hans Dedecker --- redirects.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/redirects.c b/redirects.c index 6cd09f1..ab95395 100644 --- a/redirects.c +++ b/redirects.c @@ -350,7 +350,7 @@ check_redirect(struct fw3_state *state, struct fw3_redirect *redir, struct uci_e if (!valid) return false; - if (!redir->port_redir.set) + if (redir->target == FW3_FLAG_DNAT && !redir->port_redir.set) redir->port_redir = redir->port_dest; return true; -- 2.19.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH firewall3] redirects: properly handle src_dport in SNAT rules
In case of SNAT rules the src_dport parameter is used both as a rewrite parameter as well as a matching parameter which is not the expected behavior. The latter is caused by port_redir being set to src_dport in case dest_port parameter is not. As this logic is in place to mimic the old shell script based firewall behavior for DNAT only set port_redir in case the redirect rule is a DNAT rule. Signed-off-by: Hans Dedecker --- redirects.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/redirects.c b/redirects.c index 6cd09f1..ab95395 100644 --- a/redirects.c +++ b/redirects.c @@ -350,7 +350,7 @@ check_redirect(struct fw3_state *state, struct fw3_redirect *redir, struct uci_e if (!valid) return false; - if (!redir->port_redir.set) + if (redir->target == FW3_FLAG_DNAT && !redir->port_redir.set) redir->port_redir = redir->port_dest; return true; -- 2.19.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH firewall3] redirects: properly handle src_dport in SNAT rules
Hi, On 12/6/18 6:03 PM, Hans Dedecker wrote: > In case of SNAT rules the src_dport parameter is used both as a rewrite > parameter as well as a matching parameter which is not the expected > behavior. > The latter is caused by port_redir being set to src_dport in case dest_port > parameter is not. > As this logic is in place to mimic the old shell script based firewall > behavior for DNAT only set port_redir in case the redirect rule is > a DNAT rule. > > Signed-off-by: Hans Dedecker Acked-by: Jo-Philipp Wich > --- > redirects.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/redirects.c b/redirects.c > index 6cd09f1..ab95395 100644 > --- a/redirects.c > +++ b/redirects.c > @@ -350,7 +350,7 @@ check_redirect(struct fw3_state *state, struct > fw3_redirect *redir, struct uci_e > if (!valid) > return false; > > - if (!redir->port_redir.set) > + if (redir->target == FW3_FLAG_DNAT && !redir->port_redir.set) > redir->port_redir = redir->port_dest; > > return true; > signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi, My first computer had 32 Mb of RAM and I was able to play in Half Life 1 on it :) Yes, I had an HDD of 2 Gb but also I played in Towers of Hanoi from a browser of QNX booted from a floppy disk 1.44 mb http://toastytech.com/guis/qnxdemo.html That's why I think that 32/4 is actually a lot :) Now I have a TP-Link WR740N and there is running OpenWrt 18.06 but without ipv6, pppoe, luci and lua but with uhttpd + tls so the router is hosting for my homepage. And there is about 2mb of free space of persistent memory so I even thought to move my blog because all posts gziped are about the 2 mb. Someone even installs OpenVPN on such routers but into /tmp folder i.e. RAM. So what I can say is that 32 RAM/4 ROM routers are working on the last OpenWrt pretty well thanking by your great job. Given the mentioned stats https://downloads.openwrt.org/stats/ in top 100 downloads 16 (i.e. 16%) contains tiny word with total of 89917 downloads. Actually I think that statistics is not complete because a lot of users like me didn't downloaded a tiny build but built it itself from sources. In fact most of those builds is just to disable ipv6, pppoe etc because removing with opkg doesn't frees the space correctly. Also as a user from Ukraine which is in top 10 of download countries I can confirm that here old and cheapest routers are most popular. Here is a list of routers sorted by popularity from the most popular shop in Ukraine https://rozetka.com.ua/routers/c80193/sort=popularity/ As you can see 4 of 9 most popular routers are with 32 and even 16 mb of RAM. And this may take years when typical device will have 64 mb. In the same time in Ukraine the government actively introduces censorship and already banned most popular in Ukraine websites (vk.com, yandex, ok.ru) because they are belongs to Russian companies. The same situation is in Russia where government also bans some Ukrainian websites and even more like Telegram and LinkedIn. I talking about this because both Russia and Ukraine are in top-10 countries and I guess that's because a typical usage is to setup OpenVPN to the cheapest router of your parents. At least for me that's the but another reason was to enable guest network (and BTW why Luci just don't have a single button for this?). The old routers loose support from vendors leaving users vulnerable to exploits. It's good for users and environment if they can just install OpenWrt instead of throwing their routers to trash. If I understood correctly the main problems are: 0. Such routers aren't produced anymore (correct) and not widely used (unfortunately not). 1. Core OpenWrt developers are not using such devices so they don't have a personal interest. 2. It's hard to test, it requires resources to build, it consumes a time of developers to review pull requests. 3. External dependencies like Linux Kernel or ulibc increases their size. 4. Resulting builds sometimes are not fit into 4 mb of persistent memory. This was solved by introducing a "tiny" builds. So about the last issue we can solve it by modularizing and by rewriting software. Let's take for example Luci as most big part of software. First of all it turned out that there is luci-mod-admin-mini package and it's supports only basic configuration which actually covers all my needs. But the luci-mod-admin-mini was not ever mentioned in wiki and seems like not used at all. Even standard Luci can be easily and significantly reduced in twice just by removing images and icons. Luci uses a lot of images but they are not in some optional theme package but in sources themselves (i.e. in modules/luci-base/htdocs/luci-static/resources/icons). So just by simple remodularization and moving the icons to theme we can change tiny-theme without icons and full theme with icons. I see that javascripts are already minimized (previously the wasn't) but css files aren't yet. Even more: we can gzip the files and serve them by Accept-Encoding: deflate (or brotli) so they will be uncompressed by the browser itself. I saw a patch for uhttpd that allows this. With the ability to serve precompressed static content we can switch icons from png to svg and this can save up to 10% of space. All this allows us to decrease luci size at least twice. We can go further and rewrite Luci itself i.e. complete the Luci2 project: get rid off Lua dependency and use JSON-RPC over ubus. But even this may be not needed: For Tp-Link recently was released a mobile app Tether to control a router https://www.tp-link.com/us/tether/ We can try to reverse engineer the protocol of the mobile app and implement it. Given that users can remove Luci and use the app to configure the router. So what I trying to say: sometimes the lack of space may mean that architecture can be improved. Then it's better to fix that or wait until it will be eventually fixed. Smaller software is usually works faster so that's a good property to keep even for larger devices. If you lack of
Re: [OpenWrt-Devel] ar71xx Vs ath79 -- sysupgrade
> -Ursprüngliche Nachricht- > Von: Henrique de Moraes Holschuh > Em 05/12/2018 21:20, Thomas Endt escreveu: > >> Auftrag von Henrique de Moraes Holschuh Do we have a wiki table > >> somewhere that has the device name, ar71xx info and ath79 info, which > >> could be expanded with ar71xx->ath79 status (no, yes but unverified, > >> yes verified to be complete)? > >> > >> That would be really useful to direct efforts on adding ath79 support > >> to something that is still ar71xx-only, as well as adding > >> ar71xx->ath79 support to targets of interest (i.e. those one happens > >> to know what changes are required for the migration, really). > >> > >> I suppose one would also add any remarks about ath79 support being > >> incomplete or any regressions for each target one knows about, too. > >> That would help steering the ar71xx deprecation. > > > > There is a table that documents the ath79 status in the OpenWrt forum: > > https://forum.openwrt.org/t/ath79-target-status/18614/9 > > > > The place to put this into the wiki would be: > > https://openwrt.org/docs/techref/targets/ath79 > > > > > > We can define a new target "ar71xx-ath79" for the dataentries, which > would then give us these 3 options: > > > > 1) "ar71xx" # device is ar71xx only > > 2) "ath79" # device is ath79 only > > 3) "ar71xx-ath79"# device is migrated (and working, if nothing in > "Unsupported Functions") > > > > ---> devices will automatically show up on the ath79 and/or ar71xx wikipage > (slight modifications necessary). > > > > For "ath79 WIP" devices, we can set the "Unsupported Functions" datafield > (that's where WIP usually is found) to "ath79 WIP, see forum". > > Any detailed discussion or description of incomplete support should > happen elsewhere, i.e. either in the forum or on the respective devicepages. > > > > Please let me know if this meets your requirements. > > Yes, this would do it nicely, provided that we take care to describe in the > web > pages what ar71xx-ath79 means. > > Note that my answer assumes "migrated" (i.e. ar71xx-ath79) means the glue > to migrate and convert low-level config (LEDs, etc) when updating from > ar71xx -> ath79 is in place on the ath79 port. > > If it just does ar71xx _and_ ath79, BUT one has to manually adjust > configuration when migrating from ar71xx to ath79, it would have to be > flagged as WIP or something like that, even if all of its functions are fully > implemented and working in ath79. I tried to include your comments while creating these two pages: https://openwrt.org/docs/techref/targets/ar71xx-ath79 https://openwrt.org/unsupported/ath79_wip Please crosscheck. > > There is a table that documents the ath79 status in the OpenWrt forum: > > https://forum.openwrt.org/t/ath79-target-status/18614/9 Can I set all devices listed as "working" to "ar71xx-ath79 + no ath79 WIP"? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ipq806x: add ath10k calibration data MAC addresses patching
28/10/2018 17:39, Christian Lamparter:
Ben Greear reported in his patch:
|Subject: netgear r7800: Fix mac address of radios.
|
|Reloading the driver causes the phyX to change, and that
|caused the MAC address to change.
This is because all ODM/OEMs except QCA bothered to write
the correct MAC address for the ath10k wifi into the
calibration data.
This patch copies over the MAC patching helper functions from ipq40xx's
target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
file and converts all the devices to patch the correct MACs into the
extracted calibration data before it gets sent to the driver, which sets
up the device with the correct MAC address. It also removes the
10_fix_wifi_mac file as it has served its purpose.
Please note the C2600: There is conflicting information on what
the offset for the second wifi is supposed to be. This patch uses
what was specified in 10_fix_wifi_mac.
Reported-by: Ben Greear
Signed-off-by: Christian Lamparter
Hey Felix,
as long as you don't strongly disagree, I would like to pick this patch.
I don't consider the calibration data patching as messy, as it is the
place where the mac address is expected but unfortunately not correct set.
Beside the issues mentioned by Ben, I really don't like to split the
wireless calibration data and wireless mac address handling across
multiple files if it can be done at a single place.
Mathias
---
.../etc/hotplug.d/firmware/11-ath10k-caldata | 64 +--
.../etc/hotplug.d/ieee80211/10_fix_wifi_mac | 37 ---
2 files changed, 57 insertions(+), 44 deletions(-)
delete mode 100644
target/linux/ipq806x/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
diff --git
a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index fa49c250f0..1d070603f2 100644
--- a/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq806x/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -1,5 +1,21 @@
#!/bin/sh
+# xor multiple hex values of the same length
+xor() {
+ local val
+ local ret="0x$1"
+ local retlen=${#1}
+
+ shift
+ while [ -n "$1" ]; do
+ val="0x$1"
+ ret=$((ret ^ val))
+ shift
+ done
+
+ printf "%0${retlen}x" "$ret"
+}
+
ath10kcal_die() {
echo "ath10cal: " "$*"
exit 1
@@ -36,6 +52,29 @@ ath10kcal_patch_mac() {
macaddr_2bin $mac | dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=6 count=6
}
+ath10kcal_patch_mac_crc() {
+ local mac=$1
+ local mac_offset=6
+ local chksum_offset=2
+ local xor_mac
+ local xor_fw_mac
+ local xor_fw_chksum
+
+ xor_fw_mac=$(hexdump -v -n 6 -s $mac_offset -e '/1 "%02x"'
/lib/firmware/$FIRMWARE)
+ xor_fw_mac="${xor_fw_mac:0:4} ${xor_fw_mac:4:4} ${xor_fw_mac:8:4}"
+
+ ath10kcal_patch_mac "$mac" && {
+ xor_mac=${mac//:/}
+ xor_mac="${xor_mac:0:4} ${xor_mac:4:4} ${xor_mac:8:4}"
+
+ xor_fw_chksum=$(hexdump -v -n 2 -s $chksum_offset -e '/1
"%02x"' /lib/firmware/$FIRMWARE)
+ xor_fw_chksum=$(xor $xor_fw_chksum $xor_fw_mac $xor_mac)
+
+ printf "%b" "\x${xor_fw_chksum:0:2}\x${xor_fw_chksum:2:2}" | \
+ dd of=/lib/firmware/$FIRMWARE conv=notrunc bs=1
seek=$chksum_offset count=2
+ }
+}
+
[ -e /lib/firmware/$FIRMWARE ] && exit 0
. /lib/functions.sh
@@ -43,53 +82,64 @@ ath10kcal_patch_mac() {
board=$(board_name)
-
case "$FIRMWARE" in
"ath10k/pre-cal-pci-:01:00.0.bin")
case $board in
linksys,ea8500)
- hw_mac_addr=$(mtd_get_mac_ascii devinfo hw_mac_addr)
ath10kcal_extract "art" 4096 12064
+ ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_ascii
devinfo hw_mac_addr) +1)
+ ;;
+ nec,wg2600hp)
+ ath10kcal_extract "ART" 4096 12064
+ ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
PRODUCTDATA 12) +1)
;;
netgear,d7800 |\
netgear,r7500v2 |\
netgear,r7800)
ath10kcal_extract "art" 4096 12064
+ ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary art
6) +1)
;;
tplink,c2600)
ath10kcal_extract "radio" 4096 12064
-# ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary
default-mac 8) -1)
+ ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
default-mac 8) -1)
;;
- nec,wg2600hp |\
tplink,vr2600v)
ath10kcal_extract "ART" 4096 12064
+ ath10kcal_patch_mac_crc $(macaddr_add $(mtd_get_mac_binary
default-mac 0) -1)
;;
zyxel,nbg6817)
ath10kcal_extract "0:ART" 4096 12064
+
[OpenWrt-Devel] [PATCH] swconfig: Add missing include
Fixes these warnings: swlib.c:455:18: warning: implicit declaration of function 'isspace' swlib.c:461:9: warning: implicit declaration of function 'isdigit' Signed-off-by: Rosen Penev --- package/network/config/swconfig/Makefile| 2 +- package/network/config/swconfig/src/swlib.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/package/network/config/swconfig/Makefile b/package/network/config/swconfig/Makefile index e457ce4882..8b1d6cd64a 100644 --- a/package/network/config/swconfig/Makefile +++ b/package/network/config/swconfig/Makefile @@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=swconfig -PKG_RELEASE:=11 +PKG_RELEASE:=12 PKG_MAINTAINER:=Felix Fietkau PKG_LICENSE:=GPL-2.0 diff --git a/package/network/config/swconfig/src/swlib.c b/package/network/config/swconfig/src/swlib.c index 0fb8ebb392..0e09a1505b 100644 --- a/package/network/config/swconfig/src/swlib.c +++ b/package/network/config/swconfig/src/swlib.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include -- 2.19.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] f2fs-tools: Update to 1.12.0
Tested on Turris Omnia. Signed-off-by: Rosen Penev --- package/utils/f2fs-tools/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/utils/f2fs-tools/Makefile b/package/utils/f2fs-tools/Makefile index 659b3d244c..b782b80670 100644 --- a/package/utils/f2fs-tools/Makefile +++ b/package/utils/f2fs-tools/Makefile @@ -8,14 +8,14 @@ include $(TOPDIR)/rules.mk PKG_NAME:=f2fs-tools -PKG_VERSION:=1.11.0 +PKG_VERSION:=1.12.0 PKG_RELEASE:=1 PKG_LICENSE:=GPLv2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/snapshot/ -PKG_HASH:=b916ac7cda902502cf18de98da94921f71edbab40fb0437d757f0716191c79e3 +PKG_HASH:=e2124e4dffaba865d41495d817bcb924d096adaec67ff777b8c7da99aa13f696 PKG_FIXUP:=autoreconf PKG_BUILD_PARALLEL:=1 -- 2.19.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi, > Even standard Luci can be easily and significantly reduced in twice just > by removing images and icons. I don't think this is true. The few icons bundled with LuCI at are approx 19KB overall while a recent mips 24kc snapshot build of luci-base is 126KB in size. So the images account for less than 10% of the luci-base size. > Luci uses a lot of images but they are not in some optional theme > package but in sources themselves (i.e. in > modules/luci-base/htdocs/luci-static/resources/icons). Note that we're talking about 23 icons with a size of roughly 14KB here. This is not the silver bullet which will magically make 4MB flash devices viable again. > So just by simple remodularization and moving the icons to theme we can > change tiny-theme without icons and full theme with icons. Saving about 20KB before compression, this is less than OpenWrt master consumes in size increase during a few months due to mere package updates. > I see that javascripts are already minimized (previously the wasn't) but > css files aren't yet. Saving about 4KB after squashfs compression. > Even more: we can gzip the files and serve them by Accept-Encoding: > deflate (or brotli) so they will be uncompressed by the browser itself. > I saw a patch for uhttpd that allows this. Note that squashfs performs optimized LZMA compression - shipping precompressed artifacts in rootfs would actually increase the image size due to double compression overhead. > With the ability to serve precompressed static content we can switch > icons from png to svg and this can save up to 10% of space. I doubt that. So far my LZMA compression tests have shown that precompressing content will not really result in an effective size decrease after squashfs/lzma. > All this allows us to decrease luci size at least twice. Not really, at most in a single digit percent range - if at all. > We can go further and rewrite Luci itself i.e. complete the Luci2 > project: get rid off Lua dependency and use JSON-RPC over ubus. Patches for this are very welcome. From what I learned so far, the space required to store all the modern day web framework dependencies will easily outweigh the ~70KB liblua + ~5KB lua runtime footprint. I've seen CSS scaffholdings and JS polyfills requiring more space than the entire Lua runtime. > But even this may be not needed: For Tp-Link recently was released a > mobile app Tether to control a router https://www.tp-link.com/us/tether/ This would imply both tying OpenWrt to a proprietary app and limiting its configuration to whatever settings that happen to be exposed by it - this hardly sounds like a viable solution to me. > We can try to reverse engineer the protocol of the mobile app and > implement it. Given that users can remove Luci and use the app to > configure the router. I don't think that attempting to accommodate proprietary vendor configuration protocols is going to help in significantly reducing the storage footprint in future OpenWrt versions. > So what I trying to say: sometimes the lack of space may mean that > architecture can be improved. Then it's better to fix that or wait until > it will be eventually fixed. LuCI master was recently further modularized to allow installing only the components wanted/needed to support certain functions, this could already help to reduce the footprint in some scenarios. > Smaller software is usually works faster so that's a good property to > keep even for larger devices. I'm with you here, but building small software and actively avoiding all the libraries/bloat floating around takes effort and dedication, which is scarce, especially for the rather uncommon use-cases targeted by OpenWrt. ~ 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: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi, > At least for me that's the but another reason was to enable guest > network (and BTW why Luci just don't have a single button for this?). Because it has not been implemented yet. Adding the code for it would probably consume another 5-10KB uncompressed. > [...] > Let's take for example Luci as most big part of software. > > First of all it turned out that there is luci-mod-admin-mini package and > it's supports only basic configuration which actually covers all my needs. This package is marked broken and hasn't been maintained in years. > But the luci-mod-admin-mini was not ever mentioned in wiki and seems > like not used at all. > > Even standard Luci can be easily and significantly reduced in twice just > by removing images and icons. As I already pointed out in my other reply, this is a rather optimistic assumption. At best you can expect a single digit percentage improvement by dropping icons. I know that people love to point at the ui and complain about single kilobyte size increases there while kernel and user land updates easily throw away dozens to hundreds of KB due to new transient dependencies, larger vmlinux images or additional feature code footprint. All I can say is that I've been extremely conservative with LuCI changes, always trying to not increase the storage footprint at all and avoiding dependencies or code bloat whenever possible. > Luci uses a lot of images but they are not in some optional theme > package but in sources themselves (i.e. in > modules/luci-base/htdocs/luci-static/resources/icons). See my other reply. Regards, 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: [OpenWrt-Devel] [PATCH] f2fs-tools: Update to 1.12.0
Hi, Duplicate, https://github.com/openwrt/openwrt/pull/1575 There's also some weird bug on Atheros MIPS (ath79 and ar71xx), more info on Github Best regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] brcm2708: add kernel 4.14 support
On 11/11/18 18:37, Stijn Tintel wrote: > Hi, > > I have just pushed support for the 4.14 kernel on the brcm2708 target to > my staging tree [1], and would like to get some feedback before pushing > it to master. It would also be nice if people could do runtime tests on > bcm2709 and bcm2710, as I don't own such hardware. > > Thanks, > Stijn > > [1] > https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14 > Updated [1]: - based on 4.14.86 - split kmod changes in separate commits - kept lan78xx patches except those that are superseded by upstream changes, added another one that attempts to fix broken ethernet and "kevent 4 may have been dropped" flood - added missing compatible strings using upstream names for compute modules - no longer removing the sense HAT patch, I might add kmod packages for that later Compile-tested all 3 subtargets again with CONFIG_ALL_KMODS=y, and runtime-tested bcm2708 on RPi0W and bcm2710 on RPi3B+. The wired interface on the latter seems to be usable now. I'm planning to push this to master as soon as Koen pushed the 4.14.86 bump. If there are any objections, please speak up ASAP. Thanks, Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox] hotplug: add hotplug_call() helper
On Thu, 6 Dec 2018 at 20:42, Rafał Miłecki wrote: > > From: Rafał Miłecki > > This new function imlements common code needed to run /etc/hotplug.d/ > listeners. It allows specifying subsystem and environment strings as > commonly used in the hotplug.d. hotplug-call is currently a OpenWrt-specific shell script from base-files. A library function's dependence on exact name and path of non-standard executable does not seem fit. Hotplug events from the kernel is already being handled by hotplug.json script. Events from non-standard subsystem like "iface" as defined by netifd are generated and handled fine just by itself [1]. As such, I cannot find enough other places needing this function to make it into libubox. [1] https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-event.c;h=a40f6dc883d3a3654d73d0592cd7eb65c2a8de85;hb=HEAD#l45 yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
Hi, On Wed, 2018-12-05 at 09:56 +0100, Mathias Kresin wrote: > Hey all, > I would like to start to reject patches for adding boards with only 32 MByte > of RAM and 4 > MByte of flash [0]. These boards barely work with todays OpenWrt default > builds and > require quite some modifications to be useful at all [1]. > IMHO it doesn't make much sense to waste resources (reviewer time, build > resources) for > boards which will most likely never see an official build and/or are more or > less > unusable with the official build. > I prefer to have a joint statement which I can link to, to prevent endless > discussions or > accusations of acting purely arbitrary. > I'm not sure whether the topic qualifies for a formal voting, hence the RFC. > Mathias > [0] https://github.com/openwrt/openwrt/pull/1577 > [1] https://openwrt.org/supported_devices/432_warning > The point about these boards requiring a lot of modification to be useful is simply not true.I have a TP-Link tl-wr841n-v11 running the master branch with kernel 4.14 with luci and sqm-scripts + miniupnpd with no problem at all. The only change I had to do was disable IPv6 and the opkg package from the build imageresulting in the final image size of 3.8M For reference I have attached .config that I use. > ___openwrt-devel mailing > listopenwrt-de...@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Regards, Shaleen Jain CONFIG_TARGET_ar71xx=y CONFIG_TARGET_ar71xx_tiny=y CONFIG_TARGET_ar71xx_tiny_DEVICE_tl-wr841-v11=y CONFIG_DEVEL=y CONFIG_BUILD_PATENTED=y CONFIG_CCACHE=y CONFIG_CLEAN_IPKG=y CONFIG_IMAGEOPT=y # CONFIG_IPV6 is not set CONFIG_KERNEL_COREDUMP=y CONFIG_KERNEL_DEBUG_INFO=y CONFIG_KERNEL_DEBUG_KERNEL=y CONFIG_KERNEL_ELF_CORE=y # CONFIG_KERNEL_IPV6 is not set CONFIG_KERNEL_SWAP=y CONFIG_LUCI_SRCDIET=y CONFIG_PACKAGE_iptables-mod-conntrack-extra=y CONFIG_PACKAGE_iptables-mod-ipopt=y CONFIG_PACKAGE_kmod-fs-exfat=m CONFIG_PACKAGE_kmod-ifb=y CONFIG_PACKAGE_kmod-ipt-conntrack-extra=y CONFIG_PACKAGE_kmod-ipt-ipopt=y CONFIG_PACKAGE_kmod-ipt-raw=y CONFIG_PACKAGE_kmod-nls-base=m CONFIG_PACKAGE_kmod-sched-cake=y CONFIG_PACKAGE_kmod-sched-core=y CONFIG_PACKAGE_libiwinfo-lua=y CONFIG_PACKAGE_liblua=y CONFIG_PACKAGE_liblucihttp=y CONFIG_PACKAGE_liblucihttp-lua=y CONFIG_PACKAGE_librt=y CONFIG_PACKAGE_libubus-lua=y CONFIG_PACKAGE_libuuid=y CONFIG_PACKAGE_lua=y CONFIG_PACKAGE_luci=y CONFIG_PACKAGE_luci-app-firewall=y CONFIG_PACKAGE_luci-app-sqm=y CONFIG_PACKAGE_luci-app-upnp=y CONFIG_PACKAGE_luci-base=y CONFIG_PACKAGE_luci-lib-ip=y CONFIG_PACKAGE_luci-lib-jsonc=y CONFIG_PACKAGE_luci-lib-nixio=y CONFIG_PACKAGE_luci-mod-admin-full=y CONFIG_PACKAGE_luci-proto-ppp=y CONFIG_PACKAGE_luci-theme-bootstrap=y CONFIG_PACKAGE_miniupnpd=y # CONFIG_PACKAGE_odhcpd-ipv6only is not set # CONFIG_PACKAGE_opkg is not set CONFIG_PACKAGE_rpcd=y CONFIG_PACKAGE_rpcd-mod-rrdns=y CONFIG_PACKAGE_sqm-scripts=y CONFIG_PACKAGE_tc=y CONFIG_PACKAGE_uhttpd=y CONFIG_STRIP_KERNEL_EXPORTS=y CONFIG_TARGET_SQUASHFS_BLOCK_SIZE=256 CONFIG_USE_MKLIBS=y CONFIG_PACKAGE_kmod-nf-ipt6=y CONFIG_PACKAGE_libip6tc=y ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
