**** BEGIN LOGGING AT Wed May 27 03:04:13 2020 May 27 06:00:08 hm weird May 27 06:00:22 my x86 build after merging latest master is now building as x86-64-generic May 27 06:00:28 and sysupgrade is all image check failed May 27 06:12:30 looks like lots of changes there May 27 06:14:32 Wed May 27 02:09:46 2020 daemon.notice procd: /etc/rc.d/S50qos: Cannot find device "ifb0" May 27 06:14:33 =[ May 27 06:20:30 Wed May 27 02:10:17 2020 daemon.notice procd: /etc/rc.d/S99acpid: /etc/rc.common: /etc/rc.d/S99acpid: line 18: procd_send_signal: not found May 27 06:20:30 Wed May 27 02:10:17 2020 daemon.notice procd: /etc/rc.d/S99acpid: /etc/rc.common: /etc/rc.d/S99acpid: line 19: syntax error: unexpected "}" May 27 06:22:48 so much brokeness May 27 06:26:42 qos-scripts doesnt create an ifb device May 27 06:37:01 https://github.com/openwrt/packages/blob/master/utils/acpid/files/acpid.init May 27 06:37:03 wtf with ash and the \ May 27 06:51:09 soooo... how to get this system to stop reporting invalid image when i sysupgrade now... already hit it with -F, flashing same image still says invalid... May 27 07:11:45 "fwtool_signature": false, May 27 07:11:45 hm May 27 07:19:31 any idea why? something in last 90 days of changes :/ May 27 07:22:29 https://github.com/openwrt/openwrt/commit/b044b52ab9553b8d94cfc5565d2ea5013364159d#diff-4f4efa227c9da065c4f2908d54957bf3 May 27 07:22:31 https://github.com/openwrt/openwrt/commit/61e01f248eb22ea9a4cffa862218f47970f3ab2c#diff-4f4efa227c9da065c4f2908d54957bf3 May 27 07:22:32 hmf May 27 07:44:22 untrusted comment: signed by key 9ad32b16dee66895 May 27 07:53:51 what exactly is ucert checking May 27 08:06:07 hm, no ucert full, ucert doestn print any messages... fun May 27 08:08:32 https://git.openwrt.org/?p=project/ucert.git;a=summary lots of recent changes =[ May 27 08:09:45 maybe just the new signing for x86 that was added in april that's screwing me up :/ May 27 08:23:03 chain_verify: certificate expired May 27 08:23:08 * nyt dies May 27 08:23:30 weird not having error messages unless ucert full May 27 09:02:58 build #146 of lantiq/ase is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/lantiq%2Fase/builds/146 May 27 09:19:03 Hello! Few days ago I sent to mailing list two simple oneline patches for iwinfo: http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023479.html http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023480.html May 27 09:19:22 Could you please look at them? It is just update of hardware database May 27 09:42:04 jow: wasn't there a hidden ?json-targets command for downlaods.opewnrt.org to get all targets in json format? May 27 09:43:23 jow: just found it sorry https://downloads.openwrt.org/releases/19.07.3/targets/?json-targets. I have to start thinking 30 secs more before bothering you... May 27 09:44:37 hi there. since today I have some issues building openwrt. I'm getting syntax errors on tmp/.config-package.in for example May 27 09:44:47 and in there the dependency looks weird: "depends on PACKAGE_PACKAGE_wpad-wolfssl||" May 27 09:44:53 seems like those pipes shouldn't be there May 27 09:45:11 I'm wondering whether that broke with a recent update on my Debian Sid here May 27 09:46:42 T_X: i think || is pretty standard. you should pastebin/google your syntax errors. sometimes a make clean on a singular affected package can help as well. May 27 09:59:52 okay, we (or especially ecsv) narrowed the issue down to the update of "make" in Debian May 27 10:00:31 make 4.2.1-2+b1 works, 4.3-1 doesn't May 27 10:00:39 https://github.com/openwrt/packages/pull/12341 May 27 10:00:43 fix for broken acpid init May 27 10:02:49 one of the differences is that now in tmp/.packageinfo and tmp/info/.packageinfo-network_services_hostapd there is an extra space between wpad-mesh-wolfssl and wpad wpad-mesh-openssl May 27 10:03:06 tmp/.packageinfo:Conflicts: hostapd hostapd-basic hostapd-mini hostapd-openssl hostapd-wolfssl wpad wpad-mesh-openssl wpad-mesh-wolfssl wpad wpad-mesh-openssl wpad-mesh-wolfssl May 27 10:04:27 build #146 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/at91%2Fsam9x/builds/146 May 27 10:04:29 and we believe that the extra spaces is substituted with a "||" here: May 27 10:04:51 package/network/services/hostapd/Makefile: DEPENDS:=@$(subst $(space),||,$(foreach pkg,$(SUPPLICANT_PROVIDERS),PACKAGE_$(pkg))) May 27 10:05:05 build #145 of x86/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/x86%2F64/builds/145 May 27 10:08:35 any idea how I can add a bool in lua prmoetheus node exporter as label? May 27 10:08:44 build #145 of ipq806x/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/ipq806x%2Fgeneric/builds/145 May 27 10:09:24 build #145 of brcm47xx/mips74k is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/brcm47xx%2Fmips74k/builds/145 May 27 10:15:57 I'm doing something like this to export it local ht_support = (ap_table['ht_support'] == true) and 1 or 0 May 27 10:46:07 T_X: this issue has long been fixed May 27 10:47:24 T_X: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=766e778226f5d4c6ec49ce22b101a5dbd4306644 May 27 10:58:52 jow: oh, okay, thanks! and I see, it's been part of v19.07.2 May 27 11:28:59 hm, the built-in switch in my BT Home Hub 5a seems to be misbehaving. May 27 11:29:08 I have two other APs plugged in directly to it May 27 11:29:22 when a device roams from one to the other, the new AP doesn't get its packets. May 27 11:29:56 I can see them being sent if I tcpdump on the hh5a. Not received on the device that's plugged into the other end of the cable. May 27 11:36:04 jow: and yes, works like a charm. thanks again! :) May 27 14:39:54 can someone point me to docs or an example for building a "sub package" like tc (a part of iproute2)? May 27 14:44:16 hm, the wifi isn't coming up reliably either May 27 14:44:19 Wed May 27 15:38:06 2020 daemon.notice netifd: radio0 (3602): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe) May 27 14:46:53 Wed May 27 15:38:06 2020 daemon.notice netifd: radio0 (3602): Command failed: Invalid argument May 27 16:21:20 dwmw2_gone: did the switch in the BT HH 5a receive a packet with the source mac on the new port? May 27 16:21:32 if it receives it the mapping should be updated May 27 16:21:42 otherwise it expires after 5 minutes May 27 16:30:14 k, i guess the answer is you don't specify "tc" explicitly May 27 16:30:25 just make package/network/utils/iproute2/{clean,compile} seems to build it May 27 16:33:21 Hauke: It should have May 27 16:53:08 it's weirder than that actually May 27 16:53:17 Many DHCP offers aren't being seen May 27 16:53:31 shown by tcpdump on the router going out eth0.2 which is *only* the 'WAN' port. May 27 16:53:42 not seen in RX at the other end of that wire, and no dropped or bad crc May 27 18:05:51 jow: regarding this comment: May 27 18:06:02 > e.g. sprintf(lodev.name, "lo"); -> strlcpy(lodev.name, "lo", sizeof(lodev.name)); May 27 18:07:10 there are analysis tools that consider the lack of any %-specifiers as a security bug. May 27 18:37:47 I just managed to crash a 4019 QCA NIC so that the radio fell off the bus and will not recover. I think probably a power-cycle is required to recover, but the OS is working OK. Is there any existing framework to detect issues that require a reboot and automatically do the reboot? May 27 18:39:39 nope May 27 18:40:17 philipp64|laptop: I'd rather avoid optimizing the code for buggy security tools May 27 18:40:50 is there a general watchdog support that would power-cycle an AP if you get a more thorough lockup? May 27 18:41:13 well some/most targets have watchdog support, so the bort will reset if userspace ceases to function May 27 18:41:18 *board May 27 18:42:14 so maybe that watchdog could check for (or be told) of other reasons a reboot is needed, such as my case, and stop petting the watchdog in that case? May 27 18:44:07 that would be a large change May 27 18:45:11 right now procd is responsible for poking /dev/watchdog, it would either need to handover to something else or implement some kind of pluggable health check interface where you can register custom logic May 27 18:45:30 both is unlikely to happen on a short notice May 27 18:45:56 you're better off with having a custom monitoring daemon and triggering a panic through sysrq triggers I guess May 27 18:46:46 a simple shell while loop would probably do the job as well May 27 18:47:17 as long as there's some easy way to check for "fell of the bus" (sysfs? debugfs? lspci?) May 27 18:47:28 gcc will give such warnings with -Wformat2 … that’s not a buggy security tool. Nor are the MITRE 25 best practices… May 27 18:48:09 I consider a security warning for buggy May 27 18:48:28 philipp64|laptop: if format string is a string literal that has no % format specifiers at all then there's nothing to warn about in this regard. May 27 18:48:29 if "lo" were a variable, fair enough, but not for a constant expression May 27 18:48:34 lastly, the semantics of strlcpy() are exactly the right ones. it’s an operation that corresponds 100% to what’s trying to be done. sprintf() on the other hand isn’t a good match… there’s no formatting happening. May 27 18:48:55 at the very least, it would need to be: snprintf(lodev.name, sizeof(lodev.name), “%s”, “lo”); May 27 18:49:14 on my system there is no strlcpy() May 27 18:49:16 and that would be a much more verbose expression of what can be more concisely stated with the strlcpy(). May 27 18:49:37 and no, I don't want to link libbsd to fw3 May 27 18:50:58 PaulFertser: I didn’t write the logic of -Wformat2 … but there’s soundness to the reasoning. sprintf() has a lot more attack surface and using a “broad” function where a “narrow” one would do is taking extra risk. And security is an exercise in mitigating risk to acceptable levels. May 27 18:51:33 jow: MUSL provides strlcpy()… May 27 18:51:40 glibc not May 27 18:51:48 at least not in older versions May 27 18:51:48 jow, what if for very simple integration, procd checked for existence of a particular file, /tmp/__FUBAR_REBOOTME__ or similar. If found, it does its best job to first take the system down cleanly, and if that fails, then WDT will finish the job? May 27 18:51:53 and on systems that don’t, we could easily provide it. May 27 18:52:03 how old are we talking? May 27 18:52:34 debian sid May 27 18:53:08 sorry, are you talking about building or running? do you run fw3 on debian sid? May 27 18:53:14 yes May 27 18:53:27 glibc 2.30 May 27 18:53:57 openwrt uses glibc 2.27 (?) which is even older May 27 18:54:07 wheezy had it… odd that it wouldn’t be in sid. May 27 18:56:31 so if the patch included strlcpy() for systems not having it? May 27 18:56:47 it’s a 5 line function... May 27 18:56:54 so even more code for something I don't want May 27 18:57:14 then we probably need a cmake test too May 27 18:58:24 jow: can you please give me additional information how you build a release with the buildbot? Do you just extend the config seed with the option to but the version name into generated images? May 27 18:58:42 aparcar[m]: its all in buildbot.git, I do nothing specifically May 27 18:59:00 apart from manually scheduling a build with the property "tag" set to the git tag May 27 18:59:52 so the config_seed here is the very same? https://git.openwrt.org/?p=buildbot.git;a=blob;f=phase1/config.ini.example;h=eacf7a40b8e425108769b5be8b0d609810045166;hb=HEAD#l21 May 27 19:01:45 aparcar[m]: https://pastebin.com/8JRjrN6u May 27 19:02:17 jow: useful paper from the authors of sudo… https://www.sudo.ws/todd/papers/strlcpy.html May 27 19:02:39 please resubmit without strlcpy May 27 19:02:52 if anyone understands the tradeoffs of security… May 27 19:02:53 or use a define <#define strlcpy(d, s, l) snprintf(d, l, "%s", s)> if that makes your -wformat2 thing happy May 27 19:02:56 jow: thanks that's what I needed May 27 19:05:15 I also don’t understand the objection to fmemopen()… it’s a glibc-ism, it’s been around for years… surely it’s in Sid and everywhere else. May 27 19:26:08 the objection is invoking heaps of stdio code to print a couple of substrings into a buffer May 27 19:30:08 jow: do you see any chance for backporting JSON to 19.07.4? https://github.com/openwrt/openwrt/pull/3055 May 27 19:49:08 jow: shameless hijack but speaking of buildbot.git I don't see the 1-liner I sent you some months ago in there, normal? May 27 19:52:44 jow: without my patches: May 27 19:52:46 text data bss dec hex filename May 27 19:52:48 102140 2984 5168 110292 1aed4 firewall3 May 27 19:52:53 with my patches: May 27 19:53:05 102573 2992 5168 110733 1b08d firewall3 May 27 19:53:47 I’m not sure less than 500 bytes qualifies as “heaps of stdio code” but I guess we all have our individual thresholds... May 27 19:54:50 that’s on x86_64 with MUSL. on other systems with glibc it might be more. May 27 19:58:06 if glibc on master, fmemopen.c is 227 lines 57 of which are comments or #include's. May 27 20:27:42 philipp64|laptop: those are bsd guys in that paper May 27 20:28:13 the solution to this is C++ May 27 20:28:15 * mangix hides May 27 21:15:53 f00b4r0: what one-liner? May 27 21:55:12 jow: the one that fixed rsync failures not being reported May 27 21:55:17 i'll resend May 27 21:56:00 jow: resent to your email May 27 21:57:08 mangix: and? May 27 21:57:09 https://github.com/openwrt/openwrt/commit/5c2b130ec9b011691771cad2dab9994a66836a1a May 27 21:57:12 this commit breaks qos-scripts May 27 22:02:33 mangix: are they less legitimate if they’re from a BSD background? I was part of the 4.3BSD release at MIT… May 27 22:02:47 … yeah, I’m that old. May 27 22:47:07 they're naturally biased. anyway, I seem to be missing the original context. No idea why the strl* functions are being discussed. May 27 22:49:35 Ah this: https://patchwork.ozlabs.org/project/openwrt/patch/20200527195959.615-1-philipp@redfish-solutions.com/ May 27 22:51:57 I imagine strlcpy prevents some GCC optimizations since it's non-standard May 28 01:23:51 Hi, can someone help me with the following issue? I've noticed that `ubus call luci getInitList` command hangs forever on my openwrt-19.07.3-brcm47xx-mips74k-asus-rt-n16-squashfs.trx. The further investigation has shown that it hangs because of /etc/init.d/network script which calls /lib/functions/procd.sh. and that procd.sh hangs on line 55 (flock 1000) when 1000 corresponds to /var/lock/procd_network.lock file. Can anyone help May 28 01:23:51 to troubleshoot it? **** ENDING LOGGING AT Thu May 28 03:00:05 2020