**** BEGIN LOGGING AT Mon Mar 29 02:59:56 2021 Mar 29 03:01:02 Pepe: If you wanted to, I'd be more than happy to test it for you. Like I stated, I'm just looking to use it, I'm not picky about how it gets there Mar 29 03:13:41 nbd: Hi Felix, I'm updating a prior NLS fix you made in binutils (which you also maintain) and have some questions in https://github.com/openwrt/openwrt/pull/4038. Please take a look. Thanks! Mar 29 03:20:14 Grommish: BTW, curious on what platform you run suricata? Wondering also if you enable eBPF? Mar 29 03:23:30 guidosarducci: I've tested on mipsel and mips64, someone on the forums tested under aarch64. There is an option for ebpf but I can't use test it because of the arch. Like Hyperscan. I know suricata can support it, but I can't test it Mar 29 03:25:17 guidosarducci: I've not set deps for arches yet for those options though and I've not put hyperscan in at all yet Mar 29 03:29:06 Grommish: I was more curious of the HW platforms used that are actually capable of using suricata without struggle. What is this arch restriction for eBPF? Mar 29 03:32:13 guidosarducci: Using debian as a guide: EBPF_ARCHS = amd64 arm64 armel armhf i386 ppc64el s390x ppc64 sparc64 x32. I know Hyperscan is Intel x86_64/AMD64 specific Mar 29 03:34:02 guidosarducci: I've not production tested suricata yet outside of getting it booted and loaded, I need to make sure the rules get loaded and then test throughput Mar 29 03:34:52 guidosarducci: WIth snort3 on the Shield, I get about 80% max when it's running, I expect about the same for suricata Mar 29 03:37:58 Grommish: thanks for the explanation. Interesting about the restriction, I wonder if that's artificial or based on something. Thought maybe BPF JIT support, since mips32 lacks this, but mips64 works so should be there. Let me know when you using this in anger ..err.. production. Mar 29 03:40:18 I've not tried building on a target platform that should support it yet, but I can give you the error I get for mipsel easy enough if you want to give me a few minutes Mar 29 03:48:24 guidosarducci: General error, although more details are avail.. checking checking if mipsel-openwrt-linux-musl-gcc supports -march=native... no Mar 29 03:52:46 Grommish: strange, could it be it doesn't support cross builds for mips? if you gist the details somewhere I'll try to take a look. Mar 29 03:54:39 guidosarducci: From the suricata config.log, which is massive.. https://gist.github.com/Grommish/04be6003d04e5335a0d0a9a708d3526d Mar 29 03:55:09 It just seems -march=native isn't valid Mar 29 03:55:59 For cross-compile, I dunno how it would though Mar 29 03:57:35 guidosarducci: I saw your BTF PR, and was wondering if it was related to the eBPF issues I was seeing, but then I saw the arch restrictions Mar 29 04:01:32 guidosarducci: what do you plan to achieve with ebpf on low speed links like wireless / dsl / FTTH Mar 29 04:03:33 guidosarducci: I don't actually use bpftools. No idea what the actual issue is. Mar 29 04:03:43 Grommish: right, kernel debug BTF is not arch specific and shouldn't affect something not looking for it. Mar 29 04:05:42 guidosarducci: I am just going to build out an x86_64 target and see what happens Mar 29 04:06:53 mangix: was referring to the compile issue, shouldn't matter what exec we're building, right? Mar 29 04:07:38 mangix: if you're unsure of details may be better to upstream the change and get feedback. Mar 29 04:14:36 OutBackDingo: flexible, programmable packet processing is one aspect, tracing/monitoring/debug is the other motivation for BPF. The link speed being high or low is orthogonal... Mar 29 04:15:58 OutBackDingo: a BPF jited program can run at native speed, but if your CPU is underpowered you have the same issues as always. Mar 29 04:18:20 OutBackDingo: but compared to traditional tc filters or netfilter rules you can have more capabilities and efficiency with BPF than before. Mar 29 04:29:14 Grommish: Hmm, I think you need to figure out where that "native" is coming from in "-march=native". Mar 29 04:32:59 guidosarducci: yes im quite familar with BPF... Mar 29 04:37:41 guidosarducci: Yeah, it's coming from the conftest it looks like, but I'll get to test a few things, create a rust toolchain for x86_64 a target and see what breaks :) Mar 29 04:54:42 OutBackDingo: oh, so then why the troll? Mar 29 05:01:09 guidosarducci: not so much a troll just more seeking insight from a low end embedded platform perspective. Mar 29 05:02:36 as most of these "wireless access points have minimium resources Mar 29 05:02:46 hey all, has anyone published anything about the release of 21.02? Mar 29 05:13:28 nvm, this is enough https://openwrt.org/docs/guide-developer/20.xx.major.changes Mar 29 05:13:49 but i did not see any forum announcement Mar 29 05:18:04 mangix: ping Mar 29 05:18:16 since you merged this ninja patch, do you see any change in building speed/ Mar 29 05:38:19 aparcar[m]: I provided some numbers in that PR..” Anyway, I build with ccache so any numbers I post would not be representative. Mar 29 05:38:35 I see Mar 29 05:38:40 are buildbots running without ccache? Mar 29 05:42:01 They are Mar 29 05:42:39 ccache is not enabled by default anywhere **** BEGIN LOGGING AT Mon Mar 29 06:28:42 2021 Mar 29 06:51:28 ynezz: I am working on fixing procd right now and I can't believe that code is actually in use. There are balatant problems like at least one use after free, problems with signedness, and use of stack variables in a global variable. The CI tells me about them. How did that not get fixed before the code was used?! Mar 29 07:07:18 probably because the developer didnt want to invest time in setting up a CI, learn the configuration etc. Mar 29 07:08:36 in-tree documentation is missing too from procd Mar 29 07:08:48 so much to do and so little time Mar 29 07:27:05 plntyk: No, it's not CI specific. It's stuff that you get already when you compile with -Werror=sign-compare Mar 29 07:27:13 With -Wall specifically Mar 29 07:27:19 Generally I mean Mar 29 07:27:49 It's standard stuff you see if you care at all Mar 29 07:28:09 And the C functions with the stack variables and use after free are like 10 lines long only. Mar 29 07:28:15 It boggles the mind Mar 29 07:40:49 Thermi: I doubt anyone has looked at it honestly. Mar 29 07:40:56 Yeah. Mar 29 07:41:21 Pearls Mar 29 07:41:22 /builds/Thermi/openwrt-procd/service/instance.c:1362:15: error: comparison of unsigned expression in ‘>= 0’ is always true [-Werror=type-limits] Mar 29 07:41:32 Diamonds even Mar 29 07:43:27 Fortunately or unfortunately, there’s a lot of NIH code here. Mar 29 07:44:16 That's the first time reading NIH code Mar 29 07:44:18 what is that? Mar 29 07:44:29 Not invented here Mar 29 07:44:32 Ah Mar 29 07:44:33 I see. Mar 29 07:45:32 procd ubus uclient umdns etc... Mar 29 07:59:59 * rmilecki has pushed mtd update Mar 29 08:00:06 changes look more scary than they are Mar 29 08:00:12 still blame me for issus Mar 29 08:28:04 mangix: I wouldn't call it NIH. What were the alternatives at the time (and even today!) at the same footprint? Mar 29 08:32:58 Well... he specifically didn't say it is automatically bad thing :) Mar 29 08:34:52 NIH has a usually pejorative meaning, though… But in this case I really couldn't see any alternative. :) Mar 29 08:37:06 Maybe that's why he started with how he started ;P but yeah... peoples are hard, y0 =D Mar 29 08:41:09 let's see... procd->systemd. On my system the main executable is 1.7M, the shared libsystemd-shared-247.so 2.6M Mar 29 08:41:17 so this already exceeds the size of my entire openwrt rootfs Mar 29 08:43:13 ubus->dbus, main executable 240K, shared library 330K, also requires expat, lzma, zstd, lz4, libsystemd Mar 29 08:43:48 that's roughly another MB Mar 29 08:44:37 umdns->modemmanager, the ipk for modemmanager alone is ~1.2MB Mar 29 08:44:43 and it still requires dbus, glib etc. Mar 29 08:45:31 That reminds me… has anyone played already with dbus-broker? Mar 29 08:47:08 I tried it for the lulz on my Debian system, and it worked just fine, but somehow the at-spi-bus-launcher still invokes the original dbus daemon directly. Mar 29 08:53:36 mangix: ping Mar 29 08:57:02 anyone ideas why the call setupterm (ncurses) could fail on openwrt while it works on other distros? Mar 29 08:57:09 question into the blue Mar 29 08:58:00 aparcar[m]: missing terminfo maybe? Mar 29 08:58:11 define "fail" Mar 29 08:58:19 root@OpenWrt:~/keys# opkg install terminfo Mar 29 08:58:19 Package terminfo (6.2-1) installed in root is up to date. Mar 29 08:58:27 that's what i thought but it's installed... Mar 29 08:58:28 aparcar[m]: pont Mar 29 08:58:34 *pong Mar 29 08:58:44 aparcar[m]: our terminfo pacakge only ships a handful of terminfo defintions Mar 29 08:58:55 if you have anything exotic, it likely won't help Mar 29 08:59:04 mangix: I just wanted to bother you with the same question Mar 29 08:59:05 jow: good info, thanks Mar 29 08:59:22 rsalvaterra: I intentionally made no opinion on that. Mar 29 08:59:29 would be interesting to know what your $TERM is and what the failure is exactly ("could not find terminal"?) Mar 29 09:00:09 mangix: Yeah… I probably need to wait for the caffeine to kick in. :) Mar 29 09:00:12 root@OpenWrt:~/keys# echo $TERM Mar 29 09:00:12 xterm-256color Mar 29 09:00:26 that should be present though Mar 29 09:00:32 https://github.com/openwrt/openwrt/blob/master/package/libs/ncurses/Makefile#L123 Mar 29 09:00:33 jow: i'ts dying there https://github.com/tmate-io/tmate-ssh-server/blob/master/tmate-main.c#L283 Mar 29 09:01:22 aparcar[m]: ah, it'll try to load terminfo with "screen-256color" Mar 29 09:01:27 which we don't ship Mar 29 09:01:36 see https://github.com/tmate-io/tmate-ssh-server/blob/97d20249be029036e3301abf454df7dd0113ccb2/tmate-ssh-daemon.c#L171 Mar 29 09:02:09 Impressive code digestion Mar 29 09:02:30 how big is the size impact in case we add it? I can also just patch tmate-ssh-server Mar 29 09:03:07 aparcar[m]: if you have the few minutes, I'd suggest to introduce a new "terminfo-extra" pacakge which ships all terminfo files except the ones in line 123 here: https://github.com/openwrt/openwrt/blob/master/package/libs/ncurses/Makefile#L123 Mar 29 09:03:16 aparcar[m]: then simply make the tmate server depend on terminfo-extra Mar 29 09:03:55 a few days ago, someone in #openwrt complained about another missing termifo db for st-256color Mar 29 09:04:12 so I suppose it makes sense to have a complete terminfo available as installable package Mar 29 09:04:19 let me try, i need to catch up on terminfo anyway Mar 29 09:04:21 thanks for the quick pointers Mar 29 09:05:05 ohh st <3 Mar 29 09:05:27 however, given that we already ship s/screen one could argue that shipping s/screen-256color as well would make sense Mar 29 09:05:45 considering that we ship xterm, xterm-color and xterm-256color too Mar 29 09:06:24 i don't want to ruin rsalvaterra day by introducing all that by default Mar 29 09:06:32 or how much bytes are we speaking per profile? Mar 29 09:06:59 ~2KB per color variant, at least according to my desktop's /usr/share/terminfo/ Mar 29 09:07:39 aparcar[m]: No opinion there. :P Mar 29 09:08:28 What's the issue with the terminal type, exactly? Mar 29 09:08:59 there's software emulating a non-xterm-style terminal Mar 29 09:09:01 some minor terminal compatibility issues - "st" not working or so Mar 29 09:09:04 like tmate ssh Mar 29 09:09:11 or suckless terminal Mar 29 09:09:20 and we don't package profiles for them Mar 29 09:09:21 also "tmux" isnt working too for example Mar 29 09:09:42 plntyk: I use tmux all the time on openwrt Mar 29 09:09:44 we only cover dumb non-color GNU screen, dumb linux console and xterm compatibles Mar 29 09:09:59 jow: the full folder would be, tada, 12MB. Any ideas for a good selection? Mar 29 09:10:15 well xterm-256color is part of it Mar 29 09:10:16 12 MB, fml…! Mar 29 09:10:24 aparcar[m], over ssh it works i think but with for example qemu "normal" tty it doesnt Mar 29 09:10:27 the price of choice :P Mar 29 09:10:28 rsalvaterra: it's about compatibility Mar 29 09:10:40 So I just add this specific one? Mar 29 09:10:54 and maybe st? or is that a can of worms? Mar 29 09:10:55 aparcar[m]: hm, maybe grouped by family Mar 29 09:11:01 aparcar[m], using qemu with --nographic Mar 29 09:11:56 aparcar[m]: but maybe check how large these 12M are after gzip/lzma/zstd Mar 29 09:12:02 I could imagine a lot of redundancies Mar 29 09:12:31 jow: I was thinking the same… It all lives in squashfs… Mar 29 09:12:42 looks like there are 2822 profiles Mar 29 09:13:48 636K after tar.gz Mar 29 09:14:07 hm, still too much Mar 29 09:14:18 A lot more palatable, but still fat. Mar 29 09:14:20 something in the 20-30KB ballpark after gzip would acceptable I guess Mar 29 09:14:52 Wait, they're stored compressed? Mar 29 09:15:06 They should be uncompressed, for better squashfs compression. Mar 29 09:15:19 rsalvaterra: I'm just experimenting here Mar 29 09:15:32 ~/src/openwrt/openwrt/staging_dir/target-aarch64_cortex-a53_musl/usr/share/terminfo is where the fun begins Mar 29 09:15:41 Oh, right. Experiment away, then. :) Mar 29 09:16:14 so the one I'd add is 1.7KB... Mar 29 09:17:01 or 885 compressed Mar 29 09:19:11 wwjd? Mar 29 09:19:30 Turn water into wine? Mar 29 09:20:04 885 bytes is tempting. Mar 29 09:25:30 so tar czf test.tar.gz s/screen-256color s/st s/st-256color is about 2.1kb Mar 29 09:25:46 jow: should we just add that rather than adding a 12mb extra package? Mar 29 09:28:02 [A Mar 29 09:28:02 [A Mar 29 09:28:17 what are te "st" ones for/from? Mar 29 09:28:24 those are unfamiliar to me. Mar 29 09:28:34 simple term or something Mar 29 09:28:40 karlp: a project quite in the spirit of openwrt https://st.suckless.org/ Mar 29 09:30:11 just ran into a build problem on x86_64, something about elf, doing a make dirclean world to see if that clears it up Mar 29 09:30:32 russell--: there where some changes recently... maybe install libelf or something Mar 29 09:30:50 not entirely sure I'd compare that to openwrt, but thanks :) Mar 29 09:32:12 :) Mar 29 09:34:46 * russell-- stares a live volcano cam while build works away Mar 29 09:36:23 russell--: no ship cam? Mar 29 09:39:18 The suez canal one? Mar 29 09:41:21 I'll just leave this here… https://9gag.com/tag/evergiven?ref=related-tag Mar 29 09:44:27 Amusing Mar 29 09:45:34 The internet doesn't forgive. :P Mar 29 09:52:27 aparcar[m]: btw, elf changes related to your buildbots update? Mar 29 09:54:27 I was just thinking of you patch here https://github.com/openwrt/openwrt/pull/3855 Mar 29 09:54:32 but it's not yet merged so nevermind Mar 29 09:56:09 aparcar[m]: anyway libelf absence would only generate a kernel build warning on x86_64, not a failure Mar 29 10:01:07 guidosarducci: ack Mar 29 10:18:58 dirclean fixed my problem Mar 29 10:19:15 ah, I always wondered why bmon gives really garbled output on openwrt, maybe that's because I'm missing the right terminfo Mar 29 10:44:39 zorun: reviews welcoem Mar 29 10:44:44 ;) Mar 29 10:45:07 rsalvaterra: could you patch dropbear to use sha256 for key validation rather than sha1? Mar 29 10:47:09 aparcar[m]: Isn't it doing SHA-256 by default? Mar 29 10:48:16 https://github.com/mkj/dropbear/blob/master/signkey.c#L515 Mar 29 10:48:44 looks like it's either md5 or sha256. Not sure how relevant are fingerprint of ssh keys Mar 29 10:49:34 With ssh -v here… debug1: Server accepts key: /home/rui/.ssh/id_ed25519 ED25519 SHA256 Mar 29 10:49:51 maybe it's just a feature of dropbearkey Mar 29 10:49:59 Fingerprint: sha1!! c6:b7:cc:fb:39:79:5e:73:1b:66:49:b8:58:b2:b9:4d:96:02:28:1a Mar 29 10:50:01 Can you try on your side? Mar 29 10:51:33 However, note that I'm not running the default dropbear configuration. Mar 29 10:52:07 https://patchwork.ozlabs.org/project/openwrt/list/?series=220651 Mar 29 10:54:23 yea I remember... Mar 29 11:19:29 Thermi: yeah, patches welcome :) Mar 29 11:19:35 mangix: whatsup? Mar 29 13:39:44 aparcar[m]: dropear logs during auth? That just identifies which pubkey was used (see the `-E` option to `ssh-keygen` from OpenSSH.) That's just reference only, no bearing on the keytype you're using. Mar 29 13:39:48 dropbear* Mar 29 13:42:37 From your interactive Unix-host, try for example: for kt in md5 sha256; do find ~/.ssh -name '*.pub' -print0 | xargs -0L1 ssh-keygen -E "$kt" -lf; done Mar 29 13:43:31 (works for server keys too.) Mar 29 20:09:34 pekster: thanks Mar 29 20:14:51 Hauke: do you know if the reset bit (15) in GSWIP_MII_CFGp(p) is self-clearing? Mar 29 20:16:33 Hauke: background info: I am debugging with jwh why the two AR8030 PHY based LAN ports in the 7360v2 are deaf (no RX, no TX), while the two GPHY based ones are working fine. we already found the ISOLATE bit and cleared that, but that did not do the trick (yet) Mar 29 20:22:19 xdarklight: the documentation says "Read/write register with input from and output to hardware" Mar 29 20:22:33 so I think it is self clearing Mar 29 20:22:35 but I am not sure Mar 29 20:23:24 you could try it by setting it to 1 wait some ns and then read it back Mar 29 20:29:24 Hauke: thanks - I also checked the AVM kernel sources and there they're treating it as self-clearing with 100us delay after setting that bit Mar 29 20:32:14 do they do activly do changes to this register or is this the standard lantiq code? Mar 29 21:50:50 Hi did OpenWrt join the Free Software Foundation? Mar 29 21:52:13 Conservancy is not them rite? Mar 29 21:54:02 OK I have my ancer. https://sfconservancy.org/blog/2021/mar/23/outreachy-fsf/ Mar 29 21:57:20 Hauke: just checked, yes - it seems to be used (at least in theory. it's BSP code, so you can never be sure ;)) Mar 29 22:00:03 Tapper: SFC is not FSF right :) Mar 29 22:16:59 PaulFertser Cool. Mar 29 23:49:52 ugh how do I match against the BSDs? Mar 29 23:51:36 found it Mar 30 01:02:08 anyone else having issues with this new linksys 8450 device? Mar 30 01:02:09 * aparcar[m] < https://matrix.org/_matrix/media/r0/download/matrix.org/buABbMQRdsAZHPHHeShFkeCS/message.txt > Mar 30 01:02:48 ugh fu matrix Mar 30 01:02:49 https://paste.debian.net/1191614/ Mar 30 01:12:27 Does anyone know when Package/xxx i read in the build system? I've got conditional DEPENDS to try and keep the size down when certain options aren't needed.. I don't thik it would be read until make menuconfig is run again, which won't work. Mar 30 01:13:30 example, if the nflog option is selected, I want to add +libnet-1.2.x +libnetfilter-log +libnetfilter-queue +libnfnetlink to the DEPENDS so they get installed Mar 30 01:21:14 Grommish: what's the definition of "nflog option"? Config variable, KCONFIG, etc? Mar 30 01:22:17 guidosarducci: Suricata option, not kmod, but it means I need to add those above (for example) to Package/suricata6 DEPENDS so it gets installed properly Mar 30 01:22:42 I don't want to have the buid system install 4 packages if they aren't needed Mar 30 01:23:06 or like libmagic and file, which isn't needed unless suricata is built to be libmagic aware Mar 30 01:23:14 Grommish: so how do you define that Suricata option in our build system? Mar 30 01:24:25 guidosarducci: https://gist.github.com/Grommish/991cda34e5bc1cc23d63ddc4855a6372#file-gistfile1-txt-L51-L98 Mar 30 01:26:42 guidosarducci: But, it only seems to read the Package/suricata6 one time, so I'm not sure how to do it without being tacky and just adding everything Mar 30 01:33:18 Grommish: that's where it's used, I asked where it's defined. Is it in our build system? Sounds like no. Without a better picture of how things are set up and how they fail for you, difficult to help. Mar 30 01:34:43 The deps don't get set, so the build system doesnt pull in the additional libraries. I think it only reads the DEPENDS once, so I'm not sure how to introduce additinal depends based on the if the option that requires them is selected Mar 30 01:34:57 So, yes, I'm referring to the build system itself :) Mar 30 01:35:42 The way I linked, it added the CONFIGURE_ARGS without issues, but doesn't add th additiona DEPENDS to support that option Mar 30 01:42:31 guidosarducci: I echo out the SURICATA_EXTRA_DEPENDS as a sanity check, and it read as +luajit +libmaxminddb +libmagic +file +libhiredis +libevent2 +libnet-1.2.x +libnetfilter-log +libnetfilter-queue +libnfnetlink +luajit +libmaxminddb +libmagic +file +libhiredis +libevent2 +libnet-1.2.x +libnetfilter-log +libnetfilter-queue +libnfnetlink - but they aren't present **** ENDING LOGGING AT Tue Mar 30 02:59:56 2021