**** BEGIN LOGGING AT Mon Mar 16 02:59:58 2020 Mar 16 07:38:49 hm, the updated iptables fails to build for me Mar 16 07:41:16 seems libnftnl needed a manual clean and rebuild... smells like missing dependency Mar 16 07:41:22 or rather missing ABI tracking Mar 16 07:41:44 nvm still doesn't work Mar 16 08:47:21 jow: https://git.openwrt.org/?p=project/ucert.git;a=blob;f=tests/cram/test_ucert.t Mar 16 08:48:21 jow: so probably missing some test case Mar 16 08:51:34 jow: ping - iptables ? Mar 16 08:52:07 jow: I've never used ucert (or signed images) myself, but I've that on my TODO as it would be nice to get signed firmware images working by default for next release Mar 16 08:53:02 jow: IIRC there was some bug report related to ucert on FS as well Mar 16 08:53:23 ldir: the culprit was CONFIG_IPTABLES_NFTABLES, apparently our packaged version of libnftnl is incompatible / too old Mar 16 08:54:07 ldir: when the above option is enabled, link iptables fails with: nft-bridge.c:(.text.nft_bridge_parse_lookup+0x109): undefined reference to `nftnl_set_list_lookup_byname' Mar 16 08:54:30 ldir: and indeed, rgrep-ing 'nftnl_set_list_lookup_byname' in libnftl's build dir yields zero results Mar 16 08:55:15 Ah, I don't have nftables enabled so that's why I've never seen it. Mar 16 08:55:16 ynezz: tbh I don't trust ucert and I wouldn't want to use it by default for signing formware images Mar 16 08:55:40 ynezz: can't we simpl package bsd signify and use that? Mar 16 08:55:45 +1 Mar 16 08:56:08 actually, no that's odd - macbot went through ok and that builds 'phase1' Mar 16 08:56:27 then simply add the base64 signature string to the existing json metadata and make it a requirement Mar 16 08:57:14 ldir: I guess CONFIG_IPTABLES_NFTABLES, is disabled by default, I might have had it enabled due to some past experiements Mar 16 09:04:28 jow: ok, let me see if I can replicate... then I'll bump libnftnl to 1.1.5 and see if that cures it. Mar 16 09:22:11 blogic: when you've a moment, can you take a look at the ipq40xx fix please https://patchwork.ozlabs.org/patch/1255345/ ? Mar 16 09:23:26 * f00b4r0 discovers that 802.11r apparently doesn't work on ath9k/ath10k *sigh* Mar 16 09:44:33 f00b4r0: are you sure? There're some reports of it working, and why wouldn't it? Mar 16 09:45:20 PaulFertser: i'm on 18.06.8 and I see this in the logs: hostapd: wlan1: STA IEEE 802.11: Could not set STA to kernel driver Mar 16 09:45:36 google then told me this: https://forum.openwrt.org/t/802-11r-troubleshooting-ath9k-ath10k/49691 :) Mar 16 09:45:55 compat problem between hostapd and athXk Mar 16 09:47:44 f00b4r0: so not a hardware or driver limitation but some interop problem of hostapd due to API changes. Mar 16 09:48:37 looks that way Mar 16 10:43:17 ldir: I think the ABI version of libnftnl should be inceased as well Mar 16 10:43:43 * ldir looks Mar 16 10:45:05 Oooh! There's the ABI_VERSION lurking there... missed it. Mar 16 10:45:27 Hauke: so you received an email? Mar 16 10:45:54 ldir: yes Mar 16 10:46:26 ldir: I got the mail you sedn 10 minutes ago Mar 16 10:47:16 I've tried to resubscribe to openwrt-devel but I never receive the confirmation emails. I didn't think sending to the list when not subscribed would work. Mar 16 11:09:46 "Your subscription request has been received, and will soon be acted upon. Depending on the configuration of this mailing list, your subscription request may have to be first confirmed by you via email, or approved by the list moderator. If confirmation is required, you will soon get a confirmation email which contains further instructions." and then nothing Mar 16 11:33:52 ldir: overly aggressive spam filter? :) Mar 16 11:35:15 don't think so, openwrt-adm gets through. Mar 16 11:36:04 f00b4r0: that thread hasn't had any posts for 3 months Mar 16 11:36:39 DonkeyHotei: and? Mar 16 11:36:59 something may have changed Mar 16 11:42:33 DonkeyHotei: seems to be long standing. https://www.spinics.net/lists/hostap/msg05159.html Mar 16 11:42:47 apparently switching over DS off might "fix" it for me. Will test. Mar 16 12:29:12 f00b4r0: hm, but that mail says it was fixed more than a year ago, so you must be running a rather old hostapd if it doesn't have that. Mar 16 12:42:19 which openwrt branches have that patch? Mar 16 13:06:27 interestingly, sysupgrade -v -n openwrt-omap-ti_am335x-bone-black-squashfs-sdcard.img.gz is preserving old settings Mar 16 13:22:19 ynezz: Ack Mar 16 13:51:33 build #113 of sunxi/cortexa7 is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa7/builds/113 blamelist: Jun Su , Sungbo Eo , Rafa? Mi?ecki , Adrian Schmutzler , Felix Fietkau Mar 16 13:51:33 , Catrinel Catrinescu Mar 16 14:13:03 PaulFertser: 18.06.8, as I mentioned earlier. Dunno if it has the patch. Mar 16 14:13:31 in fact I haven't followed the thread long enough to see whether the patch was eventually accepted, it seemed to be frowned upon wrt side effect on KRACK Mar 16 14:15:35 f00b4r0: Juoni answered in the next mail that he committed https://w1.fi/cgit/hostap/commit/?id=4cf5efece394067542673a252d6ea67b898b8eb9 to fix it Mar 16 14:16:16 PaulFertser: i see. thx for the pointer Mar 16 19:55:14 jow: people want mvebu split up to a neon and non-neon target. thoughts? Mar 16 19:56:48 AFAIK, there's only one device (Linksys WRT1900ACv1) that needs vfpv3-d16 (yes, vfpv3 is a mistake) Mar 16 20:14:41 mangix: do you have some benchmarks? Mar 16 20:15:03 In general I am fine with that as we build the packages anyway only once per CPU Mar 16 20:16:01 I do not. However I do know that there is an impact with WireGuard as it uses kernel crypto as well as an optimized NEON implementation. Mar 16 20:16:35 vfpv3 is also a mistake. there are runtime issues on old hardware Mar 16 20:16:46 * mangix looks it up Mar 16 20:18:31 https://forum.openwrt.org/t/gcc-was-broken-on-mvebu-armada-370-device-after-commit-on-2019-03-25/43272?u=wackejohn Mar 16 20:19:04 Illegal instruction crashing Mar 16 21:41:54 mangix: It looks like armada 370 only supports VFP3-D16 http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf Mar 17 02:49:21 Hauke: correct **** ENDING LOGGING AT Tue Mar 17 02:59:57 2020