**** BEGIN LOGGING AT Tue Jan 05 03:01:24 2021 Jan 05 07:54:20 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 98.4% packages reproducible in our current test framework.) Jan 05 09:25:30 Anyone have any issues with https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=b80d8600ed321df5a9941f17c63804a7cff5af77 ? Jan 05 09:28:23 As you may have guessed, this fixes building on macos - I should put that as additional info in the commit msg Jan 05 09:30:15 https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commit;h=08cedbdc294a46a3ec7a6241242b089a35327074 Jan 05 09:41:31 ldir: I imagine hwdata can be fixed Jan 05 09:44:56 hwdata itself doesn't need PKG_INSTALL Jan 05 09:45:06 or compilation actually Jan 05 09:49:45 I'd just like it to work, whatever the solution is in the end :-) Jan 05 09:54:34 Ah it's the '-T' option - typo, will fix Jan 05 09:55:37 no, I had it correct in the commit msg already - doh! Jan 05 10:17:56 ldir: meh. i'll probably fix it at some point. hwdata already has the needed files directly on the repo Jan 05 10:18:08 no configure/make/install needed. Jan 05 13:47:59 Hey, I have a question about using the imagebuilder and a locally built repo. I already have "src myrepo file:///a/b/c" and the Packages file is downloaded without a problem. But then it tries to do a signature check. Is there any way to disable the signature check? Jan 05 13:56:04 not sure what you mean but maybe add "PKG_MIRROR_HASH:=skip" to the package Makefile? Jan 05 13:58:02 probably not what you are asking Jan 05 13:58:40 No, the packages themselves are building just fine. I'm using the sdk for that. I also have generated the Packages and Packages.gz files with the sdk. When I use the ImageBuilder to source in my local repo, it pulls the Packages.gz from all the standard repos and from my local repo. Additionally it checks the Packages.sig file, which fails only Jan 05 13:58:41 on my local repo. But thanks for the suggestion. Jan 05 14:02:49 ok sry I dont know that, i just enclose the package directly with IB like so: make image PACKAGES="/home/grift/openwrt/bin/packages/target/custom/package.ipk" Jan 05 14:02:53 maybe someone else knows Jan 05 14:09:05 pmelange: check /etc/opkg/keys/ Jan 05 14:09:12 that's where the signatures are Jan 05 14:10:38 Yes, on a running system. But that is also not what I'm looking for. I want to create an image with my custom repo and some of the packages within. Jan 05 14:13:03 Since I'm tired of figting against the imagebuilder, I'm just building all the packages needed for my target with the SDK and creating an image with that. It seems kinda pointless though. I'd rather use the prebuilt packages provided by openwrt whenever possible. Jan 05 14:13:39 you're using the sdk to include packages into the image, right? Jan 05 14:14:29 I'm using the SDK to build the packages as a local repo, then I want to use the imagebuilder to make the images including the previously built repo. Jan 05 14:27:31 pmelange, scripts/sign_image.sh ? Jan 05 14:28:55 That is how the generated images get signed :) But thanks for the suggestion. Jan 05 14:36:28 you can disable the signature check in .config Jan 05 14:36:49 CONFIG_SIGNATURE_CHECK=y Jan 05 14:42:55 I set it to CONFIG_SIGATURE_CHECK=n and I still have signature checks :/ Jan 05 14:44:36 look around in that file Jan 05 14:44:45 if you want symbol disabled it shouldn't be set Jan 05 14:44:48 I also tried setting CONFIG_SIGNED_PACKAGES=n. Jan 05 14:44:54 https://pastebin.com/CLe7ypjy Jan 05 14:45:35 Also tried commenting it out. Still doing the sig check Jan 05 14:49:45 I'm not using IB, so just guessing Jan 05 14:50:05 have you tried to disable the `option check_signature` in repositories.conf? Jan 05 14:50:13 Thanks for the suggestions Jan 05 14:51:36 pmelange: option check_signature is repositories.conf should do the trick Jan 05 14:52:14 Yes, that was it. Thanks for the great tip. Now how about adding that to the wiki? Jan 05 14:59:19 wiki's editable by everyone, if you register an account Jan 05 15:06:14 Thanks everyone for your support. I'm going to work on testing the new image. Jan 05 15:20:41 dangole sorry about loong time... If still relevant test the ppc stuff, now I have device literally at hands now :) Jan 05 15:21:03 olmari: yes, very relevant :) Jan 05 15:21:45 olmari: please update to latest snapshot and install packages 'procd-ujail' and 'procd-seccomp' (the latter only if available on that platform) Jan 05 15:21:45 dangole: aight, I shall wait AP 1 build to finish then take detour with wdr4900 Jan 05 15:54:40 anyone any idea if something changed to the imagebuilder? Jan 05 15:54:59 I'm playing around with master again these days and noticed this when issueing make package_index Jan 05 15:55:04 Generating index for package ./kmod-wireguard_5.4.86+1.0.20201112-1_mips_24kc.ipk Jan 05 15:55:05 Cannot open file '/home/koen/firmware/cus_31013/openwrt-imagebuilder-ath79-mikrotik.Linux-x86_64/key-build' for reading Jan 05 15:55:07 Makefile:135: recipe for target 'package_index' failed Jan 05 15:55:08 make: *** [package_index] Error 1 Jan 05 15:55:32 PaulFertser, adrianschmutzler, dangole, look at that. sweet :). and here i had spent some time today making the suggested changes Jan 05 15:57:32 dangole: Anything else there to test when device is up and installed? I remember do check something, but generally like "does it internet" and whatnot specifics? Jan 05 15:59:28 aparcar[m]: Any idea regarding avove? Jan 05 15:59:39 adrianschmutzler, i was a bit perturbed by your suggestion to remove the "SOC"-part of the makefile since that'd become an issue during build Jan 05 15:59:42 as I notice you comitted some patches for the imagebuilder Jan 05 16:01:31 dangole, also, since the dts has been changed to remove the underscore for the usb leds, i have a feeling that 01_leds should be updated? Jan 05 16:04:19 "16:59 shibboleth: adrianschmutzler, i was a bit perturbed by your suggestion to remove the "SOC"-part of the makefile since that'd become an issue during build" Jan 05 16:04:27 don't understand what you are referring to Jan 05 16:05:40 well, i ran a test to be sure: https://paste.debian.net/hidden/f81fc11d/ Jan 05 16:05:59 Qt's decision to restrict access to (security-)fixes for respective LTS versions to commercial users only is a real downer. I wonder how Debian is dealing with it, given they the amount of Qt based software Jan 05 16:06:46 err, I never suggested to remove the SOC variable Jan 05 16:06:52 aparcar[m]: I notice the file key-build is present in the actual openwrt root folder after building, but it's not present in the generated imagebuilder.tar Jan 05 16:07:11 I think this is a bug and it should be included also inside the imagebuilder.tar ? Jan 05 16:07:24 I suggested to either use tplink,ad7200-v1 or drop DEVICE_VARIANT Jan 05 16:07:44 while BOARD_NAME and SUPPORTED_DEVICES need to be dropped Jan 05 16:11:42 well, i went by https://paste.debian.net/hidden/16578840/ Jan 05 16:11:51 still, i may have read too much into it Jan 05 16:16:32 in any case, i'm assuming 01_leds should be updated to reflect the changes to the dts? Jan 05 16:16:51 yes, without having looked at it Jan 05 16:17:27 i will have a look later and maybe fix it myself Jan 05 16:17:38 alright, i'll forward it to dangole since hes able to commit for review Jan 05 16:28:04 shibboleth, adrianschmutzler: fixed the names in 01_leds Jan 05 16:28:14 ty Jan 05 16:32:11 looks like it's finally done then. been a while since https://github.com/seemoo-lab/lede-ad7200, but still: huzzah Jan 05 16:40:02 dangole: dude... I do not know what to say... I do NOT have wdr4900, thus no correct target here... I know I _had_ some, but apparently device is swapped with archer c7 at some point because that was needed here and ppc with it's double 11n was beter suited other location Jan 05 16:40:49 -_- Jan 05 16:40:57 wasn't there a owrt mug with wdr4399/4900 that limited txpower? Jan 05 16:41:03 bug Jan 05 16:41:19 shibboleth: I remember the 3700 one which was due to not properly flipping the PAs on all the anntennas Jan 05 16:41:21 or was it 3600? Jan 05 16:41:23 olmari: thanks for getting back and remembering anyway, i'll have to find some other potential PPC-target-owner to test ujail... Jan 05 16:41:34 iirc the 3600/4300 Jan 05 16:41:44 same device, except for the extra antenna Jan 05 16:41:51 dangole: well I know where the device is, but makes no go for immediate testing Jan 05 16:42:02 dangole: I own MX60 (apm82181), HiveAP 330 (mpc85xx) Jan 05 16:42:04 and my recollection is that the 4900 is very similar Jan 05 16:42:33 by test you mean what -- boot staging initramfs and install the packages? Jan 05 16:42:38 (and test them, presumably?) Jan 05 16:42:38 3600/4300 and then archer c2 is arm something something Jan 05 16:42:49 4900 is ath wifi but PPC cpu Jan 05 16:43:10 right. same radio iirc Jan 05 16:43:44 and dangoles test was specifically test some process jailing or whatnot on PPC :) Jan 05 16:44:08 sorry, i read "double 11n was beter suited other location" as better wifi perf Jan 05 16:44:16 tho if there is WRD4300 or archer c2 related testing, both I could do exactly now :D Jan 05 16:45:04 shibboleth: well... basically "worse" wifi by paper specs, but the cabin it is hauled now does not need ac wifi, while this house benefits from that, hence swap Jan 05 16:46:11 well, you'd be lucky to hit 5mbps openvpn on the 4300, presumably the 4900 fares better Jan 05 16:46:17 but if there exist openwrt buld for hurricos device(s), I'd be so happy if he would test it Jan 05 16:46:22 anyway, i have a feeling this is offtopic :) Jan 05 16:47:03 shibboleth: I know neither of these are powerhouses in those regards... but at these locations they perform very suitably for their respective needs Jan 05 16:47:07 shibboleth: kinda :P Jan 05 16:47:31 yeah, at least now that the aforementioned bug was corrected Jan 05 16:50:32 dangole: for whatever it's worth, I know there is propably no business on the cabin before some months, especially that I cna't do this remotely Jan 05 16:50:50 hurricos: if you are willing to install latest snapshot on either of them and also install procd-ujail and procd-seccomp as well as umdns, that'd be a great help Jan 05 16:51:05 or I mean... can, could... but should is very different Jan 05 16:52:54 hurricos: once procd-ujail and procd-seccomp are installe, dnsmasq should be mountns jailed, busybox-ntpd should run non-root with capabilities and umdns should be seccomp jailed after the next reboot. just see if all three services come up and work as expected. Jan 05 17:07:22 Hello all!! Jan 05 17:07:25 noltari: ping Jan 05 17:11:00 yellow Jan 05 17:18:05 Borromini: hi!! Jan 05 17:20:14 BTW, for whomever listened me looong time ago.. thank yo... "firewall" is no longer practically mandatory in menuconfig :) Jan 05 17:20:53 Had eve nforgot I made noise about it once, but now in the menuconfig I see I can untick it Jan 05 17:21:09 Awesome for AP use here :) Jan 05 17:21:51 olmari: i just disable it on my APs Jan 05 17:25:43 mm well... Fortunately nowadays not THAT big of an issue, but wouldn't be first time need to compile in just that much stuff that I needed desperately to find things to drop... firewall was one of them, exept it was not easy "an yar ago" Jan 05 17:26:12 ynezz: i'll continue in here because biot doesn't like the openwrt so much in #rtl83xx Jan 05 17:26:31 Plus at places I don't wanna put anything in that over-eager but know-nothing scriptkidides wanna conf stuff and block stuff out Jan 05 17:26:34 ynezz: bmork's observation on the realtek target breakage is here: https://forum.openwrt.org/t/support-for-rtl838x-based-managed-switches/57875/228 Jan 05 17:27:39 ..I also know mine wish is propably the one sad man that swims towards tides, but I still appreciate menuconfig working in sane manner with this one too, so, thank you still :P Jan 05 17:30:41 now... the age old WirelessAPD menuconfig mess question... :P Jan 05 17:30:42 anyone wanting to have some fun with me on bcm63xx? Jan 05 17:31:01 dows wpad-openssl include wpad-mest-openssl Jan 05 17:31:06 mesh* Jan 05 17:31:18 despite tree structure it is presented in Jan 05 17:32:58 I'd say "full" (in the description" means "everything is included", but also as I select one, I can't make other one as <*> Jan 05 17:33:12 thank you or listening and mental support ;P Jan 05 17:43:11 you can have them all if you just use Jan 05 17:43:23 or whatever the sign for modular is Jan 05 17:50:11 Borromini: I know that, rootissue was that I wanted em all in system, not as modules in server... answer wasn't obviously clear from looking at the menu, but selection behaviour confirmed at latest that how it is... sure the one selection did mention "full" somewhere in description too, which I did not see at glancing :) Jan 05 18:34:25 noltari: I am having no luck with nmrp to e.g. load regular firmware, even tough it communicates. i have the CFE web interface available, but don't know exactly what image it expects, I'll try later to build something Jan 05 18:43:39 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 98.1% packages reproducible in our current test framework.) Jan 05 18:49:35 Preliminary report, master from not 2h ago: Jan 05 18:49:43 * check_data_file_clashes: Package libustream-openssl20201210 wants to install file /home/olmari/sorsat/openwrt/build_dir/target-mips_24kc_musl/root-ath79/lib/libustream-ssl.so Jan 05 18:49:43 But that file is already provided by package * libustream-wolfssl20201210 Jan 05 18:49:43 * opkg_install_cmd: Cannot install package libustream-openssl20201210. Jan 05 18:50:39 Did choose luci-ssl-openssl, nothing else on luci menuconfig Jan 05 18:53:56 xback: key-build is a private you ideally distribute as little as possible Jan 05 18:54:14 however the imagebuilder creates it's own key pair, if desired Jan 05 18:58:30 I did not have chosen "backend tls provider" (or what was it exactly), I'll make clean and try again if that makes difference Jan 05 19:10:40 ..nope, that alone did not help, I wonder what else is choosing what in those conflicting stuff Jan 05 19:54:38 okay, libraries has those libustream-openssl and -wolfssl... openssl was force-selected (because luci-ssl-openssl I think), but wolfssl was not deselected... is manually deselectable though.. so current master has tha deficiency, how ever that should or could be circumvented (I'd say also regression as this is new to me in this context) Jan 05 19:59:41 ^ on menuconfig Jan 05 20:43:11 Hi there Jan 05 20:44:56 I guess I would need some help 😅 Jan 05 21:09:55 someone might help me in understanding some properties like CFE_WFI_VERSION or CFE_WFI_FLASH type? Jan 05 21:19:41 olmari / dangole: I was afraid to ask for help actually running something using those packages. So by default you just have normal system services running non-root? Jan 05 21:21:28 I'll boot up an initramfs each on amp821xx and mpc85xx tonight Jan 05 21:21:37 (and see if they work) Jan 05 21:22:05 in like an hour if I get my way. Jan 05 21:22:58 @freenode_hurricos:matrix.org: While I know exactly as much as you do what to do at face value, but yes, for testing what is asked to confirm em working, would be indeed plain normal _snapshop_ version of mpc85xx openwrt build, and then install those packages mentioned (will need device to have internet or othermeans of providing packages to it) Jan 05 21:23:12 but starting point is default openwrt indeed Jan 05 21:23:19 while snapshot version Jan 05 21:23:19 olmari: not sure if it will help but I just today discovered this great guide for maintaining configs as a diff: https://openwrt.org/docs/guide-developer/build-system/use-buildsystem#configure_using_config_diff_file Jan 05 21:23:58 I have a 24 core Westmere server which takes 15 or so seconds to render `make menuconfig` which is fun when you accidentally close it all the time Jan 05 21:24:19 olmari: sounds good Jan 05 21:25:12 AFAIK nothing in configwise is needed to be tested... but function test that "jailing" stuff works in MPC85xx as intended (like describer by dangole ) Jan 05 21:25:40 in theory it should be fast test... would.. if I ever have access to the damned elusive MPC85xx device :D Jan 05 21:25:45 was just mentioning it as you were talking about futzing w/ menuconfig Jan 05 21:26:18 olmari: Aerohive HiveAP 330 is cheap, my work still uses them and I snagged a few "" dead "" ones Jan 05 21:26:25 hurricos: well those are well separate things... irrelevant to that specific test that is wanted to be done with that specific CPU / target platform :D Jan 05 21:26:35 oh right right. Jan 05 21:27:42 P.S. I usually use ./scripts/env to maintain different device setups on same buildroot Jan 05 21:59:05 dangole: what could possible go wrong. "PCIE over 60g". that's what dell / lenovo is using. Jan 05 21:59:16 "i guess.." Jan 05 22:09:16 lynxis: just out of curiosity, what actual performance can you achieve over 802.11ad? (I know, range and oxygen penetration of the signal are a problem - just curious what you can get at an arm's length) Jan 05 22:10:00 pkgadd: between 860mbit (uni directional) -> ~1gbit (two ways at the same time). Jan 05 22:10:18 ping is really weird because of aggregation without any load :) Jan 05 22:11:38 this is with wil6210 firmware 5.x and generic boardfile. mikrotik has firmware 6.x Jan 05 22:12:22 nice, so in the rough realm of 802.11ax (I've seen ~930 MBit/s between BCM43684 and QCN5054, limited by my 1000BASE-T ethernet) Jan 05 23:01:14 dangole, owrt.org sysupgrade, factory image confirmed working Jan 05 23:04:05 shibboleth: on the talon? Jan 05 23:04:15 mhm Jan 05 23:04:25 802.11ad ap up and running Jan 05 23:05:01 iwinfo output is ofc lackluster, did not figure out how to apply dangoles patch to master in a hurry Jan 05 23:11:19 lynxis, also, i've been using one in production for months at this point, the patch was first submitted in october, i believe Jan 05 23:14:32 shibboleth: i've just tested everything extensively on lynxis hardware and another non-AD dakota device, pushed everything to master Jan 05 23:15:55 shibboleth: ie. tomorrows snapshot for the ad7200 device will have all 802.11ad-related issues I've found in rpcd and iwinfo fixed Jan 05 23:16:17 sweet. i've got a sep commitment for this evening but i'll report back tomorrow Jan 05 23:19:53 any idea on how I might create a smaller jffs2 images? the build system creates 64MB images by default, I would need something smaller I guess Jan 05 23:50:43 dangole: ping Jan 06 00:15:04 pkgadd: Don't forget though. 11ax has interference. One single 11ad channel is 2160MHz wide (`iw reg get`) Jan 06 00:17:56 shibboleth: Cool! You can get QCA9462+wil6120's for like $10, but you need the wil6110 for the actual RF. Found that out the hard way last year :'( Jan 06 00:18:34 or I guess in 2019. Jan 06 01:58:44 I mean if you can get it for cheap and it fills a need for a short point to point link that you can't cable for some reason Jan 06 01:59:35 interference must be brutal though **** ENDING LOGGING AT Wed Jan 06 02:59:58 2021