**** BEGIN LOGGING AT Wed Jan 01 18:02:25 2020 Jan 01 18:52:40 any objections on doing 18.06.6 now? is something missing? Jan 01 18:57:55 Hauke: I've noticed some request on GitHub Jan 01 18:58:29 backporting some CVE fix in some util Jan 01 18:58:49 ynezz: https://github.com/openwrt/openwrt/commit/0062aad8ecc9bbe36c55895fd78fcaf9a406b006 Jan 01 18:59:14 yep Jan 01 18:59:56 what about the libubox/ubus fixes? Jan 01 19:12:41 ynezz: I am not sure about the lububox changes Jan 01 19:13:16 I would like to have them in, but them have ABI changes Jan 01 19:13:29 uh, where? Jan 01 19:15:12 4dfd24ed88c4d721d2b26d478b9ada86395d0554 Jan 01 19:15:36 d'oh :( Jan 01 19:19:22 I even remember the rationale for this change, data[len - 1]; where len=-3 Jan 01 19:20:44 what to do now? Jan 01 19:21:46 should I revert it and add size_t casts around the users in the libubox OR guard against < 0 ? Jan 01 19:23:15 I'm just afraid, that it might uncover some other hard to debug issues, similar to the most recent sysupgrade/procd Jan 01 19:24:29 I mean this one https://gitlab.com/ynezz/openwrt-procd/commit/8904b34203055bdc619cd95581a19b307b91e362 Jan 01 19:29:46 hmm we could also add a patch which reverts this commit Jan 01 19:29:52 and updatze the rest to master Jan 01 19:30:44 I would rather do this first in master, wait 1-2 days, backport it to 19.07, wait 1-2 days, then backport it to 18.06 Jan 01 19:31:18 there might be other (racy) stuff which might pop-up by just this simple revert Jan 01 19:31:38 so some (even if very small) additional testing would make sense Jan 01 19:32:02 ynezz: doesn't master already have it? Jan 01 19:32:10 that revert? Jan 01 19:32:24 that revert of 4dfd24ed88c4d721d2b26d478b9ada86395d0554 in libubox? Jan 01 19:32:25 I think the ABI change in master and 19.07 is ok Jan 01 19:32:36 ah, ok then Jan 01 19:32:53 Are you sure that you want to backport libubox and ubus fixes? I wouldnt do that. It is causing some issues with Python3. That's why I reverted it and didnt look at it so far. Jan 01 19:33:19 Pepe: CVE fixes Jan 01 19:33:37 what issues in python3? :) Jan 01 19:33:46 I'm not aware about them Jan 01 19:34:40 I can help fix those if I'm able to reproduce them here Jan 01 19:35:40 Pepe: do you have a link to the description of the python3 problems? Jan 01 19:35:42 Will this be the last bump to 18.xx branch? Jan 01 19:35:53 Then on to 19.xx Jan 01 19:36:43 Hauke: if you've some time on hand (and taste) could you pls review the last 4 commits https://gitlab.com/ynezz/openwrt-procd/commits/wip so I don't need to send them via mailing list? Jan 01 19:37:15 then I would just push those to master and backport libubox/procd/ubus fixes to 19.07 tomorrow during the day if nobody complains Jan 01 19:38:45 Hauke: I've this procd bump in my staging tree in case you would like to runtime test it as well https://git.openwrt.org/b005f5a703133f4d0b2f6ec39b671c55e11f4fd5 Jan 01 19:39:45 Hauke, ynezz: First thanks for taking care. Unfortunately, I didn't create a post about that, yet. One guy who is using master builds let me know about that and I was able to reproduce it, but I didn't investigate it. Jan 01 19:39:52 ynezz: Stability goes hand in hand with fixing security bugs. Jan 01 19:40:57 By reverting temporarily those commits which were recently introduced to the master branch, it helped. Jan 01 19:45:58 ynezz: errno is set to EINTR and not -EINTR ? Jan 01 19:47:11 ynezz: think looks good to me Jan 01 19:47:37 Hauke: I have a few patches to fix mikrotik support, I will send them today Jan 01 19:48:35 ynezz: why is there no break in case it prints the error message: https://gitlab.com/ynezz/openwrt-procd/commit/8904b34203055bdc619cd95581a19b307b91e362 Jan 01 19:50:36 Hauke: good question, but I don't know the JSON lexer enough to answer that, maybe rmilecki ? Jan 01 19:51:22 I also do not know this code well, but it could be that you introduced a endless loop Jan 01 19:52:08 that depends on child Jan 01 19:52:31 if the child never finishes, then it could end in the endless loop, yes Jan 01 19:52:59 otherwise the read() would finish with ret=0, finishing the while loop Jan 01 19:53:11 but this could happen even without my change Jan 01 19:53:32 my change just handles the EINTR, so it should be safe Jan 01 19:54:14 ok Jan 01 19:54:41 loks like you do not make it worse ;-) Jan 01 19:54:45 *looks Jan 01 19:55:05 EINTR=repeat the interrupted blocking call Jan 01 19:57:19 zorun: for which branch are you patches? Jan 01 19:58:33 Hauke: backports for 18.06 Jan 01 20:02:13 https://github.com/openwrt/openwrt/pull/2668 Jan 01 20:05:58 zorun: looks good to me, but I am not an expert in this area Jan 01 20:50:57 In the moderator queue of openwrt-devel, there is updated tools/expat, which fixes two CVEs in 18.06. Should be harmless to apply it as in our repository, we have been using it already for 3 months. Jan 01 20:53:25 Pepe: so that python3 breakage was build failure or runtime failure? Jan 01 20:53:41 runtime Jan 01 20:53:53 so it was some python3 library using libubox/ubus? Jan 01 20:54:54 It looks like yes, but I will investigate it and let you know. Jan 01 20:55:11 build #224 of apm821xx/sata is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/apm821xx%2Fsata/builds/224 Jan 01 20:55:15 I can't see such library in the packages repo Jan 01 21:46:18 build #215 of mpc85xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fgeneric/builds/215 Jan 01 22:05:37 happy new year Jan 02 00:59:25 From 19.07 git head, tplink archer c7 v2 with ath10k-ct firmware, now I can confidentally tell that indeed enabling/requiring 11w (AFAIK it is enough that it gets used, be setting optional or required) will cap download speeds at 30mbps Jan 02 00:59:56 disabling 11w makes me cap 250mbps downstream on these premises Jan 02 01:00:57 thus in conjunction wpa3 will cause that too as wpa3 mandates 11w required (where I found an bug in a sense at least Luci will still show11w options in wpa3, but choosing anyuthng there will not affect it being enabled) Jan 02 01:02:03 I tested all the combinations I could figure between WPA2 and 2 (PSK and SAE-mixed), 11w disabled and required, consistent results Jan 02 01:02:39 wpad-openssl, wpa-cli and hostapd-utils all also installed Jan 02 01:05:34 So ping greearb_ and who else, jow for Luci stuff... to notice this when awaken :) **** ENDING LOGGING AT Thu Jan 02 02:59:58 2020