Re: here we are again: real name 'discussion'

[Etienne Champetier]

Le mar. 16 avr. 2024 à 10:34, Paul D  a écrit :
>
> On 2024-03-27 23:56, Etienne Champetier wrote:
> >
> > As this is a legal issue, should we get SFC opinion first ?
> >
> > Etienne
> >
>
> Is this happening?

Sorry I missed your last ping
This was an open question, I don't know who to contact at SFC

Looking at old emails, John, Jo and Hauke are our liaison with SFC

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

Re: [RFC netifd 1/2] interface-ip: mask out host bits in IPv4 route targets

[Etienne Champetier]

Hi Jo,

Le jeu. 24 août 2023 à 08:55, Jo-Philipp Wich  a écrit :
>
> The kernel will reject attempts to install routes with target addresses
> having host bits set with an "Invalid prefix for given prefix length"
> error.
>
> A route configuration like the one below will silently fail to apply:
>
> config route
> option interface lan
> option target 10.40.40.1/24
>
> Attempting to do the same with iproute2 will fail as well:
>
> # ip route add 10.40.40.1/24 dev br-lan
> Error: Invalid prefix for given prefix length.
>
> However, for IPv6 route targets with set host bits are allowed:
>
> # ip -6 route add 3000::1/64 via fe80::1234:5678:9abcd:ef01 dev br-lan
> # ip -6 route list 3000::1/64
> 3000::/64 via fe80::1234:5678:9abc:def1 dev br-lan metric 1024 pref medium
>
> In order to stay consistent here, and to avoid unecessary configuration
> pitfalls, make netifd more lenient and simply mask out excess host bits
> while parsing IPv4 route configuration.
>
> Signed-off-by: Jo-Philipp Wich 
> ---
>  interface-ip.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/interface-ip.c b/interface-ip.c
> index a06a514..fee29a9 100644
> --- a/interface-ip.c
> +++ b/interface-ip.c
> @@ -441,6 +441,10 @@ interface_ip_add_route(struct interface *iface, struct 
> blob_attr *attr, bool v6)
> DPRINTF("Failed to parse route target: %s\n", (char 
> *) blobmsg_data(cur));
> goto error;
> }
> +
> +   /* Mask out IPv4 host bits to avoid "Invalid prefix for given 
> prefix length" */
> +   if (af == AF_INET && route->mask < 32)
> +   route->addr.in.s_addr &= ((1u << route->mask) - 1);

Maybe print a warning / info message if the route was fixed

Etienne

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

Re: [openwrt/openwrt] urngd: update to the latest master

[Etienne Champetier]

Hello Rafał,

Le mar. 25 juil. 2023 à 10:05, LEDE Commits
 a écrit :
>
> rmilecki pushed a commit to openwrt/openwrt.git, branch master:
> https://git.openwrt.org/c74b5e09e692839b39c8325b5f8dc5f2a3b3896c
>
> commit c74b5e09e692839b39c8325b5f8dc5f2a3b3896c
> Author: Rafał Miłecki 
> AuthorDate: Tue Jul 25 09:51:35 2023 +0200
>
> urngd: update to the latest master

Is urngd still needed/relevant given the 'recent" improvements in
linux random generator ?

Best
Etienne

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

Docker is sunsetting Free Team organizations

[Etienne Champetier]

Hi All, Paul

Docker wants to shutdown free team organisations, so this include
docker.io/openwrtorg
Here the announcement:
https://web.docker.com/rs/790-SSB-375/images/privatereposfaq.pdf

Those 3 repos seem active, do we mirror the content somewhere else ?
(gitlab/github)
docker.io/openwrtorg/imagebuilder
docker.io/openwrtorg/sdk
docker.io/openwrtorg/rootfs

Do we want to apply for "Docker-Sponsored Open Source Program"
https://www.docker.com/community/open-source/application/

Best
Etienne

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

Re: [PATCH] urandom-seed: use seedrng for seeding the random number generator

[Etienne Champetier]

Le mer. 1 févr. 2023 à 10:29, Andre Heider  a écrit :
>
> On 04/04/2022 21:35, Etienne Champetier wrote:
> > Hi Jason,
> >
> > Le lun. 4 avr. 2022 à 14:39, Jason A. Donenfeld  a écrit :
> >>
> >> Hey Etienne,
> >>
> >> On Tue, Mar 29, 2022 at 7:21 AM Jason A. Donenfeld  wrote:
> >>>
> >>> Hi Etienne,
> >>>
> >>> On Tue, Mar 29, 2022 at 1:06 AM Etienne Champetier
> >>>  wrote:
> >>>>> Oh that's an interesting set of considerations and it's possible I
> >>>>> didn't understand some aspect of this. Most OSes should call seedrng
> >>>>> once at boot and once at shutdown.
> >>>>
> >>>> As routers are always on devices, it's rare to have clean shutdown.
> >>>> Personally, my routers boot after an upgrade or after a power loss,
> >>>> so they almost never shutdown properly.
> >>>
> >>> That's a good point indeed.
> >>>
> >>>>> 1) read seed into memory, delete seed from disk, write into rng &
> >>>>> credit if good seed, write new seed to disk; repeat at shutdown/some
> >>>>> other time
> >>>>> 2) read seed into memory, write into rng w/o crediting, re-use the
> >>>>> same seed next boot
> >>>>
> >>>> Before this patch we had 2 and users could opt-in to renew seed on
> >>>> each boot, so closer to 1.
> >>>
> >>> I guess the issue is that the implementation of (1) was somewhat
> >>> non-optimal, but not exactly catastrophic either.
> >>>
> >>>> Looking at random.c, I would love add_device_randomness() behavior.
> >>>> Maybe it was already answered on LKML,
> >>>> but why can't writes to /dev/urandom from a process with CAP_SYS_ADMIN
> >>>> be mixed in right away a la add_device_randomness() without being 
> >>>> credited ?
> >>>> This would not init the RNG faster, but this would make early
> >>>> /dev/urandom reads "safer".
> >>>
> >>> add_device_randomness() does not mix in immediately. It goes into the
> >>> entropy pool, but that doesn't get extracted into a new key until the
> >>> next reseeding. It does get mixed in directly for crng_init=0, but not
> >>> for crng_init=1 or crng_init=2, which is a big gap. Making
> >>> /dev/urandom writes behave like that for crng_init=0 doesn't address
> >>> the crng_init=1 and crng_init=2 cases, unfortunately. The bigger
> >>> problem, though, is that some users of /dev/urandom credit the entropy
> >>> via the RNDADDTOENTCNT ioctl _afterwards_. If we mixed it directly in,
> >>> then programs with the pattern of write 4 bytes, credit 32 bits,
> >>> writes 4 bytes, credit 32 bits, etc could have those 4 written bytes
> >>> brute forced each time in what's called a "premature next". For that
> >>> reason the key is only modified when 256 bits have accumulated first.
> >>>
> >>>> I'm fine with writing on each boot, but as we can't rely on shutdown,
> >>>> what we could do with the seeds:
> >>>> 1) load seed.no-credit, leave it on disk
> >>>> 2) mv seed.credit seed.no-credit && load seed.no-credit (and credit it)
> >>>> 3) read from getrandom a new seed.credit
> >>>>
> >>>> This would allow to always keep a seed on disk, only use seed.credit 
> >>>> once,
> >>>> and actually write seed.credit.
> >>>> I would get rid of the whole hashing part as all our seeds would come
> >>>> from getrandom().
> >>>
> >>> If possible, it's better to not leave a seed on disk after using it,
> >>> even if not credited. If that's the only entropy, it's better to
> >>> "forget" it after use, so that you can't compromise past secrets. At
> >>> the very least, if you have poor entropy, you can replace the seed
> >>> with HASH(seed), so at least it ratchets forward. Another thing to
> >>> consider is that if you _do_ credit it, that'll initialize the RNG, so
> >>> getrandom() automatically works without blocking. These two
> >>> observations have lead to seedrng's current scheme, where the sequence
> >>> is:
> >>>
> >>> - load
> >>> - delete
> >>> - seed & credit, or seed & don't credit, depending
> >>&

Re: CVE-2020-15888 - libtasn1

[Etienne Champetier]

Hi Peter,

Can you resend this as a proper patch ready to be applied ?
Or as a PR on Github if this is easier for you ?

Le jeu. 3 nov. 2022 à 10:26, Peter Naulls  a écrit :
>
>
> https://nvd.nist.gov/vuln/detail/CVE-2021-46848
>
> Against openwrt-22.03
>
> --- /dev/null
> +++ b/libs/libtasn1/patches/099-CVE-2020-15888.patch

CVE link and patch name do not match

> @@ -0,0 +1,11 @@
> +--- a/lib/int.h2022-11-03 10:15:01.065656767 -0400
>  b/lib/int.h2022-11-03 10:15:39.333658083 -0400
> +@@ -97,7 +97,7 @@
> + #define ETYPE_TAG(etype) (_asn1_tags[etype].tag)
> + #define ETYPE_CLASS(etype) (_asn1_tags[etype].class)
> + #define ETYPE_OK(etype) (((etype) != ASN1_ETYPE_INVALID && \
> +-  (etype) <= _asn1_tags_size && \
> ++  (etype) < _asn1_tags_size && \
> +   _asn1_tags[(etype)].desc != NULL)?1:0)
> +
> + #define ETYPE_IS_STRING(etype) ((etype == ASN1_ETYPE_GENERALSTRING || \

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

Re: Security changes - restricting uhttpd addresses

[Etienne Champetier]

Le mar. 25 oct. 2022 à 17:47, Michael Richardson
 a écrit :
>
>
> Peter Naulls  wrote:
> > Nevertheless, the security people are looking at this config
> > statically, and not seeing that it's bound to the LAN interface IP
> > only.
>
> I don't think they are really security people, but...
>
> > For my use, I've changed the default binding to the LAN IP, and also
> > added another init.d script to check the current LAN address, and
> > update the uhttpd config if need be and then restart it (and add
> > a config hook to the network config). Obviously this isn't
> > very satisfactory, open to better suggestions here.
>
> So, it needs to bound to *all* the IPv6 "LAN" IPs.
> That means:
>   a) the ULA that is created.
>   b) the LL-IPv6 that are always present
>   c) the GUA IPv6 that is delegated
>
> And when we make guest LANs, we may also need to bind it to that, because
> there are things that guests might need to know, such as seeing the status
> page to see if the network is up.
>
> > It might also be better if uhttpd could be configured to bind
> > to a specific interface rather than knowing its IP upfront, but
> > that might be impractical.
>
> It's totally impractical.

Can't we bind to 0.0.0.0 and use SO_BINDTODEVICE to make sure it's
really only responding on the right interface ?
With complicated routing setup it changes a bit the behavior, but this
might be the simplest option if we don't want to rely only on the
firewall


> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-

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

Re: [PATCH] bridge: Support nf_call_{ip,ip6,arp}tables attributes

[Etienne Champetier]

Hi Maximilian

Le mar. 13 sept. 2022, 17:23, Maximilian Riemensberger
 a écrit :
>
> The bridge driver allows passing bridged frames to netfilter.  Add
> bridge config options nf_call_iptables, nf_call_ip6tables,
> nf_call_arptables to opt in.

You should have a look at using nftables instead,
no need for those coarse grain options and way more flexible / powerful.
https://wiki.nftables.org/wiki-nftables/index.php/Bridge_filtering

Here an example switching from iptables + br_netfilter to nftables +
table bridge:
https://github.com/nccgroup/phantap/commit/b066ce2c2bb21038958a117b3b67413e9a0ea0a3
https://github.com/openwrt/packages/commit/66b7c19992688b924d2ecbbbc20781b32a82452f

Etienne

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

Re: Setting Linux Capabilities

[Etienne Champetier]

Hi Ravi,

Le mar. 16 août 2022 à 07:52, Ravi Paluri (QUIC)
 a écrit :
>
> Hi Team,
> We would like to set below capabilities for our process.
> * CAP_NET_ADMIN
> * CAP_NET_RAW
>
> Do we need to use APIs mentioned in https://linux.die.net/man/3/cap_set_flag 
> and https://linux.die.net/man/3/cap_set_proc to get this functionality?
>
> On Systemd, I see that this can be achieved by writing below lines in a 
> service file.
> CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
> AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW
>
> So, would like to know if there is any thing similar that can be done in 
> procd init scripts?

OpenWrt has procd-ujail, to set capabilities with it:
https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/sysntpd#L80
https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/files/ntpd.capabilities

Best
Etienne

> Thanks,
> Ravi

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

[PATCH ubus] lua: add optional path filter to objects() method

[Etienne Champetier]

'ubus list []' passes the path to ubusd,
this commit fix the lua bindings to do the same

Signed-off-by: Etienne Champetier 
---
 lua/ubus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lua/ubus.c b/lua/ubus.c
index e2bb081..07b816d 100644
--- a/lua/ubus.c
+++ b/lua/ubus.c
@@ -286,9 +286,10 @@ ubus_lua_objects(lua_State *L)
 {
int rv;
struct ubus_lua_connection *c = luaL_checkudata(L, 1, METANAME);
+   const char *path = (lua_gettop(L) >= 2) ? luaL_checkstring(L, 2) : NULL;
 
lua_newtable(L);
-   rv = ubus_lookup(c->ctx, NULL, ubus_lua_objects_cb, L);
+   rv = ubus_lookup(c->ctx, path, ubus_lua_objects_cb, L);
 
if (rv != UBUS_STATUS_OK)
{
-- 
2.35.1


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

Re: [PATCH] urandom-seed: use seedrng for seeding the random number generator

[Etienne Champetier]

Hi Jason,

Le lun. 4 avr. 2022 à 14:39, Jason A. Donenfeld  a écrit :
>
> Hey Etienne,
>
> On Tue, Mar 29, 2022 at 7:21 AM Jason A. Donenfeld  wrote:
> >
> > Hi Etienne,
> >
> > On Tue, Mar 29, 2022 at 1:06 AM Etienne Champetier
> >  wrote:
> > > > Oh that's an interesting set of considerations and it's possible I
> > > > didn't understand some aspect of this. Most OSes should call seedrng
> > > > once at boot and once at shutdown.
> > >
> > > As routers are always on devices, it's rare to have clean shutdown.
> > > Personally, my routers boot after an upgrade or after a power loss,
> > > so they almost never shutdown properly.
> >
> > That's a good point indeed.
> >
> > > > 1) read seed into memory, delete seed from disk, write into rng &
> > > > credit if good seed, write new seed to disk; repeat at shutdown/some
> > > > other time
> > > > 2) read seed into memory, write into rng w/o crediting, re-use the
> > > > same seed next boot
> > >
> > > Before this patch we had 2 and users could opt-in to renew seed on
> > > each boot, so closer to 1.
> >
> > I guess the issue is that the implementation of (1) was somewhat
> > non-optimal, but not exactly catastrophic either.
> >
> > > Looking at random.c, I would love add_device_randomness() behavior.
> > > Maybe it was already answered on LKML,
> > > but why can't writes to /dev/urandom from a process with CAP_SYS_ADMIN
> > > be mixed in right away a la add_device_randomness() without being 
> > > credited ?
> > > This would not init the RNG faster, but this would make early
> > > /dev/urandom reads "safer".
> >
> > add_device_randomness() does not mix in immediately. It goes into the
> > entropy pool, but that doesn't get extracted into a new key until the
> > next reseeding. It does get mixed in directly for crng_init=0, but not
> > for crng_init=1 or crng_init=2, which is a big gap. Making
> > /dev/urandom writes behave like that for crng_init=0 doesn't address
> > the crng_init=1 and crng_init=2 cases, unfortunately. The bigger
> > problem, though, is that some users of /dev/urandom credit the entropy
> > via the RNDADDTOENTCNT ioctl _afterwards_. If we mixed it directly in,
> > then programs with the pattern of write 4 bytes, credit 32 bits,
> > writes 4 bytes, credit 32 bits, etc could have those 4 written bytes
> > brute forced each time in what's called a "premature next". For that
> > reason the key is only modified when 256 bits have accumulated first.
> >
> > > I'm fine with writing on each boot, but as we can't rely on shutdown,
> > > what we could do with the seeds:
> > > 1) load seed.no-credit, leave it on disk
> > > 2) mv seed.credit seed.no-credit && load seed.no-credit (and credit it)
> > > 3) read from getrandom a new seed.credit
> > >
> > > This would allow to always keep a seed on disk, only use seed.credit once,
> > > and actually write seed.credit.
> > > I would get rid of the whole hashing part as all our seeds would come
> > > from getrandom().
> >
> > If possible, it's better to not leave a seed on disk after using it,
> > even if not credited. If that's the only entropy, it's better to
> > "forget" it after use, so that you can't compromise past secrets. At
> > the very least, if you have poor entropy, you can replace the seed
> > with HASH(seed), so at least it ratchets forward. Another thing to
> > consider is that if you _do_ credit it, that'll initialize the RNG, so
> > getrandom() automatically works without blocking. These two
> > observations have lead to seedrng's current scheme, where the sequence
> > is:
> >
> > - load
> > - delete
> > - seed & credit, or seed & don't credit, depending
> > - save new seed, which may be creditable or not, depending on whether
> > previous things made the rng init
> >
> > It sounds like maybe a modification of your suggestion might be to make 
> > this:
> >
> > - load
> > - delete
> > - seed & credit, or seed & don't credit, depending
> > - save new seed using getrandom(0), so that it's always creditable
> >
> > Would that satisfy your concerns? Or are you also trying to preserve a
> > mode where the filesystem doesn't need to be written to on each boot?
> >
> >
> >
> > > /var is a symlink to /tmp
> >
> > Oh, then in these cleanups, we should change that /tmp/run t

Re: [PATCH] urandom-seed: use seedrng for seeding the random number generator

[Etienne Champetier]

Hey Jason,

Le lun. 28 mars 2022 à 13:04, Jason A. Donenfeld  a écrit :
>
> Hey Etienne,
>
> On Mon, Mar 28, 2022 at 10:19 AM Etienne Champetier
>  wrote:
> >
> > Hi All, Jason,
> >
> > @Petr Štetiar this merge was a bit too fast to get reviews ...
> > Some comments inline
>
> We can apply fixups on top, no big deal.
>
> > When urandom-seed was introduced in 2016 it was decided during review
> > that writing on each boot might cause too much wear to the flash.
> > Maybe we can say that 6 years later this is not a problem anymore, but
> > would love to have more devs comment
> > Old thread: 
> > https://www.mail-archive.com/lede-dev@lists.infradead.org/msg01225.html
> >
> > Now if I understand correctly, with this patch we are writing a seed
> > to flash twice per boot, in preinit/81_urandom_seed and in
> > init.d/urandom_seed.
> > Also there are good chances we will never have a seed.credit at all on
> > many devices,
> > would be great if seedrng had an option "writeseed" that blocks on 
> > getrandom().
>
> Oh that's an interesting set of considerations and it's possible I
> didn't understand some aspect of this. Most OSes should call seedrng
> once at boot and once at shutdown.

As routers are always on devices, it's rare to have clean shutdown.
Personally, my routers boot after an upgrade or after a power loss,
so they almost never shutdown properly.

> It's also fine to call seedrng at
> any other specific time during runtime too. Because it's involved with
> crediting, it always always removes the seed file after reading but
> before using, and after it's used, it immediately writes a new seed
> file.
>
> It sounds like what you might want here is, perhaps, the original
> behavior? Namely, the seed is never credited, but it never changes
> either? That won't help you initialize the RNG, but since you're not
> crediting it, you can argue that all new rng inputs are good inputs,
> even if they've been used before.
>
> So these are the two schemes to choose from:
>
> 1) read seed into memory, delete seed from disk, write into rng &
> credit if good seed, write new seed to disk; repeat at shutdown/some
> other time
> 2) read seed into memory, write into rng w/o crediting, re-use the
> same seed next boot

Before this patch we had 2 and users could opt-in to renew seed on
each boot, so closer to 1.

> If the second scheme is what you prefer, then your original bug report
> suggesting this was an issue for OpenWRT might not really be so, and
> we can just go back to what we were doing before. OTOH, if you want to
> have a good mechanism that actually initializes the RNG, perhaps we
> can move forward with some tweaks to seedrng.

Looking at random.c, I would love add_device_randomness() behavior.
Maybe it was already answered on LKML,
but why can't writes to /dev/urandom from a process with CAP_SYS_ADMIN
be mixed in right away a la add_device_randomness() without being credited ?
This would not init the RNG faster, but this would make early
/dev/urandom reads "safer".

I'm fine with writing on each boot, but as we can't rely on shutdown,
what we could do with the seeds:
1) load seed.no-credit, leave it on disk
2) mv seed.credit seed.no-credit && load seed.no-credit (and credit it)
3) read from getrandom a new seed.credit

This would allow to always keep a seed on disk, only use seed.credit once,
and actually write seed.credit.
I would get rid of the whole hashing part as all our seeds would come
from getrandom().

> > > +
> > > +#define SEED_DIR "/etc/seedrng"
> >
> > If we worry about seed reuse, we should not use /etc as it can be
> > restored from a backup
>
> Indeed you're right. Most other distros use /var/lib/seedrng; is
> /var/lib available on OpenWRT?

/var is a symlink to /tmp

> Is there a different place for it that would be good?

Maybe we can leave it in etc and just make sure to exclude it from backups

Etienne

>
> Jason

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

Re: [PATCH] urandom-seed: use seedrng for seeding the random number generator

[Etienne Champetier]

Hi All, Jason,

@Petr Štetiar this merge was a bit too fast to get reviews ...
Some comments inline

Le lun. 28 mars 2022 à 00:26, Jason A. Donenfeld  a écrit :
>
> The RNG can't actually be seeded from a shell script, due to the
> reliance on ioctls. For this reason, the seedrng project provides a
> basic script meant to be copy and pasted into projects like OpenWRT
> and tweaked as needed: .
>
> This commit imports it into the urandom-seed package and wires up the
> init scripts to call it. This also is a significant improvement over the
> current init script, which does not robustly handle cleaning up of seeds
> and syncing to prevent reuse.

When urandom-seed was introduced in 2016 it was decided during review
that writing on each boot might cause too much wear to the flash.
Maybe we can say that 6 years later this is not a problem anymore, but
would love to have more devs comment
Old thread: 
https://www.mail-archive.com/lede-dev@lists.infradead.org/msg01225.html

Now if I understand correctly, with this patch we are writing a seed
to flash twice per boot, in preinit/81_urandom_seed and in
init.d/urandom_seed.
Also there are good chances we will never have a seed.credit at all on
many devices,
would be great if seedrng had an option "writeseed" that blocks on getrandom().

> Additionally, the existing script creates
> a new seed immediately after writing an old one, which means that the
> amount of entropy might actually regress, due to failing to credit the
> old seed.

