[PATCH] iprule: add support for uidrange
Allow for per-user routing policies via the uidrange iprule option.
Option allows for a single UID or range of UIDs.
Signed-off-by: Matthew Hagan
---
iprule.c | 13 -
iprule.h | 5 +
system-linux.c | 8
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/iprule.c b/iprule.c
index b9e16a5..57976b1 100644
--- a/iprule.c
+++ b/iprule.c
@@ -44,6 +44,7 @@ enum {
RULE_ACTION,
RULE_GOTO,
RULE_SUP_PREFIXLEN,
+ RULE_UIDRANGE,
RULE_DISABLED,
__RULE_MAX
};
@@ -59,6 +60,7 @@ static const struct blobmsg_policy rule_attr[__RULE_MAX] = {
[RULE_FWMARK] = { .name = "mark", .type = BLOBMSG_TYPE_STRING },
[RULE_LOOKUP] = { .name = "lookup", .type = BLOBMSG_TYPE_STRING },
[RULE_SUP_PREFIXLEN] = { .name = "suppress_prefixlength", .type =
BLOBMSG_TYPE_INT32 },
+ [RULE_UIDRANGE] = { .name = "uidrange", .type = BLOBMSG_TYPE_STRING },
[RULE_ACTION] = { .name = "action", .type = BLOBMSG_TYPE_STRING },
[RULE_GOTO] = { .name = "goto", .type = BLOBMSG_TYPE_INT32 },
[RULE_DISABLED] = { .name = "disabled", .type = BLOBMSG_TYPE_BOOL },
@@ -201,7 +203,7 @@ iprule_add(struct blob_attr *attr, bool v6)
struct blob_attr *tb[__RULE_MAX], *cur;
struct iprule *rule;
char *iface_name;
- int af = v6 ? AF_INET6 : AF_INET;
+ int af = v6 ? AF_INET6 : AF_INET, ret;
blobmsg_parse(rule_attr, __RULE_MAX, tb, blobmsg_data(attr),
blobmsg_data_len(attr));
@@ -282,6 +284,15 @@ iprule_add(struct blob_attr *attr, bool v6)
rule->flags |= IPRULE_SUP_PREFIXLEN;
}
+ if ((cur = tb[RULE_UIDRANGE]) != NULL) {
+ ret = sscanf(blobmsg_get_string(cur), "%u-%u",
>uidrange_start, >uidrange_end);
+ if (ret == 1)
+ rule->uidrange_end = rule->uidrange_start;
+ else if (ret != 2)
+ DPRINTF("Failed to parse UID range: %s\n", (char *)
blobmsg_data(cur));
+ rule->flags |= IPRULE_UIDRANGE;
+ }
+
if ((cur = tb[RULE_ACTION]) != NULL) {
if (!system_resolve_iprule_action(blobmsg_data(cur),
>action)) {
DPRINTF("Failed to parse rule action: %s\n", (char *)
blobmsg_data(cur));
diff --git a/iprule.h b/iprule.h
index 89b94b4..6d91d06 100644
--- a/iprule.h
+++ b/iprule.h
@@ -63,6 +63,9 @@ enum iprule_flags {
/* rule suppresses results by prefix length */
IPRULE_SUP_PREFIXLEN= (1 << 13),
+
+ /* rule specifies uidrange */
+ IPRULE_UIDRANGE = (1 << 14),
};
struct iprule {
@@ -102,6 +105,8 @@ struct iprule {
unsigned int lookup;
unsigned int sup_prefixlen;
+ unsigned int uidrange_start;
+ unsigned int uidrange_end;
unsigned int action;
unsigned int gotoid;
};
diff --git a/system-linux.c b/system-linux.c
index 654f2ac..a14d779 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -2954,6 +2954,14 @@ static int system_iprule(struct iprule *rule, int cmd)
if (rule->flags & IPRULE_SUP_PREFIXLEN)
nla_put_u32(msg, FRA_SUPPRESS_PREFIXLEN, rule->sup_prefixlen);
+ if (rule->flags & IPRULE_UIDRANGE) {
+ struct fib_rule_uid_range uidrange = {
+ rule->uidrange_start,
+ rule->uidrange_end
+ };
+ nla_put(msg, FRA_UID_RANGE, sizeof(uidrange), );
+ }
+
if (rule->flags & IPRULE_GOTO)
nla_put_u32(msg, FRA_GOTO, rule->gotoid);
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Mutt configuration options being auto-enabled by default
Hi Stijn, Thanks for pointing this out. The same also applies for postfix. I have submitted a PR at for both: https://github.com/openwrt/packages/pull/17087 Regards, Matthew On 06/11/2021 19:43, Stijn Segers wrote: > Hi Matthew, > > It looks like you expanded Mutt support with commit > 19877a952d1136e134547835d335ffc771917ccc. > > I just refreshed my config on master and was a bit surprised to see Mutt > configuration options enabled by default. I haven't enabled mutt as a > package, so I don't think these should be popping up? > > I'm noticing those three options have each a 'default y', but shouldn't > these options be exposed (and activated) only when Mutt is selected as a > package? > > @@ -4298,6 +4311,18 @@ CONFIG_PACKAGE_luci-lib-nixio_notls=y > # CONFIG_PACKAGE_msmtp-nossl is not set > # CONFIG_PACKAGE_msmtp-queue is not set > # CONFIG_PACKAGE_mutt is not set > + > +# > +# Select mutt build options > +# > +CONFIG_MUTT_POP=y > +CONFIG_MUTT_IMAP=y > +# CONFIG_MUTT_SMTP is not set > +# CONFIG_MUTT_SASL is not set > +# CONFIG_MUTT_GNUTLS is not set > +CONFIG_MUTT_OPENSSL=y > +# end of Select mutt build options > + > # CONFIG_PACKAGE_nail is not set > # CONFIG_PACKAGE_opendkim is not set > # CONFIG_PACKAGE_opendkim-tools is not set > > Thanks > > Stijn > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] bcm53xx: remove extsw interface on Linksys EA9500
On 23/10/2021 22:31, Arınç ÜNAL wrote:
> On 24/10/2021 00:14, Rafał Miłecki wrote:
>> On 2021-10-23 23:09, Arınç ÜNAL wrote:
>>> On 23/10/2021 23:35, Rafał Miłecki wrote:
On 2021-10-23 21:56, Arınç ÜNAL wrote:
> Remove extsw interface from the bridge as it's used as a master
> interface by the DSA driver.
According to Vivek it's required, I explicitly asked about it:
https://forum.openwrt.org/t/build-for-linksys-ea9500/1817/984
>>>
>>> I suspect the reason for this happening is:
# For kernels earlier than v5.12, the master interface needs to be
# brought up manually before the slave
ports.https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#configuration-with-tagging-support
>>>
>>> I have a branch running kernel 5.15 on bcm53xx on Asus RT-AC88U. All
>>> interfaces work fine without adding extsw to the bridge.
>>> https://github.com/arinc9/openwrt/commit/26019530962967079c3772dc3a2ee57b68662bab
>>>
>>>
>>> A fix should be implemented in a different way than including the
>>> extsw interface on the bridge (an initscript would do).
>>
>> I think we have backported related commit, unless it's a different one.
>>
>> See commit 2e17c710954b ("kernel: Backport patch to automatically
>> bring up DSA master when opening user port")
>>
>> I prefer the right fix of course, but you need to point me to it first :)
>
> I'm going to investigate further with Vivek. Should I send the second
> patch in the series as a single one?
For reference, no additional config is needed for the MX65. sw0/sw1 come
up by themselves[1].
https://github.com/clayface/openwrt/commit/41203464f26ac93d06d5134e899dfd47bd4aa6a4#diff-52f037ccd42c5073f1aec02c5e0b33768c675b39cf04f244319db09e7a03539f
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
On 09/09/2021 01:04, Stefan Lippers-Hollmann wrote: > I'm not really in a position to give advice, but -imho- unless those > other targets have at least proof-of-concept code for using qca8k on > their devices /working/ and an intention to migrate to DSA for these > devices within reasonable time frame, I personally wouldn't overthink > this (yet). > > There is no problem with adding these patches for ipq806x first, and then > moving the patches from ipq806x to generic later, when there is something > tangible for ath79 or bcm53xx (as part of their PRs/ patch series to > migrate from swconfig to qca8k). In fact we are at this stage with the bcm53xx Meraki MX65[1] which is just about ready to go, but requires part of Ansuel's series which is currently destined for ipq806x only in his PR[2]. This may be held up while more devices are tested so my suggestion is to get the series into generic/backports so the MX65 can use it while testing continues on other platforms. Moving it later would mean having some duplication in the bcm53xx/ipq806x platform directories until then. Perhaps that is acceptable if it will only be temporary? The other, perhaps main question is whether reintroducing dsa.mk is the correct approach. Adding the kmod to the relevant platform's modules.mk or kernel/linux/modules/netdevices.mk are alternatives. I am happy to submit a patch for whichever option is preferred, though whether this should be done within my PR, as a new PR or on the mailing list I'm not sure. I also don't wish to interfere with Ansuel's work so would prefer to have the idea accepted by him first before doing anything. [1] https://github.com/openwrt/openwrt/pull/3996 [2] https://github.com/openwrt/openwrt/pull/4036 Matthew ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Question about qca8k dsa driver and path to follow
On 07/09/2021 17:48, ansuelsmth at gmail.com (Ansuel Smith) wrote: > > Problem is that excluding ipq806x, not every device uses the qca8k > switch and including > that by default seems wrong. It was suggested to compile that as a > module (with optionally > the dsa subsistem as a kmod) so the driver (and dsa) can be installed > only on the required > devices. So the idea is to reintroduce the dsa.mk kernel modules > makefile used some time ago > for the mvebu target. dsa.mk was removed with the reasoning that "Targets that need switch drivers should select them in their kernel config." There are a few cases where this isn't appropriate since the switch used is not commonly used with that target. This has now come up with the bcm53xx Meraki MX65 which has a QCA8337 switch and thus needs a qca8k kmod. There are several devices where their switch swconfig driver is a kmod so the same issue will arise, for example the Ubiquiti ES-8XP (ATH79) with a BCM53128 switch. > > In short the main concerns are: > 1. Is it right to move qca8k patch to generic? > 2. Should we move it to a kmod with the dsa subsystem or compile the > driver built-in ? For 1 and 2 (the kmod option) I see no reason not to do this. In the case of the MX65, we can justify doing this immediately since the device has been tested extensively, so the driver will be used on one platform with expectation of more platforms in the very near future. I would therefore propose submitting your upstream series to backports-5.10. For dsa.mk we can enable by target if necessary. What do you think? > Also another concern would be: > 1. Can we consider moving the ar8227 swconfig driver to kmod? > That would make the transition easier since we will be able to include > both the required > nodes in the dts and make the user decide what to use. (by > removing/installing the required > kmod). Is there any situation where the user would need to decide whether DSA or swconfig should be used, assuming both are working? A kmod may be justified for devices having issues supporting the DSA driver. Another option is to have DSA/non-DSA subtargets but there seems to be pushback against this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
