**** BEGIN LOGGING AT Thu Apr 29 02:59:57 2021
Apr 29 04:22:10 <philipp64> shibboleth: "stop whatever you're doing and get a better grip on the basics".... meaning what?
Apr 29 04:22:55 <philipp64> tmn505: I can get the base image back into the box, but that doesn't help me.  I'm trying to get a tailored image into the box and have it boot successfully and I'm not sure what that's failing.
Apr 29 06:37:53 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 98.1% packages reproducible in our current test framework.)
Apr 29 06:53:05 <philipp64> tmn505: usually when I do this sort of work I have development models of the platform with JTAG's or serial ports soldered on...
Apr 29 06:55:57 <PaulFertser> philipp64: it doesn't take a development version to attach serial console (not rs-232 though)
Apr 29 06:56:28 <philipp64> Okay, so how do I get a console onto an Archer A7 v5?
Apr 29 06:56:39 <PaulFertser> philipp64: in your initial question it's unclear who/what gets the image. Are you following the instructions in the commit message?
Apr 29 06:57:47 <philipp64> sorry, which commit message?
Apr 29 06:57:51 <PaulFertser> philipp64: https://openwrt.org/toh/tp-link/archer_a7_v5 talks about serial
Apr 29 06:58:04 <PaulFertser> philipp64: commit message of the commit which added support for this board.
Apr 29 06:58:46 <PaulFertser> philipp64: it clearly tells what to do.
Apr 29 06:59:06 <philipp64> I take the -sysupgrade-factory.bin image and copy it to /tftpboot/ArcherC7v5_tp_recovery.bin and then follow the steps here: https://openwrt.org/toh/tp-link/archer_a7_v5#installation_using_the_tftp_method
Apr 29 07:01:01 <PaulFertser> philipp64: that sounds about right, but what exactly happens is unclear without serial output
Apr 29 07:02:08 <philipp64> this commit? 1e4ee63cc8d1889a78b539a5ed7be8d56e9b976f
Apr 29 07:02:14 <philipp64> reading it now...
Apr 29 07:03:46 <philipp64> Not sure what's meant by "Make sure you have shorten R24 on the PCB" here: https://openwrt.org/toh/tp-link/archer_a7_v5#serial
Apr 29 07:04:56 <PaulFertser> philipp64: it refers to some part of C7 instructions
Apr 29 07:05:29 <PaulFertser> Appalently there's a placeholder for resistor with R24 designator and it should be shorted.
Apr 29 07:07:55 <PaulFertser> philipp64: size of the image that you mention sounds wrong.
Apr 29 07:08:35 <PaulFertser> philipp64: https://downloads.openwrt.org/releases/21.02.0-rc1/targets/ath79/generic/openwrt-21.02.0-rc1-ath79-generic-tplink_archer-a7-v5-squashfs-factory.bin is about 5.5 MB
Apr 29 07:08:35 <philipp64> I might be tired, but I'm looking at https://openwrt.org/toh/tp-link/archer_c7#version_50 and can't tell what's supposed to happen.
Apr 29 07:09:25 <philipp64> sorry, image was 12.9MB... dropped a decimal point.
Apr 29 07:10:12 <PaulFertser> philipp64: that's still odd
Apr 29 07:10:26 <PaulFertser> philipp64: is that something you self-compiled?
Apr 29 07:17:49 <philipp64> yes.  I've enabled strace, gdb, valgrind... I need to debug some management software under development.
Apr 29 07:35:44 <PaulFertser> philipp64: I suggest you try to flash the factory image built by the buildbots
Apr 29 07:35:53 <PaulFertser> philipp64: then if it works you can sysupgrade to your own
Apr 29 07:59:05 <PaulFertser> philipp64: it's possible that u-boot is using a severely limited memory region when fetching from tftp so the size might be essential there
Apr 29 07:59:26 <philipp64> hmm... no, seems to have been something else.
Apr 29 08:00:09 <philipp64> OutBackDingo sent me a .config that I substituted in and it booted better, so I probably had a kmod that was causing the build to fail...
Apr 29 08:00:45 <OutBackDingo> YAY!
Apr 29 08:03:41 <PaulFertser> philipp64: but are you able to boot vanilla upstream OpenWrt image?
Apr 29 08:05:10 <PaulFertser> philipp64: additional kmods are loaded after pre-init so you should be able to enter generic failsafe even if such a bad kmod is present.
Apr 29 08:05:52 <PaulFertser> philipp64: I'm asking about vanilla image because it's essential for the upcoming release. If the factory image from it doesn't work it should better be fixed during the RC stage.
Apr 29 08:06:51 <philipp64> PaulFertser: it might also be some other reason, like me having bad CONFIG_KERNEL_* settings...
Apr 29 08:07:14 <PaulFertser> philipp64: regarding the serial, apparently the board has some resistor divider meant to be used on Rx line, and it's not present so it's probably enough to simply short R24 with a blob of solder. Should be fairly obvious by looking at the board when you have it in your hands.
Apr 29 08:07:29 <philipp64> but to answer you, I had been running https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_archer-a7-v5-squashfs-factory.bin just fine.
Apr 29 08:08:00 <PaulFertser> philipp64: ok, that's good to know. So you have a solid recovery path now no matter what.
Apr 29 08:08:19 <philipp64> Yup.
Apr 29 08:15:50 <philipp64> PaulFertser: thanks for the pointers.
Apr 29 08:25:15 <PaulFertser> philipp64: best of luck with your debugging. BTW, do you know OpenWrt has a convenient script to use gdbserver so in cases where valgrind is not needed you might benefit from that. Also valgrind can be used as a gdbserver too.
Apr 29 08:26:17 <philipp64> did not know that, no...
Apr 29 08:26:24 <philipp64> Do I need vgdb?
Apr 29 08:27:03 <PaulFertser> philipp64: it's integrated in valgrind, you can just run it in a way so that it stops on the first error, then you attach gdb from your host, the OpenWrt script gives you all the sources and debug info etc.
Apr 29 08:28:17 <PaulFertser> philipp64: so basically you can add gdbserver even to the very constrained targets and then debug whatever you need by running gdb on host, nothing special needed, no flash space on target wasted (in case you just need debugging and not valgrind).
Apr 29 09:12:40 <aparcar[m]> jow: thoughts on a notification daemon service? https://github.com/openwrt/luci/issues/5018
Apr 29 09:42:23 <aparcar[m]> nick: ping
Apr 29 10:21:54 <nick[m]1> aparcar thanks for merging!!!
Apr 29 10:22:46 <nick[m]1> The sxtsq are running for several months without any problem in our Network
Apr 29 10:23:28 <aparcar[m]> nick: amazing
Apr 29 10:53:31 <nick[m]1> aparcar: you made a lot of people happy. directly got a notification in my freifunk channel with people being happy that the stuff is merged.
Apr 29 10:53:36 <nick[m]1> xD
Apr 29 11:01:33 <rsalvate_> ldir: I'm going to start tagging you in my bump pulls, otherwise it's duplicated work. :) https://github.com/openwrt/openwrt/pull/4123
Apr 29 11:05:35 <ldir> rsalvaterra: fair enough - I was just looking at pushing 'my' bump when you posted that - you can be bothered with commit messages...I was lazy and hadn't done that yet :-)
Apr 29 11:05:47 <rsalvaterra> ldir: Oh, this is weird. I got confused.
Apr 29 11:06:06 <ldir> ???
Apr 29 11:06:28 <rsalvaterra> I thought you and also done the bump, since in your tree it shows you as the author.
Apr 29 11:07:16 <ldir> yes I had, but not yet pushed to master... I was thinking about pushing to master and coming up with a suitable commit message when you irc'd me :-)
Apr 29 11:07:30 <rsalvaterra> And sometimes it shows me as the commiter, which is impossible, thankfully. :P
Apr 29 11:07:56 <ldir> so because I'm lazy I pulled in your PR (github-apply.sh) and pushed that instead :-)
Apr 29 11:08:01 <rsalvaterra> Ah, I see. :)
Apr 29 11:09:03 <ldir> surprising to see a bump with no refresh changes though
Apr 29 11:10:06 <ldir> does happen, just not very often
Apr 29 11:10:23 <rsalvaterra> ldir: Indeed, I had to double check, but such is life.
Apr 29 11:10:59 <rsalvaterra> Not many changes… https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y
Apr 29 11:12:19 <rsalvaterra> I was now looking at https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commitdiff;h=a42bc0f9d88e50f8f16e24c07f0b0284d92fd444
Apr 29 11:12:43 <rsalvaterra> Shouldn't the other branch also need the hostsdir change?
Apr 29 11:13:12 <rsalvaterra> (As it's now on top of João's change, here… https://git.openwrt.org/?p=openwrt/staging/ldir.git;a=commitdiff;h=e8a5670122e04574fdb5855ecd63d18f317c5bfd)
Apr 29 11:35:01 <rsalvaterra> Nevermind. Coffee hasn't kicked in.
Apr 29 12:57:47 <aparcar[m]> nick: please say thanks to adrian, roger and whoever else did any actual work. My involvement was half a cup of coffee
Apr 29 12:58:27 <aparcar[m]> ldir: thoughts on the bpf stuff?
Apr 29 13:05:23 <nick[m]1> Thanks to all! :)
Apr 29 13:10:38 <blocktrr1> russell--: try the latest 3 commits from my staging tree for your buffalo
Apr 29 16:44:26 <nick[m]1> aparcar: could we maybe also backport that into 21.02? Othewise the gluon community will not benefit from the SoC. We plan to role out more free wifi in public spaces, since corona... I think this SoC is very good for that (except if there is a window). I would make a PR, or do you think it will be rejected?
Apr 29 16:52:07 <aparcar[m]> nick: I imagine it would be accepted but give it a day or two
Apr 29 16:55:00 <nick[m]1> aparcar: okay I will give it a try. :) but this would require to add mikrotik_nor from current trunk. But worth a try.
Apr 29 16:55:48 <aparcar[m]> well then I don't know - sorry... I don't want to postpone the 21 release any more
Apr 29 16:57:53 <nick[m]1> no problem. it is just a small change. Let me try. ;) thanks for helping.
Apr 29 17:15:35 <nick[m]1> aparcar: https://github.com/openwrt/openwrt/pull/4126 actually, it is not much. just compile testing and at home, I will runtest again.
Apr 29 19:21:30 <aparcar[m]> nick: thanks
Apr 29 19:27:43 <huaracheguarache> Anyone here running 802.11r in their setup? It looks like it's broken in master now. Whenever a client tries to roam I get the following message in the log: "daemon.err hostapd: nl80211: kernel reports: key addition failed"
Apr 29 19:28:16 <huaracheguarache> The first connection attempt fails, but it's able to connect when it tries again.
Apr 29 19:31:16 <huaracheguarache> This happens with the 3 clients that I've tried: an iPad, my laptop running Fedora, and my Nokia 8.1 running Android 11.
Apr 29 20:56:18 <nick[m]1> aparcar: compile and on sxtsq 5 ac runtested.
Apr 29 20:58:46 <aparcar[m]> nick: please comment that in the PR
Apr 29 21:04:29 <nick[m]1> aparcar: done
Apr 29 21:10:09 <aparcar[m]> nick: let's see how it goes
Apr 29 21:10:18 <aparcar[m]> please benchmark your device for a bit
Apr 29 21:27:03 <nick[m]1> okay, let me do some iperf3 tests
Apr 29 21:58:36 <russell--> blocktrr1: thanks, will try
Apr 30 01:06:08 <Grommish> mangix: ping
Apr 30 01:09:43 <mangix> Grommish: pong
Apr 30 01:11:07 <Grommish> mangix: I found https://github.com/openwrt/packages/issues/14179 while researching a "daemon.notice miniupnpd[4452]: private/reserved address checking is ignore" error. Any idea what it's actually trying to do?
Apr 30 01:11:47 <Grommish> Doesn't seem to negatively effect anything, but I figured I'd ask you since you know about the package it seems
Apr 30 01:16:10 <mangix> beats me. miniupnpd badly needs a maintainer.
Apr 30 01:16:48 <Grommish> mangix: Gotcha.  I don't usually use uPNP, but I was testing some things.. Thanks!
Apr 30 01:17:25 <mangix>  AFAIK most uses of upnp are xboxes
Apr 30 01:18:46 <Grommish> Yeah, and Plex
Apr 30 01:19:27 <Grommish> Although just opening/forwarding 3074 works for Xbox well enough
Apr 30 01:19:59 <Grommish> mangix: Are you ever going to officially PR the gcc-gold stuff?
Apr 30 01:20:19 <Grommish> err ld-gold I guess it is
Apr 30 01:20:46 <Grommish> I've been using it since you mentioned it without issues.. It's part of my main branch now
Apr 30 01:23:07 <mangix> if you could do it that'd be great. I would add some numbers.
Apr 30 01:23:22 <mangix> that's the only thing missing IIRC
Apr 30 02:39:54 <russell--> blocktrr1: in your staging tree target/linux/ath79/patches-5.10/411-spi-ath79-add-SPI_MASTER_GPIO_SS-flag.patch doesn't apply
**** ENDING LOGGING AT Fri Apr 30 02:59:56 2021