We used getrandom to create the seeds, so when configured to write new
seed on each boot,
either we reboot too fast and we will reuse the seed (not ideal but
not catastrophic as we don't credit),
or the new seed is created after getrandom() unblock, so not sure to
understand how entropy regress.

> Closes: https://github.com/openwrt/openwrt/issues/9570
> Signed-off-by: Jason A. Donenfeld 

[snip]

> diff --git a/package/system/urandom-seed/seedrng.c 
> b/package/system/urandom-seed/seedrng.c
> new file mode 100644
> index 00..9a2cb10f55
> --- /dev/null
> +++ b/package/system/urandom-seed/seedrng.c

[snip]

> +
> +#define SEED_DIR "/etc/seedrng"

If we worry about seed reuse, we should not use /etc as it can be
restored from a backup

Best
Etienne

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

Drop CONFIG_IPV6 ?

[Etienne Champetier]

Hi All,

We currently have some circular dependencies caused by the usage of
PROVIDES and @IPV6
https://github.com/openwrt/openwrt/issues/9407

One radical way to fix, suggested by Jow, is to completely remove
CONFIG_IPV6 from OpenWrt.
This would also allow to simplify packaging of some core components.

Is anyone disabling CONFIG_IPV6 ?
Do people agree we can drop CONFIG_IPV6 ?
Should we do this before we branch 22.x ?

Best
Etienne

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

Update buildbots (was: Re: Switch issues and CI to GitHub)

[Etienne Champetier]

Hi Petr & Jow

Le jeu. 20 janv. 2022 à 09:10, Paul Spooren  a écrit :
>
> Hi Etienne,
>
> >>
> >> Currently we’re facing an issue[1] from our heterogeneous buildbot 
> >> setup[2] that partly uses outdated runners missing packages installed host 
> >> packages, causing them to upload broken SDKs at random.
> >
> > My understanding is that buildbot runner are docker containers now so
> > we are 1 "docker pull" away from fixing this
>
> I agree, however someone needs to do that and also do it in the future.

Any chance you can update the buildbots docker images ?
(I see only you 2 listed as admins here: https://openwrt.org/infrastructure)

Best
Etienne

> We could also automate it[1], but from what I remember people didn’t like the 
> idea.
>
> [1]: https://github.com/containrrr/watchtower
>
> Paul

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

Re: Switch issues and CI to GitHub

[Etienne Champetier]

Hi Paul,

Le jeu. 20 janv. 2022 à 05:04, Paul Spooren  a écrit :
>
> Hi Florian,
>
> > I have now been persuaded to share my thoughts on the subject as well.
>
> Thank you.
>
> > Why not gitlab?
> > Here we can take the services (GIT, CI/CD, ISSUE-Tracking) from them.
>
> Some people don’t like the particularly “bloated” interface of GitLab but I 
> agree, they offer the stuff we’re looking for (and much much much more we 
> don’t).
>
> > And if necessary, we can also host everything ourselves.
>
> That’s not an entirely new idea. However in the last three years nobody 
> stepped up to host (and maintain) it. Setting up a GitLab instance is easy 
> enough, hosting it for the next 15 years or something is a bit more of a 
> task. None of the OpenWrt project members were particularly excited about 
> hosting it.
>
> >
> > What I like is the CI handling with the gitlabrunners.
> > We can take the ones from Gitlab or we can configure gitlabrunners running 
> > on our own hardware.
>
> When you say GitLab here I’m assuming GitLab.com. During the vote multiple 
> people were against GitLab.com due to their past in buying and shutting down 
> another Git service. It’s surely possible to host GitLab and a bunch of 
> workers ourselves, the question is, do we want that?
>
> Currently we’re facing an issue[1] from our heterogeneous buildbot setup[2] 
> that partly uses outdated runners missing packages installed host packages, 
> causing them to upload broken SDKs at random.

My understanding is that buildbot runner are docker containers now so
we are 1 "docker pull" away from fixing this

Best
Etienne

> > Somewhere in the thread @arprcar I read that gitlab is not an option.
> > Unfortunately, it didn't say why.
> > Did you mean hosting it yourself?
>
> Neither GitLab.com nor a self hosted GitLab instance seem great at this point.
>
> [1]: https://github.com/openwrt/packages/pull/17645#issuecomment-1016548435
> [2]: https://buildbot.openwrt.org/master/images/#/workers
>
> Best,
> Paul
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [PATCH,opkg-lede] opkg_remove: avoid remove pkg repeatly with option --force-removal-of-dependent-packages

[Etienne Champetier]

Hello OpenWrt devs,

Here an example of CI failure this patch fixes:
https://github.com/openwrt/packages/runs/4427963136?check_suite_focus=true
Anything I can do to have this patch included ?

Best,
Etienne

Le dim. 12 sept. 2021 à 18:31, Etienne Champetier
 a écrit :
>
> + @Jo-Philipp Wich
>
> Tested using mvebu target removing librt
>
> Le mar. 7 sept. 2021 à 18:42, Etienne Champetier
>  a écrit :
> >
> > From: Hongxu Jia 
> >
> > While remove pkg with '--force-removal-of-dependent-packages',
> > pkg may be added to pkgs remove list multiple times, add status
> > check to make sure pkg only be removed once.
> >
> > Signed-off-by: Hongxu Jia 
> > Signed-off-by: Paul Barker 
> > (Cherry picked from 
> > https://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=e8996180833aa35d101fbeadec3d787ce0bbda5c)
> > (Fixes https://dev.archive.openwrt.org/ticket/18320 and openwrt/packages CI)
> > ---
> >  libopkg/opkg_remove.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/libopkg/opkg_remove.c b/libopkg/opkg_remove.c
> > index 96ca558..c2abf81 100644
> > --- a/libopkg/opkg_remove.c
> > +++ b/libopkg/opkg_remove.c
> > @@ -249,6 +249,14 @@ int opkg_remove_pkg(pkg_t * pkg, int from_upgrade)
> > if ((parent_pkg = pkg->parent) == NULL)
> > return 0;
> >
> > +   /* While remove pkg with '--force-removal-of-dependent-packages',
> > +  pkg may be added to remove list multiple times, add status
> > +  check to make sure pkg only be removed once. */
> > +   if (conf->force_removal_of_dependent_packages &&
> > +   pkg->state_flag & SF_FILELIST_CHANGED &&
> > +   pkg->state_status == SS_NOT_INSTALLED)
> > +   return 0;
> > +
> > /* only attempt to remove dependent installed packages if
> >  * force_depends is not specified or the package is being
> >  * replaced.
> > --
> > 2.31.1
> >

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

Re: [PATCH,opkg-lede] opkg_remove: avoid remove pkg repeatly with option --force-removal-of-dependent-packages

[Etienne Champetier]

+ @Jo-Philipp Wich

Tested using mvebu target removing librt

Le mar. 7 sept. 2021 à 18:42, Etienne Champetier
 a écrit :
>
> From: Hongxu Jia 
>
> While remove pkg with '--force-removal-of-dependent-packages',
> pkg may be added to pkgs remove list multiple times, add status
> check to make sure pkg only be removed once.
>
> Signed-off-by: Hongxu Jia 
> Signed-off-by: Paul Barker 
> (Cherry picked from 
> https://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=e8996180833aa35d101fbeadec3d787ce0bbda5c)
> (Fixes https://dev.archive.openwrt.org/ticket/18320 and openwrt/packages CI)
> ---
>  libopkg/opkg_remove.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libopkg/opkg_remove.c b/libopkg/opkg_remove.c
> index 96ca558..c2abf81 100644
> --- a/libopkg/opkg_remove.c
> +++ b/libopkg/opkg_remove.c
> @@ -249,6 +249,14 @@ int opkg_remove_pkg(pkg_t * pkg, int from_upgrade)
> if ((parent_pkg = pkg->parent) == NULL)
> return 0;
>
> +   /* While remove pkg with '--force-removal-of-dependent-packages',
> +  pkg may be added to remove list multiple times, add status
> +  check to make sure pkg only be removed once. */
> +   if (conf->force_removal_of_dependent_packages &&
> +   pkg->state_flag & SF_FILELIST_CHANGED &&
> +   pkg->state_status == SS_NOT_INSTALLED)
> +   return 0;
> +
> /* only attempt to remove dependent installed packages if
>  * force_depends is not specified or the package is being
>  * replaced.
> --
> 2.31.1
>

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

[PATCH, opkg-lede] opkg_remove: avoid remove pkg repeatly with option --force-removal-of-dependent-packages

[Etienne Champetier]

From: Hongxu Jia 

While remove pkg with '--force-removal-of-dependent-packages',
pkg may be added to pkgs remove list multiple times, add status
check to make sure pkg only be removed once.

Signed-off-by: Hongxu Jia 
Signed-off-by: Paul Barker 
(Cherry picked from 
https://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=e8996180833aa35d101fbeadec3d787ce0bbda5c)
(Fixes https://dev.archive.openwrt.org/ticket/18320 and openwrt/packages CI)
---
 libopkg/opkg_remove.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libopkg/opkg_remove.c b/libopkg/opkg_remove.c
index 96ca558..c2abf81 100644
--- a/libopkg/opkg_remove.c
+++ b/libopkg/opkg_remove.c
@@ -249,6 +249,14 @@ int opkg_remove_pkg(pkg_t * pkg, int from_upgrade)
if ((parent_pkg = pkg->parent) == NULL)
return 0;
 
+   /* While remove pkg with '--force-removal-of-dependent-packages',
+  pkg may be added to remove list multiple times, add status
+  check to make sure pkg only be removed once. */
+   if (conf->force_removal_of_dependent_packages &&
+   pkg->state_flag & SF_FILELIST_CHANGED &&
+   pkg->state_status == SS_NOT_INSTALLED)
+   return 0;
+
/* only attempt to remove dependent installed packages if
 * force_depends is not specified or the package is being
 * replaced.
-- 
2.31.1


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

Re: [openwrt/openwrt] ucode: update to latest Git HEAD

[Etienne Champetier]

Hi Jow,

Thanks for your work on firewall4 !
2 nitpicks inline

Le mer. 1 sept. 2021 à 09:42, LEDE Commits
 a écrit :
>
> jow pushed a commit to openwrt/openwrt.git, branch master:
> https://git.openwrt.org/9e9057f4164a31bbe5a645878a9e0f083b533c0f
>
> commit 9e9057f4164a31bbe5a645878a9e0f083b533c0f
> Author: Jo-Philipp Wich 
> AuthorDate: Sun Jul 11 20:37:45 2021 +0200
>
> ucode: update to latest Git HEAD
>

[...]

>
> Signed-off-by: Jo-Philipp Wich 
> ---
>  package/utils/ucode/Makefile | 47 
> +++-
>  1 file changed, 38 insertions(+), 9 deletions(-)
>
> diff --git a/package/utils/ucode/Makefile b/package/utils/ucode/Makefile
> index 7c8907a716..26281af730 100644
> --- a/package/utils/ucode/Makefile
> +++ b/package/utils/ucode/Makefile
> @@ -12,15 +12,19 @@ PKG_RELEASE:=1
>
>  PKG_SOURCE_PROTO:=git
>  PKG_SOURCE_URL=https://github.com/jow-/ucode.git

Why not use https://github.com/openwrt/ ?

> -PKG_SOURCE_DATE:=2021-03-31
> -PKG_SOURCE_VERSION:=973cc6c865dcf6075c493125313058b650b08234
> -PKG_MIRROR_HASH:=fb4d3e231c79a9122743f0ced7fd4fdcf81903de5c721d3c18d5779e44d50bdf
> +PKG_SOURCE_DATE:=2021-07-30
> +PKG_SOURCE_VERSION:=929c8627cf077c3e348fb12b02553d4a444c5e48
> +PKG_MIRROR_HASH:=

Missing value

Best
Etienne

[...]

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

Re: SSH/MTU Issues in OpenVPN tunnel on OpenWRT 21.02 RC3

[Etienne Champetier]

Hi Federico,

Le sam. 31 juil. 2021 à 20:33, Federico Capoano
 a écrit :
>
> Hi everyone,
>
> I wrote about this issue in the forum and I was advised to post here
> as well so I'm following the advice.
> (Forum discussion:
> https://forum.openwrt.org/t/ssh-mtu-issues-on-openvpn-on-openwrt-21-02-rc3-linux-kernel-5-4-132/102686).
>
[...]
>
> OpenVPN version on clients with new firmare:
>
> OpenVPN 2.5.3 mipsel-openwrt-linux-gnu [SSL (mbed TLS)] [LZ4] [EPOLL]
> [MH/PKTINFO] [AEAD]
> library versions: mbed TLS 2.16.10
> Originally developed by James Yonan
> Copyright (C) 2002-2021 OpenVPN Inc 

openvpn-mbedtls is now build without lzo support, you can:
1) disable lzo on the server (actually the best thing to do IMO)
2) enable it in your build
3) use openvpn-openssl package

More discussion here: https://github.com/openwrt/packages/issues/15854

Best
Etienne

> OpenVPN version on clients with older firmware:
>
> OpenVPN 2.5.3 mipsel-openwrt-linux-gnu [SSL (mbed TLS)] [LZO] [LZ4]
> [EPOLL] [MH/PKTINFO] [AEAD]
> library versions: mbed TLS 2.16.10, LZO 2.10
> Originally developed by James Yonan
> Copyright (C) 2002-2021 OpenVPN Inc 
>
[...]
>
> Best regards
> Federico Capoano

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

Re: Activate https server support in 21.02 by default

[Etienne Champetier]

Hi Hauke,

Le dim. 16 mai 2021 à 09:21, Hauke Mehrtens  a écrit :
>
> On 5/14/21 4:22 PM, Etienne Champetier wrote:
> > Hi All,
> >
> > Le ven. 14 mai 2021 à 05:00, Petr Štetiar  a écrit :
> >>
> >> Fernando Frediani  [2021-05-11 20:13:18]:
> >>
> >> Hi,
> >>
> >>> I am no sure https support should still be something by default in the
> >>> images as it's not something really essential
> >>
> >> to me it's like discussion about telnet versus SSH. (Puting aside, that one
> >> shouldn't be using password at all) If it's fine with you to send your
> root
> >> password over telnet, then SSH is not essential, I agree.
> >>
> >> FYI HTTPS wouldn't be enabled by default, it would be *available* by 
> >> default,
> >> giving users of default release images choice for management of their 
> >> devices
> >> over HTTPS, by doing so *explicitly*.
> >
> > I'm all for HTTPS to be shipped by default
> > One painfull "bug" that some people might face having both HTTP and HTTPS,
> > when you login using HTTPS, the sysauth cookie has secure=true,
> > so you can't login via HTTP anymore because it's trying to modify the
> > secure=true sysauth cookie :(
> >
> > Etienne
>
> I ran into this when I first used an image with luci-ssl and then
> changed to one without it. What about setting a not secure cookie that
> tells the browser that https was used when we access LuCI over https.
> When the browser accesses LuCI now over unencrypted http the code will
> check for this cookie and forward the browser to the https version. If
> this cookie is not found, it behaves like before. If https worked once it
> will probably also work a second time.
>
> Is it even possible to handle the error when we want to overwrite the
> secure=true cookie and do a forward to https instead?

I would keep it simple and use different names, sysauth-http and sysauth-https,
and if you want to be redirected to HTTPS, just configure the redirection,
or trust your browser remembered to use https like last time (firefox
does for me)

Shipping at least 1 release without the redirection allows to iron out
any small bugs like that
and maybe get more people looking at the https config and cert we generate.
A quick look on my router:
- it talks TLS 1.2/1.3 only :)
- we generate RSA 2048 key which should be fine for some more years
but code signing now requires 3072
so don't know how many more years it'll be ok for HTTPS
- my cert is expired because it was generated before time was synced I guess
- cert life is 2 years
If I remember correctly notbefore / notafter constraints just do not
apply to self signed certs, so seems pretty good to me

Etienne

>
> Hauke

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

Re: Activate https server support in 21.02 by default

[Etienne Champetier]

Hi All,

Le ven. 14 mai 2021 à 05:00, Petr Štetiar  a écrit :
>
> Fernando Frediani  [2021-05-11 20:13:18]:
>
> Hi,
>
> > I am no sure https support should still be something by default in the
> > images as it's not something really essential
>
> to me it's like discussion about telnet versus SSH. (Puting aside, that one
> shouldn't be using password at all) If it's fine with you to send your root
> password over telnet, then SSH is not essential, I agree.
>
> FYI HTTPS wouldn't be enabled by default, it would be *available* by default,
> giving users of default release images choice for management of their devices
> over HTTPS, by doing so *explicitly*.

I'm all for HTTPS to be shipped by default
One painfull "bug" that some people might face having both HTTP and HTTPS,
when you login using HTTPS, the sysauth cookie has secure=true,
so you can't login via HTTP anymore because it's trying to modify the
secure=true sysauth cookie :(

Etienne

> OpenWrt has quite huge community, so I hope, that having HTTPS available in
> default images would bring the currently horrible UX of self-signed
> certificates to wider audience which in turn might foster improvements.
>
> -- ynezz

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

Mandatory VLAN Tagging on mv88e6085 since f1158f

[Etienne Champetier]

Hi Quigfang,

I've started testing 21.02 and updated my Turris Omnia from 19.07.
In 19.07 I had a usable configuration (maybe with some bugs ;) )
without VLAN tagging with lanX port simply bridged to different wifi.
Since 21.02 I have the following errors in dmesg
[   15.739908] mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already
used by port 4 in br-lan
[   15.784026] mv88e6085 f1072004.mdio-mii:10 lan3: failed to
initialize vlan filtering on this port

Reading 
https://forum.openwrt.org/t/kernel-5-4-96-broke-untagged-dsa-vlans-on-my-mvebu-routers/88361,
I understand that a working workaround is to use VLAN tagging
explicitly, but I'm wondering if
- this is just a limitation of your hack
(https://github.com/openwrt/openwrt/blob/f1158fbcf63c190fb4f7686075ab99f2aee98a92/target/linux/generic/hack-5.4/710-net-dsa-mv88e6xxx-default-VID-1.patch)
- or if this hack is really mandatory and this switch is just plain
unusable without VLAN tagging

Thanks
Etienne

P.S: here is part of my pretty simple config:

/etc/config/network
config interface 'lan'
option type 'bridge'
option proto 'static'
...
option ifname 'lan4'

config interface 'lan_iot'
option proto 'static'
...
option ifname 'lan3'
option type 'bridge'

/etc/config/wireless
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
...

config wifi-iface 'default_radio1'
option device 'radio1'
option mode 'ap'
option network 'lan_iot'
...

And a bigger part of dmesg ouput
[   15.686385] mv88e6085 f1072004.mdio-mii:10 lan3: configuring for
phy/gmii link mode
[   15.700429] 8021q: adding VLAN 0 to HW filter on device lan3
[   15.706521] br-lan_iot: port 1(lan3) entered blocking state
[   15.712126] br-lan_iot: port 1(lan3) entered disabled state
[   15.726871] device lan3 entered promiscuous mode
[   15.739908] mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already
used by port 4 in br-lan
[   15.784026] mv88e6085 f1072004.mdio-mii:10 lan3: failed to
initialize vlan filtering on this port
[   15.820888] br-lan_iot: port 1(lan3) entered blocking state
[   15.826485] br-lan_iot: port 1(lan3) entered disabled state
[   15.838961] mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already
used by port 4 in br-lan
[   15.884020] mv88e6085 f1072004.mdio-mii:10 lan3: failed to
initialize vlan filtering on this port
[   15.920849] br-lan_iot: port 1(lan3) entered blocking state
[   15.926442] br-lan_iot: port 1(lan3) entered disabled state
[   15.938179] mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already
used by port 4 in br-lan
[   15.984020] mv88e6085 f1072004.mdio-mii:10 lan3: failed to
initialize vlan filtering on this port
[   16.020844] br-lan_iot: port 1(lan3) entered blocking state
[   16.026437] br-lan_iot: port 1(lan3) entered disabled state
[   16.038173] mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already
used by port 4 in br-lan
[   16.084036] mv88e6085 f1072004.mdio-mii:10 lan3: failed to
initialize vlan filtering on this port

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

Re: [PATCH rpcd] iwinfo: add 802.11ax HE support

[Etienne Champetier]

Hi David,

Le mer. 28 avr. 2021 à 07:07, David Bauer  a écrit :
>
> Expose 802.11ax HE rate as well as HW / HT mode information. This is
> required to add 802.11ax support to LuCI.
>
> Signed-off-by: David Bauer 
> ---
>  iwinfo.c | 45 +
>  1 file changed, 45 insertions(+)
>
> diff --git a/iwinfo.c b/iwinfo.c
> index 63ff2a1..6b376c4 100644
> --- a/iwinfo.c
> +++ b/iwinfo.c

...

> }
>  }
> @@ -280,6 +295,9 @@ rpc_iwinfo_call_hwmodes(const char *name)
> if (modes & IWINFO_80211_AC)
> blobmsg_add_string(, NULL, "ac");
>
> +   if (modes & IWINFO_80211_AX)
> +   blobmsg_add_string(, NULL, "ac");

I think you meant "ax" no ?

> +
> if (modes & IWINFO_80211_A)
> blobmsg_add_string(, NULL, "a");
>

...

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

Re: Brokenness of the OpenWrt "packages" repo (was: Re: [PATCH] Revert "dbus: update to 1.13.18")

[Etienne Champetier]

Hi Bjørn,

Le dim. 25 avr. 2021 à 09:53, Bjørn Mork  a écrit :
>
> Rosen Penev  writes:
>
> > Why was this sent here? dbus is in the packages feed.
>
> Sorry, I assumed that was obvious.  I'll explain
>
> There is a continous push to move packages from the OpenWrt core repo to
> the "packages" repo. This would have been fine if both these repos could
> be trusted. Unfortunately, that is not the case.
>
> That's why this is relevant to OpenWrt. The low standards of the
> packages repo reflects back to OpenWrt.  I believe core needs to take
> control over packages again, or something must be done to improve the
> quality of the packages repo.

I see you are the maintainer of "conserver", why should any of the
core developers care about such a niche software and spend time run
testing it ? ;)

The packages repo was moved to Github and control was given to non
core developers to be able to scale better.
Before that it was more or less impossible to add new packages or do
modifications to them.
You have to think of OpenWrt packages as Ubuntu PPA or Fedora Copr,
each package has a separate maintainer and quality will vary,
and you can install only the packages you are interested in while
building using "./scripts/feeds install "

It's not perfect, but asking the core maintainers to review an
additional 1000 packages is not going to fly.
The only improvements that scale are more automation and CI IMO, but
if you have concrete ideas I'm all ears.

> When a package cannot even be installed, like the current example, then
> how do we know what security issues other packages have?

Are you trying at the same time to complain about not run-tested
updates and possibly having packages not up to date ?
For dbus there is no maintainer
(https://github.com/openwrt/packages/blob/3ddefd7feb2014e8a45cfbb1491f4afc1a1d2d04/utils/dbus/Makefile#L18),
I would personally mark it as broken or remove it instead of making it
work again, but it means removing some other packages.

> No testing and no review is a recipe for disaster.

I believe each maintainer is usually given some time to review / test
changes on their packages,
but here there is no maintainer :(

> No one should use the packages repo as is.

1 package out of 1000 has been broken for more than 2 weeks, seems a
bit of an overreaction don't you think ?
Even if 100 packages are broken I prefer the current situation,
because we still have 900 packages working to answer everyone specific
needs

> The bad or missing procedures adds to this.  Why can anyone commit their
> own code without any review?

The occasional breakage isn't worth the extra effort of having each
commit reviewed by someone else, and nobody has offered to do that.
Not everyone has commit access, and Rosen isn't anyone, he is the top
contributor to OpenWrt packages and by far (~2400 commits),
sure he causes breakage from time to time but he is also there to fix it.

>  Why are squashed commits allowed?  One
> commit, one change is a golden rule.  There's a reason for that.

For PR only merge and rebase is enabled for multiple months now, where
do you see squashed commits ?

> IMHO, the problem with the packages repo is mostly about attitude. There
> is no reason to skip run testing in the first place.  This buggy change
> would never have been commited by any qualified developer.

No need for attacks.
Run testing is the job of the maintainer, no maintainer == no run testing
Should we let the package stay without update ? or should we just remove it ?

> And you got a report 19 days ago that the package was uninstallable:
> https://github.com/openwrt/packages/commit/0fb5d3ed2cb31a0a6076d36fb7a668cfe5328c92#commitcomment-49147445
> The only logical thing to do would be an immediate revert.  But no, the
> package is still broken.  Why?

Yes this should have been reverted immediately, everything else in
this email is overreaction to me

> So the question for OpenWrt core is: Do you really want to depend on the
> packages repo?  Going down with it?

$ find . -name Makefile | grep '^./package/' | wc -l
264
$ find . -name Makefile | grep '^./feeds/packages/' | wc -l
1039

> (As you know, dbus is not the first package you've left so broken that a
> simple install was enough to find the bug.  I stumbled on
> https://github.com/openwrt/packages/pull/14366 a while ago - I assume
> there are plenty more)

More than happy to merge broken packages removal, you can ping me,
and looking forward to your concrete proposals to improve the current
status quo ;)

Etienne

>
> Bjørn

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

Re: [PATCH] build: prereq: drop support for Python 3.5

[Etienne Champetier]

Le sam. 17 avr. 2021 à 17:47, Sven Roederer  a écrit :
>
> Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer:
> > On my Ubuntu 16.04 based build-system I also have build-failures for meson
> > using Python3.5.
>
> Correction: it's a 18.04 LTS ...

Should we just recommend to people that want to use "old stable" OS to
use the buildbot container images ?

>
> Sven

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

Re: [PATCH] build: prereq: drop support for Python 3.5

[Etienne Champetier]

Le mar. 16 févr. 2021 à 11:19, Petr Štetiar  a écrit :
>
> Andre Heider  [2021-02-16 08:21:08]:
>
> Hi,
>
> > The meson build system bumped their python requirement to 3.6 for the 0.57.0
> > release. This patch ensures that OpenWrt can update meson while still
> > relying on the host python.
>
> Current buildbot images are based on Debian 9, which uses Python 3.5 so 
> merging this
> would result in broken buildbots.

Debian 9 is EOL, so we should definitely update the buildbot images

>
> Cheers,
>
> Petr
>
> ___
> 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

CircleCi removal

[Etienne Champetier]

Hi All,

CircleCI was not used by any repos anymore, so I remove it everywhere
I could see it in OpenWrt org conf pages

Best
Etienne

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

Re: Requiring 2FA on OpenWrt GitHub organization

[Etienne Champetier]

Hi All,

I enabled some minutes ago 2FA on OpenWrt Github organization

Best
Etienne

Le dim. 11 avr. 2021 à 21:51, Etienne Champetier
 a écrit :
>
> Hi Paul,
>
> Le dim. 11 avr. 2021 à 21:07, Paul Spooren  a écrit :
> >
> > I did so a week ago and asked everyone with direct emails to turn on 2FA.
> > Everyone who didn't respond after 3 weeks and multiple mails lost their
> > commit access.
> >
> > If there's someone with commit access and no 2FA, it was added
> > afterwards.
>
> I saw that,
> I just convinced one more to enable 2FA and only one "almost active"
> is still a member (but without access)
> Once this person answers (or not) I just want to make sure we don't "regress"
>
> Best
> Etienne
>
>
> > --
> >
> >
> >
> > Apr 11, 2021 4:52:22 AM Etienne Champetier
> > :
> >
> > > Hi All,
> > >
> > > There are currently 65 members in OpenWrt org, 58 of them with 2FA
> > > enabled.
> > > Requiring 2FA would kick out the 7 users without 2FA, 6 of them have
> > > no OpenWrt related activity for more than 2 or 3 years, I've emailed
> > > the 7th one privately.
> > >
> > > Anyone see any problem enforcing 2FA ?
> > >
> > > Best
> > > Etienne
> > >
> > > ___
> > > 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

tango.drone.openwrt.ninja OAuth apps removal

[Etienne Champetier]

Hi All,

I just deleted 'tango.drone.openwrt.ninja' from OpenWrt GitHub organization,
It had 0 users, no recent activity and the callback url pointed to
"http://tango.drone.openwrt.ninja/authorize;, openwrt.ninja domain is
currently for sale
(https://shop.gandi.net/en/domain/suggest?search=openwrt.ninja)

We also have 'Transistion bug tracker' that is not used but it point
to a valid OpenWrt domain so we can keep it around

Best
Etienne

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

Re: Requiring 2FA on OpenWrt GitHub organization

[Etienne Champetier]

Hi Paul,

Le dim. 11 avr. 2021 à 21:07, Paul Spooren  a écrit :
>
> I did so a week ago and asked everyone with direct emails to turn on 2FA.
> Everyone who didn't respond after 3 weeks and multiple mails lost their
> commit access.
>
> If there's someone with commit access and no 2FA, it was added
> afterwards.

I saw that,
I just convinced one more to enable 2FA and only one "almost active"
is still a member (but without access)
Once this person answers (or not) I just want to make sure we don't "regress"

Best
Etienne


> --
>
>
>
> Apr 11, 2021 4:52:22 AM Etienne Champetier
> :
>
> > Hi All,
> >
> > There are currently 65 members in OpenWrt org, 58 of them with 2FA
> > enabled.
> > Requiring 2FA would kick out the 7 users without 2FA, 6 of them have
> > no OpenWrt related activity for more than 2 or 3 years, I've emailed
> > the 7th one privately.
> >
> > Anyone see any problem enforcing 2FA ?
> >
> > Best
> > Etienne
> >
> > ___
> > 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

Requiring 2FA on OpenWrt GitHub organization

[Etienne Champetier]

Hi All,

There are currently 65 members in OpenWrt org, 58 of them with 2FA enabled.
Requiring 2FA would kick out the 7 users without 2FA, 6 of them have
no OpenWrt related activity for more than 2 or 3 years, I've emailed
the 7th one privately.

Anyone see any problem enforcing 2FA ?

Best
Etienne

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

Re: Job board support on openwrt.org?

[Etienne Champetier]

Hi All,

Le sam. 23 janv. 2021 à 18:09, Sam Kuper  a écrit :
>
> On Sat, Jan 23, 2021 at 02:55:05PM +, Ted Hess wrote:
> > [T]here must be some sort of criteria (contributions, legitimate
> > business site or references) to get your name/outfit listed. And, as
> > Daniel said, we don't want to be in the business of certifying
> > contractors.
>
> Those two sentences seem to be slightly contradictory ;)
>
>
>
> Anyway, an alternative approach to the whole question of how to connect
> potential clients and contractors would be a mailing list, e.g.:
> openwrt-j...@openwrt.org .
>
> This would be a place for potential *clients/employers* to post
> jobs/tenders (to which potential contractors/employees could then reply
> on- or off-list).
>
> It would therefore place responsibility for establishing the credentials
> of the would-be employee or contractor entirely onto the potential
> employer or client, rather than onto the OpenWRT project.
>
> I.e. it is an inversion of the wiki page idea.
>
> I suggest that if a vote is held, it should be a three-way vote between
> the following outcomes (which should probably be mutually exclusive):
>
> - OpenWRT Jobs wiki page;
>
> - openwrt-jobs mailing list;

- OpenWrt Jobs forum section, with a "non endorsement" disclaimer at the top

My 2 cents
Etienne

>
> - Do nothing.
>
> Sam
>
> P.S.  I don't have an opinion on whether such a vote should be under
> FPTP or AV or Condorcet or some other voting method.  For reference, I
> think Debian uses "Condorcet/Clone Proof SSD":
> https://www.debian.org/vote/2003/vote_0002 .

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

Re: [RFC] raise gcc/make versions for 20.x

[Etienne Champetier]

Le mer. 16 déc. 2020 à 07:33, Yousong Zhou  a écrit :
>
> On Wed, 16 Dec 2020 at 13:11, Petr Štetiar  wrote:
> >
> > Paul Spooren  [2020-12-15 16:26:14]:
> >
> > Hi,
> >
> > > I've seen two patches for version raises of build requirements and would
> > > like to know if we should merge them before or after 20.x.
> > >
> > > make: 3.81.x -> 4.1.x
> > > gcc: 4.8 -> 6.x
> > >
> > > I'm in favor to merge both *before* the branch.
> >
> > it would probably help to know the reason as well. "I'm in favor" might not 
> > be
> > enough in this almost pre-release stage.
> >
> > AFAIK that Make version bump fixes an issue with possibly few stray ANSI 
> > color
> > escapes (workaround is to use NO_COLOR=1 in this case) and \r characters in 
> > the
> > log file. Is it really that big issue to do this last minute version bump?
> >
> > FYI that gcc6+ one was NACKed[1] by Yousong and I'm fine with that for 20.12
> > release. I plan to rebase/resend that patch once 20.12 is branched.
> >
> > 1. 
> > https://patchwork.ozlabs.org/project/openwrt/patch/20191112081625.27695-1-yn...@true.cz/#2301662
> >
>
> I still hold the belief that a system such as CentOS could deserve a
> work-out-of-the-box experience ;)  But now that CentOS like the old
> day is not an option anymore in the future, I say we move on in the
> next release.

Why not just install devtoolset, up to date gcc supported by RedHat people ?
Or use a build container ?
There are a lot of options to not be stuck with a 7 years old version of GCC ;)

Etienne

>
> Regards,
> yousong

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

Re: [PATCH 0/2] enable procd security features by default

[Etienne Champetier]

Hi Petr, Daniel,

Le jeu. 26 nov. 2020 à 11:45, Petr Štetiar  a écrit :
>
> Daniel Golle  [2020-11-07 14:17:12]:
>
> Hi,
>
> > Please report back
>
> testing now the latest master on rtl8382 booted from initramfs and seeing 
> following:
>
>  Thu Nov 26 14:45:35 2020 user.notice dnsmasq: DNS rebinding protection is 
> active, will discard upstream RFC1918 responses!
>  Thu Nov 26 14:45:36 2020 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
>  Thu Nov 26 14:45:42 2020 user.err : jail: pivot_root(/tmp/ujail-CgOmPF, 
> /tmp/ujail-CgOmPF/old) failed: Invalid argument
>  Thu Nov 26 14:45:42 2020 daemon.info procd: Instance dnsmasq::cfg01411c s in 
> a crash loop 14 crashes, 0 seconds since last crash
>  Thu Nov 26 14:45:45 2020 user.notice dnsmasq: DNS rebinding protection is 
> active, will discard upstream RFC1918 responses!
>  Thu Nov 26 14:45:45 2020 user.notice dnsmasq: Allowing 127.0.0.0/8 responses
>  Thu Nov 26 14:45:46 2020 user.err : jail: pivot_root(/tmp/ujail-kfIjBM, 
> /tmp/ujail-kfIjBM/old) failed: Invalid argument
>  Thu Nov 26 14:45:46 2020 daemon.info procd: Instance dnsmasq::cfg01411c s in 
> a crash loop 15 crashes, 0 seconds since last crash

https://man7.org/linux/man-pages/man2/pivot_root.2.html
> The rootfs (initial ramfs) cannot be pivot_root()ed.

A possible solution
https://patchwork.ozlabs.org/project/openwrt/patch/9231d502b07c5e4a8b32d5115c9f19991f9a9...@irsmsx108.ger.corp.intel.com/

>
> -- ynezz

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

Re: busybox: allow ntpd to run as non-root ntpd user (master breakage)

[Etienne Champetier]

Hello Daniel,

Le dim. 25 oct. 2020 à 09:08, LEDE Commits
 a écrit :
>
> dangole pushed a commit to openwrt/openwrt.git, branch master:
> https://git.openwrt.org/2d34355e16b442fcf51e93786401716dae3c4ea2
>
> commit 2d34355e16b442fcf51e93786401716dae3c4ea2
> Author: Daniel Golle 
> AuthorDate: Mon Oct 19 21:22:30 2020 +0100
>
> busybox: allow ntpd to run as non-root ntpd user
>
> Signed-off-by: Daniel Golle 
> ---
>  package/utils/busybox/Makefile |  5 -
>  package/utils/busybox/files/ntpd.capabilities  | 22 
> ++
>  package/utils/busybox/files/sysntpd|  7 +++
>  .../busybox/patches/600-allow-ntpd-non-root.patch  | 12 
>  4 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile
> index b2de0a852b..6d9a0088e5 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:=4
> +PKG_RELEASE:=5
>  PKG_FLAGS:=essential
>
>  PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
> @@ -50,6 +50,7 @@ define Package/busybox/Default
>TITLE:=Core utilities for embedded Linux
>URL:=http://busybox.net/
>DEPENDS:=+BUSYBOX_CONFIG_PAM:libpam +BUSYBOX_CONFIG_NTPD:jsonfilter
> +  USERID:=ntpd=123:ntpd=123

ntpd package has
USERID:=ntp=123:ntp=123
and this cause breakage (reports on IRC and
https://github.com/openwrt/openwrt/commit/2d34355e16b442fcf51e93786401716dae3c4ea2#commitcomment-43560876)
Just replace ntpd with ntp should fix it


>  endef
>
>  define Package/busybox
> @@ -144,6 +145,8 @@ endif
>  ifneq ($(CONFIG_BUSYBOX_$(BUSYBOX_SYM)_NTPD),)
> $(INSTALL_BIN) ./files/sysntpd $(1)/etc/init.d/sysntpd
> $(INSTALL_BIN) ./files/ntpd-hotplug $(1)/usr/sbin/ntpd-hotplug
> +   $(INSTALL_DIR) $(1)/etc/capabilities/
> +   $(INSTALL_DATA) ./files/ntpd.capabilities 
> $(1)/etc/capabilities/ntpd.json
>  endif
> -rm -rf $(1)/lib64
>  endef
> diff --git a/package/utils/busybox/files/ntpd.capabilities 
> b/package/utils/busybox/files/ntpd.capabilities
> new file mode 100644
> index 00..8a05dba4bc
> --- /dev/null
> +++ b/package/utils/busybox/files/ntpd.capabilities
> @@ -0,0 +1,22 @@
> +{
> +   "bounding": [
> +   "CAP_NET_BIND_SERVICE",
> +   "CAP_SYS_TIME"
> +   ],
> +   "effective": [
> +   "CAP_NET_BIND_SERVICE",
> +   "CAP_SYS_TIME"
> +   ],
> +   "ambient": [
> +   "CAP_NET_BIND_SERVICE",
> +   "CAP_SYS_TIME"
> +   ],
> +   "permitted": [
> +   "CAP_NET_BIND_SERVICE",
> +   "CAP_SYS_TIME"
> +   ],
> +   "inheritable": [
> +   "CAP_NET_BIND_SERVICE",
> +   "CAP_SYS_TIME"
> +   ]
> +}
> diff --git a/package/utils/busybox/files/sysntpd 
> b/package/utils/busybox/files/sysntpd
> index 52866ba32a..cbc760a48e 100755
> --- a/package/utils/busybox/files/sysntpd
> +++ b/package/utils/busybox/files/sysntpd
> @@ -55,6 +55,13 @@ start_ntpd_instance() {
> procd_append_param command -p $peer
> done
> procd_set_param respawn
> +   [ -x /sbin/ujail ] && {
> +   procd_add_jail ntpd
> +   procd_set_param capabilities /etc/capabilities/ntpd.json
> +   procd_set_param user ntpd
> +   procd_set_param group ntpd
> +   procd_set_param no_new_privs 1
> +   }
> procd_close_instance
>  }
>
> diff --git a/package/utils/busybox/patches/600-allow-ntpd-non-root.patch 
> b/package/utils/busybox/patches/600-allow-ntpd-non-root.patch
> new file mode 100644
> index 00..b5d4c2a07d
> --- /dev/null
> +++ b/package/utils/busybox/patches/600-allow-ntpd-non-root.patch
> @@ -0,0 +1,12 @@
> +--- a/networking/ntpd.c
>  b/networking/ntpd.c
> +@@ -2414,9 +2414,6 @@ static NOINLINE void ntp_init(char **arg
> +
> +   srand(getpid());
> +
> +-  if (getuid())
> +-  bb_error_msg_and_die(bb_msg_you_must_be_root);
> +-
> +   /* Set some globals */
> +   G.discipline_jitter = G_precision_sec;
> +   G.stratum = MAXSTRAT;
>
> ___
> lede-commits mailing list
> lede-comm...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-commits

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

Re: [PATCH] tools/zstd: update to 1.4.5

[Etienne Champetier]

Hello Rosen,

Le mer. 2 sept. 2020 à 23:20, Rosen Penev  a écrit :
>
> Fix URL. The GITHUB macro is meant to be used for files inside a git
> repository. This gets downloaded purely by accident (19.07 packages
> feed has zstd 1.4.5 with the file in sources.openwrt.org).
>
> Remove upstream backport.
>
> Signed-off-by: Rosen Penev 
> ---
>  tools/zstd/Makefile   |  6 +-
>  ...re-portable-header-prefix-usage-1987.patch | 61 ---
>  2 files changed, 3 insertions(+), 64 deletions(-)
>  delete mode 100644 
> tools/zstd/patches/0001-build-issue-More-portable-header-prefix-usage-1987.patch
>
> diff --git a/tools/zstd/Makefile b/tools/zstd/Makefile
> index 7459725e8e..ef268c0b86 100644
> --- a/tools/zstd/Makefile
> +++ b/tools/zstd/Makefile
> @@ -1,11 +1,11 @@
>  include $(TOPDIR)/rules.mk
>
>  PKG_NAME:=zstd
> -PKG_VERSION:=1.4.4
> +PKG_VERSION:=1.4.5


There is a blocker regression in 1.4.5 for some use case:
https://github.com/facebook/zstd/issues/
Haven't checked if it impacts anything in OpenWrt

Best
Etienne

> [snip]

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

Re: Policy on BUILD_PATENTED

[Etienne Champetier]

Hi Rosen,

Le lun. 3 août 2020 à 00:04, Rosen Penev  a écrit :
>
> Recently there's been a pull request to get patented functionality in
> the packages feed: https://github.com/openwrt/packages/pull/12992
>
> Which pointed me to this lovely description: 
> https://www.videolan.org/legal.html
>
> Two excerpts:
>
> In the USA, you should check out the US Copyright Office decision that
> allows circumvention in some cases.
> VideoLAN is NOT a US-based organization and is therefore outside US
> jurisdiction.
>
> Neither French law nor European conventions recognize software as
> patentable (see French section below).
> Therefore, software patents licenses do not apply on VideoLAN software.
>
> The commit that disabled patented packages is:
> https://github.com/openwrt/openwrt/commit/dc555d003c21679c8c94ac7f5c74cbd5cd089ae0
>
> This caused controversy regarding ffmpeg at the time since it meant
> that minidlna would be unavailable.
>
> Which brings me to my question. How should BUILD_PATENTED be treated?
> OpenWrt as far as I know is not US based.

OpenWrt is represented by a US non profit, so not sure where it is based.
https://openwrt.org/about
> The remerged OpenWrt project is legally represented by the Software in the 
> Public Interest (SPI) - an US 501(c)(3) non-profit organization which is 
> managing our OpenWrt trademark, handling our donations and helping us with 
> legal problems.

Software Freedom Conservancy (future replacement of SPI) is also US based

Best

Etienne

>
> Whenever discussion about patents arise, I usually point to Fedora
> whose parent company is Red Hat, which is based in the US. There are
> many things that they do not distribute that OpenWrt does for legal
> reasons. Should Fedora's practices be mirrored or should a more
> liberal policy regarding patented functionality be taken?
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [RFC PATCH] Introduce UCI support for configuring DSA VLAN filter rules

[Etienne Champetier]

Le mar. 7 juil. 2020 à 09:36, Jo-Philipp Wich  a écrit :
>
> This patch series introduces a new package "dsaconfig" which provides the
> necessary logic to allow configuration of bridge vlan filter rules for
> DSA switches.

Nice !
[...]

>
> Open questions/topics:
>
>  - Ensure that the chosen configuration approach actually works with
>DSA_TAG_PROTO_NONE switches

Is there an easy way to find which hardware is DSA_TAG_PROTO_NONE

>  - Consider changing the types of the UCI sections from
>switch/switch_vlan/switch_port to dsa/dsa_vlan/dsa_port

Using dsa/dsa_vlan/dsa_port would remove a lot of end user confusion
and make googling easier IMO

Cheers
Etienne

>  - Investigate potential MTU issues regarding the CPU port
>
> Jo-Philipp Wich (1):

[...]

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

Re: [OpenWrt-Devel] [PATCH v2 4/4] build: use zstd for SDK and ImageBuilder tarballs

[Etienne Champetier]

Hi Petr and Matthias

Le lun. 1 juin 2020 à 06:21, Petr Štetiar  a écrit :

> Matthias Schiffer  [2020-05-31 11:08:47]:
>
> Hi,
>
> > For patch 4, I'd like to have an ACK from someone familiar with the
> buildbot
> > setup.
>
> Disclaimer: I'm Buildbot setup noob, just helping occasionally with the
> maintenance burden, but from my limited understanding it's not just about
> ACK,
> some additional work is needed:
>
>  1. Someone has to provide patches against Buildbot[1] repo with the zstd
> naming changes
>  2. Someone has to build and publish updated Docker images for buildbot
> master/slave
>  3. Someone has to deploy this on machines under our control (having root
> access), we need to notify owners of the buildslave machines to
> upgrade their
> buildslaves to the updated Docker images built/published in step 2.
>

4. Fixup some of the feed repo CI
https://github.com/openwrt/packages/blob/master/.circleci/config.yml#L9
https://github.com/openwrt/telephony/blob/master/.circleci/config.yml#L9
(not sure the docker image has zstd, might also need to rebuild it)

Regards
Etienne


> I can probably help with 2. and 3., I would ideally done this with Buildbot
> version bump which is in the works[1], so we don't bother people with
> buildslaves upgrades that often.
>
> 1. https://git.openwrt.org/?p=buildbot.git
> 2.
> https://git.openwrt.org/?p=buildbot.git;a=shortlog;h=refs/heads/buildbot-2.4.1
>
> -- ynezz
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] package/base-files: caldata: work around dd's limitation

[Etienne Champetier]

Hi Thibaut,

Le dim. 17 mai 2020 à 15:46, Thibaut VARÈNE  a écrit :
>
> tl;dr: dd will silently truncate the output if reading from special
> files (e.g. sysfs attributes) with a too large bs parameter.
>
> This problem was exposed on some RouterBOARD ipq40xx devices which use a
> caldata payload which is larger than PAGE_SIZE, contrary to all other
> currently supported RouterBOARD devices: the caldata would fail to
> properly load with the current scripts.
>
> Background: dd doesn't seem to correctly handle read() results that
> return less than requested data. sysfs attributes have a kernel exchange
> buffer which is at most PAGE_SIZE big, so only 1 page can be read() at a
> time. In this case, if bs is larger than PAGE_SIZE, dd will silently
> truncate blocks to PAGE_SIZE. With the current scripts using bs=
> count=1, the data is truncated to PAGE_SIZE as soon as the requested
>  exceeds this value.
>
> This commit works around this problem by using `cat` in the caldata
> routines that can read from a file (routines that read from mtd devices
> are untouched). cat correctly handles partial read requests. The output
> is then piped to dd with the same parameters as before, to ensure that
> the resulting file remains exactly the same.
>
> This is a simple workaround, the downside is that it uses a pipe and one
> more executable, and therefore has a larger memory footprint and is
> slower. This is deemed acceptable considering these routines are only
> used at boot time.
>
> Tested-by: Robert Marko 
> Signed-off-by: Thibaut VARÈNE 
> ---
> v2: leave a comment in scripts
> ---
>  package/base-files/Makefile   | 2 +-
>  package/base-files/files/lib/functions/caldata.sh | 8 +---
>  2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/package/base-files/Makefile b/package/base-files/Makefile
> index d8e7c31878..5fb275533d 100644
> --- a/package/base-files/Makefile
> +++ b/package/base-files/Makefile
> @@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
>  include $(INCLUDE_DIR)/feeds.mk
>
>  PKG_NAME:=base-files
> -PKG_RELEASE:=220
> +PKG_RELEASE:=221
>  PKG_FLAGS:=nonshared
>
>  PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
> diff --git a/package/base-files/files/lib/functions/caldata.sh 
> b/package/base-files/files/lib/functions/caldata.sh
> index 6862da7164..e22c7d27e6 100644
> --- a/package/base-files/files/lib/functions/caldata.sh
> +++ b/package/base-files/files/lib/functions/caldata.sh
> @@ -64,7 +64,8 @@ caldata_from_file() {
>
> [ -n "$target" ] || target=/lib/firmware/$FIRMWARE
>
> -   dd if=$source of=$target iflag=skip_bytes bs=$count skip=$offset 
> count=1 2>/dev/null || \
> +   # dd doesn't handle partial reads from special files: use cat
> +   cat $source | dd of=$target iflag=skip_bytes bs=$count skip=$offset 
> count=1 2>/dev/null || \

Not way more elegant, but you could use something like
tail -c+$start $source | head -c$count > $target
with $start == $offset+1 I think

# head -c10 /dev/zero | wc
0 010
# head -c10 /dev/zero | tail -c+3 | wc
0 0 8

> caldata_die "failed to extract calibration data from $source"
>  }
>
> @@ -73,13 +74,14 @@ caldata_sysfsload_from_file() {
> local offset=$(($2))
> local count=$(($3))
>
> +   # dd doesn't handle partial reads from special files: use cat
> # test extract to /dev/null first
> -   dd if=$source of=/dev/null iflag=skip_bytes bs=$count skip=$offset 
> count=1 2>/dev/null || \
> +   cat $source | dd of=/dev/null iflag=skip_bytes bs=$count skip=$offset 
> count=1 2>/dev/null || \
> caldata_die "failed to extract calibration data from $source"
>
> # can't fail now
> echo 1 > /sys/$DEVPATH/loading
> -   dd if=$source of=/sys/$DEVPATH/data iflag=skip_bytes bs=$count 
> skip=$offset count=1 2>/dev/null
> +   cat $source | dd of=/sys/$DEVPATH/data iflag=skip_bytes bs=$count 
> skip=$offset count=1 2>/dev/null
> echo 0 > /sys/$DEVPATH/loading
>  }
>
> --
> 2.11.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] MT7621 and bridge firewalling

[Etienne Champetier]

Le dim. 26 avr. 2020 à 10:57, Etienne Champetier
 a écrit :
>
> Hi All,
>
> Le sam. 11 avr. 2020 à 12:48, Etienne Champetier
>  a écrit :
> >
> > Hello OpenWrt hackers,
> >
> > I'm playing around with OpenWrt master on a MikroTik RB750Gr3 and
> > would like to do hardware accelerated statefull bridge firewalling. My
> > end goal is to learn and make PhanTap
> > (https://github.com/nccgroup/phantap) work at line rate.
> >
> > MT7621 supports flow offload, so the high level idea would be to:
> > - create a linux bridge with 2 ports (say lan4/lan5)
> > - disable normal switch offload (do not forward just based on mac
> > dest) and have the packets go through netfilter
>
> Big thanks to Qingfang for the tip, for this part I just disabled MAC leaning
>
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -1319,6 +1319,9 @@ mt7530_setup(struct dsa_switch *ds)
>  /* Enable consistent egress tag */
>  mt7530_rmw(priv, MT7530_PVC_P(i), PVC_EG_TAG_MASK,
> PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
> +
> +/* hack */
> +mt7530_set(priv, MT7530_PSC_P(i), SA_DIS);
>  }
>
>  /* Setup port 5 */
>
> > - have netfilter create/install flow offload rules for most
> > connections like we do for the routing case.

Just trying to have software flow offloading for bridge working on
RB750Gr3 (Linux 5.4)
sysctl -w net.bridge.bridge-nf-call-iptables=1

In iptables I see the FLOWOFFLOAD rule
# iptables-save
...
-A FORWARD -m comment --comment "!fw3: Custom forwarding rule chain"
-j forwarding_rule
-A FORWARD -m comment --comment "!fw3: Traffic offloading" -m
conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
...

In conntrack I see [OFFLOAD] connections
# cat /proc/net/nf_conntrack
ipv4 2 tcp  6 src=192.168.1.2 dst=192.168.1.15 sport=56018
dport=22 packets=29858 bytes=1609629 src=192.168.1.15 dst=192.168.1.2
sport=22 dport=56018 packets=57155 bytes=20636422 [OFFLOAD] mark=0
zone=0 use=3

But if I add an iptables LOG rule
# iptables -A forwarding_rule -j LOG --log-prefix "ipt forward: " --log-level 4

# logread -f
...
Sun Apr 26 17:56:33 2020 kern.warn kernel: [ 8798.430466] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=lan5 PHYSOUT=lan2
MAC=50:7b:9d:f0:06:4e:e4:95:6e:47:66:4c:08:00 SRC=192.168.1.15
DST=192.168.1.2 LEN=148 TOS=0x10 PREC=0x00 TTL=64 ID=57031 DF
PROTO=TCP SPT=22 DPT=56018 WINDOW=2687 RES=0x00 ACK PSH URGP=0
Sun Apr 26 17:56:33 2020 kern.warn kernel: [ 8798.454055] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=lan2 PHYSOUT=lan5
MAC=e4:95:6e:47:66:4c:50:7b:9d:f0:06:4e:08:00 SRC=192.168.1.2
DST=192.168.1.15 LEN=52 TOS=0x08 PREC=0x40 TTL=64 ID=40139 DF
PROTO=TCP SPT=56018 DPT=22 WINDOW=1316 RES=0x00 ACK URGP=0
...

Same test with 2 separate interfaces (GL-AR150 / Linux 4.19):
# logread -f
Sat Apr 25 22:04:40 2020 kern.warn kernel: [  968.671777] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=eth1 PHYSOUT=eth0
MAC=50:7b:9d:f0:06:4e:e4:95:6e:47:66:4c:08:00 SRC=192.168.1.15
DST=192.168.1.2 LEN=116 TOS=0x10 PREC=0x00 TTL=64 ID=48741 DF
PROTO=TCP SPT=22 DPT=58094 WINDOW=2165 RES=0x00 ACK PSH URGP=0
Sat Apr 25 22:04:40 2020 kern.warn kernel: [  968.698088] ipt forward:
IN=br-lan OUT=br-lan PHYSIN=eth0 PHYSOUT=eth1
MAC=e4:95:6e:47:66:4c:50:7b:9d:f0:06:4e:08:00 SRC=192.168.1.2
DST=192.168.1.15 LEN=52 TOS=0x08 PREC=0x40 TTL=64 ID=31502 DF
PROTO=TCP SPT=58094 DPT=22 WINDOW=83 RES=0x00 ACK URGP=0
# grep 192.168.1.15 /proc/net/nf_conntrack
ipv4 2 tcp  6 src=192.168.1.2 dst=192.168.1.15 sport=58094
dport=22 packets=461 bytes=40449 src=192.168.1.15 dst=192.168.1.2
sport=22 dport=58094 packets=252 bytes=35034 [OFFLOAD] mark=0 zone=0
use=3

So software flow offload seems broken with bridge :(
(I'll do some more tests with classic distros and latest Linux version)



> > - enjoy
> >
> > My questions are:
> > - will the hardware let me do that (any restrictions on the flow
> > offload rules or ...) ?
> > - is it already possible with OpenWrt master (I was not able to have a
> > bridge without offload yet) ?
> > - any pointer to ongoing work in that area (while writing this email I
> > just found NF_CONNTRACK_BRIDGE)
> >
> > Thanks
> > Etienne

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

Re: [OpenWrt-Devel] MT7621 and bridge firewalling

[Etienne Champetier]

Hi All,

Le sam. 11 avr. 2020 à 12:48, Etienne Champetier
 a écrit :
>
> Hello OpenWrt hackers,
>
> I'm playing around with OpenWrt master on a MikroTik RB750Gr3 and
> would like to do hardware accelerated statefull bridge firewalling. My
> end goal is to learn and make PhanTap
> (https://github.com/nccgroup/phantap) work at line rate.
>
> MT7621 supports flow offload, so the high level idea would be to:
> - create a linux bridge with 2 ports (say lan4/lan5)
> - disable normal switch offload (do not forward just based on mac
> dest) and have the packets go through netfilter

Big thanks to Qingfang for the tip, for this part I just disabled MAC leaning

--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1319,6 +1319,9 @@ mt7530_setup(struct dsa_switch *ds)
 /* Enable consistent egress tag */
 mt7530_rmw(priv, MT7530_PVC_P(i), PVC_EG_TAG_MASK,
PVC_EG_TAG(MT7530_VLAN_EG_CONSISTENT));
+
+/* hack */
+mt7530_set(priv, MT7530_PSC_P(i), SA_DIS);
 }

 /* Setup port 5 */

> - have netfilter create/install flow offload rules for most
> connections like we do for the routing case.
> - enjoy
>
> My questions are:
> - will the hardware let me do that (any restrictions on the flow
> offload rules or ...) ?
> - is it already possible with OpenWrt master (I was not able to have a
> bridge without offload yet) ?
> - any pointer to ongoing work in that area (while writing this email I
> just found NF_CONNTRACK_BRIDGE)
>
> Thanks
> Etienne

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

Re: [OpenWrt-Devel] [PATCH RFC procd] jail: add option to provide /dev/console to containers

[Etienne Champetier]

Hi Daniel

Le dim. 26 avr. 2020 à 06:53, Daniel Golle  a écrit :
>
> Hi Etienne,
>
> On Sat, Apr 25, 2020 at 10:37:01PM -0400, Etienne Champetier wrote:
> > Hi Daniel,
> >
> > Le sam. 25 avr. 2020 à 19:48, Daniel Golle  a écrit :
> > >
> > > Create UNIX/98 PTY, pass master fd to procd and setup mount-bind of
> > > slave PTS device on /dev/console inside jail.
> > > Allow attaching to an instance's console by using the newly introduced
> > > ujail-console command (no multiplexing for now).
> >
> > Just curious how far you want to push ujail ?
> > ie do you want a docker lite / what features do you want to add ?
>
> More like runc-lite with ubus support :)
> Ideally with roughly 80% of features covered with about 20% of the
> code...
> Most features have been added by now, next steps would be cleaning up
> and fixing things. For now, userns support needs a lot more love to
> function properly, starting with deciding about quite fundamental
> things like this one:
>
> https://aur.archlinux.org/cgit/aur.git/tree/ubuntu-unprivileged-overlayfs.patch?h=linux-userns
>
> (or use FUSE-based approach like LXC, but that's a lot of overhead...)
>
> What I'm still planning for procd/ujail is basic support for cgroupsv2
> (including a way to use cgroup-devices via static BPF, similar to how
> we generate BPF for seccomp filter)
> So no volume/image-management, no docker index, no freezer/migration,
> but good enough to boot Debian, Arch or Alpine rootfs.
>
> See my incomplete prototype tool: https://guthub.com/dangowrt/uxc
>
> The idea is to add useful features to procd for single services up to
> full-system containers running systemd inside (and everything in
> between). Think of network-namespaces which is already useful now to
> wire up any service with veth device(s) in it's own netns or tmpoverlay
> which is useful eg. for transmission which wants to create temporary
> files at run-time having a random names...
>
> Anyway, all testing, feedback and review is highly appreciated!

Nice!

One really useful feature that I would like to have is ambient
capabilities, to easily run as non root many daemons
(and ideally it should be in procd / always available)

Thanks for all this work
Etienne

>
>
> Cheers
>
>
>
> Daniel
>
>
>
>
> >
> > Regards
> > Etienne
> >
> > >
> > > Signed-off-by: Daniel Golle 
> > > ---
> > >  CMakeLists.txt |   6 ++
> > >  jail/console.c | 209 +
> > >  jail/jail.c|  83 +-
> > >  service/instance.c |  70 +++
> > >  service/instance.h |   3 +
> > >  service/service.c  |  71 +++
> > >  6 files changed, 438 insertions(+), 4 deletions(-)
> > >  create mode 100644 jail/console.c
> > >
> > > diff --git a/CMakeLists.txt b/CMakeLists.txt
> > > index cff47cf..3eb79f9 100644
> > > --- a/CMakeLists.txt
> > > +++ b/CMakeLists.txt
> > > @@ -110,6 +110,12 @@ INSTALL(TARGETS ujail
> > > RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
> > >  )
> > >  ADD_DEPENDENCIES(ujail capabilities-names-h)
> > > +
> > > +ADD_EXECUTABLE(ujail-console jail/console.c)
> > > +TARGET_LINK_LIBRARIES(ujail-console ${ubox} ${ubus} ${blobmsg_json})
> > > +INSTALL(TARGETS ujail-console
> > > +   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
> > > +)
> > >  endif()
> > >
> > >  IF(UTRACE_SUPPORT)
> > > diff --git a/jail/console.c b/jail/console.c
> > > new file mode 100644
> > > index 000..75ce9c5
> > > --- /dev/null
> > > +++ b/jail/console.c
> > > @@ -0,0 +1,209 @@
> > > +/*
> > > + * Copyright (C) 2020 Daniel Golle 
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU Lesser General Public License version 
> > > 2.1
> > > + * as published by the Free Software Foundation
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> &g

Re: [OpenWrt-Devel] [PATCH RFC procd] jail: add option to provide /dev/console to containers

[Etienne Champetier]

Hi Daniel,

Le sam. 25 avr. 2020 à 19:48, Daniel Golle  a écrit :
>
> Create UNIX/98 PTY, pass master fd to procd and setup mount-bind of
> slave PTS device on /dev/console inside jail.
> Allow attaching to an instance's console by using the newly introduced
> ujail-console command (no multiplexing for now).

Just curious how far you want to push ujail ?
ie do you want a docker lite / what features do you want to add ?

Regards
Etienne

>
> Signed-off-by: Daniel Golle 
> ---
>  CMakeLists.txt |   6 ++
>  jail/console.c | 209 +
>  jail/jail.c|  83 +-
>  service/instance.c |  70 +++
>  service/instance.h |   3 +
>  service/service.c  |  71 +++
>  6 files changed, 438 insertions(+), 4 deletions(-)
>  create mode 100644 jail/console.c
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index cff47cf..3eb79f9 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -110,6 +110,12 @@ INSTALL(TARGETS ujail
> RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
>  )
>  ADD_DEPENDENCIES(ujail capabilities-names-h)
> +
> +ADD_EXECUTABLE(ujail-console jail/console.c)
> +TARGET_LINK_LIBRARIES(ujail-console ${ubox} ${ubus} ${blobmsg_json})
> +INSTALL(TARGETS ujail-console
> +   RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
> +)
>  endif()
>
>  IF(UTRACE_SUPPORT)
> diff --git a/jail/console.c b/jail/console.c
> new file mode 100644
> index 000..75ce9c5
> --- /dev/null
> +++ b/jail/console.c
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright (C) 2020 Daniel Golle 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License version 2.1
> + * as published by the Free Software Foundation
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static inline int setup_tios(int fd, struct termios *oldtios)
> +{
> +   struct termios newtios;
> +
> +   if (!isatty(fd)) {
> +   return -1;
> +   }
> +
> +   /* Get current termios */
> +   if (tcgetattr(fd, oldtios))
> +   return -1;
> +
> +   newtios = *oldtios;
> +
> +   /* Remove the echo characters and signal reception, the echo
> +* will be done with master proxying */
> +   newtios.c_iflag &= ~IGNBRK;
> +   newtios.c_iflag &= BRKINT;
> +   newtios.c_lflag &= ~(ECHO|ICANON|ISIG);
> +   newtios.c_cc[VMIN] = 1;
> +   newtios.c_cc[VTIME] = 0;
> +
> +   /* Set new attributes */
> +   if (tcsetattr(fd, TCSAFLUSH, ))
> +   return -1;
> +
> +   return 0;
> +}
> +
> +
> +
> +#define OPT_ARGS   "i:s:"
> +
> +static struct ustream_fd cufd;
> +static struct ustream_fd lufd;
> +
> +static void usage()
> +{
> +   fprintf(stderr, "ujail-console -s  [-i ]\n");
> +   exit(1);
> +}
> +
> +static void client_cb(struct ustream *s, int bytes)
> +{
> +   char *buf;
> +   int len, rv;
> +
> +   do {
> +   buf = ustream_get_read_buf(s, );
> +   if (!buf)
> +   break;
> +
> +   rv = ustream_write(, buf, len, false);
> +
> +   if (rv > 0)
> +   ustream_consume(s, rv);
> +
> +   if (rv <= len)
> +   break;
> +   } while(1);
> +}
> +
> +static void local_cb(struct ustream *s, int bytes)
> +{
> +   char *buf;
> +   int len, rv;
> +
> +   do {
> +   buf = ustream_get_read_buf(s, );
> +   if (!buf)
> +   break;
> +
> +   if ((len > 0) && (buf[0] == 2))
> +   uloop_end();
> +
> +   rv = ustream_write(, buf, len, false);
> +
> +   if (rv > 0)
> +   ustream_consume(s, rv);
> +
> +   if (rv <= len)
> +   break;
> +   } while(1);
> +}
> +
> +int main(int argc, char **argv)
> +{
> +   struct ubus_context *ctx;
> +   uint32_t id;
> +   static struct blob_buf req;
> +   char *service_name = NULL, *instance_name = NULL;
> +   int client_fd, server_fd, tty_fd;
> +   struct termios oldtermios;
> +   int ch;
> +
> +   while ((ch = getopt(argc, argv, OPT_ARGS)) != -1) {
> +   switch (ch) {
> +   case 'i':
> +   instance_name = optarg;
> +   break;
> +   case 's':
> +   service_name = optarg;
> +   break;
> +   default:
> +   usage();
> +   }
> +   }

Re: [OpenWrt-Devel] ubus acls for params or hotplugd ?

[Etienne Champetier]

Hi all,

Le dim. 19 avr. 2020 à 20:16, Etienne Champetier
 a écrit :
>
> Hi all,
>
> Most OpenWrt daemon are still running as root today.
> If we take the case of ntpd, to do its job it just need CAP_SYS_TIME
> and to be able to deliver a hotplug event.
> Right now hotplug-call is a simple shell loop executing all the
> scripts in /etc/hotplug.d/$1/, so ntpd need to run as root.
>
> I would like to have this hotplug call go over ubus, and I see 2 ways:
> 1) either extend ubus acl to validate params, then have a generic exec
> functionality to basically have a sudo via ubus (really flexible but
> not super clean)
> 2) or have a small hotplugd that publish one path per type (ie have
> 'hotplug.ntp' with an 'event' method)
>
> Similarly to ntpd, udhcpc and odhcp6c don't require much capabilities
> (at most CAP_NET_RAW, CAP_NET_BIND_SERVICE) if we send the dhcp events
> as hotplug events over ubus.
>
> As some of you might already have ideas on this topic, I'm sending
> this email to get feedback how you would see this implemented (1, 2 or
> ...)

I had a good chat with Jow today on IRC and here is a sum up.
What we agree on:
- extending acl to filter on params would slow down ubus in the
default case and complicate the code, so it's better to have a
path/namespace per type
- we should extend procd instead of having a separate 'hotplugd' deamon
- this new mechanism should be smart enough to detect new event type at runtime
- the event params are untrusted, when converting them to environment
variables, we either need to whitelist them, to prefix them or a
combination of both.
If prefixing we need to ensure the name is a valid identifier
([^a-zA-Z0-9_]+) or reject the full request
- we should only support basic types for params (numbers / strings /
bool) and no nesting

What need more discussion:
- if we don't whitelist all currently used variables for hotplug
events, we need to adapt all current hotplug scripts. This means
potential breakage for OpenWrt derivatives.
(if multiple devs are fine with it I'm also fine)
- hotplug semantic is fire and forget, ie you don't expect a return
code, but for cases like udhcpc / odhcp6c the return code might be
important, and we don't really want to execute multiple scripts
(we could have /etc/hotplug.d/script ?)
- threading model, I was thinking only 1 exec at a time per type to be
on the safe side

Comments welcome
Etienne

>
> Thanks
> Etienne

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

[OpenWrt-Devel] ubus acls for params or hotplugd ?

[Etienne Champetier]

Hi all,

Most OpenWrt daemon are still running as root today.
If we take the case of ntpd, to do its job it just need CAP_SYS_TIME
and to be able to deliver a hotplug event.
Right now hotplug-call is a simple shell loop executing all the
scripts in /etc/hotplug.d/$1/, so ntpd need to run as root.

I would like to have this hotplug call go over ubus, and I see 2 ways:
1) either extend ubus acl to validate params, then have a generic exec
functionality to basically have a sudo via ubus (really flexible but
not super clean)
2) or have a small hotplugd that publish one path per type (ie have
'hotplug.ntp' with an 'event' method)

Similarly to ntpd, udhcpc and odhcp6c don't require much capabilities
(at most CAP_NET_RAW, CAP_NET_BIND_SERVICE) if we send the dhcp events
as hotplug events over ubus.

As some of you might already have ideas on this topic, I'm sending
this email to get feedback how you would see this implemented (1, 2 or
...)

Thanks
Etienne

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

Re: [OpenWrt-Devel] MT7621 and bridge firewalling

[Etienne Champetier]

Le sam. 11 avr. 2020 à 12:48, Etienne Champetier
 a écrit :
>
> Hello OpenWrt hackers,
>
> I'm playing around with OpenWrt master on a MikroTik RB750Gr3 and
> would like to do hardware accelerated statefull bridge firewalling. My
> end goal is to learn and make PhanTap
> (https://github.com/nccgroup/phantap) work at line rate.
>
> MT7621 supports flow offload, so the high level idea would be to:
> - create a linux bridge with 2 ports (say lan4/lan5)
> - disable normal switch offload (do not forward just based on mac
> dest) and have the packets go through netfilter
> - have netfilter create/install flow offload rules for most
> connections like we do for the routing case.
> - enjoy
>
> My questions are:
> - will the hardware let me do that (any restrictions on the flow
> offload rules or ...) ?
> - is it already possible with OpenWrt master (I was not able to have a
> bridge without offload yet) ?
> - any pointer to ongoing work in that area (while writing this email I
> just found NF_CONNTRACK_BRIDGE)

I spent part of the day randomly patching out some part of the kernel, example:

--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1658,15 +1658,15 @@ static const struct dsa_switch_ops mt753
 .port_enable= mt7530_port_enable,
 .port_disable= mt7530_port_disable,
 .port_stp_state_set= mt7530_stp_state_set,
-.port_bridge_join= mt7530_port_bridge_join,
-.port_bridge_leave= mt7530_port_bridge_leave,
-.port_fdb_add= mt7530_port_fdb_add,
-.port_fdb_del= mt7530_port_fdb_del,
+//.port_bridge_join= mt7530_port_bridge_join,
+//.port_bridge_leave= mt7530_port_bridge_leave,
+//.port_fdb_add= mt7530_port_fdb_add,
+//.port_fdb_del= mt7530_port_fdb_del,
 .port_fdb_dump= mt7530_port_fdb_dump,
-.port_vlan_filtering= mt7530_port_vlan_filtering,
-.port_vlan_prepare= mt7530_port_vlan_prepare,
-.port_vlan_add= mt7530_port_vlan_add,
-.port_vlan_del= mt7530_port_vlan_del,
+//.port_vlan_filtering= mt7530_port_vlan_filtering,
+//.port_vlan_prepare= mt7530_port_vlan_prepare,
+//.port_vlan_add= mt7530_port_vlan_add,
+//.port_vlan_del= mt7530_port_vlan_del,
 .port_mirror_add= mt7530_port_mirror_add,
 .port_mirror_del= mt7530_port_mirror_del,
 .phylink_validate= mt7530_phylink_validate,

I was only able to break unicast traffic :(
L2 broadcast works fine but I don't see unicast responses if the dst
MAC is not the one of the switch
As a first step I just want all traffic of lanX to go to the software
bridge, but no luck so far

>
> Thanks
> Etienne

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

[OpenWrt-Devel] MT7621 and bridge firewalling

[Etienne Champetier]

Hello OpenWrt hackers,

I'm playing around with OpenWrt master on a MikroTik RB750Gr3 and
would like to do hardware accelerated statefull bridge firewalling. My
end goal is to learn and make PhanTap
(https://github.com/nccgroup/phantap) work at line rate.

MT7621 supports flow offload, so the high level idea would be to:
- create a linux bridge with 2 ports (say lan4/lan5)
- disable normal switch offload (do not forward just based on mac
dest) and have the packets go through netfilter
- have netfilter create/install flow offload rules for most
connections like we do for the routing case.
- enjoy

My questions are:
- will the hardware let me do that (any restrictions on the flow
offload rules or ...) ?
- is it already possible with OpenWrt master (I was not able to have a
bridge without offload yet) ?
- any pointer to ongoing work in that area (while writing this email I
just found NF_CONNTRACK_BRIDGE)

Thanks
Etienne

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

Re: [OpenWrt-Devel] Java compiler

[Etienne Champetier]

Le ven. 10 avr. 2020 à 17:09, Etienne Champetier
 a écrit :
>
> Hi Michael,
>
> Le ven. 10 avr. 2020 à 16:48, W. Michael Petullo  a écrit :
> >
> > Has anyone tried to build a Java compiler package for OpenWrt? I am
> > investigating doing this. I see the lang/jamvm JVM, but no compiler
> > akin to devel/gcc or lang/golang. I have packaged a number of things,
> > but I suspect this will be a bit more of a challenge. Hence my question
> > here.
>
> Do you want the JDK on the router ? or the JDK in the toolchain and
> "just" the JRE on the router ?
> For both JDK and JRE I don't know what architecture are officially
> supported, but that would be the first think to check, because
> debugging a JIT compiler might require some work :P

Here a bit old but good presentation of java hotspot debugging fun
https://archive.fosdem.org/2016/schedule/event/hunting_the_bug_from_hell/

> Good luck!
>
> >
> > Thank you!
> >
> > --
> > Mike
> >
> > :wq
> >
> >
> > ___
> > openwrt-devel mailing list
> > openwrt-devel@lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Java compiler

[Etienne Champetier]

Hi Michael,

Le ven. 10 avr. 2020 à 16:48, W. Michael Petullo  a écrit :
>
> Has anyone tried to build a Java compiler package for OpenWrt? I am
> investigating doing this. I see the lang/jamvm JVM, but no compiler
> akin to devel/gcc or lang/golang. I have packaged a number of things,
> but I suspect this will be a bit more of a challenge. Hence my question
> here.

Do you want the JDK on the router ? or the JDK in the toolchain and
"just" the JRE on the router ?
For both JDK and JRE I don't know what architecture are officially
supported, but that would be the first think to check, because
debugging a JIT compiler might require some work :P
Good luck!

>
> Thank you!
>
> --
> Mike
>
> :wq
>
>
> ___
> 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] 454 TLS currently unavailable on openwrt.org email

[Etienne Champetier]

Hello,

Just a heads up, I tried to send an email to @openwrt.org (not
lists.openwrt.org) and gmail fails to deliver it, error message is:
454 TLS currently unavailable

Regards
Etienne

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

Re: [OpenWrt-Devel] [PATCH] ath79: WNDR3700 v1/v2: make u-boot env partition writable

[Etienne Champetier]

Hello Hannu,

Le lun. 3 févr. 2020 à 14:59, Hannu Nyman  a écrit :
>
> Michal Cieslakiewicz kirjoitti 3.2.2020 klo 20.54:
> > Remove read-only flag from U-boot environment partition for Netgear
> > WNDR3700 v1 and v2 so u-boot-envtools can modify data there.
> >
>
> Any reason, why you have left out the third router in the series, WNDR3800?
> It is identical to WNDR3700v2 except the RAM amount. If the u-boot-env
> read-only attribute is modified for v1 and v2, also 3800 would be logical to
> fix at the same time.

I see 1 use case that is not really common, it's the ability to
enable/disable failsafe

>
> Btw, what is the practical need for this change?  During the last 10 years
> with OpenWrt with this router I have not seen any need for modifying the
> u-boot-env.
>

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

Re: [OpenWrt-Devel] [PATCH 2/4] kernel: add backported phy/phylink/sfp patches

[Etienne Champetier]

Hello Russell,

Le mar. 26 nov. 2019 à 14:50, Russell King - ARM Linux admin
 a écrit :
>
> On Tue, Nov 26, 2019 at 12:07:43AM +, Russell King - ARM Linux admin 
> wrote:
> > René,
> >
> > I can see your reply in the OpenWrt archives, but I never received
> > it, so I can't reply to it...  (I'm not subscribed to openwrt-devel.)
> >
> > Yes, it could be made generic I suppose, if you understand the
> > OpenWrt build system and where stuff needs to be placed.  Any
> > suggestions where these should go?
> >
> > Sorry, but I've already spent many hours trying to get the OpenWrt
> > build system to a state that I was able to build just a kernel and
> > associated kmod packages that I don't have the patience to try and
> > delve into the amazingly complex makefiles that someone's dreamt up...
> > My impression is that the build system is designed to keep people out!
> >
> > Russell.
>
> All,
>
> Some guidance would be most helpful.  Silence on the other hand
> will result in nothing changing.

For faster response try IRC #openwrt-devel

> It's been suggested privately by Telus that they go in
> target/linux/generic/backport-4.19.  What about numbering, how
> do the patch numbers get allocated?  Do I just pick something at
> random?
>
> Some clues would be really useful.

This page might have some answers
https://openwrt.org/docs/guide-developer/build-system/use-patches-with-buildsystem#naming_patches

Etienne

>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
>

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

Re: [OpenWrt-Devel] [PATCH procd] initd/init: add minimal SELinux policy loading support

[Etienne Champetier]

Hello Thomas,

Le lun. 18 nov. 2019 à 05:33, Thomas Petazzoni
 a écrit :
>
> Hello Petr,
>
> Thanks for your feedback again.
>
> On Sat, 16 Nov 2019 14:22:13 +0100
> Petr Štetiar  wrote:
>
> > (nitpick, it's OpenWrt, not OpenWRT)
>
> Thanks for this clarification, it's always good to use the proper
> capitalization for project names. I'll try to use OpenWrt in the
> future, but please bear with me if I sometimes forget.
>
> > > No, this patch is not RFC, it should be ready for merging, I'm already
> > > using it in some devices.
> >
> > Ok, this patch is good enough for your limited use case, but in order to
> > include SELinux support in OpenWrt, then the first patch series should be 
> > more
> > comprehensive, minimal yet complete.
>
> I guess I'll send the patch series itself, so we can have the
> discussion on the actual proposal. I sent this procd patch separately,
> just because it is a requirement for the rest of the series to work
> (right now I was working with this procd patch in the OpenWrt procd
> package).
>
> > > The thing is that the SELinux support in OpenWRT needs this improvement
> > > in procd, otherwise it won't work at runtime as nothing will be loading
> > > the SELinux policy.
> >
> > Where is that policy? What about kernel part? What about userspace part? 
> > What
> > about filesystem image? And so on.
>
> In terms of policy, I'm simply using the reference policy provided by
> the SELinux project itself, with no specific customization for OpenWrt.
> Of course, additional tuning may be required, but for my use case, it
> was sufficient. In terms of kernel part, it of course requires some
> kernel options to be enabled. In terms of user-space parts, this is
> where my patch series is the most interesting: it packages all the
> user-space components that are necessary to be able to work with
> SELinux.

If you can include the compressed size of each part, this is also
important for the discussion I think
I know part of the debug tools on regular distro, like audit2why, are
python scripts, so pretty huge dependency

Regards
Etienne

>
> > > Regarding the flash space, RAM and CPU overhead, I'm not sure it's that
> > > relevant: the SELinux packaging I've done makes it completely optional,
> > > so you only have an impact of flash space, RAM and CPU if you enable
> > > SELinux support.
> >
> > Once its merged, we basically say, that its more or less supported, even if
> > it's optional.
> >
> > It's pretty much crystal clear, that some additional hardening layer would 
> > be
> > very welcome. I think, that OpenWrt should aim for something, which could be
> > usable on most of modern devices today and enabled by default. Security
> > shouldn't be an option, it should be default.
> >
> > SELinux is just one of the LSMs in Linux.  Is SELinux the right one for
> > OpenWrt project? Are we going to support all of them? I doubt that, so
> > decision needs to be made.
>
> I guess here I don't have the OpenWrt mindset, as I come from a
> Buildroot background. Buildroot supports multiple solutions for the
> same "problem", and let users decide which solution they want to use
> (so the users have some integration work to do), while it seems that
> OpenWrt wants to make a decision on one solution to use, but provide
> something that is seamlessly integrated for users.
>
> > > Do you have more details about entering failsafe mode ? How do you do 
> > > that ?
> >
> > It's usually triggered by the button during the boot process[1], but it 
> > should
> > be possible to force it from procd as well.
> >
> > 1. 
> > https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset
>
> OK, thanks.
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] wireless-regdb: Make it build with python2

[Etienne Champetier]

Hi Hauke,

Le dim. 17 nov. 2019 à 15:00, Hauke Mehrtens  a écrit :
>
> This backports a patch to build it work with python2 in addition to
> python3.

Why not make the scripts "/usr/bin/env python3" and require python 3 in 19.07 ?
(I'm stuborn but I don't understand trying to keep python2 alive or
using unversionned python)

Cheers
Etienne

>
> Signed-off-by: Hauke Mehrtens 
> ---
>
> After this patch went into master I would like to backport all the
> changes for wireless-regdb from master to OpenWrt 19.07.
> There are already some changes to the regulatory rules in this database
> and I would like to stay close to the current legal guidelines for
> OpenWrt 19.07 as well.
>
>  ...regdb-fix-compatibility-with-python2.patch | 58 +++
>  1 file changed, 58 insertions(+)
>  create mode 100644 
> package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
>
> diff --git 
> a/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
>  
> b/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
> new file mode 100644
> index 00..81f50f5dc0
> --- /dev/null
> +++ 
> b/package/firmware/wireless-regdb/patches/010-regdb-fix-compatibility-with-python2.patch
> @@ -0,0 +1,58 @@
> +From 651e39dee8605995b736b6056c6f7dc5c5a9c948 Mon Sep 17 00:00:00 2001
> +From: Johannes Berg 
> +Date: Thu, 22 Aug 2019 21:46:27 +0200
> +Subject: [PATCH] regdb: fix compatibility with python2
> +
> +Various changes in the commit mentioned below broke
> +compatibility with python2. Restore it in a way that
> +makes it worth with both versions.
> +
> +Fixes: f3c4969c2485 ("wireless-regdb: make scripts compatible with Python 3")
> +Signed-off-by: Johannes Berg 
> +Signed-off-by: Seth Forshee 
> +---
> + db2bin.py  | 2 +-
> + db2fw.py   | 2 +-
> + dbparse.py | 3 +--
> + 3 files changed, 3 insertions(+), 4 deletions(-)
> +
> +--- a/db2bin.py
>  b/db2bin.py
> +@@ -118,7 +118,7 @@ reg_country_ptr.set()
> + for alpha2 in countrynames:
> + coll = countries[alpha2]
> + # struct regdb_file_reg_country
> +-output.write(struct.pack('>BBxBI', alpha2[0], alpha2[1], 
> coll.dfs_region, reg_rules_collections[coll.permissions]))
> ++output.write(struct.pack('>2sxBI', alpha2, coll.dfs_region, 
> reg_rules_collections[coll.permissions]))
> +
> +
> + if len(sys.argv) > 3:
> +--- a/db2fw.py
>  b/db2fw.py
> +@@ -85,7 +85,7 @@ countrynames = list(countries)
> + countrynames.sort()
> + for alpha2 in countrynames:
> + coll = countries[alpha2]
> +-output.write(struct.pack('>BB', alpha2[0], alpha2[1]))
> ++output.write(struct.pack('>2s', alpha2))
> + country_ptrs[alpha2] = PTR(output)
> + output.write(b'\x00' * 4)
> +
> +--- a/dbparse.py
>  b/dbparse.py
> +@@ -1,6 +1,5 @@
> + #!/usr/bin/env python
> +
> +-from builtins import bytes
> + from functools import total_ordering
> + import sys, math
> + from math import ceil, log
> +@@ -359,7 +358,7 @@ class DBParser(object):
> + for cname in cnames:
> + if len(cname) != 2:
> + self._warn("country '%s' not alpha2" % cname)
> +-cname = bytes(cname, 'ascii')
> ++cname = cname.encode('ascii')
> + if not cname in self._countries:
> + self._countries[cname] = Country(dfs_region, 
> comments=self._comments)
> + self._current_countries[cname] = self._countries[cname]
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH] build: make GCC version 6+ minimal host build requirement

[Etienne Champetier]

Hi Petr,

Le mar. 12 nov. 2019 à 00:16, Petr Štetiar  a écrit :
>
> Currently minimal GNU supported GCC version is 7 (from May 2, 2017), buildbots
> are using default GCC version 6 on Debian 9 (old stable), current Debian
> stable 10 has GCC version 8.
>
> Signed-off-by: Petr Štetiar 
> ---
>
> While adding CI support in C based projects, I've started adding -Wextra as
> well, which seems to work just fine for gcc6+, but it's apparently causing
> issues with older GCCs like for example gcc 4.8.5[1] on CentOS 7.
>
> Although it's certainly possible to fix those issues and make gcc 4 usable, I
> think, that it's not worth the additional effort and resources anymore.
>
> 1. 
> https://github.com/openwrt/openwrt/commit/4ba8f7b1ef1e4c0607185a41c06b51928c625d8b
>
>  README  |  2 +-
>  include/prereq-build.mk | 18 --
>  2 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/README b/README
> index c867c1fa4da8..6d11dd1188ff 100644
> --- a/README
> +++ b/README
> @@ -11,7 +11,7 @@ To build your own firmware you need a Linux, BSD or MacOSX 
> system (case
>  sensitive filesystem required). Cygwin is unsupported because of the lack
>  of a case sensitive file system.
>
> -You need gcc, binutils, bzip2, flex, python3.5+, perl, make, find, grep, 
> diff,
> +You need gcc6+, binutils, bzip2, flex, python3.5+, perl, make, find, grep, 
> diff,
>  unzip, gawk, getopt, subversion, libz-dev and libc headers installed.
>
>  1. Run "./scripts/feeds update -a" to obtain all the latest package 
> definitions
> diff --git a/include/prereq-build.mk b/include/prereq-build.mk
> index 4c5991005634..58cbc0678fa1 100644
> --- a/include/prereq-build.mk
> +++ b/include/prereq-build.mk
> @@ -27,12 +27,7 @@ $(eval $(call TestHostCommand,proper-umask, \
> umask | grep -xE 0?0[012][012]))
>
>  $(eval $(call SetupHostCommand,gcc, \
> -   Please install the GNU C Compiler (gcc) 4.8 or later, \
> -   $(CC) -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?)', \
> -   gcc -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?)', \
> -   gcc48 --version | grep gcc, \
> -   gcc49 --version | grep gcc, \
> -   gcc5 --version | grep gcc, \
> +   Please install the GNU C Compiler (gcc) 6 or later, \
> gcc6 --version | grep gcc, \
> gcc7 --version | grep gcc, \
> gcc8 --version | grep gcc, \

Don't we also want to reverse the order to choose the newest compiler first ?
Also on Fedora 31, in the path I only have gcc, not gcc9, what I match is:
$ gcc -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?)'
9
not the other rules, so this patch breaks at least Fedora 31

Etienne

> @@ -40,18 +35,13 @@ $(eval $(call SetupHostCommand,gcc, \
> gcc --version | grep -E 'Apple.(LLVM|clang)' ))
>
>  $(eval $(call TestHostCommand,working-gcc, \
> -   \nPlease reinstall the GNU C Compiler (4.8 or later) - \
> +   \nPlease reinstall the GNU C Compiler (6 or later) - \
> it appears to be broken, \
> echo 'int main(int argc, char **argv) { return 0; }' | \
> gcc -x c -o $(TMP_DIR)/a.out -))
>
>  $(eval $(call SetupHostCommand,g++, \
> -   Please install the GNU C++ Compiler (g++) 4.8 or later, \
> -   $(CXX) -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?)', \
> -   g++ -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?)', \
> -   g++48 --version | grep g++, \
> -   g++49 --version | grep g++, \
> -   g++5 --version | grep g++, \
> +   Please install the GNU C++ Compiler (g++) 6 or later, \
> g++6 --version | grep g++, \
> g++7 --version | grep g++, \
> g++8 --version | grep g++, \
> @@ -59,7 +49,7 @@ $(eval $(call SetupHostCommand,g++, \
> g++ --version | grep -E 'Apple.(LLVM|clang)' ))
>
>  $(eval $(call TestHostCommand,working-g++, \
> -   \nPlease reinstall the GNU C++ Compiler (4.8 or later) - \
> +   \nPlease reinstall the GNU C++ Compiler (6 or later) - \
> it appears to be broken, \
> echo 'int main(int argc, char **argv) { return 0; }' | \
> g++ -x c++ -o $(TMP_DIR)/a.out - -lstdc++ && \
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] [PATCH v2 maintainer-tools] patchwork-apply.sh: try to fix DMARC mangled patches

[Etienne Champetier]

Hi Petr, "mailing list admins",

Le dim. 10 nov. 2019 à 10:05, Petr Štetiar  a écrit :
>
> In order to avoid DMARC plague in the commit messages:

I saw this some days ago:
http://arc-spec.org/
Haven't had time to look at it, but it's supposed to be a solution to
the DMARC + mailing list mess

Etienne

>
>  87f9292300cf hostapd: add IEEE 802.11k support
>  450d44a8ead2 openssl: change defaults: ENGINE:on, NPN:off, misc
>  eabc1ddc4541 build: Honour NO_COLOR in include/scan.mk
>  3fb45576ac16 cryptodev-linux: move from packages feed
>  a73283dc10f7 kernel: nf-nathelper-extra depends on ipt-raw
>  0317fc3658eb libpcap: patch to add limits.h to pcap-usb-linux.c
>  26dbf79f4905 libevent2: Don't build tests and samples
>  d59126040701 brcm63xx: initial support for Sky SR102 router
>  094d49cddf93 kernel: bump 4.14 to 4.14.51
>  247055cbfbf1 igmpproxy: bump to 0.2.1
>  c451434b963d cake: bump to 20180504 bake
>  080fb7a3fbb6 iproute2: import latest cake
>  ad5af37ca793 iproute2: backport json_print-fix-hidden-64-bit-type-promotion
>  78f4305933b9 iftop: bump to latest
>  7783f31359cb base-files: nand: use CI_KERNPART whenever the kernel volume is 
> needed
>
> Signed-off-by: Petr Štetiar 
> ---
>  patchwork-apply.sh | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/patchwork-apply.sh b/patchwork-apply.sh
> index 5506adbfe451..1543c7fdaceb 100755
> --- a/patchwork-apply.sh
> +++ b/patchwork-apply.sh
> @@ -140,6 +140,13 @@ echo "$1" | grep -sqE '^[0-9]+$' || {
> }
>  }
>
> +grep --color --context=3 "DMARC Reject/Quarantine" "$1.patch" && {
> +   if ! yesno "DMARC manled patch detected, attempt to fix it?" "y"; then
> +   exit 4
> +   fi
> +   sed -i '/The sender domain has a DMARC/,/automatically by the mailing 
> list software./d' "$1.patch"
> +}
> +
>  git am "$1.patch" || {
> echo "Failed to apply patch $1" >&2
> git am --abort
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] OpenWrt 19.07 release schedule ?

[Etienne Champetier]

Hi Jo,

Le mer. 16 oct. 2019 à 12:15, Jo-Philipp Wich  a écrit :
>
> Hi,
>
> another blocker:
>
> opkg fails to select the correct provider package in case multiple
> repositories provide the same kmod with different versions and only one
> of the provider satisfied version dependency constraints.

Does it impact OpenWrt ? or just some OpenWrt based distributions ?
(might influence who need to fix this ;) )

Etienne

>
> Someone needs to debug and fix this.
>
> ~ Jo
>

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

[OpenWrt-Devel] [PATCH 19.07] kernel: add disable_eap_hack sysfs attribute

[Etienne Champetier]

We are not sure if 640-bridge-only-accept-EAP-locally.patch is still needed
as a first step, add disable_eap_hack sysfs config to allow to disable it

Signed-off-by: Etienne Champetier 
(cherry picked from commit 7d542dc8047d276517b296132926e722004065e0)
---
 .../640-bridge-only-accept-EAP-locally.patch  | 59 +--
 1 file changed, 55 insertions(+), 4 deletions(-)

diff --git 
a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
index 0dbb8ee3c0..fbe9ab0876 100644
--- a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
@@ -1,4 +1,3 @@
-From c6905cfdeb31a5c049db3da434b10fa0d3e83569 Mon Sep 17 00:00:00 2001
 From: Felix Fietkau 
 Date: Fri, 7 Jul 2017 17:18:54 +0200
 Subject: bridge: only accept EAP locally
@@ -7,9 +6,9 @@ When bridging, do not forward EAP frames to other ports, only 
deliver
 them locally, regardless of the state.
 
 Signed-off-by: Felix Fietkau 
+[add disable_eap_hack sysfs attribute]
+Signed-off-by: Etienne Champetier 
 ---
- net/bridge/br_input.c | 7 +--
- 1 file changed, 5 insertions(+), 2 deletions(-)
 
 --- a/net/bridge/br_input.c
 +++ b/net/bridge/br_input.c
@@ -19,7 +18,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !br->disable_eap_hack)
 +  return br_pass_frame_up(skb);
 +
if (p->state == BR_STATE_LEARNING)
@@ -29,3 +28,55 @@ Signed-off-by: Felix Fietkau 
BR_INPUT_SKB_CB(skb)->src_port_isolated = !!(p->flags & BR_ISOLATED);
  
if (IS_ENABLED(CONFIG_INET) && skb->protocol == htons(ETH_P_ARP))
+--- a/net/bridge/br_private.h
 b/net/bridge/br_private.h
+@@ -320,6 +320,8 @@ struct net_bridge {
+   u16 group_fwd_mask;
+   u16 group_fwd_mask_required;
+ 
++  booldisable_eap_hack;
++
+   /* STP */
+   bridge_id   designated_root;
+   bridge_id   bridge_id;
+--- a/net/bridge/br_sysfs_br.c
 b/net/bridge/br_sysfs_br.c
+@@ -170,6 +170,30 @@ static ssize_t group_fwd_mask_store(stru
+ }
+ static DEVICE_ATTR_RW(group_fwd_mask);
+ 
++static ssize_t disable_eap_hack_show(struct device *d,
++ struct device_attribute *attr,
++ char *buf)
++{
++  struct net_bridge *br = to_bridge(d);
++  return sprintf(buf, "%u\n", br->disable_eap_hack);
++}
++
++static int set_disable_eap_hack(struct net_bridge *br, unsigned long val)
++{
++  br->disable_eap_hack = !!val;
++
++  return 0;
++}
++
++static ssize_t disable_eap_hack_store(struct device *d,
++  struct device_attribute *attr,
++  const char *buf,
++  size_t len)
++{
++  return store_bridge_parm(d, buf, len, set_disable_eap_hack);
++}
++static DEVICE_ATTR_RW(disable_eap_hack);
++
+ static ssize_t priority_show(struct device *d, struct device_attribute *attr,
+char *buf)
+ {
+@@ -817,6 +841,7 @@ static struct attribute *bridge_attrs[]
+   _attr_ageing_time.attr,
+   _attr_stp_state.attr,
+   _attr_group_fwd_mask.attr,
++  _attr_disable_eap_hack.attr,
+   _attr_priority.attr,
+   _attr_bridge_id.attr,
+   _attr_root_id.attr,
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH] kernel: add disable_eap_hack sysfs attribute

[Etienne Champetier]

We are not sure if 640-bridge-only-accept-EAP-locally.patch is still needed
as a first step, add disable_eap_hack sysfs config to allow to disable it

Signed-off-by: Etienne Champetier 
---
 .../640-bridge-only-accept-EAP-locally.patch  | 59 +--
 .../640-bridge-only-accept-EAP-locally.patch  | 59 +--
 .../640-bridge-only-accept-EAP-locally.patch  | 59 +--
 3 files changed, 165 insertions(+), 12 deletions(-)

diff --git 
a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
index 0dbb8ee3c0..fbe9ab0876 100644
--- a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
@@ -1,4 +1,3 @@
-From c6905cfdeb31a5c049db3da434b10fa0d3e83569 Mon Sep 17 00:00:00 2001
 From: Felix Fietkau 
 Date: Fri, 7 Jul 2017 17:18:54 +0200
 Subject: bridge: only accept EAP locally
@@ -7,9 +6,9 @@ When bridging, do not forward EAP frames to other ports, only 
deliver
 them locally, regardless of the state.
 
 Signed-off-by: Felix Fietkau 
+[add disable_eap_hack sysfs attribute]
+Signed-off-by: Etienne Champetier 
 ---
- net/bridge/br_input.c | 7 +--
- 1 file changed, 5 insertions(+), 2 deletions(-)
 
 --- a/net/bridge/br_input.c
 +++ b/net/bridge/br_input.c
@@ -19,7 +18,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !br->disable_eap_hack)
 +  return br_pass_frame_up(skb);
 +
if (p->state == BR_STATE_LEARNING)
@@ -29,3 +28,55 @@ Signed-off-by: Felix Fietkau 
BR_INPUT_SKB_CB(skb)->src_port_isolated = !!(p->flags & BR_ISOLATED);
  
if (IS_ENABLED(CONFIG_INET) && skb->protocol == htons(ETH_P_ARP))
+--- a/net/bridge/br_private.h
 b/net/bridge/br_private.h
+@@ -320,6 +320,8 @@ struct net_bridge {
+   u16 group_fwd_mask;
+   u16 group_fwd_mask_required;
+ 
++  booldisable_eap_hack;
++
+   /* STP */
+   bridge_id   designated_root;
+   bridge_id   bridge_id;
+--- a/net/bridge/br_sysfs_br.c
 b/net/bridge/br_sysfs_br.c
+@@ -170,6 +170,30 @@ static ssize_t group_fwd_mask_store(stru
+ }
+ static DEVICE_ATTR_RW(group_fwd_mask);
+ 
++static ssize_t disable_eap_hack_show(struct device *d,
++ struct device_attribute *attr,
++ char *buf)
++{
++  struct net_bridge *br = to_bridge(d);
++  return sprintf(buf, "%u\n", br->disable_eap_hack);
++}
++
++static int set_disable_eap_hack(struct net_bridge *br, unsigned long val)
++{
++  br->disable_eap_hack = !!val;
++
++  return 0;
++}
++
++static ssize_t disable_eap_hack_store(struct device *d,
++  struct device_attribute *attr,
++  const char *buf,
++  size_t len)
++{
++  return store_bridge_parm(d, buf, len, set_disable_eap_hack);
++}
++static DEVICE_ATTR_RW(disable_eap_hack);
++
+ static ssize_t priority_show(struct device *d, struct device_attribute *attr,
+char *buf)
+ {
+@@ -817,6 +841,7 @@ static struct attribute *bridge_attrs[]
+   _attr_ageing_time.attr,
+   _attr_stp_state.attr,
+   _attr_group_fwd_mask.attr,
++  _attr_disable_eap_hack.attr,
+   _attr_priority.attr,
+   _attr_bridge_id.attr,
+   _attr_root_id.attr,
diff --git 
a/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
index 3de4048074..f77a1965ca 100644
--- a/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
@@ -1,4 +1,3 @@
-From c6905cfdeb31a5c049db3da434b10fa0d3e83569 Mon Sep 17 00:00:00 2001
 From: Felix Fietkau 
 Date: Fri, 7 Jul 2017 17:18:54 +0200
 Subject: bridge: only accept EAP locally
@@ -7,9 +6,9 @@ When bridging, do not forward EAP frames to other ports, only 
deliver
 them locally, regardless of the state.
 
 Signed-off-by: Felix Fietkau 
+[add disable_eap_hack sysfs attribute]
+Signed-off-by: Etienne Champetier 
 ---
- net/bridge/br_input.c | 7 +--
- 1 file changed, 5 insertions(+), 2 deletions(-)
 
 --- a/net/bridge/br_input.c
 +++ b/net/bridge/br_input.c
@@ -19,7 +18,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !br->disable_eap_hack)
 +  return br_pass_frame_up(skb);
 +
if (p->state == BR

Re: [OpenWrt-Devel] [PATCH] [RFC] kernel: disable EAP local hack when using group_fwd_mask

[Etienne Champetier]

Hi Petr,

Le jeu. 1 août 2019 à 12:51, Etienne Champetier
 a écrit :
>
> Hi Petr,
>
> Le jeu. 1 août 2019 à 11:39, Petr Štetiar  a écrit :
> >
> > Etienne Champetier  [2019-08-01 07:23:18]:
> >
> > > If the fix was to workaround a client bug we might want to keep it,
> >
> > Actually we don't know if it wasnt fixed already upstream as Rafał suggested
> > in his old removal patch.
> >
> > > else maybe we could rework it and add a warn_once if this hack prevent
> > > a EAP frame from being forwarded
> >
> > This warn_once would have probably saved some time already.
> >
> > > 'disable-eap-local-hack' to enable/disable this hack, what do you
> > > prefer ?
> >
> > I would prefer to remove this patch for 4.19 kernel to find out if it's 
> > still
> > needed.
>
> you mean all versions in master (4.19/4.14/4.9) or really only 4.19 ?
>
> > And if it's needed, then it would make sense to discuss this use case
> > with upstream and make it official feature.
>
> I have a small tool/OpenWrt package
> (https://github.com/openwrt/packages/blob/master/net/phantap/Makefile)
> that I'm presenting at DEF CON in a week, and would really love to
> have a way to disable this hack,
> so I don't have to tell people that want to test it that they have to
> rebuild OpenWrt.
> So I'm willing to work on any small patch that workaround my issue and
> seems reasonable to everyone in a short time-frame ;)
>
> >
> > Let's wait for Felix's input as well.

Last email from Felix that I see is from june 12, so I sent an RFCv2
(kernel: add disable_eap_hack sysfs attribute) for consideration

>
> I'll also try to dig some more in the old repo & bug tracker to see if
> there is more info than in the patch & email
>
> Etienne
>
> >
> > -- ynezz

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

[OpenWrt-Devel] [PATCH] [RFCv2] kernel: add disable_eap_hack sysfs attribute

[Etienne Champetier]

We are not sure if 640-bridge-only-accept-EAP-locally.patch is still needed
as a first step, add disable_eap_hack sysfs config to allow to disable it

Signed-off-by: Etienne Champetier 
---
 .../640-bridge-only-accept-EAP-locally.patch  | 59 +--
 .../640-bridge-only-accept-EAP-locally.patch  | 59 +--
 .../640-bridge-only-accept-EAP-locally.patch  | 59 +--
 3 files changed, 165 insertions(+), 12 deletions(-)

diff --git 
a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
index 0dbb8ee3c0..7b026642a6 100644
--- a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
@@ -1,4 +1,3 @@
-From c6905cfdeb31a5c049db3da434b10fa0d3e83569 Mon Sep 17 00:00:00 2001
 From: Felix Fietkau 
 Date: Fri, 7 Jul 2017 17:18:54 +0200
 Subject: bridge: only accept EAP locally
@@ -7,9 +6,9 @@ When bridging, do not forward EAP frames to other ports, only 
deliver
 them locally, regardless of the state.
 
 Signed-off-by: Felix Fietkau 
+[add disable_eap_hack sysfs attribute]
+Signed-off-by: Etienne Champetier 
 ---
- net/bridge/br_input.c | 7 +--
- 1 file changed, 5 insertions(+), 2 deletions(-)
 
 --- a/net/bridge/br_input.c
 +++ b/net/bridge/br_input.c
@@ -19,7 +18,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !br->disable_eap_hack)
 +  return br_pass_frame_up(skb);
 +
if (p->state == BR_STATE_LEARNING)
@@ -29,3 +28,55 @@ Signed-off-by: Felix Fietkau 
BR_INPUT_SKB_CB(skb)->src_port_isolated = !!(p->flags & BR_ISOLATED);
  
if (IS_ENABLED(CONFIG_INET) && skb->protocol == htons(ETH_P_ARP))
+--- a/net/bridge/br_private.h
 b/net/bridge/br_private.h
+@@ -320,6 +320,8 @@ struct net_bridge {
+   u16 group_fwd_mask;
+   u16 group_fwd_mask_required;
+ 
++  booldisable_eap_hack;
++
+   /* STP */
+   bridge_id   designated_root;
+   bridge_id   bridge_id;
+--- a/net/bridge/br_sysfs_br.c
 b/net/bridge/br_sysfs_br.c
+@@ -170,6 +170,30 @@ static ssize_t group_fwd_mask_store(stru
+ }
+ static DEVICE_ATTR_RW(group_fwd_mask);
+ 
++static ssize_t disable_eap_hack_show(struct device *d,
++ struct device_attribute *attr,
++ char *buf)
++{
++  struct net_bridge *br = to_bridge(d);
++  return sprintf(buf, "%u\n", br->disable_eap_hack);
++}
++
++static int set_disable_eap_hack(struct net_bridge *br, unsigned long val)
++{
++  br->disable_eap_hack = val ? true : false;
++
++  return 0;
++}
++
++static ssize_t disable_eap_hack_store(struct device *d,
++  struct device_attribute *attr,
++  const char *buf,
++  size_t len)
++{
++  return store_bridge_parm(d, buf, len, set_disable_eap_hack);
++}
++static DEVICE_ATTR_RW(disable_eap_hack);
++
+ static ssize_t priority_show(struct device *d, struct device_attribute *attr,
+char *buf)
+ {
+@@ -817,6 +841,7 @@ static struct attribute *bridge_attrs[]
+   _attr_ageing_time.attr,
+   _attr_stp_state.attr,
+   _attr_group_fwd_mask.attr,
++  _attr_disable_eap_hack.attr,
+   _attr_priority.attr,
+   _attr_bridge_id.attr,
+   _attr_root_id.attr,
diff --git 
a/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
index 3de4048074..dfe64cb5af 100644
--- a/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
@@ -1,4 +1,3 @@
-From c6905cfdeb31a5c049db3da434b10fa0d3e83569 Mon Sep 17 00:00:00 2001
 From: Felix Fietkau 
 Date: Fri, 7 Jul 2017 17:18:54 +0200
 Subject: bridge: only accept EAP locally
@@ -7,9 +6,9 @@ When bridging, do not forward EAP frames to other ports, only 
deliver
 them locally, regardless of the state.
 
 Signed-off-by: Felix Fietkau 
+[add disable_eap_hack sysfs attribute]
+Signed-off-by: Etienne Champetier 
 ---
- net/bridge/br_input.c | 7 +--
- 1 file changed, 5 insertions(+), 2 deletions(-)
 
 --- a/net/bridge/br_input.c
 +++ b/net/bridge/br_input.c
@@ -19,7 +18,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !br->disable_eap_hack)
 +  return br_pass_frame_up(skb);
 +

Re: [OpenWrt-Devel] [PATCH] [RFC] kernel: disable EAP local hack when using group_fwd_mask

[Etienne Champetier]

Hi Petr,

Le jeu. 1 août 2019 à 11:39, Petr Štetiar  a écrit :
>
> Etienne Champetier  [2019-08-01 07:23:18]:
>
> > If the fix was to workaround a client bug we might want to keep it,
>
> Actually we don't know if it wasnt fixed already upstream as Rafał suggested
> in his old removal patch.
>
> > else maybe we could rework it and add a warn_once if this hack prevent
> > a EAP frame from being forwarded
>
> This warn_once would have probably saved some time already.
>
> > 'disable-eap-local-hack' to enable/disable this hack, what do you
> > prefer ?
>
> I would prefer to remove this patch for 4.19 kernel to find out if it's still
> needed.

you mean all versions in master (4.19/4.14/4.9) or really only 4.19 ?

> And if it's needed, then it would make sense to discuss this use case
> with upstream and make it official feature.

I have a small tool/OpenWrt package
(https://github.com/openwrt/packages/blob/master/net/phantap/Makefile)
that I'm presenting at DEF CON in a week, and would really love to
have a way to disable this hack,
so I don't have to tell people that want to test it that they have to
rebuild OpenWrt.
So I'm willing to work on any small patch that workaround my issue and
seems reasonable to everyone in a short time-frame ;)

>
> Let's wait for Felix's input as well.

I'll also try to dig some more in the old repo & bug tracker to see if
there is more info than in the patch & email

Etienne

>
> -- ynezz

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

Re: [OpenWrt-Devel] [PATCH] [RFC] kernel: disable EAP local hack when using group_fwd_mask

[Etienne Champetier]

Hi Petr,

Le jeu. 1 août 2019 à 01:51, Petr Štetiar  a écrit :
>
> Etienne Champetier  [2019-07-26 19:23:02]:
>
> Hi,
>
> I've noticed your request for feedback on IRC.
Thanks for taking some time

>
> > and 640-bridge-only-accept-EAP-locally.patch hack is there to prevent
> > bridges from forwarding these EAP frames
>
> it would be nice to know if this patch is still needed so we could possibly
> remove[1] it from 4.19 kernel.

I revived this old email thread last week to try to get more
information from Felix
(http://lists.infradead.org/pipermail/openwrt-devel/2019-July/018127.html)
If the fix was to workaround a client bug we might want to keep it,
else maybe we could rework it and add a warn_once if this hack prevent
a EAP frame from being forwarded

>
> > -+if (skb->protocol == htons(ETH_P_PAE))
> > ++if (skb->protocol == htons(ETH_P_PAE) && !(br->group_fwd_mask & (1u 
> > << 3)))
> >  +return br_pass_frame_up(skb);
>
> This usage of magic numbers is usually a warn sign to me, so I went ahead and
> read the surrounding code and it seems to me, that you probably wanted
> something like this instead:
>
>   u16 fwd_mask = p->br->group_fwd_mask_required;
>   fwd_mask |= p->br->group_fwd_mask;
>   const unsigned char *dest = eth_hdr(skb)->h_dest;
>
>   if (skb->protocol == htons(ETH_P_PAE) && !(fwd_mask & (1u << dest[5])))
>   return br_pass_frame_up(skb);

Actually no, let me try to explain it again
By default a bridge forward everything except 01-80-C2-00-00-XX, which
includes 01-80-C2-00-00-03, which is the multicast mac for EAP frames.
For wifi, EAP are not using multicast but unicast (it's what I
understood reading various email thread, I haven't double checked
that).

What I think an admin wants when he do
echo 8 > /sys/class/net/brX/bridge/group_fwd_mask
is not to allow 01-80-C2-00-00-03 forwarding, but allow all EAP forwarding.
Your patch would allow multicast EAP forwarding but not unicast EAP
forwarding, except if dest mac ends with 03,
which would be very surprising.

Another approach would be to add a setting like
'disable-eap-local-hack' to enable/disable this hack, what do you
prefer ?

Etienne


>
> 1. https://patchwork.ozlabs.org/patch/884518/
>
> -- ynezz

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

[OpenWrt-Devel] [PATCH] [RFC] kernel: disable EAP local hack when using group_fwd_mask

[Etienne Champetier]

By default bridges will not forward frame with destination 01-80-C2-00-00-03
(ie wired EAP frames). You can allow forward using:
echo 8 > /sys/class/net/brX/bridge/group_fwd_mask

EAP frames over wireless are using the AP MAC address as destination,
and 640-bridge-only-accept-EAP-locally.patch hack is there to prevent
bridges from forwarding these EAP frames

Disable this hack when the administrator allow 01-80-C2-00-00-03 forward,
so that all EAP frames are allowed to be forwarded

Signed-off-by: Etienne Champetier 
---
 .../generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch  | 2 +-
 .../generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch  | 2 +-
 .../generic/hack-4.9/640-bridge-only-accept-EAP-locally.patch   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
index 0dbb8ee3c0..2dfd88f3aa 100644
--- a/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.14/640-bridge-only-accept-EAP-locally.patch
@@ -19,7 +19,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !(br->group_fwd_mask & (1u << 
3)))
 +  return br_pass_frame_up(skb);
 +
if (p->state == BR_STATE_LEARNING)
diff --git 
a/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
index 981d49b9c0..31d5b09ac6 100644
--- a/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.19/640-bridge-only-accept-EAP-locally.patch
@@ -19,7 +19,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !(br->group_fwd_mask & (1u << 
3)))
 +  return br_pass_frame_up(skb);
 +
if (p->state == BR_STATE_LEARNING)
diff --git 
a/target/linux/generic/hack-4.9/640-bridge-only-accept-EAP-locally.patch 
b/target/linux/generic/hack-4.9/640-bridge-only-accept-EAP-locally.patch
index ba87420b32..c65b8ac611 100644
--- a/target/linux/generic/hack-4.9/640-bridge-only-accept-EAP-locally.patch
+++ b/target/linux/generic/hack-4.9/640-bridge-only-accept-EAP-locally.patch
@@ -19,7 +19,7 @@ Signed-off-by: Felix Fietkau 
  
 +  BR_INPUT_SKB_CB(skb)->brdev = br->dev;
 +
-+  if (skb->protocol == htons(ETH_P_PAE))
++  if (skb->protocol == htons(ETH_P_PAE) && !(br->group_fwd_mask & (1u << 
3)))
 +  return br_pass_frame_up(skb);
 +
if (p->state == BR_STATE_LEARNING)
-- 
2.21.0


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

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] kernel: drop patch hacking bridge to accept EAP only locally

[Etienne Champetier]

Hi Felix,

Le mar. 13 mars 2018 à 00:41, Felix Fietkau  a écrit :
>
> On 2018-03-12 14:56, Rafał Miłecki wrote:
> > From: Rafał Miłecki 
> >
> > EAPOL frames have wireless interface address specified as destination.
> > That makes "dst->is_local" condition true for them and results in
> > upstream code processing frames the same way as OpenWrt/LEDE's hack.
> >
> > This code could be needed years ago but currently it seems redundant.
> >
> > Signed-off-by: Rafał Miłecki 
> I think I remember now why I added this years ago. The failure case
> involved a client roaming between multiple access points.
> I think in some of these cases, the bridge considered the client MAC to
> be reachable via LAN instead of the WLAN interface, because that's where
> the packets were coming from earlier.

I'm reviving this old thread because I was trying to let EAP frame go
through a bridge
with 2 wired connection (setting group_fwd_mask), and this old hack blocks me

If the client just sent an EAP frame via WLAN, why wouldn't the bridge learn
that the address is now WLAN side and send response back on the WLAN ?
And why is it an issue just for EAP ?
Say the client is roaming for A to B, maybe the problem was that the client was
sending EAP frame with A mac address as destination instead of B ?

In any case I need a way to disable this hack, would you accept a
patch to drop it
(and maybe reintroduce a bug) or would you prefer a patch to make it
configurable ?

Etienne

>
> - Felix

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

Re: [OpenWrt-Devel] [PATCH] ar71xx: enable QCA955x SGMII fixup on Mikrotik wAP AC

[Etienne Champetier]

Hi David,

Le lun. 15 juil. 2019 à 01:58, David Bauer  a écrit :
>
> Hello Etienne,
>
> On 15.07.19 04:30, Etienne Champetier wrote:
> > Hi David,
> >
> > Le dim. 14 juil. 2019 à 04:25, David Bauer  a écrit :
> >>
> >> Hi Etienne,
> >>
> >> one small remark:
> >>
> >> On 14.07.19 04:43, Etienne Champetier wrote:
> >>>   ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 0);
> >>>   ath79_eth1_data.mii_bus_dev = _phy_device.dev;
> >>>   ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII;
> >>>   ath79_eth1_data.phy_mask = BIT(RBWAPGSC_MDIO_PHYADDR);
> >>> + ath79_eth1_data.enable_sgmii_fixup = 1;
> >>
> >> This should be dropped as it's not necessary anymore.
> >
> > Did some more tests and it's definitely needed (here this is ar71xx &
> > Linux 4.14)
> > It's still used for other boards, could you detail why it's not needed
> > anymore, since what version, reference some commits ?
>
> You are right, it is needed. I was only focused on the workaround for the PHY 
> side,
> but we indeed explicitly need to enable the MAC side workaround too.
>
> So this looks good to me.

