[OpenWrt-Devel] (no subject)
Code de admin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] firewall3: Improve ipset support
This patch is an attempt at improving the ipset support in firewall3.
The following changes have been made:
* The enabled option did not work properly for ipsets, as it was not
checked on create/destroy of a set. After this commit, sets are only
created/destroyed if enabled is set to true.
* Add support for reloading, or recreating, ipsets on firewall reload.
By setting "reload_set" to true, the set will be destroyed and then
re-created when the firewall is reloaded. My use-case for "reload_set"
was to reset sets populated by dnsmasq, without having to restart the
firewall or resort to scripts.
* Add support for the counters and comment extensions. By setting
"counters" or "comment" to true, then counters or comments are added to
the set.
Signed-off-by: Kristian Evensen
---
ipsets.c | 35 +--
ipsets.h | 6 --
main.c| 16 +++-
options.h | 4
utils.c | 5 +
5 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/ipsets.c b/ipsets.c
index b73c3d2..49ba672 100644
--- a/ipsets.c
+++ b/ipsets.c
@@ -21,6 +21,9 @@
const struct fw3_option fw3_ipset_opts[] = {
FW3_OPT("enabled", bool, ipset, enabled),
+ FW3_OPT("reload_set",bool, ipset, reload_set),
+ FW3_OPT("counters", bool, ipset, counters),
+ FW3_OPT("comment", bool, ipset, comment),
FW3_OPT("name", string, ipset, name),
FW3_OPT("family",family, ipset, family),
@@ -56,6 +59,8 @@ enum ipset_optflag {
OPT_HASHSIZE = (1 << 3),
OPT_MAXELEM = (1 << 4),
OPT_FAMILY= (1 << 5),
+ OPT_COUNTERS = (1 << 6),
+ OPT_COMMENT = (1 << 7),
};
struct ipset_type {
@@ -204,6 +209,10 @@ check_types(struct uci_element *e, struct fw3_ipset *ipset)
static bool
check_ipset(struct fw3_state *state, struct fw3_ipset *ipset, struct
uci_element *e)
{
+ if (!ipset->enabled) {
+ return false;
+ }
+
if (ipset->external)
{
if (!*ipset->external)
@@ -253,6 +262,9 @@ fw3_alloc_ipset(struct fw3_state *state)
INIT_LIST_HEAD(>entries);
ipset->enabled = true;
+ ipset->reload_set = false;
+ ipset->counters = false;
+ ipset->comment = false;
ipset->family = FW3_FAMILY_V4;
list_add_tail(>list, >ipsets);
@@ -389,6 +401,12 @@ create_ipset(struct fw3_ipset *ipset, struct fw3_state
*state)
if (ipset->hashsize > 0)
fw3_pr(" hashsize %u", ipset->hashsize);
+ if (ipset->counters)
+ fw3_pr(" counters");
+
+ if (ipset->comment)
+ fw3_pr(" comment");
+
fw3_pr("\n");
list_for_each_entry(entry, >entries, list)
@@ -398,7 +416,8 @@ create_ipset(struct fw3_ipset *ipset, struct fw3_state
*state)
}
void
-fw3_create_ipsets(struct fw3_state *state)
+fw3_create_ipsets(struct fw3_state *state, enum fw3_family family,
+ bool reload_set)
{
int tries;
bool exec = false;
@@ -410,6 +429,10 @@ fw3_create_ipsets(struct fw3_state *state)
/* spawn ipsets */
list_for_each_entry(ipset, >ipsets, list)
{
+ if (ipset->family != family ||
+ (reload_set && !ipset->reload_set))
+ continue;
+
if (ipset->external)
continue;
@@ -442,15 +465,23 @@ fw3_create_ipsets(struct fw3_state *state)
}
void
-fw3_destroy_ipsets(struct fw3_state *state)
+fw3_destroy_ipsets(struct fw3_state *state, enum fw3_family family,
+ bool reload_set)
{
int tries;
bool exec = false;
struct fw3_ipset *ipset;
+ if (state->disable_ipsets)
+ return;
+
/* destroy ipsets */
list_for_each_entry(ipset, >ipsets, list)
{
+ if (ipset->family != family ||
+ (reload_set && !ipset->reload_set))
+ continue;
+
if (!exec)
{
exec = fw3_command_pipe(false, "ipset", "-exist", "-");
diff --git a/ipsets.h b/ipsets.h
index 2ba862d..fec79f8 100644
--- a/ipsets.h
+++ b/ipsets.h
@@ -28,8 +28,10 @@
extern const struct fw3_option fw3_ipset_opts[];
void fw3_load_ipsets(struct fw3_state *state, struct uci_package *p, struct
blob_attr *a);
-void fw3_create_ipsets(struct fw3_state *state);
-void fw3_destroy_ipsets(struct fw3_state *state);
+void fw3_create_ipsets(struct fw3_state *state, enum fw3_family family,
+ bool reload_set);
+void fw3_destroy_ipsets(struct fw3_state *state, enum fw3_family family,
+ bool reload_set);
struct fw3_ipset * fw3_lookup_ipset(struct fw3_state *state, const char *name);
diff --git a/main.c b/main.c
index 1410fef..8d9a2e8 100644
--- a/main.c
+++ b/main.c
@@ -224,8 +224,10 @@
[OpenWrt-Devel] [PATCH] include: add KERNEL_ENTRY to TARGET_VARS
This will allow us to override the variable from within a Device template. Signed-off-by: Christian Lamparter --- include/image.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/image.mk b/include/image.mk index 4851a71bcd..aea27c0458 100644 --- a/include/image.mk +++ b/include/image.mk @@ -388,8 +388,8 @@ endef DEFAULT_DEVICE_VARS := \ DEVICE_NAME KERNEL KERNEL_INITRAMFS KERNEL_SIZE KERNEL_INITRAMFS_IMAGE \ - KERNEL_LOADADDR DEVICE_DTS DEVICE_DTS_CONFIG DEVICE_DTS_DIR BOARD_NAME \ - CMDLINE UBOOTENV_IN_UBI KERNEL_IN_UBI \ + KERNEL_ENTRY KERNEL_LOADADDR DEVICE_DTS DEVICE_DTS_CONFIG DEVICE_DTS_DIR \ + BOARD_NAME CMDLINE UBOOTENV_IN_UBI KERNEL_IN_UBI \ BLOCKSIZE PAGESIZE SUBPAGESIZE VID_HDR_OFFSET \ UBINIZE_OPTS UIMAGE_NAME UBINIZE_PARTS \ SUPPORTED_DEVICES IMAGE_METADATA -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 0/6] x86: switch to generic image generation code and
On 06.02.2019 16:08, Tomasz Maciej Nowak wrote:
W dniu 04.02.2019 o 09:29, Lucian Cristian pisze:
On 13.01.2019 23:49, Tomasz Maciej Nowak wrote:
This is aftermath of partially failed series [1].
When I was searching for ways to upgrade of bootloader on existing
OpenWrt installations, I noticed that it'll be difficult to add this
feature within existing code creating x86 target images. I decided to
switch this code to generic one, wich is used in most of the OpenWrt
targets. Both of the chages are rather intrusive hence te RFC tag.
[...]
rename target/linux/x86/image/{grub.cfg => grub-pc.cfg} (57%)
create mode 100644 target/linux/x86/image/legacy.mk
delete mode 100644 target/linux/x86/legacy/profiles/000-Generic.mk
tested on systems with multiple drives and multiple partitions, the only thing
is that the target images will always be gziped, this is annoying on other
targets too, also needs a rebase
Thank You for testing.
The generated images are gziped because they are built by default and this will
save space and bandwidth, maybe this can be turned off by default and enabling
it would be responsibility of buildbots, this would need some input of someone
responsible for infrastructure.
I'll rebase and add minor improvements to this series after sorting out some of
my pending patches.
Regards
Regards, Tomasz.
selecting ext4, gzip option will appear and deselecting gzip images has
no effect, before the option was available for squashfs also, anyway
this is another issue that is seen on other targets and if I remember
there was recently a PR related to this option on some target
Regards
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 0/6] x86: switch to generic image generation code and
W dniu 04.02.2019 o 09:29, Lucian Cristian pisze:
> On 13.01.2019 23:49, Tomasz Maciej Nowak wrote:
>> This is aftermath of partially failed series [1].
>> When I was searching for ways to upgrade of bootloader on existing
>> OpenWrt installations, I noticed that it'll be difficult to add this
>> feature within existing code creating x86 target images. I decided to
>> switch this code to generic one, wich is used in most of the OpenWrt
>> targets. Both of the chages are rather intrusive hence te RFC tag.
>> Please voice Your concerns and opinions.
>>
>> https://patchwork.ozlabs.org/cover/1000625
>>
>> Tomasz Maciej Nowak (6):
>> x86/grub2: move grub2 image creation to grub2 package
>> x86: switch image generation to new code
>> x86: remove obsolete profiles
>> x86: geode: shrink amount of default packages
>> x86/grub2: add bootloader upgrade on sysupgrade
>> grub2: add preinit hook for bootloader upgrade
>>
>> config/Config-images.in | 22 +-
>> include/image.mk | 1 -
>> package/boot/grub2/Makefile | 79 ++-
>> .../boot/grub2/files/81_upgrade_bootloader | 20 ++
>> .../boot/grub2/files}/grub-early.cfg | 0
>> target/linux/x86/64/profiles/000-Generic.mk | 15 --
>> target/linux/x86/64/target.mk | 2 +-
>> target/linux/x86/Makefile | 4 +-
>> .../x86/base-files/lib/upgrade/platform.sh | 27 ++-
>> .../linux/x86/generic/profiles/000-Generic.mk | 18 --
>> target/linux/x86/generic/target.mk | 2 +-
>> .../linux/x86/geode/profiles/000-Generic.mk | 20 --
>> target/linux/x86/geode/profiles/100-Geos.mk | 19 --
>> target/linux/x86/geode/target.mk | 14 +-
>> target/linux/x86/image/64.mk | 5 +
>> target/linux/x86/image/Makefile | 199 +++---
>> target/linux/x86/image/generic.mk | 8 +
>> target/linux/x86/image/geode.mk | 16 ++
>> target/linux/x86/image/grub-iso.cfg | 2 +-
>> .../linux/x86/image/{grub.cfg => grub-pc.cfg} | 4 +-
>> target/linux/x86/image/legacy.mk | 8 +
>> .../linux/x86/legacy/profiles/000-Generic.mk | 18 --
>> target/linux/x86/legacy/target.mk | 1 +
>> 23 files changed, 255 insertions(+), 249 deletions(-)
>> create mode 100644 package/boot/grub2/files/81_upgrade_bootloader
>> rename {target/linux/x86/image => package/boot/grub2/files}/grub-early.cfg
>> (100%)
>> delete mode 100644 target/linux/x86/64/profiles/000-Generic.mk
>> delete mode 100644 target/linux/x86/generic/profiles/000-Generic.mk
>> delete mode 100644 target/linux/x86/geode/profiles/000-Generic.mk
>> delete mode 100644 target/linux/x86/geode/profiles/100-Geos.mk
>> create mode 100644 target/linux/x86/image/64.mk
>> create mode 100644 target/linux/x86/image/generic.mk
>> create mode 100644 target/linux/x86/image/geode.mk
>> rename target/linux/x86/image/{grub.cfg => grub-pc.cfg} (57%)
>> create mode 100644 target/linux/x86/image/legacy.mk
>> delete mode 100644 target/linux/x86/legacy/profiles/000-Generic.mk
>>
> tested on systems with multiple drives and multiple partitions, the only
> thing is that the target images will always be gziped, this is annoying on
> other targets too, also needs a rebase
Thank You for testing.
The generated images are gziped because they are built by default and this will
save space and bandwidth, maybe this can be turned off by default and enabling
it would be responsibility of buildbots, this would need some input of someone
responsible for infrastructure.
I'll rebase and add minor improvements to this series after sorting out some of
my pending patches.
>
> Regards
>
Regards, Tomasz.
--
TMN
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] User space replacement for named GPIO exports kernel patch
Hi, there's open PR[A] on GitHub "kernel: move GPIO-add-named-gpio-exports.patch to generic" which has started discussion around this topic already and before digging into the possible solution deeper, I would like to get some feedback first (Maybe, that someone is already working on this also). It's clear, that this named gpio exports kernel patch was rejected by upstream long time ago, so we shouldn't probably carry it on forever, and we should probably start using libgpiod based solution instead. How to tackle this in the OpenWrt spirit? I see following options: 1. Use commandline utils from libgpiod (gpio-set, gpio-find etc.) and potentially add missing features to those utils - probably good enough for handling of outputs only 2. Add support for GPIO inputs/outputs using libgpiod to procd 3. Create gpiod and add support for GPIO inputs/outputs using libgpiod 4. Other A. https://github.com/openwrt/openwrt/pull/1366 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices
On Tue, 15 Jan 2019 at 15:42, Daniel Golle wrote: > > Hi Jonas, > > On Mon, Jan 07, 2019 at 03:48:29PM +0100, Daniel Golle wrote: > > On Mon, Jan 07, 2019 at 02:39:26PM +, Jonas Gorski wrote: > > > On Mon, 7 Jan 2019 at 14:21, Daniel Golle wrote: > > > > > > > > On Mon, Jan 07, 2019 at 01:17:34PM +, Jonas Gorski wrote: > > > > > On Mon, 7 Jan 2019 at 11:42, Petr Štetiar wrote: > > > > > > > > > > > > Daniel Golle [2019-01-07 10:03:09]: > > > > > > > > > > > > Hi, > > > > > > > > > > > > > One. The MT7621 EVB. The TP-LINK RE350 v1 can probably be > > > > > > > converted to > > > > > > > a more sane flash partition layout to gain another megabyte or so. > > > > > > > > > > > > I've looked only at mt7621, so this was just example from one > > > > > > subtarget of > > > > > > ramips target. So I tend to believe, that there's quite more such > > > > > > cases hidden > > > > > > in the tree. Please correct me if I'm wrong. > > > > > > > > > > > > > Why specific devices? Wouldn't all devices with the resources > > > > > > > (which > > > > > > > boils down to !SMALL_FLASH) be potentially more useful with those > > > > > > > kernel features enabled? > > > > > > > > > > > > You currently can't use !SMALL_FLASH, because this is > > > > > > target/subtarget > > > > > > specific feature, not per device feature. I think, that in order to > > > > > > use this > > > > > > feature, you would need to convert/fix all devices like that > > > > > > TP-Link RE350 > > > > > > from all (sub)targets into tiny subtarget and then you could freely > > > > > > use > > > > > > !SMALL_FLASH. > > > > > > > > > > I agree with not abusing small_flash for that. It has a clear defined > > > > > meaning, and shouldn't have unrelated side effects. > > > > > > > > So what else would the SMALL_FLASH symbol be used for then? > > > > A quick grep reveals that currently already quite a few kernel config > > > > defaults are set according to SMALL_FLASH, see > > > > > > > > origin/master:Config-kernel.in- > > > > origin/master:Config-kernel.in-config KERNEL_SWAP > > > > origin/master:Config-kernel.in- bool "Support for paging of anonymous > > > > memory (swap)" > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > -- > > > > origin/master:Config-kernel.in- > > > > origin/master:Config-kernel.in-config KERNEL_KALLSYMS > > > > origin/master:Config-kernel.in- bool "Compile the kernel with symbol > > > > table information" > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > -- > > > > origin/master:Config-kernel.in- > > > > origin/master:Config-kernel.in-config KERNEL_DEBUG_INFO > > > > origin/master:Config-kernel.in- bool "Compile the kernel with debug > > > > information" > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > -- > > > > origin/master:Config-kernel.in-config KERNEL_ELF_CORE > > > > origin/master:Config-kernel.in- bool "Enable process core dump support" > > > > origin/master:Config-kernel.in- select KERNEL_COREDUMP > > > > origin/master:Config-kernel.in: default y if !SMALL_FLASH > > > > ... > > > > > > Most of these option only influence the size of the kernel, and have > > > no further runtime side effects. Also small_flash has impact on the > > > compression options used. > > > > They sure do, cache size on small CPUs is a very finite resource > > and having a kernel with debug symbols will make things slower, of > > course. SWAP also makes every single malloc call more expensive and > > is just as well only useful on devices with block storage (ok, and > > zramswap, but lets not talk about that). > > > > > > > > > > > > > > > > > > > I think a new opt-in symbol for those targets with hardware > > > > > virtualization support and/or beefy enough cpus would make more sense. > > > > > Those virtualization options (probably) don't come for free, they will > > > > > have also a memory and performance impact even when not actively used. > > > > > How much that is (and if this assumption is true) would be nice to > > > > > have in the PR/patch for it. > > > > > > > > This is not about virtualization and none of the features selected > > > > requires any special hardware support apart from the few extra > > > > kilobytes of flash and memory. You are still right, it doesn't come > > > > all for free at runtime in terms of CPU cycles, but the impact is > > > > hardly measurable. > > > > > > > > But sure, I understand that this can be opt-in, so lets call it > > > > 'full_kernel' or something like that and have target maintainers > > > > decide themselves. In the picture I get after browsing through > > > > all targets, it would still end up such that > > > > full_kernel == !small_flash is true for all cases. > > > > > > "Full kernel" really has no real meaning and would describe > > > everything. The name should clearly describe the (non-default) feature > > > set it enables. > > > > But they are not even necessarily related, just closer to the vanilla > >
