**** BEGIN LOGGING AT Wed Dec 09 02:59:56 2020 Dec 09 08:36:51 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 97.5% packages reproducible in our current test framework.) Dec 09 09:10:58 Hrrm - should https://openwrt.org/docs/guide-developer/security Support Status EOL dates be updated? Dec 09 09:11:21 I imagine that 18.06 be show as projected EOL "soon" (when 20.x released) Dec 09 09:11:34 19.07 then considerably beyond that Dec 09 09:36:32 stintel: so the lldpd issue Dec 09 09:36:59 stintel: we need to make it run on the member interfaces of a bridge, rather than the bridge Dec 09 09:37:11 if you run it on the bridge, remote hosts will see the AP Dec 09 09:37:17 but the AP can't see them Dec 09 09:43:03 blogic: you can get it to compile? Dec 09 09:44:51 1.0.7 ? Dec 09 09:44:55 yes build locally Dec 09 09:45:02 or whatever the update was Dec 09 09:45:12 tested in mips, arm and aarch64 Dec 09 09:45:45 mangix: we tried reproducing the buildbot bug, it builds for Hauke for me on d10 for jow, even in the Docker container used by the build slaves Dec 09 09:45:54 so very much heisenbug Dec 09 09:46:05 what is the buildbug ? Dec 09 09:46:14 blogic: it builds for 0 archs Dec 09 09:46:28 yeah but where/what does it fall over Dec 09 09:46:41 some autoconf crap Dec 09 09:46:51 is what jow suggested Dec 09 09:46:58 mangix: have a link handy? Dec 09 09:47:41 nvm Dec 09 09:47:42 https://downloads.openwrt.org/snapshots/faillogs/arm_cortex-a9_vfpv3-d16/base/lldpd/compile.txt Dec 09 09:47:51 arm-openwrt-linux-muslgnueabi-gcc: error: READLINE_LIBS@: No such file or directory Dec 09 09:56:34 yep Dec 09 09:56:35 stintel: does it fail on all arches? Dec 09 09:56:44 I have the same failure on CentOS and Fedora Dec 09 09:56:47 if so I'll try to grab a config.log from one of the slaves Dec 09 09:57:01 mangix: ah you can repro it? Mind to share config.log ? Dec 09 09:57:06 jow: afaik yes Dec 09 09:57:40 my hunch is that it is somehow related to sed Dec 09 09:58:07 build in progress Dec 09 09:58:55 or maybe it is a pkgconfig issue Dec 09 09:59:02 just guessing Dec 09 10:03:05 jow: https://gist.github.com/neheb/b60c7a05d06c2aeeb747e163b23c68a6 Dec 09 10:03:49 ccache is enabled there but the bug doesn't depend on that Dec 09 10:06:47 mangix: can you also paste grep -r 'READLINE_LIBS=' build_dir/target-*/lldpd-1.0.7/ ? Dec 09 10:07:06 seems your ./configure gets differently generated Dec 09 10:08:38 build_dir/target-powerpc_464fp_musl/lldpd-1.0.7/m4/ax_lib_readline.m4: READLINE_LIBS="$ax_cv_lib_readline" Dec 09 10:09:12 that's theo nly occurence? Dec 09 10:09:16 yes Dec 09 10:09:33 $ grep -r 'READLINE_LIBS=' Dec 09 10:09:33 config.log:READLINE_LIBS='' Dec 09 10:09:33 m4/ax_lib_readline.m4: READLINE_LIBS="$ax_cv_lib_readline" Dec 09 10:09:33 configure: READLINE_LIBS="$ax_cv_lib_readline" Dec 09 10:09:36 autom4te.cache/output.1: READLINE_LIBS="$ax_cv_lib_readline" Dec 09 10:09:38 autom4te.cache/traces.0: READLINE_LIBS="$ax_cv_lib_readline" Dec 09 10:09:41 autom4te.cache/output.2: READLINE_LIBS="$ax_cv_lib_readline" Dec 09 10:09:43 autom4te.cache/output.0: READLINE_LIBS="$ax_cv_lib_readline" Dec 09 10:09:47 so this explains the substitution error at least Dec 09 10:10:02 can you now please paste the log output of make package/lldpd/{clean,compile} V=s ? Dec 09 10:10:08 to see the autoreconf messages Dec 09 10:12:57 hmmm Dec 09 10:13:11 was 2&> for directing both stdout and stderr? Dec 09 10:14:07 in bash can just &> Dec 09 10:14:12 I think 2>&1 Dec 09 10:14:23 is the posix way but might be wrong Dec 09 10:14:39 jow: https://gist.github.com/neheb/f1b2967d147df3b4d346adf625f46c5f Dec 09 10:15:13 I wonder if the issue is gawk Dec 09 10:15:36 CentOS 7 has gawk 4.0.2 Dec 09 10:16:40 stintel: just tested. seems &> and 2&> produce identical output Dec 09 10:21:53 mangix: can you please also grep this: Dec 09 10:22:06 grep -r AX_LIB_READLINE staging_dir/target-*/host/share/aclocal/ staging_dir/target-*/usr/share/aclocal/ staging_dir/hostpkg/share/aclocal/ Dec 09 10:22:48 5 results in staging_dir/target-powerpc_464fp_musl/usr/share/aclocal/ Dec 09 10:23:00 in one .m4 file I presume Dec 09 10:23:05 two Dec 09 10:23:10 can you please paste them? Dec 09 10:23:18 ax_lib_readline.m4 and ax_lua.n4 Dec 09 10:23:45 so the lldpd guys forked the official ax_lib_readline.m4 Dec 09 10:23:52 https://gist.github.com/neheb/d7def655d651cc75d46413a10c2f31fb Dec 09 10:23:58 and put a modified copy with the same name in their tree Dec 09 10:24:21 and likely even the same or a higher serial Dec 09 10:24:27 erm same or lower Dec 09 10:24:45 so our autoconf prefers the official macro of the same name from the global shared macro dir Dec 09 10:25:04 which is differently defined and likely does not set READLINE_LIBS Dec 09 10:25:13 mangix: can you paste the contents of these files? Dec 09 10:25:27 actually only ax_lib_readline.m4 is interesting Dec 09 10:25:35 ax_lua.m4 is just using it Dec 09 10:25:41 so https://github.com/openwrt/openwrt/tree/master/tools/autoconf-archive broke two packages :) Dec 09 10:26:11 well it was foolish to assume that downstream projects use autoconf correctly Dec 09 10:27:11 https://gist.github.com/neheb/c17317ffaa6f69db5804dfa68728efb0 = usr/share/aclocal Dec 09 10:27:30 yeah, now it is clear Dec 09 10:27:58 compare with https://github.com/lldpd/lldpd/blob/master/m4/ax_lib_readline.m4 Dec 09 10:28:23 lldpd forked it, using same name, lower serial (version) Dec 09 10:29:02 the simplest fix would be a global s/AX_LIB_READLINE/AX_LIB_READLINE_LLDPD/g in the lldpd tree Dec 09 10:29:12 to avoid ading knee deep through m4sh hell Dec 09 10:29:17 *wading Dec 09 10:29:49 so basically rename the macro in the locally shipped m4/ax_lib_readline.m4 and its invocation in configure.ac Dec 09 10:30:17 stintel: so the reason why we weren't able to reproduce is because we didn't build autoconf-archive in our tests Dec 09 10:30:30 stintel: in hindsight it is an obvious candidate for interference Dec 09 10:31:06 jow: there might be a simpler fix Dec 09 10:31:23 for ola, the other package that broke, this was the fix for it: https://github.com/openwrt/packages/blob/master/net/ola/patches/201-automake-fix.patch Dec 09 10:32:04 I think this case is different Dec 09 10:32:19 usually it is locally shipped macros which are broken and omitting them fixes things Dec 09 10:32:32 but in this case, lddpd relies on a "broken" (modified) local macro Dec 09 10:32:44 the official one does not set the expected variables Dec 09 10:33:35 and due to the official one having a higher serial, autoconf will always prefer it, even if we'd shuffle the include paths to prefer local over global (which was my first idea for a fix) Dec 09 10:34:19 hmm git grep amincline doesn't show anything interesting Dec 09 10:34:45 *aminclude Dec 09 10:35:17 jow: right but ola broke with the introduction of autoconf-archive Dec 09 10:36:40 well, autoconf has more failure modes than working code paths Dec 09 10:38:08 mangix: http://sprunge.us/d17Srz Dec 09 10:38:18 can you give this one a try, just to confirm the suspected cause? Dec 09 10:38:50 if this fixes things, it should be added as patch, changing m4/ax_lib_readline.m4 + configure.ac Dec 09 10:41:10 yep that fixed it Dec 09 10:48:56 shall I prepare a patch? Dec 09 10:49:06 sure Dec 09 10:51:10 looks like several packages have broken pkgconfig files... Dec 09 10:51:13 git grep libdir=/usr | wc -l Dec 09 10:51:16 5 Dec 09 10:57:59 stintel, mangix: https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commit;h=f491b90f9463cf04b2b2a59ca6e46f3a4ba2b16a Dec 09 10:58:08 maybe I could get your tested-by Dec 09 11:02:53 jow: I guess revbump is not needed because no package has been built for a long time Dec 09 11:02:58 compiles. feel free to add mine. Dec 09 11:03:28 stintel: lldpd doesn't really change either Dec 09 11:07:29 mangix: Do you think that we can someone enable this https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/enabling-or-disabling-github-discussions-for-a-repository#enabling-or-disabling-discussions-for-your-repository for packages repository? It would be good to move feature requests from issues to it. And BTW: Github has Dark Mode finally! :) Dec 09 11:08:32 somehow* my bad Dec 09 11:13:08 upstream PR sent: https://github.com/lldpd/lldpd/pull/423 Dec 09 11:13:22 speaking of dark mode, what's the general view here of dark mode for LuCi? Dec 09 11:13:34 jow: in favor, or you prefer light? Dec 09 11:13:53 okay for me if implemented through CSS variables Dec 09 11:13:59 no extra theme please Dec 09 11:14:11 no, not proposing to do 2 themes :) Dec 09 11:14:12 *CSS variables or slectors Dec 09 11:14:26 so css variables and some knobs in the UI to change? Dec 09 11:14:54 I think there's a media query to check if user prefers dark mode Dec 09 11:14:58 so no ui knobs needed Dec 09 11:15:21 can be added later if needed, but initially we should simply stick to the media queries Dec 09 11:15:27 ok Dec 09 11:15:31 sounds reasonable Dec 09 11:16:01 @media (prefers-color-scheme: dark) is the query in question Dec 09 11:16:06 right Dec 09 11:17:01 stintel: can I add your acked-by? Dec 09 11:21:17 Pepe: stontel disabled that Dec 09 11:21:26 * stintel Dec 09 11:23:46 stintel: That was just for team members, this is a new public feature. See how it looks: https://github.com/nodejs/node/discussions and docs can be found here: https://docs.github.com/en/free-pro-team@latest/discussions Dec 09 11:24:55 ah this is something else Dec 09 11:30:56 Pepe: whe have too many discussion places already. flyspray, forum, github issues/PRs, irc, ML. do we really need another one? Dec 09 11:31:34 jow: also builds for me, so tested-and-acked by if that is a think :) Dec 09 11:31:46 upstream accepted the change already btw Dec 09 11:31:47 I see your point, but there are already more than 200 issues in packages repository and some of them are feature request which can be moved there. Dec 09 11:31:54 so with the next bump we can get rid of the patch again Dec 09 11:32:05 jow: excellent! Dec 09 11:32:12 jow: thanks a lot for this Dec 09 11:37:18 yw Dec 09 11:39:43 hmm wish I knew when 19.07.5 was dropping so I could have backported kambs Dec 09 11:39:55 *ksmbd Dec 09 11:45:05 mangix: you can backport any non-image-included packages at any time Dec 09 11:47:41 jow: the problem is this: https://github.com/openwrt/packages/issues/12599 Dec 09 11:48:41 ah I see Dec 09 11:49:25 current version has many bugfixes Dec 09 11:49:52 courtesy of xdarklight Dec 09 12:02:19 19.07.6 is dropping anytime soon Dec 09 12:02:50 is that likely to be a simple opkg update, or more involved, ynezz? Dec 09 12:05:37 you can't update kernel that way Dec 09 12:08:43 > yeah, what I suspected. what about a semi-painless way to update an install on exroot? Dec 09 12:09:40 also, has anyone considered a mechanism to update the kernel by downloading and deploying on reboot? or is that too complex? Dec 09 12:25:09 -or- failing that, a LuCI feature that builds on the various backup/restore scripts out there, backing up all relevant configs together with a list of installed apps, with the option to import the backup to restore a previous setup post-upgrade. Dec 09 12:25:55 mangix: I just saw your pull request. Do you have a link to the upstream multi-CPU port DSA patch? :) Dec 09 13:45:52 jow: what's the rationale behind 65fad8645d72f2293a7d62d6ca338ebc2ee0d9de ? Dec 09 14:28:07 rsalvaterra: it was referenced in that PR Dec 09 14:28:23 Sorry, must have missed it. Dec 09 14:31:53 ynezz: who cuts the releases? Dec 09 15:10:42 mangix: if you look at the commits, it's mostly Hauke, he's sending usually emails few weeks in advance Dec 09 16:28:33 if i have a package mandating openssl, will wolfssl/mbedtls still make any sense at all? wolfss itself is 400K Dec 09 16:29:52 trying to switch all to openssl and see how much space it can save, the ideal world will be all packages be ssl-neutral Dec 09 17:25:39 ynezz: real world failures with canonical mirrors having expired / selfsigned certs Dec 09 17:26:18 ynezz: reasoning was that we rely on hashes to verify integrity, HTTPS only adding complexity at best Dec 09 17:27:27 modern CDNs even mass-produce throw-away certs for dozens of sites they're caching, so I really don't see any merit in turning random cert quirks into hard failures Dec 09 17:27:48 but I can live with reverting it if it makes the security fanboys happy Dec 09 17:31:24 s/canoical mirrors/canonical sources/, as in random project sites hosting tarballs Dec 09 17:31:36 likely not that much of an issue nowadays, its all github, sourceforge or aws anyway Dec 09 17:34:15 jow Are you happy with this type of patch being sent in to add short descriptions in to LuCI? https://github.com/openwrt/luci/pull/4649/commits/9060c129155e018567716d3f9cfe75b0accf6dc5 Dec 09 17:34:20 WMM and hidden SSIDs I see as low hanging fruit - they are often misconfigured Dec 09 19:15:32 this looks interesting: https://github.com/rufengsuixing/luci-app-adguardhome .. has anyone installed it? Dec 09 19:16:18 adguardhome is being packaged for 20.x so it might be an idea to see if it's worth making that available? Dec 09 19:21:24 jow: ok, makes sense, there is no commit description, so had to ask :) Dec 09 19:26:32 jow: it has been a while since i used openssh-sftp-server for luci, does dropbear work with openssh-sftp-server or i have to use openssh to replace dropbear? I'm running dropbear with openssh-sftp-server but sshfs complains "remote host has disconnected" Dec 09 19:28:06 not yet messed with sshfs, but sftp works fine with the openssh package. Dec 09 19:28:50 dorf: for sure, i just don't recall if i need openssh-server for sftp, or dropbear server can work, don't want to use openssh server due to size Dec 09 19:29:08 I never bothered to uninstall dropbear, but I did install the ssh server. Dec 09 19:30:16 openssh-sftp-server and *sftp-cient Dec 09 19:30:37 sorry, that's probably not much help. Dec 09 19:34:10 I'm guessing you probably need those for the sftp service, rr123. Dec 09 19:37:52 also, I didn't install the openssh-server package. Dec 09 19:38:13 So in short, the opensftp-server and opensftp-client packages will work with dropbear. Dec 09 19:40:51 mkdir -p /tmp/xyz && sshfs root@192.168.1.1:/usr/lib /tmp/xyz Dec 09 19:41:14 can you try that? I have dropbear + openssh-tftp-server but the above command will: remote host has disconnected Dec 09 19:44:12 if I must. how do I specify a port with sshfs? Dec 09 19:44:29 ssh is not running on port 22 here. Dec 09 19:48:58 -o port=PORT Dec 09 19:49:37 mkdir -p /tmp/xyz && sshfs root@192.168.1.1:/usr/lib /tmp/xyz -p 3453 Dec 09 19:49:41 karlp: what it you that emailed me the link to the “procd init script parameters” wiki page? Dec 09 19:50:21 seems like some of the hooks are undocumented, like “service_started()”, etc. Dec 09 19:52:17 works for me, rr123. Dec 09 19:52:43 and no, it's not -p it's -o port= Dec 09 19:57:46 dorf:thanks for testing, does not work for me still, testing Dec 09 19:58:11 that's what i kind of remembered, that dropbear + openssh-sftp-server should work Dec 09 19:58:20 sure thing. sounds like a permissions issue of sorts. Dec 09 19:58:42 did you disabled password logins in dropbear? Dec 09 20:02:02 also, maybe logread will give you some insight into what the issue is. Dec 09 20:08:05 logread was not helping, just show (root) exited, i use ssh public key access which worked fine for ssh access Dec 09 20:16:55 maybe try with a password, see if it's an issue with key access? Dec 09 20:22:51 tries that , something else is wrong, just revert some changes in my ssh_config, not helping either Dec 09 20:25:00 i can sshfs to other host just fine Dec 09 20:47:21 philipp64: I may have at some point, not recently? yeah, people keep adding things and then not documenting them, I cnat do much abotu that :) Dec 09 20:48:57 maybe rmilecki can fix that if he gets bored... Dec 09 20:55:41 rr123: openssh-sftp-server works with dropbear Dec 09 20:55:44 it does not replace it Dec 09 20:56:34 jow: you're a little late to the party! Dec 09 21:05:32 thanks, i found the problem, i was replacing wolfssl with openssl as i need openssl anyway so why adding the 400KB wolfssl, in the process I enabled cryptodev, then disable it as i realize my ath79 probably does not have it supported, then i mistakenly disable openssh engine support, it's place holder but must be on, otherwise sftp won't run. now it works, no openssh-server needed. Dec 09 21:05:59 \o/ Dec 09 21:06:08 s/openssh engine support/openssl engine suport/ Dec 09 21:06:37 jow: you around? seeing something weird in IPsec… Dec 09 21:06:50 Dec 7 18:12:46 OpenWrt2 ipsec: 12[NET] received packet: from 45.33.216.244[500] to 192.168.254.2[500] (617 bytes) Dec 09 21:07:00 what would cause that reflection? Dec 09 21:07:51 * rr123 finally ready to play with luci js files Dec 09 21:10:51 jow: I just ran “iptables-save | less” but nothing looks like a culprit (that I could see, anyway) regarding reflection…. And why would reflection happen on traffic coming from the outside, anyway? I thought reflection only happened when you tried to connection (from the inside) to a service on the WAN address… Dec 09 21:11:27 philipp64: uhm no idea, sorry. Dec 09 21:11:44 I usually avoid touching ipsec since it never works as intended for me Dec 09 21:11:50 okay, who knows that part of the firewall? Dec 09 21:12:01 I do, but I fail to see the relation to ipsec Dec 09 21:12:09 * rr123 thought the whole world is already on wireguard Dec 09 21:12:19 or could tell me where to dive into the reflection/NATting? Dec 09 21:12:34 iptables -t nat -nvL ? Dec 09 21:14:31 jow: http://paste.ubuntu.com/p/PPP277SNXb/ Dec 09 21:15:08 https://gitlab.bau-ha.us/mt/owsd-tiny a potential uhttpd-mod-ws? after 2 days I have not given up on websockets... Dec 09 21:15:33 only 53KB Dec 09 21:15:36 lol Dec 09 21:16:01 a ws proxy for uhttpd will open lots of doors Dec 09 21:16:05 hahaha.. 53K! Dec 09 21:16:11 that's HUUUUUUUGE! Dec 09 21:16:27 53KB is static, come on Dec 09 21:18:23 I'm kidding, but I don't think jow is :) Dec 09 21:18:25 why do we need websockets? Dec 09 21:18:39 I mean, what use case exactly do they address? Dec 09 21:18:55 non-linear server-side updates. Dec 09 21:19:00 evensource? Dec 09 21:19:23 jow: can we remove iftop from openwrt.git? Dec 09 21:19:28 aparcar[m]: sure Dec 09 21:19:40 you're the maintainer just checkin Dec 09 21:20:01 for a long-running backend process I do not need poll, embedded boards sometimes take time to run certain process(for seconds or even longer) Dec 09 21:20:35 jow: maybe graphs -> connections is a good trial candidate for websockets.. Dec 09 21:20:42 it's next to useless as is. Dec 09 21:20:51 dorf: can be implemented using evensource Dec 09 21:20:55 *eventsource Dec 09 21:22:03 * enyc meows Dec 09 21:23:46 eventsource > websockets? Dec 09 21:24:03 WS can transmit both binary data and UTF-8, SSE is limited to UTF-8(no binary support) Dec 09 21:24:05 mangix: mind becoming the maintainer of iftop? Dec 09 21:24:38 rr123: yes, but do you intend to decode binary data in luci? Dec 09 21:25:06 I know that it is useful for bidirectional data streaming, think video conferencing etc. Dec 09 21:25:17 but as a "better poll" alternative it is bloated mess ihmo Dec 09 21:25:51 the protocol is complicated, the implementations are complex and huge, and the requirement of persistent connections easily opens DoS vectors without further limiting measures Dec 09 21:26:22 jow: no, not a firewall problem. Strongswan is generating traffic from an interface that’s NOT the one facing the default route… Dec 09 21:26:46 hence it getting NATted on the outgoing masquerade… Dec 09 21:26:50 philipp64: was about to write that... your DNAT/SNAT rule list is quite empty Dec 09 21:26:51 jow: https://bugs.openwrt.org/index.php?do=details&task_id=2248&order=status&sort=desc can uhttpd do eventsource now Dec 09 21:27:07 Dec 7 18:12:46 OpenWrt2 ipsec: 09[NET] sending packet: from 192.168.254.2[500] to 45.33.216.244[500] (584 bytes) Dec 09 21:27:15 WTF... Dec 09 21:27:16 rr123: yeah, Rafal implemented it last month Dec 09 21:27:16 jow: eventsource sounds good to me. Dec 09 21:27:41 potentially better than websockets, unidirectional.. no need for bidirectional communication. Dec 09 21:28:07 ok I'm going to play with that, I never intend to play games within luci anyways Dec 09 21:29:18 eventsource is a new one to me, but it looks pontentially a better fit. Dec 09 21:29:50 downside of eventsource is that the EvenSource() client API does not allow setting custom headers, so no way to pass the token using Authorization: or Cookie: Dec 09 21:30:00 is the max 6 connections if !http/2 an issue? Dec 09 21:30:19 remains to be seen Dec 09 21:30:41 then how to do authentication in luci Dec 09 21:31:04 rr123: we need to allow passing the session token via query string for EventSource requests Dec 09 21:31:48 https://stackoverflow.com/questions/28176933/http-authorization-header-in-eventsource-server-sent-events Dec 09 21:32:07 the 6-connection limit is so brain-dead Dec 09 21:32:19 i mean, why 6 Dec 09 21:33:16 put session token in query string brings back the old luci style to me Dec 09 21:33:32 https://github.com/Yaffle/EventSource Dec 09 21:33:54 query strings, not good unless https Dec 09 21:34:39 at least that polyfill is being actively maintained. Dec 09 21:35:48 "If you are using HTTP Basic Authentication, you can embed credentials into the URL - http://username:password@github.com" Dec 09 21:37:36 rr123: 6 sounds like something Mozilla et al dreamt up and never bothered to fix.. "oh, we'll just make everyone use http/2" Dec 09 21:37:49 aparcar[m]: why? Dec 09 21:38:08 mangix: because you're bumping so many things anyway *duck* Dec 09 21:38:25 Mozilla have form, anyways. Took them years to fix the 10 second socks timeout. Dec 09 21:44:51 aparcar[m]: doesn't mean I want to maintain them Dec 09 21:45:07 i don't use iftop either Dec 09 21:45:24 mangix: just asking 🙂 Dec 09 21:45:42 jow: do you mind staying the maintainer if it moves to packages.git? Dec 09 21:45:48 I guess I can do it because it doesn't receive any updates anyway Dec 09 22:30:33 aparcar[m]: fine with me Dec 09 22:45:41 jow: fine to stay maintainer in packages.git or me becoming the maintainer? Dec 09 22:46:35 aparcar[m]: both actually. But since I am neither using nor updating iftop, it might make sense if you take it over Dec 09 22:57:19 jow: I'll take over. I don't use it much but as it haven't received and update in 2 years the involved work seems doable Dec 09 23:02:06 thanks Dec 09 23:02:36 jow: poke since you maintain this: https://patchwork.ozlabs.org/project/openwrt/patch/20201109070922.23088-1-rosenp@gmail.com/ Dec 09 23:05:08 hahahahaha https://github.com/openwrt/openwrt/commit/7f285d0b436c4b05a89c78ef3f1910d6f78040da Dec 09 23:05:22 makes sense someone would get irritated by that Dec 09 23:06:54 mangix: can you ping me about that tomorrow? Dec 09 23:06:59 ok Dec 09 23:07:07 hanks! Dec 09 23:07:57 oh nice. lldpd builds on the buildbots again Dec 09 23:08:29 is there any way to get alerts about packages not building ? Dec 09 23:09:44 quite interesting that nobody reported this earlier. I guess it means it doesn't have many users. Dec 09 23:10:03 for me it's a basic feature of a network device, which is why I will veto its move to the packages feed Dec 09 23:12:21 * mangix has no idea what lldpd is Dec 09 23:12:39 enterprise switch all has it, home users no need Dec 09 23:12:54 layer2 vendor compatibility stuff as I recall Dec 09 23:18:06 link layer discovery protocol, basically device X announces itself and some of its capabilities to device Y and vice versa Dec 09 23:19:51 on my switch, it gives this handy info: Dec 09 23:19:52 https://bpa.st/F65Q Dec 09 23:20:20 so if I forgot which switchport goes to which devices, this is very helpful Dec 09 23:20:52 aside from the crappy Cisco SG200-08 on MultiGE0/0/15 =) Dec 09 23:23:11 Does anyone know if there is a good way to get events from the kernel when it learns about new mac-addr (arp) ? hotplug.d/neigh is not enough because it is based on dnsmasq/dhcp. Dec 09 23:25:25 ip monitor neigh ? Dec 09 23:25:43 never used tbh but might be useful Dec 09 23:26:04 stintel, I learned something new today. Thanks Dec 09 23:26:29 welcome :) Dec 09 23:27:03 What would you say about letting it be an option to run this and plugging it into hotplug.d/neigh ? Anyone find it useful maybe? Dec 09 23:28:08 sounds like a DoS vector Dec 09 23:28:54 For me it is about being able to list clients on the network who have set a static IP Dec 09 23:30:12 there might be other options Dec 09 23:42:07 I was thinking prometheus and node_exporter, but seems the lua version doesn't expose arp entries Dec 09 23:42:18 sounds niche Dec 09 23:44:37 what about a small sh script to expose `arp -a` Dec 09 23:45:19 I think Ill skip adding this extra unnecessary arp-entries checker. I wanted to get a list of client devices reliably. hotplug.d/dhcp and hostapd_cli to catch wifi connect/disconnect catches almost all clients Dec 09 23:46:06 The only ones I'll be missing are the ones that connect via cable and incorrectly do not use dhcp and set a static IP. Those clients will never be listed Dec 09 23:47:55 * rr123 did not see hotplug.d on the master build at all Dec 09 23:48:34 barhom: monitoring netlink is the only reliable way to detect new neighbour entries Dec 09 23:49:06 ip neigh monitor does exactly that, but depending on how you implemented your solution, subscribing to a netlink socket in C might be easer Dec 09 23:49:15 compared to scraping "ip monitor" output Dec 09 23:49:38 altenratively poll /proc/net/arp Dec 09 23:50:12 I do not see why i shouldn't use ip monitor neigh if I want to subscribe to this. Feels easy enough in bash, read each line and run whatever script you want Dec 09 23:50:47 jow, do you think hotplug.d/neigh should get updates or is it too much spam? Dec 09 23:55:06 I think it Dec 09 23:55:22 'll overwhlem the event system in case of high neighbour activity Dec 09 23:56:33 yeh, I think Ill skip this whole chapter for now. Enough with dhcp+hostapd_cli Dec 09 23:58:08 It was quite cumbersome to add hostapd_cli to startup. The only good way I could find was ti add it in hotplug.d/net/ Dec 09 23:58:13 with this script, https://0bin.net/paste/mYEhK3aF#TFUvMF6FI5J+xxBXkuMTirHQBmyOUNUzLC+fXN53VYg Dec 09 23:58:46 I wish I could remove the sleep and start it more reliably Dec 10 01:05:03 git diff Dec 10 01:05:06 whoops **** ENDING LOGGING AT Thu Dec 10 02:59:56 2020