Saw that you applied it to master, I just tested the patch on 19.07, works fine
Do you want me to send the patch again, or can you just cherry-pick it ?
(git cherry-pick 2a7519e29d6cbbe1eb73623ef35add0ef596fb5f)

Thanks
Etienne

>
> Best wishes
> David
>
> >
> > Thanks
> > Etienne
> >
> >>
> >> Best wishes
> >> David
> >>
> >>>   ath79_eth1_pll_data.pll_1000 = 0x03000101;
> >>>   ath79_eth1_pll_data.pll_100 = 0x8101;
> >>>   ath79_eth1_pll_data.pll_10 = 0x80001313;
> >>>

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

[OpenWrt-Devel] [PATCH] ar71xx: enable QCA955x SGMII fixup on Mikrotik wAP AC

[Etienne Champetier]

fixes intermittent loss of connectivity on 1Gbit port, with log message:
> 803x_aneg_done: SGMII link is not ok

Thanks to David Bauer for pointing me in the right direction
I just had to figure out the right bus_id, which you find in this log:
> ag71xx ag71xx.1: connected to PHY at gpio-1:00 [uid=004dd074, driver=Atheros 
> 8031 ethernet]

Fixes FS#2236

Signed-off-by: Etienne Champetier 
---
 .../ar71xx/files/arch/mips/ath79/mach-rbspi.c| 16 
 1 file changed, 16 insertions(+)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
