**** BEGIN LOGGING AT Thu May 28 03:00:05 2020 May 28 03:47:21 build #335 of mpc85xx/p1020 is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/335 blamelist: Adrian Schmutzler , Pavel Balan May 28 03:48:52 build #333 of ramips/rt305x is complete: Failure [failed defconfig dltar] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/333 blamelist: Adrian Schmutzler , Pavel Balan May 28 08:00:59 Hauke: there is weirdness here. May 28 08:01:18 I started using the WAN port of the hh5a, the only port on VLAN2. May 28 08:01:32 Added eth0.2 to the br-lan bridge (since there is only LAN here; I just wasn't using that port before) May 28 08:01:43 tcpdump on eth0.2 shows a DHCP Response going out. May 28 08:02:05 tcpdump on the other end of that wire (which is now a Linux box being a software bridge to the switch that *was* plugged in there) shows no such packet. May 28 08:02:12 no crc failures, no drops. May 28 08:03:24 it is correlated with my shiny new rp-ac85p being plugged in as an extra AP, but not entirely. May 28 08:03:57 I first saw the missing DHCP responses (and other missing packets) with clients roaming between APs but then it affected wired clients too which had never moved. May 28 08:28:18 but not *all* clients, which is odd May 28 08:28:39 the affected clients would get *some* packets but not all. Set up IPv6 and left a ping running, it got about 1% through. May 28 08:28:44 I tried changing cables too. May 28 08:55:57 jow: adding a tag worked! thank you May 28 09:56:36 so can someone help with this issue? 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_netw May 28 09:56:36 ork.lock file. How to fix it? May 28 10:20:05 Intruder777: please open a bug report https://openwrt.org/bugs May 28 10:21:45 zorun: but I'm not sure what are the steps to replicate it. when I've installed a fresh firmware - there was no that issue. Now, after I've configured it and installed couple of packages/drivers - I have that issue May 28 10:21:52 Intruder777: that sounds as if some init script never completed running May 28 10:22:04 probably one of the packages you installed ships a broken init script May 28 10:22:31 jow: right, I have mentioned that it is /etc/init.d/network which never completes May 28 10:22:49 yeah but I don't think that one is the culprit May 28 10:23:35 jow: I've tried to run every script from init.d with "enabled" param - and only network hangs. all other complete May 28 10:23:53 ah, just noticed that it is brcm47xx May 28 10:24:01 it maybe does wonky things May 28 10:24:02 jow: the root cause of the issue is /lib/functions/procd.sh line 55. it hangs on `flock 1000` May 28 10:24:17 no, the root cause is something else still holding the lock May 28 10:24:41 can happen if e.g. a child process is forked which still keeps the fd open May 28 10:25:25 jow: if I remove that network lock file - it starts to work normally. but only until reboot. after reboot, for example when I try to see "Startup" section in LuCI - it hangs again May 28 10:25:55 because startup section calls `ubus call luci getInitList` May 28 10:26:44 Intruder777: you need to troubleshoot what leads to this (e.g. with "ps", "logread", "dmesg", check which packages causes it) and put all that in your bug report May 28 10:26:57 also, does it also happen with 19.07.2, snapshots, etc May 28 10:27:42 jow: btw, changing /lib/functions/procd.sh line 52 from `flock -n 1000 &> /dev/null` to `flock -n 1000 &` also fixes it. not sure why May 28 10:28:08 I guess because some invokedp rocess inherits the fd 1000 and never closes it May 28 10:28:50 zorun: how do I find which process uses file descriptor with "ps" "logread" and "dmesg"? May 28 10:29:37 lsof if yuou have it May 28 10:30:58 karlp: I see it in opkg. going to install it May 28 10:31:58 for x in /proc/[0-9]*/fd/1000; do sed -nep ${x%/fd/1000}/cmdline; done May 28 10:32:35 or that :) May 28 10:32:45 /proc has magic everywhere May 28 10:35:19 going to reboot now in order to make it reproducible. bare with me May 28 10:38:27 lsof shows this one: `nas 1165 root 1000w REG 0,13 0 1174 /tmp/lock/procd_network.lock` May 28 10:38:51 yo as expected May 28 10:38:54 *so May 28 10:39:06 "nas" is offender here May 28 10:39:27 and it is brcm47xx specific May 28 10:40:11 ps shows: `/usr/sbin/nas -P /var/run/nas.wl0.pid -H 34954 -i wl0 -A -m 128 -w 4 -s -g 3600 -F -k ` May 28 10:40:23 how do I fix it? May 28 10:42:08 need to check May 28 10:45:27 surprised the XDP stuff was backported for mvneta May 28 10:45:27 Intruder777: try this: https://pastebin.com/1PzeW43L May 28 10:45:49 I thought that's only for software buffer management. May 28 10:47:03 hm, 19.07 has Boost 1.71 but cmake-3.15 in which FindBoost.cmake doesn't cope with 1.71 May 28 10:49:52 dwmw2_gone: look at libfolly/libfizz. There was a cmake option to fix it. May 28 10:51:56 jow: so I have to modify my /lib/wifi/broadcom.sh right? already done, going to reboot now May 28 10:52:18 yep May 28 10:53:00 jow: any thoughts on https://github.com/openwrt/packages/pull/12295#issuecomment-634682104 ? May 28 10:55:19 mangix: we don't want local includes overriding system ones to prevent garabage versions of libtool etc. May 28 10:55:40 often stuff shipped in aclocal is utter crap May 28 10:56:56 jow: looks like nas doesn't hold that file anymore, going to check if network script works... May 28 10:58:00 jow: yep, everything works now as expected. no more hanging May 28 10:58:03 jow: thank you May 28 10:59:10 yw May 28 11:09:38 Intruder777: curious, how's the luci performance on the rt-n16? May 28 11:14:43 jow: well, I have not seen luci performance on any other router, so I have no good example to compare with :) but as for me, seems to work pretty smooth (honestly, I've expected it to be even slower, so I can say I'm satisfied with it). May 28 11:16:14 allright, thanks1 May 28 11:16:17 *! May 28 11:16:22 jow: most pages open fast, but dynamic AJAX queries seems to be a bit sleepy (like when page loads something dynamically "Loading view…") May 28 11:17:04 yeah, if you have a little flash and ram space avaialble, I suggest installing "uhttpd-mod-ubus" May 28 11:17:23 then close and reopen the browser tab, that should speed things up a bit May 28 11:19:13 jow: rt-n16 has like 32mb flash and 128mb ram. I'm going to connect USB drive to it. I've heard OpenWRT can extend it's space with external USB (kind of join USB storage to internal, or something) May 28 11:22:15 jow: is 1000>&- set fd1000 output to a copy of stdout? what's the - bit? May 28 11:22:50 x>&- closes "x" May 28 11:25:08 while you're here, 16:50 jow: did sysauth_template disappear in luci 184ea6230076 ? My template just gets ignored now, and the new themes all just have it built into the header? I want to keep requiring people to set a password, not just have the warning and ignore it. May 28 11:25:14 I have to replace the /usr/lib/lua/luci/view/sysauth.htm with my own now, which runs into the "file blah is alreadyd provided by package wop" May 28 11:25:22 yeah it likely was lost in the previous refactorings May 28 11:25:32 is it somethign we want to support again? May 28 11:25:32 I guess its easy to add back May 28 11:25:49 I can work around it, just tryign to follow the right paths forward May 28 11:25:57 well if there's a need for it, sure - yes May 28 11:26:30 I don't have a specific plan yet how future logins will be handled May 28 11:26:32 I've been using it to force people to go and set a password, not jsut leaving the warning dangling. May 28 11:26:54 there'll probably be an api of some kind so that the login can be simple unprotected view May 28 11:27:00 I'm currently setting up stuff to preset per device initial passwords anyway, so... might not matter down the road. May 28 11:28:09 I can look into it... sometime May 28 11:28:14 not sure when though May 28 11:28:29 its likely simple. I suspect it just needs to be funneled through the json May 28 11:29:03 right now lua menu trees are converted to json, merged with static json declarations to form the final menu tree May 28 11:29:03 ok, no stress, 1907 still works :) May 28 11:29:12 with the goal to fade out lua dispatchers entirely eventually May 28 11:29:19 the lua 2 json step ignores sysauth_template May 28 11:29:58 so you would then have json for your url routing, and still optionally lua backends, just no longer lua for the url routing right? May 28 11:30:03 I backported quite a lot of stuff to 19.07, are you sure it is still working? May 28 11:30:15 yeah, right May 28 11:30:27 pretty sure, at least, I tried to use menu.json stuff and that wasn't there May 28 11:30:28 though I plan to get rid of Lua completely for the base LuCI at least May 28 11:30:45 including dispatcher.lua itself, it'll be a C thing probably May 28 11:31:00 which instantiates a Lua interpreter lazily if needed May 28 11:31:15 using dlopen() on liblua, to make it an optional runtime dep May 28 11:31:22 looks like a path to lua5.3 :) May 28 11:31:31 or lua-whatever-user-uses May 28 11:32:04 yeah, but for that we still need to refactor the legacy luci löua framework libs to not rely on pcall, setfenv etc. May 28 11:32:58 I don't need 5.3 anywya, that waas more tongue in cheek :) May 28 11:33:04 jow: hi, did you get my email eventually? May 28 11:36:06 f00b4r0: yeah May 28 11:36:15 cool, thanks May 28 11:42:52 jow: but can that "uhttpd-mod-ubus" slow down the router itself? like I mean it can speedup web interface, but can it slow down overall router performance? May 28 11:43:44 Intruder777: no, it shouldn't May 28 11:45:12 jow: ok, thanks. I have like "Total Available" memory 61% May 28 11:45:38 (25% used, 10% cached) May 28 12:51:28 is it terribly bad idea to enable sh command history saving on a router (flash memory)? May 28 13:02:53 anyone found an m.2 or similar /AX NIC like AX200, but without all the instability and crashes? May 28 13:08:51 those ax from qca that are like ~200$ from compex ? ^^ May 28 13:09:09 firmware heavy and oversize-formfactor oO May 28 13:09:15 probably May 28 13:10:06 yeah, I was hoping for something smaller and lower powered so I could cram a bunch into a system May 28 13:11:04 oh "TBD" power consumption and certification May 28 13:11:51 and functional driver too probably May 28 13:13:16 is Broadcom Wifi that changed to Cypress now part of Infineon ? May 28 13:14:09 maybe some management change there brings different datasheet / code policy May 28 13:17:09 intel sold some part of its wifi tech, but maybe not the ax200 May 28 13:20:59 the ax200 is quite horrible for me as well May 28 13:21:15 if I get "too far" away from the AP even DHCP fails May 28 13:21:20 hm... maybe the broadcom->cypress change did change development of wifi/brcm in linux tree too - seems different commit now compared to ealier May 28 13:21:31 at the same position my 8260 does 200Mbps May 28 13:22:38 stintel, my problem is that the firmware crashes and often will not recover. Upload perf is poor, download can be great. We are testing with good signal, haven't tried RvR tests on it yet. May 28 13:23:25 it's basically quite disappointing. as usual with Intel May 28 13:23:56 and yet it is the best thing available anywhere, as far as I can tell. May 28 13:26:14 the chromium firmware repo has iirc even newer firmware than linux-firmware repo for some intel wifi cards May 28 13:26:55 I'll go poke around, we're currently using whatever comes with Fedora-30, which is 48.something May 28 13:27:16 and 5.4.stable kernel May 28 13:27:34 I tried 48 and 50 May 28 13:27:44 some testing indicates out 5.2 kernel is more stable, but not certain about that May 28 13:27:54 disabling .11ax helps somewhat May 28 13:28:12 but .. :) May 28 13:28:12 yeah, we are testing against a wave-2 AP for the most part May 28 13:28:23 I have an 8x8 11ax AP May 28 13:29:23 even with good signal, the transfer rates are unstable and barely higher than what I got with the 8260 on an 11ac wave 1 AP May 28 13:30:18 early testing showed we got much better throughput when disabling OFDMA, but maybe stuff is improved now May 28 13:38:59 is there some trick for adding a route to point to the gateway on the wan address learned via dhcp? May 28 13:41:37 customroutes May 28 13:41:37 wee May 28 13:42:57 hm, is that deprecated? it doesnt seem to work May 28 13:43:56 ah typod netmasks, nm May 28 13:43:58 yay May 28 15:10:35 jow: just found that we still have ar71xx images in snapshots download. they are from june 2019, I just got aware because somebody used them for reference in a recent bug report. Since I don't think they are of any use and 19.07 is probably more up-to-date now anyway, would you please just delete the entire folder May 28 15:10:40 https://downloads.openwrt.org/snapshots/targets/ar71xx/ May 28 15:22:56 what's your workflow when adding a new package but now yet knowing the HASH? Downlading manually, checking hash, putting it into the Makefile is really tedious May 28 15:23:18 i'd relaly like to have sth. like "fill in hash on first try" May 28 15:23:48 HASH=show/set as var to make May 28 15:32:03 iirc the current way to do this is "make package/foo/check FIXUP=1" May 28 15:33:13 https://openwrt.org/docs/guide-developer/packages May 28 16:04:17 zorun: ah, thanks May 28 20:40:55 build #336 of mpc85xx/p1020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/336 May 28 20:54:16 build #334 of ramips/rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/334 May 28 22:10:57 https://github.com/blogic/udevmand May 28 22:11:05 a topology mapper May 28 22:11:11 kristrev: ^^ May 28 22:11:25 still missing the mdns and dhcpv6 info May 28 22:13:54 here, enjoy some epic music before going to bed: https://www.youtube.com/watch?v=74wEfpWpISU May 28 22:14:23 way too slow May 28 22:14:30 still pretty nice May 28 22:14:34 but too slow May 28 23:54:28 mangix: between an optimized buffer overflow and an unoptimized correct buffer copy, I’ll go with the later. in any case, the operation only happens when the firewall is started/restarted, and at most 4 times per rule, so the overhead is trivial. **** ENDING LOGGING AT Fri May 29 02:59:57 2020