**** BEGIN LOGGING AT Wed Sep 30 02:59:57 2020 Sep 30 05:25:42 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_tegra.html has been updated. (0% images and 99.7% packages reproducible in our current test framework.) Sep 30 08:32:47 Grommish: what's the rust tool you're trying to port to openwrt? Sep 30 08:39:29 aparcar[m]: I'd get rid of the archs buildbot. It's not terribly useful Sep 30 08:39:59 didn't detect just yesterday some powerpc trouble? Sep 30 08:40:16 archs is not powerpc Sep 30 08:40:26 erm, arc_archs Sep 30 08:40:30 oh archs Sep 30 08:40:42 PRs welcome Sep 30 08:40:46 ^^ Sep 30 08:41:10 ARC in OpenWrt basically has no devices. It's only useful for uClibc-ng. Sep 30 08:41:35 aparcar[m]: https://git.defensec.nl/?p=selinux-policy.git Sep 30 08:41:49 will test it and if it works submit a PR Sep 30 08:42:00 gitweb can render markdown? Sep 30 08:42:23 html Sep 30 08:42:30 oh uh nevermind Sep 30 08:42:46 cool yea ping me in the comments Sep 30 08:44:20 aparcar[m] Hey Sep 30 08:44:41 aparcar[m] originally, Suricata. however, the issues with rustup means I'm going to source Sep 30 08:44:59 I swear rust hates anything not x86 Sep 30 08:47:08 hehe Sep 30 08:47:11 okay then nevermind Sep 30 08:47:27 aparcar[m]: should we get rid of CircleCI? Sep 30 08:47:35 I ported apk to OpenWrt and was wondering if their suricata port works on OpenWrt, but I wasn't really serious Sep 30 08:48:07 mangix: Not sure how long GitHub actions stay free Sep 30 08:48:41 hmm good point. It does bother me that CircleCI cannot build Boost Sep 30 08:49:14 I wonder if travis can Sep 30 08:50:51 aparcar[m] What's up? Sep 30 08:51:38 oh wow. GitHub has a code scanner. Sep 30 08:51:59 mangix: the migration to a new CI took me about two hours, mostly because I build this GitHub action SDK. I guess once GitHub starts causing trouble we are the next day on GitLab Sep 30 08:52:25 so feel free to drop CircleCI, except for the fancy colours the features should be the same Sep 30 08:52:34 mangix: the Security one? yeah Sep 30 08:53:00 it's so slow though it's not practical Sep 30 08:53:43 github tells me I have a problem. Sep 30 08:53:54 neheb 1,943 commits Sep 30 08:54:09 I understand that most of those are merge commits but still. Sep 30 08:54:15 could be a shared library Sep 30 08:55:01 something you forked.. I've many a DMCA removal for blobs I forked from someone else Sep 30 08:55:42 aparcar[m]: does openwrt have secilc already? Sep 30 09:13:27 huh. didn't know foxconn bought belkin Sep 30 09:31:11 grift: nope Sep 30 10:26:52 I would like to use libn32 full. I enabled it with make menuconfig, but I also had to patch hostapd (see https://paste.ubuntu.com/p/Qb9qb3yd4W/) is that right?!? Sep 30 10:27:57 and I also patched hostapd to support GVRP and MVRP when using dynamic vlan assignment Sep 30 10:31:57 hostapd vlan gvrp patch: https://paste.ubuntu.com/p/ykNdTj3myX/ Sep 30 11:12:31 jow: https://github.com/openwrt/luci/issues/4467 Sep 30 11:12:32 maybe it's a matter of sending POST request somehow early in the page loading process? Sep 30 11:12:55 maybe the first POST request triggers something in uhttpd behavior and breaks one of following GET requests? Sep 30 11:50:31 rmilecki: or it messes up rpc.js internal state Sep 30 11:51:14 i don't know much about it, but uhttpd hanging with connection open for 20 seconds - sounds like uhttpd issue to me Sep 30 11:53:38 rmilecki: is it actually a hanging request from the browser pov? Sep 30 11:55:00 Yes Sep 30 11:55:05 jow: see attached screenshot Sep 30 11:55:42 jow: it's always ~20 seconds which matches http_keepalive Sep 30 11:56:17 ah ok Sep 30 11:56:28 I was just looking at the github notification in thunderbird Sep 30 11:56:48 confirmed, i changed http_keepalive to 10 and chromium reported uci.js request to take 9.80 s Sep 30 11:57:22 anf after that timeout the request is failing? Sep 30 11:57:39 or suceeding? Sep 30 12:05:16 succeeds Sep 30 12:05:25 status 200 Sep 30 12:05:49 full content transferred Sep 30 13:20:59 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_mediatek.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Sep 30 17:16:23 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Sep 30 20:11:23 aparcar[m]: ill look into two of the requested changes tomorrow. although i personally feel that a mirror hash feels kind of redundant with https:// Sep 30 20:17:44 https provides no integrity guarantees Sep 30 20:18:13 and a mirror hash does? i guess i am misunderstanding it then Sep 30 20:18:27 https:// does provide authenticity Sep 30 20:19:00 it just means that one of the hundred CAs in the OS keystore signed a certificate that happens to match the requested domain Sep 30 20:19:28 whether the file you're downloading via such a connection is the expected one is another matter Sep 30 20:19:43 ok Sep 30 20:24:38 the buildsystem will produce reproducable tar.gz archives from Git clones and the build infrastructure uploads these generated tarballs to the sources download server Sep 30 20:25:11 i see, i was wondering how that works Sep 30 20:25:16 by setting PKG_MIRROR_HASH in a package makefile, buildroot can attempt to fetch the pregenerated source tarball from the openwrt mirror first without having to reclone the git repo Sep 30 20:25:17 thanks for clarifying Sep 30 20:25:36 the sha256sum ensures that the tarball matches the expected source Sep 30 20:25:58 if for whatever reason the hash fails to match, the downloaded .tar.gz is discarded and the upstream repo is cloned instead Sep 30 20:26:40 this should not happen usually but it does occur occasionally if bugs occur. E.g. for a while GNU tar generated different tarballs for clones containing symlinks under OS X and under Linux Sep 30 20:26:53 because OS X has per-symlink permission modes while Linux always encodes 07777 Sep 30 20:26:59 *0777 Sep 30 20:28:16 makes sense Sep 30 20:32:33 rmilecki: I think I found another bug Sep 30 20:32:51 jow: hit me Sep 30 20:33:04 sec Sep 30 20:35:02 rmilecki: in 11723570af9cb7bd87842e79c85ee99530be9902 ("ubus: add new RESTful API") you changed uh_ubus_request_data_cb() and replaced `blobmsg_add_field(&du->buf, BLOBMSG_TYPE_TABLE, "", blob_data(msg), blob_len(msg));` with `blob_for_each_attr(cur, msg, len) blobmsg_add_blob(&du->buf, cur);` Sep 30 20:35:36 however I don't think the new code is equivalent Sep 30 20:38:40 jow: i don't exactly remember how those callback work now (what do they do) Sep 30 20:38:53 jow: can you give some request example that was changed by my commit? Sep 30 20:39:05 jow: so I have something to test & work on recovering previous behaviour Sep 30 20:39:12 nevermind, I think it is a red herring Sep 30 20:39:40 anyhow I was trackign the "Unable to save contents: Unexpected reply data format" errors in luci and tracked it down to a changed response format Sep 30 20:40:17 it is now replying with `[{"jsonrpc":"2.0","id":5,"result":[0,{}]}]` while previously the reply was `[{"jsonrpc":"2.0","id":5,"result":[0]}]` Sep 30 20:40:33 note the superfluous empty object, this is confusing fs.js Sep 30 20:40:49 the actual underlying ubus call produces no reply at all, just an UBUS_STATUS_OK Sep 30 20:41:11 (compare `ubus call file write '{ "path": "/tmp/test.txt", "data": "Hello world" }'` on the cli) Sep 30 20:41:46 that sounds likely Sep 30 20:41:50 should we recover old behaviour? Sep 30 20:41:55 jow: when the mirror hash is wrong it will fall back to source download? Sep 30 20:42:02 or make LuCI deal with the missing {} ? Sep 30 20:42:07 at first I though the object is set but empty due to some blobmsg_*() vs. blob_*() confusion Sep 30 20:42:17 but I forgot that this particular call does not produce any response at all Sep 30 20:42:37 ah, ok Sep 30 20:43:10 rmilecki: I think we should revert to the old behaviour Sep 30 20:43:32 also in JS it is a tad easier to check for payload == null compared to isEmptyObject(payload) Sep 30 20:44:02 and any existing code performing strict format checks (like fs.js) will trip over that changew Sep 30 20:44:05 -w Sep 30 20:44:13 ok Sep 30 20:44:38 I was also attempting to debug that hanging requests things Sep 30 20:44:40 i'll try to restore that bahviour tomorrow, i'm not sure how much time i'll have for work Sep 30 20:44:47 which is really strange Sep 30 20:44:49 i may finish that on Friday Sep 30 20:44:54 did you find anything? Sep 30 20:44:58 at first I though it is related to multiple concurrent connections Sep 30 20:45:19 me too, but increating allowed amount didn't fix it Sep 30 20:45:25 *inceasing Sep 30 20:45:27 but when adding debugging on the uhttpd side, I noticed that in fact all requests happen via the same persistent tcp connection (good) Sep 30 20:45:28 nvm :p Sep 30 20:46:00 and while that one requests is "hanging" on the browser side, various other requests happen in between on the very same connection Sep 30 20:46:08 and they are all sucessfully replied to Sep 30 20:46:23 uhttpd itself also only "sees" the hanging request after 20s or so Sep 30 20:46:39 so it is not a case of accept()'ing a client and then not serving it for whatever reason Sep 30 20:46:54 but the request isn't actually received (possibly not even sent) by the browser in the first place Sep 30 20:48:31 and all those subsequent requests couldn't possibly have been served correctly if that one hanging request would indeed have been sent to uhttpd but not been replied to Sep 30 20:48:58 so somehow the browser side scheduling of the requests is messed up Sep 30 20:49:33 this is getting interesting Sep 30 20:50:43 and yeah, it correlates to http-keepalive Sep 30 20:50:58 to the http-keepalive timeout value rather Sep 30 20:53:57 rmilecki: can you explain me please in 2 sentences what you're working on? I keep reading this Browser stuff and wonder what is actually going on Sep 30 20:54:44 aparcar[m]: i added new RESTful API to uhttpd ubus, so requests look a bit nicer and it's possible to support new formats, like EventSource format for getting ubus notifications in browser Sep 30 20:56:00 new EventSource('http://192.168.1.1/ubus/subscribe/foo') Sep 30 20:56:03 cool! Sep 30 20:56:07 thanks Sep 30 20:56:12 np Sep 30 20:58:05 rmilecki: https://paste.pics/A9RGF Sep 30 20:58:26 see the transition from t=9716 to t=29704 Sep 30 20:59:11 oh my Sep 30 21:00:01 jow: let me just ask: what does it mean? Sep 30 21:00:29 browser can't read headers? Sep 30 21:00:40 connection timeout/close while reading response headers Sep 30 21:00:52 uhttpd on the other side: https://pastebin.com/AVCravuM Sep 30 21:01:18 note how the client address doesn't change, so form uhttpd's pov it is serving the same tcp connection Sep 30 21:01:59 you can see in line 59 that the menu request is interleaved with a bunch of other ubus requests Sep 30 21:02:13 while the browser already claimed to have waited 20s Sep 30 21:03:45 so is that a problem with uhttpd not sending headers if it gets GET between POST requests? Sep 30 21:04:11 so far uhttpd is not even "seeing" the request the first time the browser tries it Sep 30 21:05:07 ah, it's the second request we see on uhttpd side Sep 30 21:05:36 right Sep 30 21:06:24 maybe uhttpd's state machine got out of sync somehow Sep 30 21:07:18 so it simply "forgot" about that particular request while answering subsequent ones... but iirc that shouldn't even be possible in a keep-alive conneciton because browsers to not send the next request after the previous one concluded Sep 30 21:07:29 *do not Sep 30 21:07:34 *before the Sep 30 21:12:29 if it's HTTP/1, indeed, you cannot reply out-of-order Sep 30 21:12:58 let's not ever think about HTTP 2 Sep 30 21:13:33 I am guessing uhttpd doesn't support HTTP/2 ;) Sep 30 21:14:21 right, i meant - let's never consider implementing HTTP/2 ;) Sep 30 21:15:06 well, we have libraries in core for it... :) Sep 30 21:16:11 jow: what is the "req=" in your log? Sep 30 21:16:23 zorun: request counter Sep 30 21:16:49 ah ok, it's per-connection Sep 30 21:17:25 yes, the menu request happens to be the 19th one over this particular connection Sep 30 21:18:21 jow: did you re-do your tests? is that always 19th (indexed)? Sep 30 21:19:15 rmilecki: nope, not always the 19th Sep 30 21:19:30 right now it was the 7th Sep 30 21:19:36 ok... Sep 30 21:19:44 however from the browser side it seems clear that uhttpd is not responding Sep 30 21:19:51 and it seems to be always cgi requests Sep 30 21:20:06 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.) Sep 30 21:20:57 a packet capture would say which one is wrong Sep 30 21:21:23 however a naive curl -v -X http://192.168.1.1/cgi-bin/luci/admin/menu http://192.168.1.1/cgi-bin/luci/admin/menu ... http://192.168.1.1/cgi-bin/luci/admin/menu Sep 30 21:21:28 does not reproduce it Sep 30 21:21:34 *curl -v -X POST Sep 30 21:21:52 zorun: you have a few minutes to talk about the imagebuilder signature checking? Sep 30 21:29:29 aparcar[m]: sorry, didn't follow, and it's not the most urgent thing on my radar Sep 30 21:30:02 what are your more urgent 20.x things? Sep 30 21:31:06 I didn't mean 20.x specifically Sep 30 21:31:58 ack Sep 30 21:33:51 jow: do you have an opinion on that? Would you prefer a "trusted" option in opkg feeds for the local feed or make the ImageBuilder create signing keys? The latter has the advantage that the key ends up in the image, allow secure sysupgrades in the longer run Sep 30 21:37:34 aparcar[m]: for now I'd mark local feeds trusted Sep 30 21:37:48 and work for proper signing at a later stage Sep 30 21:38:17 can you describe proper signing? I could just add the logic from the build system to the IBs Sep 30 21:38:17 zorun: indeed, I captured the situation with wireshark now and the first menu request happened via another tcp stream to which uhttpd simply stopped responding Sep 30 21:38:24 looks like a concurrency bug after all Sep 30 21:38:43 aparcar[m]: I mean not rush before the release, give it time to test and settle Sep 30 21:38:50 tbh the entire usign infra is a mess atm Sep 30 21:39:48 fair. I just though the next IB release shouldn't use HTTP. So if this isn't reverted before the next release it's still "secure" Sep 30 21:40:16 *should use either HTTPS or signature checks Sep 30 21:41:38 you said "make the imagebuilder create signing keys" Sep 30 21:41:53 which sounds odd. if you simply copy the ones from buildroot it might make sense Sep 30 21:42:18 the public ones only, obviously Sep 30 21:53:42 jow: my understanding of the packages/ folder is that users can drop in their own packages. Therefore the index has to be created on the user side. When OPKG tries to load this local feed it can't find a valid signature because of the re-indexing Sep 30 21:54:15 see here https://github.com/openwrt/openwrt/blob/master/target/imagebuilder/files/Makefile#L131 Sep 30 21:54:39 This is always done when something in packages/ changes Sep 30 21:55:08 So the ImageBuilder requires some private keys or opkg needs the option to blindly trust a feed Sep 30 21:56:46 With the opkg patch src/trusted we can specifically trust a single local feed Sep 30 22:58:33 If I need to specify a default linker on a compile because the the compile uses the hosts linker. Do i want to tell it to use mips64-openwrt-linux-ld? Sep 30 23:01:17 the configure has a --default-linker arg, I'm just not sure what to put in it Sep 30 23:13:22 https://www.phoronix.com/scan.php?page=news_item&px=MT76-Better-WiFi-Linux-5.10 Sep 30 23:13:39 I'm curious why uses mt76 with mainline kernels... Sep 30 23:13:45 *who Sep 30 23:17:21 mangix: the USB dongles and SDIO stuff surely isn't primarily focused on the wireless router usecase Sep 30 23:18:35 sure but that article does not mention improvements for those USB adapters Sep 30 23:18:51 no idea what SDIO is used for Sep 30 23:20:09 mangix: for mediatek: TVs and Smart speakers judging from their footprints there Sep 30 23:22:49 mangix: also, "Mediatek paid him to write an upstream kernel driver." no, i'm pretty sure he was doing most of the work on it long before mediatek decided to get involved themselves Sep 30 23:42:21 DonkeyHotei: I based that statement on https://youtu.be/hiUosbhR0Wo?t=721 Sep 30 23:42:37 no idea about the full history Sep 30 23:43:56 i saw that vid when it was new but must've missed that blurb **** ENDING LOGGING AT Thu Oct 01 02:59:57 2020