index 96511a4080..1212a91d7e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
@@ -512,6 +512,18 @@ static struct platform_device rbwapgsc_phy_device = {
},
 };
 
+static struct at803x_platform_data rbwapgsc_at803x_data = {
+.override_sgmii_aneg = 1,
+};
+
+static struct mdio_board_info rbwapgsc_mdio_info[] = {
+{
+.bus_id = "gpio-1",
+.mdio_addr = RBWAPGSC_MDIO_PHYADDR,
+.platform_data = _at803x_data,
+},
+};
+
 /* RB911L GPIOs */
 #define RB911L_GPIO_BTN_RESET  15
 #define RB911L_GPIO_LED_1  13
@@ -1106,10 +1118,14 @@ static void __init rbwapgsc_setup(void)
 
platform_device_register(_phy_device);
 
+   mdiobus_register_board_info(rbwapgsc_mdio_info,
+   ARRAY_SIZE(rbwapgsc_mdio_info));
+
ath79_init_mac(ath79_eth1_data.mac_addr, ath79_mac_base, 0);
ath79_eth1_data.mii_bus_dev = _phy_device.dev;
ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII;
ath79_eth1_data.phy_mask = BIT(RBWAPGSC_MDIO_PHYADDR);
+   ath79_eth1_data.enable_sgmii_fixup = 1;
ath79_eth1_pll_data.pll_1000 = 0x03000101;
ath79_eth1_pll_data.pll_100 = 0x8101;
ath79_eth1_pll_data.pll_10 = 0x80001313;
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH] [RFC] ar71xx: fix Mikrotik wAP AC QCA955X SGMII link loss

