**** BEGIN LOGGING AT Tue May 05 02:59:57 2020 May 05 07:24:41 m4t: hey, are you there? can you pastebin "block info" from your device, please? May 05 07:30:45 gch981213: m4t: jow: I pushed some fstools changes and commented in the https://bugs.openwrt.org/index.php?do=details&task_id=2231#comment8228 May 05 08:39:38 gch981213: FYI http://lists.infradead.org/pipermail/openwrt-devel/2020-May/023238.html May 05 08:46:27 ynezz: I am the author of that email, I'm here too May 05 08:54:14 guifipedro: to me it seems like those affected devices are relying on a switch config done in bootloader, so the proper fix is to do a proper switch config after that reset May 05 08:56:02 in other words, dump regs before that reset (proper switch config as done in bootloader) and after that reset, find diff, apply diff, done May 05 09:05:35 ynezz: yes, looks like is that. I don't know how to do that. I need further indications May 05 09:05:55 Probably gch981213 has more documentation for that switch IC so that the diff can be studied properly and just the needed bit(s) set in the fix. May 05 09:06:03 is umdns supposed to support "reflection"? May 05 09:07:01 kinda want to avoid running the abomination that is avahi for that May 05 09:11:17 PaulFertser: Google "ar8236 datasheet" and the first result is a leaked pdf: http://www.jhongtech.com/DOWN/ATHEROS--AR8236.pdf May 05 09:18:09 gch981213: cool. So guifipedro or someone else affected really needs to dump the registers before the reset and after the system is fully booted I guess so that the datasheet reading work would be easier. May 05 09:18:25 I can compare the registers but I do not have affected hardware to get the source data. May 05 09:19:08 I have the device, but I don't know how do do the dump. (Thanks PaulFertser, gch981213 and ynezz for the followup) May 05 09:19:47 guifipedro: Multicast frames from lan port aren't forwarded to cpu port. Is my understanding of the bug correct? May 05 09:20:40 gch981213: I suppose is that, yes May 05 09:21:03 works in one direction, but not in the other May 05 09:21:44 so a good proof is to ping to the antenna through cable, because if you do it through the antenna, you see no issues if I am not wrong May 05 09:22:04 So flood mask register probably? May 05 09:22:39 PaulFertser: I guess so. May 05 09:26:35 ff02::1 is technically multicast May 05 09:27:42 But a special kind of it, it's supposed to be exempt from IGMP snooping rules I guess? May 05 09:45:51 guifipedro: ping - could you test if this commit works? https://git.openwrt.org/?p=openwrt/staging/981213.git;a=commit;h=b34165fd386158cbb4d8c09e2c5127b3dee3219a May 05 09:55:28 gch981213: OK, going to test it now May 05 10:15:33 can ubus method handler tell ubusd it's done with processing and stop blocking ubusd while still doing other stuff? May 05 10:29:47 i just check ubus_process_invoke(), it doesn't seem possible May 05 10:31:19 ubus_defer_request ? May 05 10:31:42 damn, that block(d) design is crazy, I have hotplug.d script calling "block hotplug", then block calling "ubus call blockd hotplug", then blockd calling "block autofs" and then block calling /sbin/hotplug-call May 05 10:32:08 ynezz: ubus_defer_request can be used by caller, not a handler May 05 10:32:14 (i think?) May 05 10:36:17 https://lxr.openwrt.org/source/ubus/examples/server.c#L101 May 05 10:36:30 this is handler May 05 10:36:42 or I didn't get your question :) May 05 10:39:00 wow, thanks! May 05 11:26:05 ynezz: PaulFertser: https://github.com/Deoptim/atheros May 05 11:30:04 dengqf6: thank you for the reference! May 05 11:59:28 I want to solve problem of not firing "mount" hotplug.d events for devices mounted at boot time May 05 11:59:32 http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020886.html May 05 11:59:37 my idea is to fire "mount" events on "blockd" start (so devices mounted on boot time will get delayed notifications) May 05 11:59:52 the only downside of this i can see is re-firing "mount" events when someone decides to restart "blockd" - anyone seeing problem with that? blogic? May 05 12:01:41 if we use some trick to not fire events on restart, then devices mounted while "blockd" was off, will get missed May 05 12:01:55 i just prefer to assume blockd is always running then May 05 12:54:45 rmilecki: here is 'block info' https://paste.ee/p/5kaCO#e358pfXgOU3KwotsB14x1k6yGa53Pd1v May 05 13:23:54 aparcar[m], ynezz: hi, my students have trouble installing luci in the snapshot docker image May 05 13:23:58 it worked a few months ago May 05 13:24:18 I told them to open a ticket on https://github.com/openwrt/docker May 05 13:24:50 nothing urgent but if you have time to have a look at some point it would be appreciated, thanks :) May 05 13:37:31 wow first experience with Intel ax200 is *horrible* May 05 13:37:46 can't even get traffic through now May 05 13:46:33 :) May 05 13:47:07 are you trying it as a client or an ap ? May 05 13:49:28 client May 05 13:54:33 disabling 802.11ax seems to help but that's the whole reason for buying the thing :P May 05 13:55:01 iwlwifi-cc-a0-48.ucode from september 2019 May 05 13:55:16 sounds ancient yet nothing newer in linux-firmware.git May 05 14:18:11 stintel, there are newer firmwares but there are some driver dependencies too afaik May 05 14:18:27 https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+/3341e7d0a655b4b61e3c43eba926dfd192f8613a iwlwifi-cc-a0-53.ucode May 05 14:18:36 2months old May 05 14:18:53 plntyk: I'm on 5.6.10, tried the firmware in linux-firmware.git (48) and in the intel repo that feeds linux-firmware (50), both are unusable May 05 14:19:08 53 is too new, driver starts to try from 52 May 05 14:19:16 let's see if I can find that in that repo May 05 14:19:28 plntyk: thanks May 05 14:20:47 seems I'm out of luck May 05 16:12:09 i just discovered ubus_defer_request() is not a solution for me May 05 16:12:39 even if i try calling hotplug.d script from uloop timer, that will still hang uloop and stop ubusd from processing any messages May 05 17:26:09 gch981213: tested your staging branch, it works (double checked by roger) May 05 17:31:57 Hauke: jow: how are you doing with release preparations? May 05 17:32:13 Hauke: jow: there is one fstools lock fix I'd like to get before release if possible May 05 17:32:41 Hauke: jow: i think i have it working locally now, so i'm planning to send patch late today or tomorrow morning May 05 17:51:23 rmilecki: do you by chance see a commit of mine in fstools john merged today? he said he did so but i fail to find it.. May 05 18:14:22 rmilecki: I just started looking into backport issues May 05 18:14:36 *looking into things for LuCI I need to backport May 05 18:15:25 mirko: no, can you point me to the patch? May 05 19:14:11 rmilecki: sure: https://pb.nanl.de/show.php?id=44995&hash=15878593&mode=raw May 05 19:14:42 Huh, what a place for a patch May 05 19:15:37 it's well formatted text going to apply nicely - what else do you want? :P May 05 19:15:37 mirko: i don't see that patch in my mailbox, did you send it to openwrt-devel@? May 05 19:16:10 rmilecki: nope, off the usual process.. May 05 19:17:15 rmilecki: nevermind, just wanted to know if i was looking at the wrong repo or the webinterface failed me showing the patch May 05 19:19:00 mirko: looks ok to me i think, but please stick to using tabs :) May 05 19:20:00 oops May 05 19:20:42 mirko: any idea why libblkid (from util-linux) doesn't handle that? May 05 19:20:50 https://github.com/karelzak/util-linux/blob/master/libblkid/src/superblocks/vfat.c#L431 May 05 19:21:08 (i googled some mirror but nvm that) May 05 19:22:37 oh, i didn't even know the tiny-variant is derived from that May 05 19:22:58 so, no, no idea May 05 19:23:02 rmilecki: rmilecki should be fine if you send it tomorrow May 05 19:26:58 Hauke: thanks, I just sent it May 05 19:27:08 Hauke: would you take a look at [PATCH fstools] blockd: use uloop_process for calling /sbin/hotplug-call mount May 05 19:27:58 https://patchwork.ozlabs.org/project/openwrt/patch/20200505192632.12154-1-zajec5@gmail.com/ May 05 19:35:35 zorun: thank you I'll look into it in a bit May 05 19:39:15 build #345 of layerscape/armv8_64b is complete: Failure [failed images] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv8_64b/builds/345 blamelist: Rafa? Mi?ecki , Adrian Schmutzler May 05 19:45:49 jow: can you please give this some 30 seconds to review? Having the CPE would be cool for future tooling. https://github.com/openwrt/openwrt/pull/1654 May 05 19:50:55 fine with me May 05 20:01:40 jow: may I quote you so feckert is motivated to apply the patch? May 05 20:03:28 ldir: is https://git.openwrt.org/?p=project/luci.git;a=commitdiff;h=c58ae7d3f41a3454a116560fd555aac0ead18ff2 relevant for 19.07 ? May 05 20:04:49 ah, f* May 05 20:05:06 aparcar[m]: meh, github pr May 05 20:05:39 jow: I can send you a mail if that helps moving things May 05 20:07:38 jow: if dnsmasq 2.80 in 19.07, then yes May 05 20:09:02 aparcar[m]: no it doesn't May 05 20:09:08 I already spent way more than 30 seconds now May 05 20:09:26 author does not match sob... sigh May 05 20:10:38 sorry I'll stay quit the next 10 time when I have a 30 seconds request May 05 20:11:58 this comment keeps cpes from being stored in Packages https://github.com/openwrt/openwrt/pull/1654#issuecomment-624246444 not sure if this is really required May 05 20:12:34 force push declined, double sigh May 05 20:14:08 how did you passed that sob post commit check hook? :) May 05 20:15:24 ah, it's probably some different repo May 05 20:15:25 it's now in master btw https://github.com/openwrt/openwrt/commit/a673abe84ca6aa337d2bd4fce1c674b83f5047b2 May 05 20:15:42 (not only in jow.git) May 05 20:15:55 this one has ok SoB May 05 20:18:03 had to disable branch protection on the github mirror and force push May 05 20:18:18 because I accidentally merged the PR which created deviating history May 05 20:18:21 stintel: you could try the iwlwifi driver from backports it is based on kernel 5.7-rc3 which support FW interface 53. May 05 20:19:30 ynezz: yeah, seems my mailmap fooled me May 05 20:21:21 I'm in snapshot and this lua code returns true, which I think is incorrect `uci.cursor():get("luci-bmx6","luci","json")` May 05 20:22:39 works for me: May 05 20:22:40 # lua -luci -e 'print(uci.cursor():get("luci-bmx6","luci","json"))' May 05 20:22:41 nil uci: Entry not found May 05 20:23:57 LuCI wrapper too: May 05 20:23:58 # lua -lluci.model.uci -e 'print(luci.model.uci.cursor():get("luci-bmx6 May 05 20:23:58 ","luci","json"))' May 05 20:23:58 false Entry not found May 05 20:24:35 module 'uci' not found, where should I go ? May 05 20:25:15 you're probably using luci.model.uci then May 05 20:26:52 jow: https://github.com/openwrt-routing/packages/blob/master/luci-app-bmx6/bmx6/usr/lib/lua/luci/model/bmx6json.lua#L57 May 05 20:28:15 then says "attempt to get length of local 't' (a boolean value)" May 05 20:46:41 guifipedro: change "url == nil" to "url == nil or url == false" May 05 20:46:47 guifipedro: or simply "if not url then" May 05 20:52:15 aparcar[m]: thanks! May 05 21:12:27 jow: If I do that, error raised "Some error detected, please check it: bmx6 json url not configured, cannot fetch bmx6 daemon data" May 05 21:13:42 The device has this branch https://git.openwrt.org/?p=openwrt/staging/981213.git;a=summary May 05 21:19:22 guifipedro: well it appears as if the uci simply cannot be read May 05 21:19:38 maybe you have a syntax error in /etc/config/luci-bmx6 May 05 21:24:22 did not know that file May 05 21:24:27 maybe this is outdated? `option json 'exec:/www/cgi-bin/bmx6-info -s'` May 05 21:24:54 http:///cgi-bin/bmx6-info still works May 05 21:25:08 but luci-compat moved to: http://10.1.59.65/cgi-bin/luci right? May 05 21:26:40 but I have another device with 19.07.1 and it works this part May 05 21:27:00 this luci view May 05 21:31:32 (now I start to understand how this code works) from uci show I see `luci-bmx6.luci.json='exec:/www/cgi-bin/bmx6-info -s'` May 05 21:31:46 so it should work but it is nil (?) May 05 21:36:41 yes May 05 21:40:03 `lua -lluci.model.uci -e 'print(uci.cursor():get("luci-bmx6","luci","json"))'` says `lua: (command line):1: attempt to index global 'uci' (a nil value)` May 05 21:40:31 print(luci.model.uci.cursor()...) May 05 21:41:12 oh yes, that worked `lua -lluci.model.uci -e 'print(luci.model.uci.cursor():get("luci-bmx6","luci","json"))'` says `exec:/www/cgi-bin/bmx6-info -s` May 05 21:41:39 might be permission issue then, maybe the broken view runs as nobody May 05 21:43:29 permission is root:root /usr/lib/lua/luci/view/bmx6/links May 05 21:43:37 links.htm* May 05 21:44:25 see /usr/lib/lua/luci/controller/, check how the bmx view is defined May 05 21:45:10 this? `entry(place,call("action_links"),"Links",2).leaf = true` May 05 21:46:19 ( https://github.com/openwrt-routing/packages/blob/master/luci-app-bmx6/bmx6/usr/lib/lua/luci/controller/bmx6.lua#L69 ) May 05 22:44:44 seems libpcap in 19.07 is completely messed up May 05 22:45:16 and despite it being the same version as in master, its differently packaged May 05 22:45:25 other patches, other makefiles directives May 05 22:52:46 Hauke: seems you introduced the regression :) patches/100-debian_shared_lib.patch of libpcap in 19.07 introduces some weird version detection stuff May 05 22:52:57 Hauke: which breaks the packaging of the library May 05 22:53:13 Hauke: it also differs from the version of the patch in master, maybe you can take a look if time permits **** ENDING LOGGING AT Wed May 06 03:00:05 2020