**** BEGIN LOGGING AT Fri Mar 26 02:59:56 2021
Mar 26 03:03:21 <pkgadd> interesting enough, ipq40xx was apparently using CPU_TYPE:=cortex-a15 && CPU_SUBTYPE:=neon-vfpv4 as well, without any ill effects
Mar 26 03:06:30 <pkgadd> (while ipq40xx was still supported within the ipq806x target)
Mar 26 03:41:59 <philipp64> aparcar[m]: done. https://github.com/openwrt/packages/pull/15266
Mar 26 03:44:34 <lipnitsk> just discovered CONFIG_MODULE_STRIPPED
Mar 26 03:44:51 <lipnitsk> seems to hide/bypass a bunch of modpost checks
Mar 26 03:45:32 <lipnitsk> like: FATAL: modpost: sound/soc/ralink/snd-soc-ralink-i2s: struct of_device_id is not terminated with a NULL entry!
Mar 26 04:00:01 <Grommish> Silly question, but what does the build system mean when it returns "Nothing to be done for 'compile'"?  I can see it not actually doing anything, even when I force the define with $(call Build/Compile/Default). it never calls the make invocation
Mar 26 04:02:31 <lipnitsk> did you misspell the target?
Mar 26 04:08:25 <Grommish> lipnitsk: I'll check, but I didn't see anything in particular
Mar 26 04:08:35 <lipnitsk> paste your command
Mar 26 04:09:27 <Grommish> make -j1 V=sc package/feeds/packages/libhtp/{clean,prepare,configure,compile}
Mar 26 04:10:32 <lipnitsk> Grommish: libevhtp?
Mar 26 04:10:38 <lipnitsk> can't find libhtp in packages
Mar 26 04:11:10 <Grommish> https://gist.github.com/Grommish/186303e6a32ee4f6ccb34d2947d653c0
Mar 26 04:11:18 <Grommish> I'm creating it
Mar 26 04:11:35 <Grommish> Again, I'm missing something stupid, I  know i t, but I can't see it
Mar 26 04:11:48 <philipp64> uhh...  why package/feeds/packages/ and not just package/
Mar 26 04:11:52 <Grommish> Build/Compile doesn't get called, even when a direct make is called
Mar 26 04:12:06 <Grommish> philipp64: Because I maintain a repo in which I forked feeds/packages
Mar 26 04:12:22 <Grommish> so Everything goes into feeds/packages, and gets worked from there\
Mar 26 04:12:28 <lipnitsk> package/feeds/packages/ works better actually, especially for 'refresh' etc
Mar 26 04:12:41 <Grommish> So, make package/feeds/packages/<pgkname>
Mar 26 04:13:00 <lipnitsk> it flattens the tree so it's helpful
Mar 26 04:13:08 <Grommish> It's all symlinked anyway
Mar 26 04:13:12 <lipnitsk> ya
Mar 26 04:13:23 <Grommish> I use it because itmakes its easy to deal with PRs
Mar 26 04:14:06 <lipnitsk> Grommish: try getting rid of ${PKG_NAME}, it may not get eval'ed in time
Mar 26 04:14:19 <lipnitsk> I mean in "define" statements
Mar 26 04:14:19 <Grommish> Ok
Mar 26 04:15:19 <Grommish> Yeah, it didn't have an issue with Prepare or Configure
Mar 26 04:15:30 <Grommish> just Compile says Go away without telling me why
Mar 26 04:15:37 <Grommish> Just "Nothing to be done"
Mar 26 04:15:47 <Grommish> But even the echo check I put in doesn't go off
Mar 26 04:16:06 <lipnitsk> yeah, something didn't get linked up. there are a bunch of layers that make it all work
Mar 26 04:17:13 <lipnitsk> "make <YOUR_TARGET> -j1 V=s --print-data-base" helps too sometimes
Mar 26 04:17:34 <lipnitsk> you can see all the MAKE variables in that output and usually see what is wrong with your particular package
Mar 26 04:18:51 <Grommish> lipnitsk: https://gist.github.com/Grommish/b9cc2685f54cebcc4fd4fb6354faf0e9
Mar 26 04:19:19 <Grommish> Its a standard autogen.sh, ./configure, make, make install
Mar 26 04:19:32 <Grommish> I just dunno why the Build/Compile isn't working
Mar 26 04:24:05 <lipnitsk> Grommish: yeah that's strange...
Mar 26 04:27:24 <Grommish> I'm going to override everything and do it in prepare to see what happens
Mar 26 05:21:35 <plntyk> 8 out of 13 hunks FAILED -- saving rejects to file ltmain.sh.rej failed patch phase
Mar 26 05:21:38 <plntyk> ?
Mar 26 05:23:07 <plntyk> not sure that autogen.sh and using autoreconf as fixup will work
Mar 26 05:23:17 <plntyk> because those do often the same thing
Mar 26 05:23:24 <plntyk> maybe subtle differences
Mar 26 05:41:16 <guidosarducci> ndb: Hi Felix, can I ask you to look at https://github.com/openwrt/openwrt/pull/3926 regarding an old change of yours that appears no longer needed?
Mar 26 05:42:50 <guidosarducci> nbd: Hi Felix, can I ask you to look at https://github.com/openwrt/openwrt/pull/3926 regarding an old change of yours that appears no longer needed?
Mar 26 05:43:05 <guidosarducci> ^^^ I mean instead...
Mar 26 06:27:58 <Grommish> plntyk: I turned them off, but it didnt seem to help
Mar 26 06:28:16 <Grommish> plntyk: Still getting a Nothing to be done for 'compile'.. hmm
Mar 26 06:39:32 <dhewg> mkresin: you recently pushed lantiq patches, could you please take care of https://github.com/openwrt/openwrt/pull/3524 and https://github.com/openwrt/openwrt/pull/3660 ? It's just two small patches which are waiting for quite some time...
Mar 26 06:49:46 <Grommish> Well, if anyone can tell me what I'm doing wrong, I'd be appreciative :) https://forum.openwrt.org/t/nothing-to-be-done-for-compile/92299
Mar 26 07:31:42 <Grommish> plntyk: It was because .config didn't have the package symbol set to m or y :/
Mar 26 08:37:57 <aparcar[m]> guidosarducci: should I merge https://github.com/openwrt/openwrt/pull/3926 now that felix approved it?
Mar 26 08:39:16 <guidosarducci> aparcar[m]: Yes, please. Thanks.
Mar 26 08:39:33 <aparcar[m]> please see my comment on your other PR
Mar 26 08:40:16 <rsalvaterra> guidosarducci: Yay, about time! :D
Mar 26 08:49:20 <ldir> I tried to bump openssl to 1.1.1k but 430-e_devcrypto-make-the-dev-crypto-engine-dynamic.patch  won't refresh
Mar 26 08:49:38 <ldir> and I ain't messin' with openssl
Mar 26 08:50:48 <rsalvaterra> ldir: Try refreshing it before.
Mar 26 08:51:08 <rsalvaterra> All current OpenSSL patches need refresh (I did it in my tree).
Mar 26 08:52:18 <ldir> so the current tree has fuzz in the openssl patches?  That's pretty shit and means prior bumps/tweaks haven't done make package/foo/refresh.
Mar 26 08:52:36 <aparcar[m]> ldir: we need a CI
Mar 26 08:52:58 <rsalvaterra> ldir: Tons of fuzz.
Mar 26 08:53:24 <ldir> rsalvaterra: that's very, very shit quite frankly.
Mar 26 08:53:42 <rsalvaterra> We need people to *refresh patches* before committing.
Mar 26 08:53:54 <ldir> expect a fuzz cleaning commit shortly
Mar 26 08:54:16 <rsalvaterra> ldir: Yes, please, thanks!
Mar 26 08:54:39 <aparcar[m]> is it just about refreshing patches? I think I even did a PR for that
Mar 26 08:55:01 <aparcar[m]> https://github.com/openwrt/openwrt/pull/3899
Mar 26 08:55:27 <guidosarducci> aparcar[m]: thanks, saw your comment and tried to respond. We can clarify here too if easier.
Mar 26 08:57:36 <rsalvaterra> aparcar[m]: https://github.com/rsalvaterra/openwrt/commit/e5a07d464a0d8478f26909122fe6ee4142aaf143
Mar 26 08:58:28 <rsalvaterra> (The huge diff happens because quilt converts the rename into add/delete.)
Mar 26 08:59:03 <aparcar[m]> jep I remember
Mar 26 08:59:13 <aparcar[m]> mangix suggested to add makefile magic...
Mar 26 09:01:52 <mangix> ldir: cotequeiroz handles that
Mar 26 09:01:59 <ldir> as soon as I see patch fuzz it tells me someone doesn't understand the openwrt quilt patch build process
Mar 26 09:01:59 <mangix> and yes, he did not refresh
Mar 26 09:02:11 <mangix> almost nobody does
Mar 26 09:02:45 <mangix> I discovered it probably two weeks before it became mandatory in the packages feed
Mar 26 09:03:58 <mangix> rsalvaterra: use Makefile magic
Mar 26 09:04:32 <mangix> rsalvaterra: https://github.com/openwrt/packages/blob/master/utils/open-vm-tools/Makefile#L85
Mar 26 09:05:28 <rsalvaterra> mangix: I'm not sure I follow you. What does that do? :)
Mar 26 09:06:20 <mangix> fixes that large diff since quilt cannot handle renames
Mar 26 09:06:34 <rsalvaterra> ldir: Does the refresh make the 1.1.1k bump easier?
Mar 26 09:06:39 <aparcar[m]> guidosarducci: we need to wait at least until the buildbot have the prereq installed :)
Mar 26 09:07:14 <ldir> don't know yet - I doubt it.
Mar 26 09:07:25 <rsalvaterra> mangix: Maybe quilt needs to be taught about renames…
Mar 26 09:07:46 <ldir> well I've pushed the refresh
Mar 26 09:08:14 <rsalvaterra> mangix: Ah, I see, you rename the file first.
Mar 26 09:08:48 <rsalvaterra> ldir: Another commit I can drop from my tree, thanks. ;)
Mar 26 09:09:12 <aparcar[m]>  ...e_devcrypto-make-the-dev-crypto-engine-dynamic.patch | 2646 +++++++++++++++++++++--
Mar 26 09:09:29 <aparcar[m]> heh
Mar 26 09:09:36 <guidosarducci> aparcar[m]: yikes, so it seems people change build prerequisites in the wiki uncorrelated to actual systems...
Mar 26 09:09:57 <guidosarducci> aparcar[m]: do I need anything special to use that gitlab?
Mar 26 09:10:15 <mangix> ldir: looks like a mistake not handling the rename
Mar 26 09:10:54 <aparcar[m]> guidosarducci: you can use your github account to login, if it's to much of a fuzz I'll do it
Mar 26 09:11:02 <ldir> fuck it - revert it - I don't care - the tree is turning to shit
Mar 26 09:11:27 <aparcar[m]> ldir: noo just because I mess up JSON fixes 3 times in a row doesn't mean everything is going to shit
Mar 26 09:13:31 <mangix> ldir: I'll fix and send a patch
Mar 26 09:15:29 <rsalvaterra> I'm starting to feel sorry for bringing the issue up… :P
Mar 26 09:25:45 <mangix> sent
Mar 26 09:26:52 <rsalvaterra> Yes, but…
Mar 26 09:26:59 <rsalvaterra> … why the rename in the first place…?
Mar 26 09:27:12 <guidosarducci> aparcar[m]: ok, logged into gitlab/buildbot, will try...
Mar 26 09:28:24 <aparcar[m]> guidosarducci: good luck
Mar 26 09:29:36 <mangix> rsalvaterra: the patch makes it an external engine, not a built-in one
Mar 26 09:29:52 <mangix> I believe it's an upstream backport
Mar 26 09:30:18 <aparcar[m]> mangix: is your patch for the reverted or the unreverted repo state?
Mar 26 09:31:06 <mangix> unreverted. didn't realize it was
Mar 26 09:31:53 <rsalvaterra> guidosarducci: Since you're doing fw3 work, could you please take a look a this, when you have time? I have it in my tree since I posted it, with no issues. https://patchwork.ozlabs.org/project/openwrt/patch/20200130135422.15939-1-rsalvaterra@gmail.com/
Mar 26 09:33:52 <rsalvaterra> guidosarducci: Wait, actually, that's horribly outdated.
Mar 26 09:34:22 <rsalvaterra> guidosarducci: The two topmost commits, here… https://github.com/rsalvaterra/firewall3/commits/salvaterra
Mar 26 09:43:36 <mangix> aparcar[m]: if you want to update https://github.com/openwrt/openwrt/pull/3899 , you should base it on https://github.com/neheb/openwrt/commits/refresh . Fixes the annoying renames
Mar 26 09:45:35 <aparcar[m]> mangix: please create new openssl patch which does the rename and the refresh at once
Mar 26 09:46:31 <aparcar[m]> actually, please just use my genius script and I'll close the PR
Mar 26 09:47:15 <guidosarducci> rsalvaterra: have you pinged jow? Not much I can personally do, and I'm loath to do cleanups in "security" components I don't fully understand anyway. Do your changes fix bugs? How are you testing it? Regressions? I'd probably be more a PITA than jow TBH. :^)
Mar 26 09:48:04 <rsalvaterra> guidosarducci: Heh… just code consolidation and cleanups, nothing fancy… :)
Mar 26 09:49:06 <mangix> aparcar[m]: what genius script?
Mar 26 09:49:45 <aparcar[m]> in the patch description
Mar 26 09:52:31 <mangix> maybe tomorrow. turns out these lua packages also have host patches...
Mar 26 09:58:47 <karlp> behaving differently with quilt sounds like a recipe for explosions that down the road honestly.
Mar 26 10:01:58 <mangix> karlp: The good news is, it's only three packages in base and one in packages
Mar 26 10:05:40 <mangix> OpenSSL will be gone with the 3.0 version update I believe
Mar 26 10:06:08 <rsalvaterra> mangix: We're dropping OpenSSL? o_O
Mar 26 10:06:48 <mangix> no I mean version bump to 3.0
Mar 26 10:07:36 <mangix> oh ffs. I found a bug with quilt.mk
Mar 26 10:08:01 <guidosarducci> aparcar[m]: this might be futzed up, but see https://gitlab.com/openwrt/buildbot/-/merge_requests/1
Mar 26 10:09:59 <rsalvaterra> mangix: Phew… don't kill my Tor, please. :P
Mar 26 10:13:06 <mangix> cotequeiroz handles the version updates not me.
Mar 26 10:13:42 <guidosarducci> aparcar[m]: not sure it's meaning, but also seeing: "Failed to get security report information. Please reload the page or try again later."
Mar 26 10:17:11 <mangix> aparcar[m]: seems that script can be simplified
Mar 26 10:17:37 <mangix> while read PKG; make package/$PKG/refresh ; end < packages.txt
Mar 26 10:17:57 <mangix> do/done for bash
Mar 26 11:38:23 <Hauke> mangix: I think it is not a problem when something does not work with gcc 7 any more in master or 21.02
Mar 26 11:39:16 <Hauke> it is not the default since some time and from my point of view only usefull if you see a problem which could be compiler related to check what happens with the older compiler
Mar 26 11:40:59 <rsalvaterra> Hm… And what's keeping us from bumping both gcc and binutils in master? :)
Mar 26 11:41:55 <Hauke> rsalvaterra: yes should probably be done
Mar 26 11:44:28 <rsalvaterra> FWIW, I'm on both latest versions for months.
Mar 26 11:45:25 <rsalvaterra> Hauke: Wait. Actually, we need to merge mangix's musl bump before, as it contains gcc 10 build fixes.
Mar 26 11:47:31 <rsalvaterra> In any case, the musl bump is also good to go, all known issues are fixed.
Mar 26 11:50:45 <Hauke> I would like to have some weks between them
Mar 26 11:52:18 <Hauke> mangix: rsalvaterra: are umdns and umbim the only applications you are aware of that do not compile with gcc 10?
Mar 26 11:54:51 <rsalvaterra> Hauke: As far as I know, yes (I don't use any of them, though).
Mar 26 11:58:12 <rsalvaterra> So, I'd say we merge the musl bump, at least to give it more exposure. There are only so many systems we can test on (ath79, ramips, mvebu and x86-64, in my case).
Mar 26 11:59:16 <rsalvaterra> In a couple of weeks, we can do the toolchain bump.
Mar 26 11:59:38 <Hauke> I would prefer to do the gcc 10 update first
Mar 26 11:59:50 <Hauke> at least I would expect there less problems
Mar 26 12:01:09 <rsalvaterra> In that case, you need to cherry-pick the fixes in mangix's musl pull, no?
Mar 26 12:03:57 <Hauke> yes
Mar 26 12:04:04 <Hauke> I already did over the time
Mar 26 12:04:20 <Hauke> It had over 20 commits in the beginning
Mar 26 12:07:51 <rsalvaterra> Ok, that's perfect, then. :)
Mar 26 16:48:49 <philipp64> aparcar[m]: thanks for fixing the dependency issue... well, "fixing".  yeah, something better is needed.
Mar 26 16:49:01 <philipp64> that's a vexxing one.
Mar 26 17:31:25 <Pepe> aparcar[m]: Would it be possible that you will obtain commit access for openwrt-routing? There is no CI and integration with packages feed is stalled. Would be good to have there Github Actions as it is in packages and telephony feeds.
Mar 26 18:09:16 <aparcar[m]> Pepe: sure I'll ask
Mar 26 18:31:15 <owrt-2102-builds> Build [#12](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/70/builds/12) of `x86/legacy` failed.
Mar 26 18:57:38 <mangix> Hauke: yeah it's just umdns and umbim. The former patch was rejected by ynezz. The latter's not a real fix.
Mar 26 18:58:19 <mangix> gdb and bpftools patches are for musl 1.2.
Mar 26 19:06:38 * enyc meows Hauke 
Mar 26 19:10:26 <enyc> Hauke: alas irl building-works and stuff all getting in way, not got to homehub v5a (lantix xrx200 with ath9k+ath10k) debugging, but can say current 21.02SNAPSHOT crashing and rebooting one awy or another....
Mar 26 19:10:39 <enyc> there was that issue with ath10k CT firmware etc
Mar 26 19:10:48 <enyc> tho that just made the ath10k reboot, not crash whole system iirc
Mar 26 19:24:33 <rr123> really like the dashboard luci
Mar 26 19:27:24 <aparcar[m]> guidosarducci: ping
Mar 26 19:30:12 <aparcar[m]> rr123: same
Mar 26 19:41:37 <mangix> aparcar[m]: https://github.com/openwrt/openwrt/pull/4030
Mar 26 19:45:56 <mangix> well, that was a fast NAK
Mar 26 19:47:00 <jow> :)
Mar 26 19:47:20 <jow> I fail to see the problem with having a remove/add patch actually
Mar 26 19:47:46 <aparcar[m]> jow: yea impressive rtt
Mar 26 19:48:25 <jow> and I fail to see taking such pains to optimize a rename case for a file that does not even end up being shipped in the resulting .ipk
Mar 26 19:48:33 <rsalvaterra> jow: I don't seen any problem with it too. Harder to review, maybe?
Mar 26 19:48:33 <jow> *fail to see the reason
Mar 26 19:49:01 <jow> nobody reviews patch refreshes
Mar 26 19:49:17 <jow> if at all you review the source before/after and do a compilation test
Mar 26 19:49:48 <jow> also wth. do we even need patches renaming entire files in the source tree?
Mar 26 19:50:08 <rsalvaterra> jow: I asked exactly the same. :P
Mar 26 19:52:05 <mangix> jow: in the packages feed , there's one package that needs to rename poll.h to avoid conflict with the libc one
Mar 26 19:52:59 <mangix> the alternative to doing renames in Makefile is quilt blowing up the patch files with file creation and deletion.
Mar 26 19:53:23 <jow> which is fine for me since those patches should be the absolute excpetion
Mar 26 19:54:19 <mangix> I think the middle ground is to manually edit the patch files after quilt with rename entries
Mar 26 20:14:29 <rr123> jow: https://openwrt.github.io/luci/jsapi/LuCI.html  Documentation generated by JSDoc 3.6.3 on Thu Aug 06 2020, is the online luci wiki page up to date?
Mar 26 20:22:32 <Pepe> OpenSSL update 1.1.1k would be cherry-picked into OpenWrt 21.02 and 19.07, right?
Mar 26 20:26:35 <rsalvaterra> Guys, I feel tempted to backport this… https://marc.info/?l=linux-crypto-vger&m=161678608013795&w=4
Mar 26 20:32:07 <mangix> rsalvaterra: that's not even merged :P
Mar 26 20:32:37 <rsalvaterra> mangix: #yolobackport :P
Mar 26 20:33:28 <rsalvaterra> Eight iterations, though…
Mar 26 20:33:55 <mangix> jow: how many CPU cores to the buildbots have?
Mar 26 20:40:58 <rr123> is build.config supposed to be in the release image or not
Mar 26 21:00:44 <Borromini> rr123: if you're talking the image you build, not unless you configure the buildroot so
Mar 26 21:00:51 <Borromini> but you can conigure it so
Mar 26 21:02:01 <Borromini> * configure
Mar 26 21:03:30 <aparcar[m]> mangix: ususally 8 cores
Mar 26 21:03:47 <aparcar[m]> rr123: your choice, there is an option for that
Mar 26 21:11:24 <rr123> found it, thanks
Mar 26 21:28:39 <mangix> aparcar[m]: cool. Ninja will speed it up then
Mar 26 21:28:52 <mangix> AFAIK, it builds with -j 1
Mar 26 21:29:06 <aparcar[m]> What,m
Mar 26 21:29:14 <aparcar[m]> How will it then speedup anything?
Mar 26 21:29:50 <mangix> ninja doesn't care about -j parameters. It always builds in parallel
Mar 26 21:38:03 <mangix> oh no it seems I ran out of disk space
Mar 26 21:38:08 <mangix> WSL begone!
Mar 26 21:40:06 <JyZyXEL> should i replace a 8M GigaDevice SPI flash with the 16M variant or a cheaper WinBond alternative?
Mar 26 21:45:31 <ianccp> The recent update of iproute2  to version 5.11.0 in commit b048a30 breaks compilation where libintl-full is enabled. The check for the new functionality which checks for libbpf in the package's configure script fails due to an unresolved symbol in libintl-full and compilation aborts. Given that it's a crucial part of openwrt, I thought I'd mention
Mar 26 21:45:32 <ianccp> it here. If I submit a patch to the mailing list, past experience tells me that it will take a month before someone looks at it. I have the necessary patches and can post them here if someone wants to take a look?
Mar 26 21:50:56 <ldir> ianccp: my suggestion would be to raise a github pr and poke @guidosarducci about it - Tony is interested in iproute2 stuff and very thorough.
Mar 26 21:54:12 <ianccp> can't raise a PR on the main openwrt repo
Mar 26 21:55:37 <ianccp> i'll send guido an email and let him deal with it - I've done the debugging already, so he just needs to send the patches to the list...
Mar 26 21:56:02 <ianccp> thanks ldir
Mar 26 21:57:58 <ldir> ianccp: yw - the trick is finding someone interested & with sufficient time/patience/skill - I'm interested but the last 3 are sorely lacking
Mar 26 23:19:10 <pkgadd> philipp64: btw. I've been carrying this patch for strongswan for a long time https://paste.debian.net/hidden/8efb1017/ - just as a fyi, I haven't been using strongswan for almost a year now
Mar 26 23:20:11 <philipp64> pkgadd: have you tried upstreaming it?
Mar 26 23:20:52 <pkgadd> philipp64: no, I never got that far (having switched to a faster ipq8065 shortly after)
Mar 26 23:21:03 <Thermi> ipsec starter is deprecated and getting removed in the 6.0.0 release
Mar 26 23:21:12 <Thermi> together with ipsec stroke, ipsec.conf, and ipsec.secrets
Mar 26 23:21:18 <pkgadd> o.k., that solves it as well ;)
Mar 26 23:21:40 <Thermi> I'll see if I can spin up a different kind of loader-notifier for whatever openwrt is using
Mar 26 23:21:45 <Thermi> shouldn't be too difficult
Mar 26 23:21:50 <karlp> is there any "right" way of waiting for a network interface properly? bumping the START number like this person suggests doesnt seem safe/reliable: https://github.com/openwrt/packages/pull/15272
Mar 26 23:22:00 <Thermi> The task is just to notify the init system when the daemon finished starting
Mar 26 23:22:21 <pkgadd> but with many strongswan sub-packages installed, on a dead-slow router (well, ath79, so not thaaat slow) the timeout wasn't enough
Mar 26 23:26:40 <pkgadd> the situation als became a lot better after I trimmed my installed strongswan package set to (almost-) the minimum I really used
Mar 26 23:26:54 <philipp64> pkgadd: you could wait for PR 14708 to go it, and use swanctl instead... it groks *most* of the existing UCI settings (the ones that aren't wrong, anyway, i.e. not "left_firewall", etc.)
Mar 26 23:27:16 <Thermi> pkgadd: looks like the issue is the router or its eMMC
Mar 26 23:27:59 <philipp64> there are only two daemons that get started for strongswan, depending on whether you use ipsec or swanctl... so one really.
Mar 26 23:28:07 <pkgadd> philipp64: I had to move over to wireguard, as I'm now on a cgNAT+IPv6 network - and the wireguard android app can deal with IPv6 better than the strongswan one (not really an issue with strongswan itself, but it nevertheless forced me to switch)
Mar 26 23:28:12 <Thermi> pkgadd: Generally, you only need a very small set of plugins, so the amount of bytes read is quite limited
Mar 26 23:28:37 <Thermi> pkgadd: with a newer Linux kernel, there's UDP encapsulation support for IPv6, so you could use that
Mar 26 23:28:52 <Thermi> That was the primary issue with any roadwarriors
Mar 26 23:29:04 <pkgadd> Thermi: interesting, thanks - I'll probably need to take another look
Mar 26 23:29:30 <Thermi> pkgadd: using UDP encapsulation with IPv6 requires setting a check mark in the config for the VPN
Mar 26 23:30:40 <pkgadd> VPN was the biggest question I had when I signed up with my current (cgNATed + IPv6) ISP - but fibre vs VDSL and using IPv6 for the incoming VPN connections helped me to settle
Mar 26 23:32:05 <jow> karlp: uci managed network interface?
Mar 26 23:33:37 <Thermi> Actually, we don't even need another wrapper around libcharon. We can just use a start-script entry to notify the daemon basically
Mar 26 23:33:43 <Thermi> errr to notify the init system basically
Mar 26 23:41:16 <Thermi> eh
Mar 26 23:41:29 <Thermi> with procd, we can't even do that because the process needs to run in the foreground
Mar 26 23:45:12 <Thermi> That makes it impossible to reliably chain other services to strongSwan on OpenWRT because it's not known when the daemon is ready
Mar 26 23:45:18 <Thermi> That's a problem.
Mar 26 23:45:51 <Thermi> There needs to be a readiness watch function or something. Like inotify for a pid file, or any file actually
Mar 26 23:45:52 <Thermi> Like a socket
Mar 26 23:47:17 <Thermi> A setting like "readinessobject" or something that can be a path to a file, or a socket address
Mar 26 23:47:24 <Thermi> e.g. tcp://127.0.0.1:25 or something
Mar 26 23:48:01 <Thermi> If it's a file, procd subscribes to an inotify for the directory is in and sets the service as having started once the file exists
Mar 26 23:48:20 <Thermi> If it's a socket address, procd checks if the socket is connectable once a second
Mar 27 00:37:13 <guidosarducci> ianccp: there should be no obstacle to raising a PR, filing a bug report at https://bugs.openwrt.org/, or reporting on netdev ML if this is an upstream bug. At least the issue will have persistent visibility, whether or not you choose to follow up.
Mar 27 00:38:12 <guidosarducci> aparcar[m]: pong, what's up?
**** ENDING LOGGING AT Sat Mar 27 02:59:58 2021