[Etienne Champetier]

This commit rework
"ar71xx: allow to override at803x sgmii aneg status" 
(4e39e213af7e3e0cd747403e8c227e145cfef988)
by moving override_sgmii_aneg param from "at803x_platform_data" to "device" 
struct
Not sure if it's the right place for it, but wAP AC uses 
"mdio_gpio_platform_data" struct,
so the current patch is currently accessing some random memory.

Fixes FS#2236

Signed-off-by: Etienne Champetier 
---
 .../files/arch/mips/ath79/mach-fritz450e.c|  2 +-
 .../files/arch/mips/ath79/mach-rambutan.c |  2 +-
 .../ar71xx/files/arch/mips/ath79/mach-rbspi.c |  2 ++
 ...at803x-add-sgmii-aneg-override-pdata.patch | 36 ++-
 4 files changed, 14 insertions(+), 28 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c
index 83127e4c64..f21b2664ba 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-fritz450e.c
@@ -122,7 +122,6 @@ static struct gpio_keys_button fritz450E_gpio_keys[] 
__initdata = {
 static struct at803x_platform_data fritz450E_at803x_data = {
.disable_smarteee = 1,
.has_reset_gpio = 1,
-   .override_sgmii_aneg = 1,
.reset_gpio = FRITZ450E_GPIO_PHY_RESET,
 };
 
@@ -157,6 +156,7 @@ static void __init fritz450E_setup(void) {
ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_SGMII;
ath79_eth0_data.phy_mask = BIT(FRITZ450E_PHY_ADDRESS);
ath79_eth0_data.enable_sgmii_fixup = 1;
+   ath79_eth0_data.mii_bus_dev->override_sgmii_aneg = 1;
ath79_eth0_pll_data.pll_1000 = 0x0300;
ath79_eth0_pll_data.pll_100 = 0x0101;
ath79_eth0_pll_data.pll_10 = 0x1313;
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c
index 1730a29f33..cb76ddcb0f 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rambutan.c
@@ -46,7 +46,6 @@ static struct mdio_board_info rambutan_mdio0_info[] = {
 
 static struct at803x_platform_data rambutan_ar8033_data = {
.has_reset_gpio = 1,
-   .override_sgmii_aneg = 1,
.reset_gpio = 23,
 };
 
@@ -82,6 +81,7 @@ static void __init rambutan_setup(void)
ath79_eth1_data.phy_mask = BIT(0);
ath79_eth1_data.mii_bus_dev = _mdio1_device.dev;
ath79_eth1_data.enable_sgmii_fixup = 1;
+   ath79_eth1_data.mii_bus_dev->override_sgmii_aneg = 1;
ath79_eth1_pll_data.pll_1000 = 0x1700;
ath79_eth1_pll_data.pll_10 = 0x1313;
ath79_register_eth(1);
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
index 96511a4080..f737d8f5b0 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rbspi.c
@@ -1115,6 +1115,8 @@ static void __init rbwapgsc_setup(void)
ath79_eth1_pll_data.pll_10 = 0x80001313;
ath79_eth1_data.speed = SPEED_1000;
ath79_eth1_data.duplex = DUPLEX_FULL;
+   ath79_eth1_data.enable_sgmii_fixup = 1;
+   ath79_eth1_data.mii_bus_dev->override_sgmii_aneg = 1;
ath79_register_eth(1);
 
rbspi_wlan_init(1, 2);
diff --git 
a/target/linux/ar71xx/patches-4.14/903-at803x-add-sgmii-aneg-override-pdata.patch
 
b/target/linux/ar71xx/patches-4.14/903-at803x-add-sgmii-aneg-override-pdata.patch
index 8948fd4954..60a6d1a9a3 100644
--- 
a/target/linux/ar71xx/patches-4.14/903-at803x-add-sgmii-aneg-override-pdata.patch
+++ 
b/target/linux/ar71xx/patches-4.14/903-at803x-add-sgmii-aneg-override-pdata.patch
@@ -1,38 +1,22 @@
 --- a/drivers/net/phy/at803x.c
 +++ b/drivers/net/phy/at803x.c
-@@ -478,12 +478,15 @@ static void at803x_link_change_notify(st
- 
- static int at803x_aneg_done(struct phy_device *phydev)
- {
-+  struct at803x_platform_data *pdata;
-   int ccr;
- 
-   int aneg_done = genphy_aneg_done(phydev);
-   if (aneg_done != BMSR_ANEGCOMPLETE)
-   return aneg_done;
- 
-+  pdata = dev_get_platdata(>mdio.dev);
-+
-   /*
-* in SGMII mode, if copper side autoneg is successful,
-* also check SGMII side autoneg result
-@@ -498,7 +501,8 @@ static int at803x_aneg_done(struct phy_d
+@@ -498,7 +498,8 @@ static int at803x_aneg_done(struct phy_d
/* check if the SGMII link is OK. */
if (!(phy_read(phydev, AT803X_PSSR) & AT803X_PSSR_MR_AN_COMPLETE)) {
pr_warn("803x_aneg_done: SGMII link is not ok\n");
 -  aneg_done = 0;
-+  if (!pdata || !pdata->override_sgmii_aneg)
++  if (phydev->mdio.dev.override_sgmii_aneg)
 +  aneg_done = 0;
}
/* switch back to copper page */
phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SE

Re: [OpenWrt-Devel] [PATCH 3/4] base-files: move urandom seed bits into separate package

[Etienne Champetier]

Hi Yousong,

Le mar. 28 mai 2019 à 09:01, Yousong Zhou  a écrit :

> On Tue, 28 May 2019 at 05:30, Petr Štetiar  wrote:
>
> ...
>
> > +
> > +save() {
> > +touch "$1.tmp"
> > +chown root:root "$1.tmp"
> > +chmod 600 "$1.tmp"
> > +getrandom 512 > "$1.tmp"
> > +mv "$1.tmp" "$1"
> > +echo "Seed saved ($1)"
> > +}
>
> Maybe we could prepare the .tmp file in /tmp of tmpfs type, to save a
> few rounds of nor flash writes.
>

The idea was to be able to do atomic mv


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

Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter

[Etienne Champetier]

Hi Petr,

Le lun. 27 mai 2019 à 10:00, Petr Štetiar  a écrit :
>
> Etienne Champetier  [2019-05-25 12:43:25]:
>
> > Just to be clear i'm 100% in favor of your effort to have random pool init
> > done fast on all devices, and your solution, based on Stephan awsome work,
> > seems really good I just want to be sure we don't make some devices worse /
> > are not missing something
>
> FYI, I've just added more devices to the testing before submitting the next
> round of patches, and got following on the MT7620A based device:
>
>  root@OpenWrt:/# cat /proc/cpuinfo
>  system type : MediaTek MT7620A ver:2 eco:6
>  machine : BDCOM WAP2100-SK
>  processor   : 0
>  cpu model   : MIPS 24KEc V5.0
>
>  root@OpenWrt:/# cat 
> /sys/devices/system/clocksource/clocksource0/available_clocksource
>  systick MIPS
>
>  root@OpenWrt:/# /sbin/urngd
>  jent-rng init failed, err: 2
>
> Where that error 2 is ECOARSETIME. It makes me wonder if there's something
> which could be tweaked on kernel side in order to provide better environment
> for jent-rng on this quite still popular SoC.

The fact that missing high precision timer is properly detected is a good news,
but now that means you really need to provide a fallback, else
removing urandom-seed is a regression

>
> -- ynezz

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

Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter

[Etienne Champetier]

Hi Petr,

Just to be clear i'm 100% in favor of your effort to have random pool
init done fast on all devices,
and your solution, based on Stephan awsome work, seems really good
I just want to be sure we don't make some devices worse / are not
missing something

Le mar. 21 mai 2019 à 16:55, Petr Štetiar  a écrit :
>
> Etienne Champetier  [2019-05-21 14:55:42]:
>
> Hi,
>
> > > First, simply writing to /dev/urandom does not increase the kernel's
> > > entropy count, this casuses processes obtaining randomness to block.
> > > Particularly processes using OpenSSL's RAND_bytes() will block until the
> > > kernel emits 'random: crng init done'. This can take upwards of twenty
> > > minutes.
> >
> > 20 minutes seems excessive, isn't one of the process blocking boot ?
>
> please note, that this is time as measured by kernel (I know it's userspace
> starving the kernel entropy pool, but still). I've personally measured 18
> minutes on my Apalis board (imx6)[1].
>
>  i.mx6 (Freescale i.MX6 Quad/DualLite)
>
>   [3.281637] random: fast init done
>   [ 1120.394672] random: crng init done (yeah, 18 minutes)

I'm not saying it's not happening, I'm wondering if the boot process
is not blocked early by a process stuck on getrandom()
and then nothing runs on router so no entropy is produced, so the
process continue to be stuck

>
> > One of the issue is that if you try to generate a new seed, you are
> > just reading a hash of the seed you injected seconds earlier with
> > maybe few new bits of entropy
>
> Exactly, that's why it's recommended[2] to save it during EVERY shutdown, so 
> it's
> different EVERY boot.

I know and I'm in favour of it, but proper shutdown is not always a
thing on router, that is why I went with getrandom() at the time

>
>  * Ensuring unpredictability at system startup
>  * 
>  *
>  * When any operating system starts up, it will go through a sequence
>  * of actions that are fairly predictable by an adversary, especially
>  * if the start-up does not involve interaction with a human operator.
>  * This reduces the actual number of bits of unpredictability in the
>  * entropy pool below the value in entropy_count.  In order to
>  * counteract this effect, it helps to carry information in the
>  * entropy pool across shut-downs and start-ups.
>
>  [...]
>
>  * Even with complete knowledge of the start-up activities, predicting the
>  * state of the entropy pool requires knowledge of the previous history of the
>  * system.
>
> We're making it easier for the potential adversary, aren't we? We're currently
> feeding static urandom.seed file (generated during first boot) to kernel every
> other boot, in some cases it might result in the same file for the lifetime of
> the device. I really miss any randomness in this.

Starting on second boot, we are sure each router state is different,
but each boot are pretty similar I agree


>
> > Just for the record, this is the default setting,
>
> I know, that's why I'm proposing removal from the default ath79 images,
> because I think, that it's wrong. Should the user ever need urandom-seed, then
> it's just one opkg install away.
>
> > you can change your config to generate a new one at each boot
>
> I know, but who does it? I expect best possible secure configuration by
> default.
>
> > (the worry was that we would wear off the flash too fast)
>
> I understand the drawbacks, that's why I think, that it doesn't make much
> sense to use it, if it's not good enough to be used in default/shipped
> configuration.
>
> > why not use jitterentropy RNG that is in kernel since 4.2 ?
> > https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa4520013
>
> I started experiments with kmod-crypto-rng package which already contains
> jitterentropy, drbg, krng and rng kernel modules, but it didn't improved the
> long booting times for me on ath79.  Other reason was size of this kernel
> module(s) as they provide much more functionality of course.

I think before anyone merge this (I'm not a core dev), we need to
explain why your user space version and the kernel module version
behave differently
Is the kernel module underestimating entropy ? Is you user space
version over estimating entropy ?

Regards
Etienne

>
> > I haven't had time to read all the papers from Stephan Muller, but I
> > don't know how safe & tested Jitter RNG is on ALL architectures
>
> I've based urngd on Jitter NPTRNG simply because Stephan did amazing work with
> testing[3] and analysis of embedded CPUs as well. I couldn't say the same
> about other solutions I've considered, like haveged for example. B

Re: [OpenWrt-Devel] [PATCH RFC 0/5] ath79: add micro non-physical true RNG based on timing jitter

[Etienne Champetier]

Hi Petr,

Le lun. 20 mai 2019 à 18:14, Petr Štetiar  a écrit :
>
> Hi,
>
> this patch series is an RFC which attempts to fix some of the current
> urandom-seed based flaws.
>
> First, simply writing to /dev/urandom does not increase the kernel's
> entropy count, this casuses processes obtaining randomness to block.
> Particularly processes using OpenSSL's RAND_bytes() will block until the
> kernel emits 'random: crng init done'. This can take upwards of twenty
> minutes.

20 minutes seems excessive, isn't one of the process blocking boot ?

>
> According to random(4) the entropy count is only increased when using the
> RNDADDENTROPY ioctl, which urandom-seed currently doesn't use when feeding the
> kernel RNG.

we could use RNDADDENTROPY, but as I'm no cryptographer,
I just imitated what was done in debian before systemd and in systemd
at the time
(read a seed when random pool is initialized, feed it on next boot)

One of the issue is that if you try to generate a new seed, you are
just reading a hash of the seed you injected seconds earlier with
maybe few new bits of entropy

>
> Second, urandom-seed is using /etc/urandom.seed file to seed the kernel's RNG
> machinery upon every boot. The problem is, that this file is created only once
> during first-boot and then reused on every consecutive boot, so pretty much
> static.

Just for the record, this is the default setting, you can change your
config to generate a new one at each boot
(the worry was that we would wear off the flash too fast)

>
> So this patch series removes urandom-seed package in favor of urngd, which is
> new micro non-physical true random number generator (system service) based on
> timing jitter.

Having a seed file never hurts, so I would keep it

>
> Using the Jitter RNG core, the urngd provides an entropy source that
> feeds into the Linux /dev/random device if its entropy runs low. It
> updates the /dev/random entropy estimator such that the newly provided
> entropy unblocks /dev/random.
>
> The seeding of /dev/random also ensures that /dev/urandom benefits from
> entropy. Especially during boot time, when the entropy of Linux is low,
> the Jitter RNGd provides a source of sufficient entropy.

why not use jitterentropy RNG that is in kernel since 4.2 ?
https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa4520013

I haven't had time to read all the papers from Stephan Muller, but I
don't know how safe & tested Jitter RNG is on ALL architectures
For example this comment doesn't inspire me
https://github.com/torvalds/linux/commit/bb5530e4082446aac3a3d69780cd4dbfa4520013#diff-8e0798e05c8dca3aa9007504c87cee73R125
> If random_get_entropy does not return a value (which is possible on,
> for example, MIPS), invoke __getnstimeofday
> hoping that there are timers we can work with.

Regards
Etienne

>
>
> Some RNG init time numbers from qca9563 (TP-Link Archer C7 v5):
>
>  [   12.045693] random: crng init done(urngd)
>  [  120.043132] random: crng init done(urandom-seed)
>
> Flash space details:
>
>  urngd:+ 4579 b
>  getrandom:- 1635 b
>  urandom-seed: -  841 b
>  --
>  diff  + 2103 b
>
> Cc: Stephan Mueller 
> Cc: Dustin Lundquist 
>
> Petr Štetiar (5):
>   urng: add micro non-physical true RNG based on timing jitter
>   ubox: move getrandom into separate getrandom package
>   base-files: move urandom seed bits into separate package
>   build: add urandom-seed to the default packages set
>   ath79: make urngd default RNG seed source
>
>  include/target.mk  |  2 +-
>  package/base-files/Makefile| 11 -
>  package/base-files/files/etc/init.d/urandom_seed   | 12 --
>  .../base-files/files/lib/preinit/81_urandom_seed   | 24 ---
>  package/base-files/files/sbin/urandom_seed | 20 -
>  package/system/ubox/Makefile   | 17 ++--
>  package/system/urandom-seed/Makefile   | 32 +++
>  .../urandom-seed/files/etc/init.d/urandom_seed | 12 ++
>  .../urandom-seed/files/lib/preinit/81_urandom_seed | 24 +++
>  .../system/urandom-seed/files/sbin/urandom_seed| 20 +
>  package/system/urngd/Makefile  | 48 
> ++
>  package/system/urngd/files/urngd.init  | 21 ++
>  target/linux/ath79/Makefile|  3 +-
>  13 files changed, 184 insertions(+), 62 deletions(-)
>  delete mode 100755 package/base-files/files/etc/init.d/urandom_seed
>  delete mode 100644 package/base-files/files/lib/preinit/81_urandom_seed
>  delete mode 100755 package/base-files/files/sbin/urandom_seed
>  create mode 100644 package/system/urandom-seed/Makefile
>  create mode 100755 package/system/urandom-seed/files/etc/init.d/urandom_seed
>  create mode 100644 
> package/system/urandom-seed/files/lib/preinit/81_urandom_seed
>  create mode 100755 

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Etienne Champetier]

Hi Petr,

Le ven. 15 mars 2019 à 13:01, Petr Štetiar  a écrit :
>
> Etienne Champetier  [2019-03-15 10:46:09]:
>
> Hi,
>
> > Just a side note, on first boot we save a random seed using getrandom()
> > https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/init.d/urandom_seed
> > https://github.com/openwrt/openwrt/blob/master/package/base-files/files/sbin/urandom_seed
> >
> > And we restore it in preinit
> > https://github.com/openwrt/openwrt/blob/master/package/base-files/files/lib/preinit/81_urandom_seed
>
> Well, it seems like we're writing the /etc/urandom.seed to the /dev/urandom
> which doesn't help with initialization of CRNG, just seeding the /dev/urandom.
>
> > So even if kernel PRNG is considered not initialized, in reality it
> > is, so starting from second boot we are ~ok
>
> Nope, see bellow.
>
> 1st boot:
>
>  [3.944674] urandom-seed: Seed file not found (/etc/urandom.seed)
>  [   75.120166] random: fast init done
>  [  140.917418] random: crng init done
>
> 2nd boot:
>
>  [3.938414] urandom-seed: Seeding with /etc/urandom.seed
>  [   22.440981] random: fast init done
>  [  135.737309] random: crng init done

I was not precise enough, writing to /dev/urandom do add entropy to
the internal CSPRNG state, but the kernel count it as 0 because he
doesn't trust it
So after urandom-seed you are ~ok from a security stand point, but yes
getrandom() still blocks

>
> -- ynezz

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

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Etienne Champetier]

Hi All,

Le ven. 15 mars 2019 à 09:29, Petr Štetiar  a écrit :
>
> While testing simple firmware image for x86/64 in QEMU I've discovered
> some weird behavior today. This image contains simple package with
> simple init script to bootstrap the device UCI configuration from
> network server. This init script uses uclient-fetch and libustream-openssl.
>
> This image was booting fine until today, usually finished booting under
> 10s, but today it was booting much slowly, boot times were in range from
> 60s to a few minutes. I was also unable to power off the QEMU with
> poweroff command.
>
> I've found out, that it's all happening because of uclient-fetch being
> blocked in getrandom syscall, leading for example to following:
>
>  root@OpenWrt:~# time uclient-fetch
>  ^CCommand terminated by signal 2
>  real   8m 31.08s
>
> The problem passes away after `random: crng init done` hits
> the system log, but this step can take ages in some cases (usually when there
> are more processes calling getrandom in parallel), but I couldn't get it
> under 60s on my QEMU machine. I've similar weird reports from users on
> MIPS devices as well.
>
>  [   13.786576] random: fast init done
>  ...
>  [  653.153740] random: crng init done
>
> I've bisected the problem down to the following commit (reverting it
> fixed the problem):
>
>   # first bad commit: [d872d00b2f] openssl: update to version 1.1.1a
>
> So this patch tries to fix this issue by making getrandom syscall
> nonblocking, and also removes possible usage of getentropy libc call,
> which in case of musl libc results again in use of getrandom syscall in
> blocking mode.
>
> I've also added new config option just in case someone would prefer to
> have probably safer but much slower boot times on some devices.

Just a side note, on first boot we save a random seed using getrandom()
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/etc/init.d/urandom_seed
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/sbin/urandom_seed

And we restore it in preinit
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/lib/preinit/81_urandom_seed

So even if kernel PRNG is considered not initialized, in reality it
is, so starting from second boot we are ~ok

I'm not sure if we block on getrandom to generate ssh keys (and any
other keys) on first boot though

Regards
Etienne

>
> Fixes: d872d00b2f ("openssl: update to version 1.1.1a")
> Reviewed-by: Eneas U de Queiroz 
> Signed-off-by: Petr Štetiar 
> ---
>  package/libs/openssl/Config.in | 12 ++
>  package/libs/openssl/Makefile  |  7 +++-
>  .../openssl/patches/150-unblock-getrandom.patch| 45 
> ++
>  3 files changed, 63 insertions(+), 1 deletion(-)
>  create mode 100644 package/libs/openssl/patches/150-unblock-getrandom.patch
>
> diff --git a/package/libs/openssl/Config.in b/package/libs/openssl/Config.in
> index ecb9eea..0809afa 100644
> --- a/package/libs/openssl/Config.in
> +++ b/package/libs/openssl/Config.in
> @@ -70,6 +70,18 @@ config OPENSSL_WITH_ERROR_MESSAGES
> This option aids debugging, but increases package size and
> memory usage.
>
> +config OPENSSL_BLOCKING_GETRANDOM
> +   bool
> +   prompt "Enable back getrandom in blocking mode"
> +   help
> +   Enable back the default (upstream) blocking behavior.  By 
> default, when
> +   reading from the random source, getrandom() blocks if no 
> random bytes are
> +   available, and when reading from the urandom source, it 
> blocks if the entropy
> +   pool has not yet been initialized.
> +
> +   Please note, that turning this option on may affect the boot 
> time, which can
> +   in some cases take minutes.
> +
>  comment "Protocol Support"
>
>  config OPENSSL_WITH_TLS13
> diff --git a/package/libs/openssl/Makefile b/package/libs/openssl/Makefile
> index 56e95af..6e7a603 100644
> --- a/package/libs/openssl/Makefile
> +++ b/package/libs/openssl/Makefile
> @@ -11,7 +11,7 @@ PKG_NAME:=openssl
>  PKG_BASE:=1.1.1
>  PKG_BUGFIX:=b
>  PKG_VERSION:=$(PKG_BASE)$(PKG_BUGFIX)
> -PKG_RELEASE:=3
> +PKG_RELEASE:=4
>  PKG_USE_MIPS16:=0
>  ENGINES_DIR=engines-1.1
>
> @@ -30,6 +30,7 @@ PKG_LICENSE:=OpenSSL
>  PKG_LICENSE_FILES:=LICENSE
>  PKG_CPE_ID:=cpe:/a:openssl:openssl
>  PKG_CONFIG_DEPENDS:= \
> +   CONFIG_OPENSSL_BLOCKING_GETRANDOM \
> CONFIG_OPENSSL_ENGINE \
> CONFIG_OPENSSL_ENGINE_BUILTIN \
> CONFIG_OPENSSL_ENGINE_BUILTIN_AFALG \
> @@ -327,6 +328,10 @@ ifdef CONFIG_i386
>endif
>  endif
>
> +ifdef CONFIG_OPENSSL_BLOCKING_GETRANDOM
> +  OPENSSL_OPTIONS += -DOPENSSL_BLOCKING_GETRANDOM
> +endif
> +
>  OPENSSL_TARGET:=linux-$(call qstrip,$(CONFIG_ARCH))-openwrt
>
>  STAMP_CONFIGURED := $(STAMP_CONFIGURED)_$(shell echo $(OPENSSL_OPTIONS) | 
> mkhash md5)
> diff --git 

Re: [OpenWrt-Devel] speed up ath10k-caldata extraction for non-ipq40xx

[Etienne Champetier]

Hi All,

Le ven. 22 févr. 2019 à 03:33, Dmitry Tunin  a écrit :
>
> This is useful for ath9k extraction as well.
>
> пт, 22 февр. 2019 г. в 13:09, Christian Lamparter :
> >
> > Hello,
> >
> > On Wednesday, February 20, 2019 7:26:55 PM CET Adrian Schmutzler wrote:
> > > just saw the commit “ipq40xx: speed up ath10k-caldata extraction”:
> > >
> > > https://github.com/openwrt/openwrt/commit/a69e101ed1169f562fc030a783cd997d3f066b16
> > >
> > > Is this specific to ipq40xx for some reason not obvious to me or can 
> > > other targets like ath79/ar71xx be “enhanced” similarly:
> > >
> > > https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata#L45
> > >
> > > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata#L33
> > >
> > > (at least two affected lines in each file)
> > >
> > > […]
> > >
> > > dd if=$mtd of=/lib/firmware/$FIRMWARE bs=1 skip=$offset count=$count 
> > > 2>/dev/null || \
> > >
> > > […]
> > >
> > > changed to
> > >
> > > […]
> > >
> > > dd if=$mtd of=/lib/firmware/$FIRMWARE bs=$count skip=$offset count=1 
> > > iflag=skip_bytes 2>/dev/null || \

If you don't have skip_bytes option, you can also do something like:
tail -c +$offset $mtd | head -c $count
(maybe i'm of by 1 bytes for the tail, to be tested)

Regards
Etienne

>
> > >
> > > […]
> > >
> >
> > No this isn't specific to the ipq40xx. In fact as you said on a the
> > ath79 device it can make a bigger difference.
> >
> > For example on my ath79 WD MyNet Range Extender (AR9344-like, s25fl064k)
> > it goes from:
> >
> > strace -c dd if=/dev/mtd6 of=/lib/firmware/test-slow bs=1 count=4096 
> > skip=4096
> > 4096+0 records in
> > 4096+0 records out
> > % time seconds  usecs/call callserrors syscall
> > -- --- --- - - 
> >  99.37   15.6954543831  4096   write
> >   0.630.098808  24  4097   read
> >   0.000.50  50 1   writev
> >   0.000.44   8 5   close
> >   0.000.00   0 4 1 open
> >   0.000.00   0 1   execve
> >   0.000.00   0 1   getuid
> >   0.000.00   0 2   dup2
> >   0.000.00   0 2   mprotect
> >   0.000.00   0 1   _llseek
> >   0.000.00   0 1   prctl
> >   0.000.00   0 1   rt_sigaction
> >   0.000.00   0 1   rt_sigprocmask
> >   0.000.00   0 2   mmap2
> >   0.000.00   0 1   fstat64
> >   0.000.00   0 1   fcntl64
> >   0.000.00   0 1   set_tid_address
> >   0.000.00   0 1   set_thread_area
> > -- --- --- - - 
> > 100.00   15.794356  8219 1 total
> >
> > compared to:
> >
> > strace -c dd if=/dev/mtd6 of=/lib/firmware/test-fast bs=4096 count=1 
> > skip=4096 iflag=skip_bytes
> > 1+0 records in
> > 1+0 records out
> > % time seconds  usecs/call callserrors syscall
> > -- --- --- - - 
> >  87.120.014953   14953 1   write
> >   5.290.000908 454 2   read
> >   3.020.000518 129 4 1 open
> >   1.420.000244 122 2   mprotect
> >   1.320.000226 113 2   mmap2
> >   0.420.72  14 5   close
> >   0.310.53  53 1   writev
> >   0.220.37  18 2   brk
> >   0.150.25  25 1   set_thread_area
> >   0.130.22  11 2   dup2
> >   0.100.17  17 1   execve
> >   0.090.16  16 1   fstat64
> >   0.090.15  15 1   prctl
> >   0.070.12  12 1   _llseek
> >   0.060.11  11 1   rt_sigprocmask
> >   0.060.10  10 1   fcntl64
> >   0.050.09   9 1   rt_sigaction
> >   0.050.08   8 1   set_tid_address
> >   0.040.07   7 1   getuid
> > -- --- --- - - 
> > 100.000.01716331 1 total
> >
> >
> > So, this should help to speed up the initial installation tremendously.
> > Especially if the overlay the device uses jffs2 it seems. If you want
> > to provide patches, 

Re: [OpenWrt-Devel] Enable security labels on ext4?

[Etienne Champetier]

Hi Mike,

(resend as text as html mail are blocked)

Le sam. 10 nov. 2018 à 22:59, W. Michael Petullo  a écrit :
>
> Capabilities are an important security mechanism on Linux because they
> allow programs to run with fewer privileges.

What you really want is ambient capabilities (Linux 4.3+), it allow
you to keep just some capabilities as non root and without filesystem
support, so this can be supported in all cases

Etienne

> I would like to propose that
> we enable security labels by default on filesystems like ext4. This is
> done by selecting the following kernel build option:
>
> File systems -> (The Extended 4 (ext4) filesystem) Ext4 Security
> Labels
>
> I have already submitted a pull request which should allow
> our build servers to provide the corresponding libcap utilities. See:
>
> https://github.com/openwrt/packages/pull/7368
>
> --
> Mike
>
> :wq
>
> ___
> 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] Add "Stale" plugin to packages feed

[Etienne Champetier]

Hi All,

In OpenWrt packages feed, we have a lot of stale issues and PR
What do you think about automatically closing them ?
https://probot.github.io/apps/stale/

https://github.com/openwrt/packages/pull/7279

Regards
Etienne

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

[OpenWrt-Devel] Packages feed DCO check

[Etienne Champetier]

Hi All,

Can one of the admin of the packages feed have a look at what is wrong
with the DCO check ?
https://probot.github.io/apps/dco/

It's not showing up anymore, for example:
https://github.com/openwrt/packages/pull/6927

Thanks
Etienne

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

Re: [OpenWrt-Devel] Enabling CircleCI for packages repo

[Etienne Champetier]

Hi Ted,

Le dim. 28 oct. 2018 à 19:26, Etienne Champetier
 a écrit :
>
> Hi again,
>
> Le dim. 28 oct. 2018 à 18:50, Etienne Champetier
>  a écrit :
> >
> > Hi Ted,
> >
> > Le dim. 28 oct. 2018 à 17:40, Ted Hess  a écrit :
> > >
> > > >> Etienne - AFAICT, I have enabled CircleCI on 10/25 for 
> > > >> openwrt/packages repo. It looks like github is posting PRs to CircleCI 
> > > >> but
> > > >> nothing is happening. The POST response says DENY without any reason. 
> > > >> Does CircleCI also need organization access to
> > > >> lede-project?
> > > >>
> > > >> The deploy key is registered, but hasn't been used.
> > > >> Is the docker image reference correct?
> > > >> There must be some"may I" thing missing that allows CircleCI to access 
> > > >> our repository?
> > > >
> > > >I've started experimenting months ago so maybe I changed some of the
> > > >defaults settings and I don't remember
> > > >can you have a look at:
> > > >https://circleci.com/gh/openwrt/packages/edit#advanced-settings
> > > >
> > > >GitHub Status updates: on
> > > >Free and Open Source: on
> > > >Build forked pull requests: off --> on
> >
> > This was definitely needed ...
> >
> > > >Pass secrets to builds from forked pull requests: off
> > > >Only build pull requests: off --> on
> > > >Auto-cancel redundant builds: off -> on
> > > >Enable build processing (preview): on --> off
> > >
> > > OK - I changed some settings to match what you have (as noted above). 
> > > Waiting to see what happens now.
> >
> > ... but this is not enough :(
> > https://github.com/openwrt/packages/pull/7272
> >
> > Can you have a llok at
> > https://circleci.com/docs/2.0/gh-bb-integration/#how-to-re-enable-circleci-for-a-github-organization
> > ?
> > Can you share more details on the denied POST you see ?
> >
> > On my account (which is not an organization) I have
> > - CircleCI as "Authorized OAuth Apps" for my whole account (Access
> > public repositories / Read org and team membership / Access user email
> > addresses (read-only))
> > - CircleCI webhook in the repo config
> > (https://github.com/champtar/packages/settings/hooks)
> > - CircleCI deploy key in the repo config
> > (https://github.com/champtar/packages/settings/keys)
>
> 2 PR almost worked
> - https://github.com/openwrt/packages/pull/6924
> - https://github.com/openwrt/packages/pull/6492
> they need to rebase on master to have CircleCI config I think

I pushed some fixes, everything seems to work now
Can you enable CircleCI Github checks ?
https://circleci.com/docs/2.0/enable-checks/
https://circleci.com/gh/organizations/openwrt/settings#vcs

Thanks
Etienne

>
> >
> > Etienne
> >
> >
> > >
> > > /ted
> > >

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

Re: [OpenWrt-Devel] Enabling CircleCI for packages repo

[Etienne Champetier]

Hi again,

Le dim. 28 oct. 2018 à 18:50, Etienne Champetier
 a écrit :
>
> Hi Ted,
>
> Le dim. 28 oct. 2018 à 17:40, Ted Hess  a écrit :
> >
> > >> Etienne - AFAICT, I have enabled CircleCI on 10/25 for openwrt/packages 
> > >> repo. It looks like github is posting PRs to CircleCI but
> > >> nothing is happening. The POST response says DENY without any reason. 
> > >> Does CircleCI also need organization access to
> > >> lede-project?
> > >>
> > >> The deploy key is registered, but hasn't been used.
> > >> Is the docker image reference correct?
> > >> There must be some"may I" thing missing that allows CircleCI to access 
> > >> our repository?
> > >
> > >I've started experimenting months ago so maybe I changed some of the
> > >defaults settings and I don't remember
> > >can you have a look at:
> > >https://circleci.com/gh/openwrt/packages/edit#advanced-settings
> > >
> > >GitHub Status updates: on
> > >Free and Open Source: on
> > >Build forked pull requests: off --> on
>
> This was definitely needed ...
>
> > >Pass secrets to builds from forked pull requests: off
> > >Only build pull requests: off --> on
> > >Auto-cancel redundant builds: off -> on
> > >Enable build processing (preview): on --> off
> >
> > OK - I changed some settings to match what you have (as noted above). 
> > Waiting to see what happens now.
>
> ... but this is not enough :(
> https://github.com/openwrt/packages/pull/7272
>
> Can you have a llok at
> https://circleci.com/docs/2.0/gh-bb-integration/#how-to-re-enable-circleci-for-a-github-organization
> ?
> Can you share more details on the denied POST you see ?
>
> On my account (which is not an organization) I have
> - CircleCI as "Authorized OAuth Apps" for my whole account (Access
> public repositories / Read org and team membership / Access user email
> addresses (read-only))
> - CircleCI webhook in the repo config
> (https://github.com/champtar/packages/settings/hooks)
> - CircleCI deploy key in the repo config
> (https://github.com/champtar/packages/settings/keys)

2 PR almost worked
- https://github.com/openwrt/packages/pull/6924
- https://github.com/openwrt/packages/pull/6492
they need to rebase on master to have CircleCI config I think

>
> Etienne
>
>
> >
> > /ted
> >

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

Re: [OpenWrt-Devel] Enabling CircleCI for packages repo

[Etienne Champetier]

Hi Ted,

Le dim. 28 oct. 2018 à 17:40, Ted Hess  a écrit :
>
> >> Etienne - AFAICT, I have enabled CircleCI on 10/25 for openwrt/packages 
> >> repo. It looks like github is posting PRs to CircleCI but
> >> nothing is happening. The POST response says DENY without any reason. Does 
> >> CircleCI also need organization access to
> >> lede-project?
> >>
> >> The deploy key is registered, but hasn't been used.
> >> Is the docker image reference correct?
> >> There must be some"may I" thing missing that allows CircleCI to access our 
> >> repository?
> >
> >I've started experimenting months ago so maybe I changed some of the
> >defaults settings and I don't remember
> >can you have a look at:
> >https://circleci.com/gh/openwrt/packages/edit#advanced-settings
> >
> >GitHub Status updates: on
> >Free and Open Source: on
> >Build forked pull requests: off --> on

This was definitely needed ...

> >Pass secrets to builds from forked pull requests: off
> >Only build pull requests: off --> on
> >Auto-cancel redundant builds: off -> on
> >Enable build processing (preview): on --> off
>
> OK - I changed some settings to match what you have (as noted above). Waiting 
> to see what happens now.

... but this is not enough :(
https://github.com/openwrt/packages/pull/7272

Can you have a llok at
https://circleci.com/docs/2.0/gh-bb-integration/#how-to-re-enable-circleci-for-a-github-organization
?
Can you share more details on the denied POST you see ?

On my account (which is not an organization) I have
- CircleCI as "Authorized OAuth Apps" for my whole account (Access
public repositories / Read org and team membership / Access user email
addresses (read-only))
- CircleCI webhook in the repo config
(https://github.com/champtar/packages/settings/hooks)
- CircleCI deploy key in the repo config
(https://github.com/champtar/packages/settings/keys)

Etienne


>
> /ted
>

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

Re: [OpenWrt-Devel] Enabling CircleCI for packages repo

[Etienne Champetier]

Hi Ted,

Le dim. 28 oct. 2018 à 12:11, Ted Hess  a écrit :
>
> -Original Message-
> From: Etienne Champetier
> Sent: Friday, October 26, 2018 6:10 PM
> To: OpenWrt Development List
> Subject: [OpenWrt-Devel] Enabling CircleCI for packages repo
>
> Hi All,
>
> Can one of the github admin enable CircleCI for the packages repo ?
> The configuration was merged:
> https://github.com/openwrt/packages/pull/5993
>
> But it needs to be installed / configured
> https://github.com/marketplace/circleci
> (at the bottom of the page)
>
> Thanks
> Etienne
>
> ___
>
> Etienne - AFAICT, I have enabled CircleCI on 10/25 for openwrt/packages repo. 
> It looks like github is posting PRs to CircleCI but
> nothing is happening. The POST response says DENY without any reason. Does 
> CircleCI also need organization access to lede-project?
>
> The deploy key is registered, but hasn't been used.
> Is the docker image reference correct?
> There must be some"may I" thing missing that allows CircleCI to access our 
> repository?

I've started experimenting months ago so maybe I changed some of the
defaults settings and I don't remember
can you have a look at:
https://circleci.com/gh/openwrt/packages/edit#advanced-settings

GitHub Status updates: on
Free and Open Source: on
Build forked pull requests: on
Pass secrets to builds from forked pull requests: off
Only build pull requests: on
Auto-cancel redundant builds: on
Enable build processing (preview): off

Thanks
Etienne

>
> /ted
>
>
>

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

[OpenWrt-Devel] Enabling CircleCI for packages repo

[Etienne Champetier]

Hi All,

Can one of the github admin enable CircleCI for the packages repo ?
The configuration was merged:
https://github.com/openwrt/packages/pull/5993

But it needs to be installed / configured
https://github.com/marketplace/circleci
(at the bottom of the page)

Thanks
Etienne

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

[OpenWrt-Devel] Package global config

[Etienne Champetier]

Hello OpenWRT devs,

In zabbix package, I have 2 config options:
- ssl support
- db choice
https://github.com/openwrt/packages/blob/master/admin/zabbix/Makefile#L35

right now ssl support is "Package/zabbix-agentd/config" and db choice
is "Package/zabbix-server/config",
Is there a way to have the options global for the whole zabbix group
of packages ?

Thanks
Etienne

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

Re: [OpenWrt-Devel] project: build speed-up with binary injection

[Etienne Champetier]

Hi Pieter,

Le mer. 12 sept. 2018 à 15:20, Pieter Smith  a écrit :
>
> Hi all,
>
> I would like to extend the OpenWRT build system to allow a substantial
> speed-up with optional pre-built binary injection. The goal is to
> perform the full distro build including toolchain in less than 10 min
> for the product that we develop.
>
> My proposal is to augment the build so that build results can optionally
> be published of fetched. Locally compiled build results can be published
> for potential fetch and injection on future builds by other developers
> or build slaves.
>
> Above all the implementation should guarantee repeatability and
> consistency. A fetch and inject speed up will only be allowed if it does
> not violate this requirement.
>
> So far I have come up with the idea to guarantee this by publishing
> build results under a strong hash (sha1 or better). The hash is
> based on the source state of what needs to be built, and the hashes of
> all dependencies and configuration leading up to that (Something similar
> to what git does to calculate a commit id).
>
> If the calculated hash for what has to be built can be fetched and
> injected, consistency is guaranteed and the speedup is safe. If the
> calculated hash has not been built before, the build step is performed
> and the result is published under the calculated hash.
>
> Can anyone comment on the above?
>
> Regards,
> Pieter Smith
>
> P.S. If I missed something existing that can already achieve some of the
> build speed-up, please let me know.

Never tried it myself, but have you tried ccache ?

Regards
Etienne

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

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

Re: [OpenWrt-Devel] time command detect fail on centos

[Etienne Champetier]

Hi,

2018-07-08 15:50 GMT+02:00 李国 :
> Hi Jon Burgess
> this patch works good. thanks.
> diff --git a/include/prereq.mk b/include/prereq.mk
> index 0f0f253744..173461e36f 100644
> --- a/include/prereq.mk
> +++ b/include/prereq.mk
> @@ -95,7 +95,7 @@ define SetupHostCommand
> if [ -n "cmd" ]; then \
> bin="(PATH="$(subst
> $(space),:,$(filter-out $(STAGING_DIR_HOST)/%,$(subst
> :,$(space),$(PATH" \
> which "{cmd%% *}")"; \
> -   if [ -x "bin" ] && eval "cmd"
>>/dev/null 2>/dev/null; then \
> +   if [ -x "bin" ] && eval
> "\\cmd" >/dev/null 2>/dev/null; then \
> mkdir -p "$(STAGING_DIR_HOST)/bin"; \
> ln -sf "bin"
> "$(STAGING_DIR_HOST)/bin/$(strip $(1))"; \
> exit 0; \
>
> 2018-07-08 0:11 GMT+08:00 Jon Burgess :
>> On Sat, 2018-07-07 at 16:23 +0800, 李国 wrote:
>>> Hi Etienne Champetier
>>>
>>> time command detect fail on centos.
>>>
>>> time is a keyword of bash on centos 6 and centos 7, and it not accept
>>> --version option, this makes time --version 2>&1 | grep GNU  always
>>> fail.

I just tried a fresh git checkout of master on an up to date CentOS 7
After "yum install time" build work perfectly fine

Regards
Etienne

>>
>> Does using \time instead help?
>>
>>   Jon
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

Re: [OpenWrt-Devel] Enable DCO check on Github OpenWrt organisation

[Etienne Champetier]

Hi Piotr,

2018-01-19 9:54 GMT+01:00 Piotr Dymacz <pep...@gmail.com>:
> Hi Etienne,
>
> On 18.01.2018 22:59, Etienne Champetier wrote:
>>
>> Hi All,
>>
>> Could someone enable this https://github.com/integration/dco on the
>> whole OpenWrt github org? (or at least on the packages repo)
>
>
> I think that packages repository already uses Travis CI which checks for
> such thing like a missing SoB, have a look at [1].

I'm well aware that the package repo uses Travis, as I'm the one
fixing it from time to time ;)

>
> It seems that for openwrt/openwrt drone.io CI is used (I don't know who
> manages that) but only to check if build fails or not. Maybe we could extend
> it and include scripts/checkpatch.pl before build? That would save reviewers
> time pointing out formal issues, not only the missing SoB.

The interest of using DCO is to have an instant response directly into
the PR (you don't have to jump into Travis logs)
We can also make it mandatory (show "required" on the fail test line)
Also this is a good minimum check to have on ALL repo
There are many ways to do it, enabling DCO is a 2 minutes job (if
someone want to do a similar script and host it that's totally fine
with me)

Cheers,
Etienne

>
> [1] https://travis-ci.org/openwrt/packages/builds/329031205
>
> --
> Cheers,
> Piotr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] patchwork

[Etienne Champetier]

Hi All,

2018-01-18 1:30 GMT-08:00 Piotr Dymacz :
> Hi,
>
> On 18.01.2018 09:44, Jo-Philipp Wich wrote:
>>
>> Hi John, Alex,
>>
>> I have no problem with closing / autorejecting open tickets in patchwork
>> as long as they somehow remain available for future reference.
>
>
> ACK.
>
> Would it be possible to send the author short message why the patch was auto
> closed/rejected (excluding the auto message from patchwork)?
>
>>> To add here. Would it be possible/desire-able to add an auto-timeout
>>> to patchwork & github PRs, issues to close after X time ? Maybe make
>>> it official as part of the submission process.
>>
>>
>> I would very much like that and have been thinking about this various
>> times, maybe it is time to finally implement it.

For github PRs you might be interrested in https://github.com/probot/stale

>>
>> I could think of an idle timeout ranging somewhere between 3 to 6 months.
>
>
> Some of us discussed this during the OpenWrt Summit and IIRC we agreed that
> it would make sense and is desirable.
>
> Also, a nice message explaining why this happens, maybe with short list of
> what the user can/should do afterwards, would save us time answering the
> same questions, especially on GitHub.
>
> --
> Cheers,
> Piotr
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Enable DCO check on Github OpenWrt organisation

[Etienne Champetier]

Hi All,

Could someone enable this https://github.com/integration/dco on the
whole OpenWrt github org? (or at least on the packages repo)

Thanks
Etienne
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] ujail bug/feature with file replacement with mv

[Etienne Champetier]

Hi,

Just a heads up,
ujail uses "bind mount" to include file and directories into the jail,
so if you include a file named aaa (procd_add_jail_mount(_rw) aaa),
and then replace it outside of the jail using "mv bbb aaa",
in the jail you will still have file aaa.

Workaround is to use a directory instead of a file.
This might be usefull to remember if you try to change a config file
atomically with mv and signal the process.

Regards
Etienne
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [LEDE-DEV] git.openwrt.org site half broken

[Etienne Champetier]

2016-06-03 11:13 GMT+02:00 John Crispin <j...@phrozen.org>:
>
>
> On 02/06/2016 13:20, Etienne Champetier wrote:
>> Hi,
>>
>> someone messed with git.openwrt.org nginx config, i can't get the js and css.
>>
>> see https://git.openwrt.org/project/static/gitweb.css (doesn't look
>> like a css :) )
>>
>> Cheers
>> Etienne
>>
>
> that url looks weird.
> -> https://git.openwrt.org/static/gitweb.css
> works and for me the service seems to be functional.

Indeed, i don't know were i found
https://git.openwrt.org/project/
right url is
https://git.openwrt.org/

>
> John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] git.openwrt.org site half broken

[Etienne Champetier]

Hi,

someone messed with git.openwrt.org nginx config, i can't get the js and css.

see https://git.openwrt.org/project/static/gitweb.css (doesn't look
like a css :) )

Cheers
Etienne
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] procd: restrict ujail to supported platforms

[Etienne Champetier]

cc list

2016-04-13 14:40 GMT+02:00 Etienne Champetier <champetier.etie...@gmail.com>
:

> Hi Zefir
>
> 2016-04-13 14:26 GMT+02:00 Zefir Kurtisi <zefir.kurt...@neratec.com>:
>
>> ujail can be selected on e.g. PowerPC platforms, which
>> currently causes the procd build to fail:
>> ./trace/trace.c:48:2: error: #error tracing is not supported on this
>> architecture
>>  #error tracing is not supported on this architecture
>>   ^
>> ./trace/trace.c: In function 'tracer_cb':
>> ./trace/trace.c:128:50: error: 'reg_syscall_nr' undeclared (first use in
>> this function)
>> int syscall = ptrace(PTRACE_PEEKUSER, c->pid, reg_syscall_nr);
>>   ^
>> This patch restricts ujail to those platforms supported.
>>
>
> trace/trace.c is the source code of utrace binary,
> which is in procd-seccomp package, not procd-ujail
>
>
> http://git.openwrt.org/?p=project/procd.git;a=blob;f=CMakeLists.txt;h=74959e02951d286efda4c361eb1cbe7cba38e668;hb=HEAD#l108
>
> https://github.com/openwrt/openwrt/blob/73b5446e9a64adb1cc55da1982447251babe2076/package/system/procd/Makefile#L111
>
> https://github.com/openwrt/openwrt/blob/73b5446e9a64adb1cc55da1982447251babe2076/package/system/procd/Makefile#L132
>
>
>> Signed-off-by: Zefir Kurtisi <zefir.kurt...@neratec.com>
>> ---
>>  package/system/procd/Makefile | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile
>> index 294985c..acd1714 100644
>> --- a/package/system/procd/Makefile
>> +++ b/package/system/procd/Makefile
>> @@ -49,7 +49,8 @@ endef
>>  define Package/procd-ujail
>>SECTION:=base
>>CATEGORY:=Base system
>> -  DEPENDS:=@KERNEL_NAMESPACES +@KERNEL_UTS_NS +@KERNEL_IPC_NS
>> +@KERNEL_PID_NS +libubox +libblobmsg-json
>> +  DEPENDS:=@KERNEL_NAMESPACES +@KERNEL_UTS_NS +@KERNEL_IPC_NS
>> +@KERNEL_PID_NS +libubox +libblobmsg-json \
>> +  @arm||@armeb||@mips||@mipsel||@i386||@x86_64
>>TITLE:=OpenWrt process jail helper
>>  endef
>>
>> --
>>
>
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] svn.openwrt.org down?

[Etienne Champetier]

You should switch to git (haven't checked if it works right now though)
Le 25 févr. 2016 21:39, "Shankar Unni"  a
écrit :

> The svn server on svn.openwrt.org seems to be down? The machine itself
> is up and running, however.
>
> Is there a known outage?
>
>
> % svn up
> svn: Can't connect to host 'svn.openwrt.org': Connection refused
>
> % ping svn.openwrt.org
> PING svn.openwrt.org (78.24.191.177) 56(84) bytes of data.
> 64 bytes from openwrt.org (78.24.191.177): icmp_req=1 ttl=51 time=181 ms
> 64 bytes from openwrt.org (78.24.191.177): icmp_req=2 ttl=51 time=180 ms
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Multi-wwan and AP only radio0

[Etienne Champetier]

Hi,

Le 5 févr. 2016 07:14, "Okupandolared"  a écrit :
>
> Hello.
>
> I have a WR740N with Barrie braker, I achieved to create my own image
with all requirements and after flash image, install mwan3 and
luci-app-mwa3.
>
> Currently I connect to a wireless network as a client-A WWAN, and create
another wireless network as master AP Wireless-B
>
> I wonder if you could connect to two wireless clients? 2 WWAN and balaced
with mwan3
>
> I would like to have 2 WWAN, connect to two WiFi networks as a client,
and another one as wireless LAN AP

In  general  you can only have 1 client per wireless card, so  i would say
no.

>
> thanks for everything
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] John, no permission to change patches even own

[Etienne Champetier]

Hi

You should respond to the original mail and not create a new thread each
time

Le 19 janv. 2016 03:03, "Daniel Dickinson" daniel.thecshore.com
> a écrit :
>
> Hi John,
>
> Contrary to what you believed it is not possible for the ordinary users
(of which I am one at the moment) to modify their own patches, so I can't
discard, archive, or otherwise do anything to patches even my own.

Maybe your patch email and your account email doesn't match exactly (+
filter or typo)?

There is not a lot of fonctions, but you can change the state of a patch to
superseeded or rejected which should be enough.
I ve created my account without admin intervention and i'm a 'normal' user.

Regards
Etienne

>
> Regards,
>
> Daniel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Possible regression with 6302a648745a7ffa5ef99c77e4d3e05afa12543b

[Etienne Champetier]

Hi,
Le 13 déc. 2015 14:16, "Nuno Gonçalves"  a écrit :
>
> root@OpenWrt:/tmp# sysupgrade openwrt.bin
> /sbin/sysupgrade: .: line 10: can't open '/lib/upgrade/nand.sh'
>

See mail "[OpenWrt-Devel] [RFC] Fixing broke sysupgrade caused by r47878
(add mr18)" i think

> Thanks,
> Nuno
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel