**** BEGIN LOGGING AT Tue Jun 02 02:59:57 2020
Jun 02 06:30:31 <rmilecki> i'm personally using two backported patches in my 19.07 builds:
Jun 02 06:30:35 <rmilecki> ddf6ec29b477 ("procd: allow usage of * as procd_running() instance parameter")
Jun 02 06:30:37 <rmilecki> ed5b9129d7a4 ("base-files: implement generic service_running") (ynezz)
Jun 02 06:31:00 <rmilecki> they allow checking service state, e.g. /etc/init.d/dropbear running && echo yes || echo no
Jun 02 06:31:34 <rmilecki> should I cherry-pick them officially to 19.07 branch? or is that too big * risky feature
Jun 02 06:31:48 <rmilecki> ynezz: nice patch btw!
Jun 02 06:37:50 <jow> rmilecki: "base-files: implement generic service_running" broke various packages
Jun 02 06:37:58 <jow> so you need to backport all those as well
Jun 02 06:38:15 <jow> I'd personally skip that one
Jun 02 07:01:34 <rmilecki> jow: thanks for letting me know!
Jun 02 07:06:03 <rmilecki> jow: do you remember some package that was broken by it? i was looking for relevant Fixes: but I didn't find anything
Jun 02 07:30:33 <ynezz> rmilecki: https://github.com/openwrt/packages/pull/10061
Jun 02 08:01:50 <ynezz> thats a deprecation notice! You are downloading ShellCheck from an outdated URL! PS: Sorry for breaking your build :(
Jun 02 08:28:56 <blogic> yawn
Jun 02 09:02:05 <dwmw2_gone> gr, my home network is broken and I can't manage to debug it.
Jun 02 09:02:51 <dwmw2_gone> I think some of the switches are eating packets, perhaps because something is echoing them from the wrong place and the switch is learning a wrong topology.
Jun 02 09:03:04 <dwmw2_gone> Which means a client doesn't get its DHCP response from the router.
Jun 02 09:07:57 <ynezz> get some proper switch?
Jun 02 09:08:33 <dwmw2_gone> it's built in to the router
Jun 02 09:10:01 <dwmw2_gone> maybe throw out all the switches and use hubs :)
Jun 02 09:10:13 <ynezz> IIRC one can see the MACs on the particular switch ports
Jun 02 09:10:23 <dwmw2_gone> or go the other way and get even more expensive switches that.... let me do that.
Jun 02 09:11:05 <dwmw2_gone> it was OK with two openwrt boxes plugged into each other directly (and the wired network via an external switch, from a different port on the main router)
Jun 02 09:11:20 <dwmw2_gone> wireless clients were either directly on the wireless of the main router, or they were out *one* physical port, on the other AP.
Jun 02 09:11:49 <dwmw2_gone> plugging a new AP into the wired network via the big switch — or directly into a different port on the main router — means that roaming clients stop getting responses.
Jun 02 09:15:22 <ynezz> if that DHCP response is send out, where does it ends?
Jun 02 09:16:14 <dwmw2_gone> At one point I put a different Linux box with two Ethernet ports, as a bridge, in between the lantiq box and the wired network with a suffering client.
Jun 02 09:16:32 <dwmw2_gone> tcpdump on the lantiq box showed the DHCP response going out *that* port.
Jun 02 09:16:43 <dwmw2_gone> tcpdump at the other end of the wire showed nothing (no drop, no bad crc)
Jun 02 09:17:17 <dwmw2_gone> Now I've tried plugging everything in via the main switch; only *one* port being used on the lantiq box. It's still happening.
Jun 02 09:17:29 <dwmw2_gone> I only ever saw it when I started plugging in the new RT-AC85P.
Jun 02 09:18:27 <dwmw2_gone> I wonder if it's that which is occasionally bouncing packets back, causing the switches to learn the wrong location for that MAC address. But that wouldn't explain it when the suffering client is *on* that wireless. Which is mostly the case.
Jun 02 09:18:50 <dwmw2_gone> I got it to happen for a wired client at one point, when moving wires around on the lantiq so even a wired client changed ports.
Jun 02 09:19:08 <dwmw2_gone> and that was weird; I set up IPv6 and left it pinging, and about 6 of 600 pings did actually work.
Jun 02 09:19:19 <dwmw2_gone> I tried a different cable after that. Didn't make a difference.
Jun 02 09:19:29 <dwmw2_gone> Considering a priest next.
Jun 02 09:23:13 <blogic> dwmw2_gone: packet excorcist
Jun 02 09:27:39 <dwmw2_gone> I don't even know how to debug it further.
Jun 02 09:28:00 <dwmw2_gone> Is there a way to query the lantiq switch about which packets it's sending where?
Jun 02 09:28:10 <blogic> probably not
Jun 02 09:28:11 <dwmw2_gone> And if I've made each port a separate vlan should it even fuck me over like that at all ?
Jun 02 09:28:31 <dwmw2_gone> I deliberately used WAN and LAN ports when I was using two ports, so that the switch didn't even get to decide.
Jun 02 09:28:53 <dwmw2_gone> I sure as hell hope it wasn't sending packets for one vlan out the wrong port just because of switch learning topology
Jun 02 09:29:39 <ynezz> there are mib counters on the switch
Jun 02 09:29:45 <ynezz> swconfig
Jun 02 09:30:02 <ynezz> packet counters
Jun 02 09:30:07 <ynezz> per port
Jun 02 09:30:29 <dwmw2_gone> that's going to be hard to correlate with a single packet
Jun 02 09:30:46 <dwmw2_gone> better than all the other options I haven't got though :)
Jun 02 09:34:07 <owrt-snap-builds> build #142 of bcm63xx/smp is complete: Failure [failed images]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/142  blamelist: ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Jun 02 09:42:55 <dwmw2_gone> ynezz: how do I get them ?
Jun 02 09:43:17 <ynezz> via swconfig
Jun 02 09:43:29 <dwmw2_gone> root@lantiq:~# swconfig dev eth0 port 1 show
Jun 02 09:43:29 <dwmw2_gone> Port 1:
Jun 02 09:43:29 <dwmw2_gone> 	uvr: 0
Jun 02 09:43:29 <dwmw2_gone> 	vsr: 0
Jun 02 09:43:30 <dwmw2_gone> 	vinr: 0
Jun 02 09:43:30 <dwmw2_gone> 	tvm: 0
Jun 02 09:43:33 <dwmw2_gone> 	pvid: 1
Jun 02 09:43:33 <dwmw2_gone> 	link: port:1 link:up speed:1000baseT full-duplex auto
Jun 02 09:45:15 <ynezz> eth0 is switch?
Jun 02 09:45:21 <ynezz> it's usually switch0
Jun 02 09:45:59 <dwmw2_gone> root@lantiq:~# swconfig list
Jun 02 09:46:00 <dwmw2_gone> Found: switch0 - eth0
Jun 02 09:46:15 <dwmw2_gone> I can use 'switch0' instead of 'eth0' with swconfig too.
Jun 02 09:56:20 <rmilecki> some switches (drivers) don't expose counters :(
Jun 02 09:58:59 <karlp> sometimes it's just disabled as it has a perf cost
Jun 02 10:08:18 <ynezz> dwmw2_gone: http://sprunge.us/fngHN6
Jun 02 10:08:39 <ynezz> search for `swconfig dev switch0 show`
Jun 02 10:09:51 <dwmw2_gone> shiny.
Jun 02 10:10:22 <dwmw2_gone> Doesn't have VDSL though. Otherwise I might be tempted to replace the lantiq.
Jun 02 10:10:33 <dwmw2_gone> Is there anything else that has VDSL?
Jun 02 10:19:37 <ynezz> what switch is that?
Jun 02 10:19:54 <ynezz> maybe you can expose those counters if you've the datasheet
Jun 02 10:20:41 <dwmw2_gone> it's the built-in lantiq xrx200 switch.
Jun 02 10:23:01 <ynezz> get_port_stats = xrx200sw_get_port_stats, //TODO
Jun 02 10:23:02 <ynezz> :)
Jun 02 10:23:29 <dwmw2_gone> :)
Jun 02 10:24:10 <zorun> maybe get a simple VDSL bridge instead, so that you have much more choice for the router?
Jun 02 10:24:15 <zorun> the Planet VC-231 is expensive but is really stable
Jun 02 10:24:23 <dwmw2_gone> Right now the second AP (which has always existed) and the new third AP are both plugged in via the *same* port in the lantiq, via the external main switch (which I suppose I now ought to put onto the UPS)
Jun 02 10:24:29 <zorun> you just have to make sure your VDSL DSLAM is using 17a
Jun 02 10:25:05 <dwmw2_gone> Profile:                                  17a
Jun 02 10:25:10 <zorun> great
Jun 02 10:26:09 <ynezz> the switch is already counting the bytes/packets
Jun 02 10:28:03 <ynezz> so you just need to expose them in that callback/ops
Jun 02 10:28:20 <dwmw2_gone> What I really want is the MAC list for each port.
Jun 02 10:28:47 <dwmw2_gone> but I'm not sure I can even blame it now. I need to sniff between it and the main switch now, and see if it's sending those responses.
Jun 02 10:29:13 <dwmw2_gone> if it isn't sending the responses now when there's only one port to send them out, that's even worse.
Jun 02 15:40:51 <ynezz> noltari: git log -p -1 scripts/config/mconf_check ? :)
Jun 02 15:59:18 <f00b4r0> https://www.theregister.com/2020/06/01/linux_5_7/
Jun 02 15:59:33 <f00b4r0> finally, we can get rid of VT100 terminals :)
Jun 02 16:14:09 <noltari> ynezz: ah shit, I knew I would end up adding that...
Jun 02 16:23:01 <noltari> ynezz: fixed, sorry for that
Jun 02 17:35:07 <guifipedro> can someone point me where should be the patch when I want to touch a file in target/linux/ath79/image ? https://forum.openwrt.org/t/lost-trying-to-apply-custom-patch-related-to-target-linux-ath79-image/65675
Jun 02 17:38:22 <Borromini> guifipedro: this is not a patch you can drop into one of the openwrt kernel patch trees; you should just apply it to your tree
Jun 02 17:38:48 <Borromini> wget https://patch-diff.githubusercontent.com/raw/openwrt/openwrt/pull/3063.patch -O test.patch && git am test.patch
Jun 02 17:39:12 <guifipedro> thanks for answering :D
Jun 02 17:39:29 <Borromini> yw;
Jun 02 17:39:39 <Borromini> glad to help ;)
Jun 02 17:39:58 <Borromini> you were probably confused because of how the kernel patches work
Jun 02 17:41:48 <guifipedro> I got confused because all the other patches I could succesfully applied in several locations like `package/firmware/wireless-regdb/patches`, `feeds/routing/bmx6/patches/`, `package/network/config/netifd/patches/`, `target/linux/generic/files/drivers/net/phy/patches/`
Jun 02 17:42:12 <guifipedro> but my workflow uses shell, so it is very easy to do in lots of ways, yea
Jun 02 17:48:29 <Borromini> yes, but those patches are for the upstream code, not for OpenWrt code (like scripts or Makefiles, in this case)
Jun 02 17:48:47 <Borromini> all the patch directories are meant so you can build on vanilla upstream
Jun 02 17:48:52 <Borromini> * vanilla upstream code
Jun 02 17:51:18 <guifipedro> Borromini: thanks, for me is very clear in the packages and feeds situation, but intrigued why it works inside target/linux/generic, that looks to be openwrt itself (?)
Jun 02 17:53:48 <Borromini> guifipedro: yes, i don't know about the intricacies, but looking at the kernel refresh script might help you: https://github.com/KanjiMonster/maintainer-tools/blob/master/update_kernel.sh
Jun 02 17:54:42 <Borromini> the logic applied to patching packages might be very similar to what's used to refresh and apply the kernel patches ^^
Jun 02 18:40:02 <guifipedro> Borromini: oh! as said by grommish in https://forum.openwrt.org/t/lost-trying-to-apply-custom-patch-related-to-target-linux-ath79-image/65675/4 you cannot patch a makefile! ok! that makes sense!
Jun 02 18:41:24 <Borromini> you can, but through git, like you did. not through the openwrt build system
Jun 02 18:41:35 <guifipedro> yea :D
Jun 02 18:41:50 <Borromini> :)
Jun 02 19:49:24 <mangix> jow: ping
Jun 02 19:49:45 <jow> mangix: pong
Jun 02 19:50:24 <mangix> can we get gcc multilib installed on the buildbots? luajit and node are not compiling for that reason.
Jun 02 19:50:33 <jow> no
Jun 02 19:51:11 <jow> I don't have access to all builders and I also lack the time to coordinate a cluster wide update atm
Jun 02 19:53:15 <mangix> k. a user was requesting node on his arm32 platform
Jun 02 22:51:15 <russell--> what is the status of vlan configuration, e.g. tagged-on-egress, with DSA?
Jun 03 00:02:20 <owrt-snap-builds> build #143 of bcm63xx/smp is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fsmp/builds/143
Jun 03 02:50:24 <owrt-snap-builds> build #393 of mediatek/mt7623 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/393  blamelist: Petr ?tetiar <ynezz@true.cz>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Jun 03 02:51:30 <owrt-snap-builds> build #398 of ramips/rt3883 is complete: Failure [failed kmodconfig]  Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt3883/builds/398  blamelist: Petr ?tetiar <ynezz@true.cz>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Jun 03 02:51:45 <owrt-snap-builds> build #389 of armvirt/32 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/389  blamelist: Petr ?tetiar <ynezz@true.cz>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Jun 03 02:52:52 <owrt-snap-builds> build #387 of mediatek/mt7622 is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7622/builds/387  blamelist: Petr ?tetiar <ynezz@true.cz>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>
Jun 03 02:53:09 <owrt-snap-builds> build #388 of cns3xxx/generic is complete: Failure [failed defconfig dltar]  Build details are at http://buildbot.openwrt.org/master/images/builders/cns3xxx%2Fgeneric/builds/388  blamelist: Petr ?tetiar <ynezz@true.cz>, ?lvaro Fern?ndez Rojas <noltari@gmail.com>
**** ENDING LOGGING AT Wed Jun 03 02:59:57 2020