**** BEGIN LOGGING AT Wed Dec 23 02:59:56 2020 Dec 23 03:23:36 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 97.4% packages reproducible in our current test framework.) Dec 23 03:34:39 build #447 of bcm47xx/legacy is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Flegacy/builds/447 Dec 23 03:36:16 build #438 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/438 Dec 23 04:06:26 looks like the runtime option to disable igdv2 is broken Dec 23 04:06:36 it works if I compile without --igd Dec 23 04:07:58 why did I not try this immediately :/ Dec 23 04:33:05 build #669 of kirkwood/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/kirkwood%2Fgeneric/builds/669 Dec 23 05:24:05 build #745 of ath25/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath25%2Fgeneric/builds/745 Dec 23 06:00:12 How far off a working build for the Xiaomi AX3600? Dec 23 06:00:33 I have seen some talk about it but did not read all the forum posts Dec 23 06:01:36 Last time people were still messing around with stock FW and getting ssh access Dec 23 06:14:09 Last time I heard there's no officialy supported wifi 6 routers at all. There is a build but it's just built from qualcomm's sdk (which only builds openwrt 15.05 or a custom build of linux with a 4.x kernel.) Dec 23 06:18:13 Also the ath11k driver for the wifi card looks like it's really buggy Dec 23 06:19:42 build #735 of at91/sam9x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsam9x/builds/735 Dec 23 06:30:55 ynezz: fixed it ccache patch posted. that was a disaster to fix. Dec 23 06:39:14 Tapper: it will happen, but the timing is completely open Dec 23 06:40:38 Tapper: this https://forum.openwrt.org/t/adding-openwrt-support-for-xiaomi-ax3600/55049/ would be the thread to follow, there are still issues with ath11k crashing and the ethernet side is rather open (problematic) as well Dec 23 06:42:09 Tapper: *if* those issues can be solved, kind of as in a light-bulb going off, it could happen rather quickly (as in "weeks") - maybe błogıc has some ideas to sort this out as well. but right now there is no solution in reach Dec 23 06:43:12 Tapper: but it should be possible, in theory the necessary bits and pieces are available - but they still need quite some re-assembling to form a functioning prototype Dec 23 06:44:54 Tapper: there have been some attempts of staying closer to the QSDK sources, which appear to have been kind of successful - but getting those issues fixed in a way closer to mainline/ OpenWrt compatibility seems to be difficult Dec 23 06:46:26 Tapper: what you can get now, is an english language international OEM firmware from xiaomi - and with some hacking working (persistent) ssh/ telnet and serial console access, underneath is a typical QSDK firmware, based on an old OpenWrt source and then heavily butchered up Dec 23 06:48:28 but it's cheap in comparison to other ipq807x devices (and already uses the v2 chips, which should make a lot of things easier), roundabout 100 EUR for 2*1.5 GHz ARM64, 512 MB RAM and 256 MB flash - no USB, only 3+1 1000BASE-T Ethernet ports, 802.11ax wireless Dec 23 06:49:13 due to its price, it is rather popular at the moment Dec 23 06:51:43 err, sorry, 4*1.5 GHz ARM64 Dec 23 07:12:04 hello Dec 23 07:14:24 build #555 of ipq40xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ipq40xx%2Fgeneric/builds/555 Dec 23 07:25:32 build #561 of ath79/tiny is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Ftiny/builds/561 Dec 23 07:29:50 pkgadd thanks for the info Dec 23 07:30:18 thanks to you lmore377 to Dec 23 07:53:29 build #574 of mxs/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mxs%2Fgeneric/builds/574 Dec 23 07:59:49 I sent http://lists.openwrt.org/pipermail/openwrt-devel/2020-December/032892.html yesterday. Will people refuse to comment if I did not sign-off the patches and did not give a proper description in the patch itself? Dec 23 08:33:25 build #661 of at91/sama5 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/661 Dec 23 08:43:07 build #589 of octeon/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/octeon%2Fgeneric/builds/589 Dec 23 08:44:48 Hmm… why do udptunnel{4,6} select CONFIG_VXLAN=m…? It's not a strict dependency. Dec 23 08:53:45 pkgadd: to quote blogic, QCA = Qualcomm Crack Addicts Dec 23 08:54:45 https://github.com/openwrt/packages/issues/13484 is apparently a problem on ipq806x Dec 23 08:55:39 build #603 of lantiq/xrx200 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fxrx200/builds/603 Dec 23 08:57:33 build #642 of mvebu/cortexa9 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mvebu%2Fcortexa9/builds/642 Dec 23 08:57:50 funman: it seems to be early stage work, so the form (signed-off-by) is less important Dec 23 08:58:13 that being said, the patch would benefit from a real subject if you want people to look at it Dec 23 08:58:36 and it's not clear where all the code you import comes from, you should clarify the copyright Dec 23 08:58:55 maybe split into several patches to make it easier to review (and add your comments in the description of each patch) Dec 23 08:59:02 I mean, each comment in the right patch Dec 23 09:24:43 build #371 of ath79/mikrotik is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fmikrotik/builds/371 Dec 23 10:15:47 build #421 of bcm47xx/mips74k is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm47xx%2Fmips74k/builds/421 Dec 23 10:28:48 build #584 of ath79/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fgeneric/builds/584 Dec 23 10:36:29 build #561 of ramips/mt7620 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7620/builds/561 Dec 23 10:38:01 build #697 of lantiq/ase is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/697 Dec 23 11:12:46 build #547 of lantiq/falcon is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Ffalcon/builds/547 Dec 23 11:33:41 build #560 of sunxi/cortexa7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/sunxi%2Fcortexa7/builds/560 Dec 23 11:47:47 build #591 of mpc85xx/p1020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/591 Dec 23 11:56:00 mangix: the core packages should build with glibc, lets see what error the build bots return for the feeds Dec 23 12:00:05 build #588 of ramips/rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/588 Dec 23 12:21:57 stintel: fyi, i backported the f2fs corruption fix to 5.10 in my staging tree Dec 23 12:22:04 it's not in 5.10.2 yet Dec 23 12:22:23 also fixed some jffs2 overlay issues Dec 23 12:22:24 nbd: ah, I misread the bug report then Dec 23 12:22:39 but I'm not running 5.10 yet anyway Dec 23 12:22:52 just figured I'd mention it here as I know some people are Dec 23 12:23:08 it's working quite well for me on mt7622 Dec 23 12:45:07 build #557 of ramips/mt7621 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Fmt7621/builds/557 Dec 23 12:58:00 zorun: thanks, I can see this is not clear. the only code I import is pci.c which has a clear license header and will go away 'soon' Dec 23 14:23:41 is there a shortcut to build just the toolchain? Dec 23 14:23:46 rather than run make then ^C Dec 23 14:38:33 funman: I think "make toolchain/compile" should do this Dec 23 14:41:50 Hauke: seems to work, thanks Dec 23 14:42:57 funman: build bot does it in a similar way: http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/749/steps/toolchain/logs/stdio Dec 23 14:52:13 ah cool Dec 23 14:52:45 related: any idea why I need to build toolchain (most likely, just libgcc) with PIE ? if I don't most of userspace tools including busybox segfault on exit Dec 23 14:54:16 target is ramips Dec 23 15:24:26 ah this also: /usr/bin/ld: /home/fun/openwrt/openwrt/staging_dir/host/lib/libcrypto.a(libcrypto_la-c_all.o): in function `OpenSSL_add_all_digests': Dec 23 15:24:29 c_all.c:(.text+0xa03): undefined reference to `pthread_once' Dec 23 15:25:47 fixed with https://pastebin.com/vs1YPAxi Dec 23 15:26:52 or maybe i should remove CONFIG_SYSTEM_TRUSTED_KEYRING Dec 23 15:28:12 seems to be required by CFG80211_REQUIRE_SIGNED_REGDB Dec 23 16:34:54 The APM82181 apparently doesn't support MSI-X. I see a patch, target/linux/apm821xx/patches-5.4/802-usb-xhci-force-msi-renesas-xhci.patch, which helps one such board initialize a PCIe to USB3 Renasas chip. Dec 23 16:35:17 To do the same thing with a brcmfmac chip, would I look into the drver init code? Dec 23 16:35:36 And similarly, can brcmfmac even work without MSI / MSI-X? Dec 23 16:36:55 Another question might be whether anyone has any good introductory reading for how PCIe initialization works other -- other than reading source, anyhow. Dec 23 16:41:29 I dealt with similar issues initializing an ath10k chip. This was easier since ath10k_pci accepts irq_mode=1 argument, enabling legacy (no-MSI) irq's. Dec 23 16:50:00 build #680 of archs38/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/archs38%2Fgeneric/builds/680 Dec 23 16:53:25 nbd: I've now been bitten multiple times by the fact that libuci's uci_delete() does not zero the flags on the given pointer Dec 23 16:55:17 nbd: given a sequence like struct uci_ptr *ptr = ...; uci_delete(ctx, ptr); ptr->value = ""; uci_set(ctx, ptr); - uci_set() will invoke uci_delete() which in turn will invoke uci_expand_ptr() which returns ptr->s since the first delete has zeroed ptr->o but not ptr->flags Dec 23 16:56:40 nbd: this led to two different bugs in rpcd so far, see https://bugs.openwrt.org/index.php?do=details&task_id=3126 and https://bugs.openwrt.org/index.php?do=details&task_id=3528 for reference Dec 23 16:56:58 nbd: question: is there any reason for uci_delete() to *not* zero ptr->flags? Dec 23 16:57:22 i think it should probably be ptr->flags &= UCI_LOOKUP_EXTENDED Dec 23 16:57:24 instead of zeroing it Dec 23 16:57:27 I mean it nullifies ->o or ->s depending on the context Dec 23 16:57:45 but i agree, this should be fixed in libuci Dec 23 16:57:48 so at the very least it should mask UCO_LOOKUP_COMPLETE Dec 23 16:58:13 so that subsequent uci_ptr reuse does not attempt to use freed memory Dec 23 16:58:28 i haven't looked at the code in a long time, so i'm not sure if we should mask just UCI_LOOKUP_COMPLETE or also UCI_LOOKUP_DONE Dec 23 16:59:21 one question though Dec 23 16:59:26 why do you call uci_delete before uci_set? Dec 23 16:59:51 jow How can I most sensibly use o.depends against the channel dropdown under _freq to check if a 2.4 GHz channel has been selected or not? Dec 23 17:03:02 jow I don't think that LuCI should unconditionally show UI to disable 802.11b (so also where a 5 GHz channel is chosen which is N/A) so I am looking to improve this Dec 23 17:04:00 nbd: rpcd calls uci_delete() before uci_set() if the given value is a string and the existing option a list or vice versa Dec 23 17:04:25 this is to ensure overwrite semantics Dec 23 17:05:09 more specific: if type(existing) == list && type(uservalue) == string then uci_delete(), uci_set() Dec 23 17:05:39 elseif type(existing) == string && type(uservalue) == list then uci_delete(), uci_add_list() foreach item in uservalue Dec 23 17:06:53 nlowe: not sure you can Dec 23 17:11:27 if i remember correctly, you should be able to overwrite a list item with a regular string using just uci_set Dec 23 17:11:47 and if you want to create a list, you can probably do set, add_list, add_list, ... Dec 23 17:11:56 i don't think you need th explicit delete Dec 23 17:21:15 nlowe: try this: http://sprunge.us/BpFlOT Dec 23 17:24:33 nbd: downside of the latter approach is that one-element lists will be stored as options then Dec 23 17:24:40 which is not whgat I want Dec 23 17:34:58 jow Just tested. That works perfectly. Will/could you merge that? :-) Dec 23 18:02:31 nlowe: will do Dec 23 18:04:06 nbd: so that libuci fix is not super urgent, will add manual flag clearing to rpcd now Dec 23 18:05:10 nbd: however in the long run I'd say uci_delete() shouldn't leave uci_ptr in an inconsistent state (that is potentially zeroing .o or .s while retaining the UCI_LOOKUP_COMPLETE flag) Dec 23 21:12:15 blogic: ping. was there a realtek dev channel? there's someone in #openwrt looking at adding support for another switch Dec 23 21:13:39 svanheule[m]: ping Dec 23 21:23:27 Borromini: o/ Dec 23 21:23:47 Borromini: that channel is #rtl83xx Dec 23 21:23:58 svanheule[m]: hey, cool, thanks Dec 23 23:16:24 Borromini: did you experience the ramips issue during the 5.4 bump? Dec 23 23:18:40 mangix: as in? Dec 23 23:18:55 the pcie one Dec 23 23:19:16 well it used to be the 2,4 GHz radio just got reset the whole time Dec 23 23:19:27 like in the mt76 #444 issue on github Dec 23 23:20:17 just a few weeks ago i tried to set up a wds with the dir-860l on the 2,4 GHz radio, and a master build from around that time. and all i saw was that reset issue. Dec 23 23:20:34 now the radio isn't found altogether Dec 23 23:21:43 did you run kernel 5.4 before? Dec 23 23:22:47 yes, for testing purposes (mainly to see what DSA would do) Dec 23 23:23:10 i never really set up the n radio though. only tried to do that a while ago. Dec 23 23:23:38 Hmm OK. These pcie problems were getting sorted out by paraka during the bump. Dec 23 23:23:49 i'm running master on a DIR-878 A1 and an RT-AC57U, both mt7621 SoCs Dec 23 23:23:50 it's unfortunate they're stuff here Dec 23 23:23:59 *still Dec 23 23:24:24 mangix: yeah, i had opened a bug report about it in may. but that somehow sorted itself out Dec 23 23:24:27 https://bugs.openwrt.org/index.php?do=details&task_id=3093 Dec 23 23:25:55 the mailing list thread i found and linked to in the PR also talked about the devices on the bus coming up sometimes, but more often not. Dec 23 23:26:13 note that the 5.10 PR has more changes applied to the pcie driver upstream than 5.4 has backported. Dec 23 23:26:38 i have no C or kernel chops whatsoever so i won't dispute when paraka says that thread was unrelated though. Dec 23 23:27:03 mangix: i considered that. but 5.4 will be stable with 20.xx for ramips i suppose. So if this can be fixed it better be, right? Dec 23 23:27:18 i considered testing 5.10 as well and i will be Dec 23 23:27:51 sure but you're posting in a 5.10 PR. If it works with 5.10 and doesn't with 5.4, then we know it's fixed upstream Dec 23 23:28:44 if 5.10 works, then we know some extra patch(es) need backporting Dec 23 23:28:52 sound reasoning. Dec 23 23:29:00 i will try testing that in the next few days Dec 23 23:30:37 anyway all of this is very nice. upstream is listening and fixing bugs. Dec 23 23:30:50 meaning core openwrt devs don't need to :P Dec 23 23:30:52 :P Dec 23 23:31:04 i get the impression mediatek is very cooperative compared to a lot of other companies Dec 23 23:31:14 is paraka on mediatek's payroll? Dec 23 23:31:18 no Dec 23 23:31:21 ok Dec 23 23:31:39 mediatek only works on their new ARM stuff Dec 23 23:31:51 ramips in general is kind of abandoned by them Dec 23 23:32:34 but because of unrelated reasons (GnuBee devices), other devs picked up the slack. Dec 23 23:33:14 ok Dec 23 23:33:57 the end result being that all local mt7621 drivers were upstreamed Dec 23 23:34:11 so they don't need to be maintained Dec 23 23:34:26 yeah that's pretty neat Dec 23 23:35:38 next up would be mt7620, but I doubt anyone is interested in that Dec 23 23:36:15 aren't those flash and ram starved in comparison? Dec 23 23:36:37 am I the only getting a broken master(after commit 1302bee12a) on tp link ac1750? Dec 23 23:36:45 s/only/only one/ Dec 23 23:37:15 rr123: define 'broken'? Dec 23 23:37:29 since i just bricked a tl-wr1043nd v2 with a recent master Dec 23 23:37:40 can't boot up , have to do tftp recovery Dec 23 23:38:07 mine is bootlooping all over the place. Dec 23 23:38:25 so yeah. that ac1750 is ath79 as well i reckon? Dec 23 23:38:59 i was just saying 'master branch is fairly stable and ready for daily use', look what I got...since then I spent 5 hours trying to figure out why a new build did not boot up :( Dec 23 23:39:15 :P Dec 23 23:39:18 yes, ath79, quite a lot of checkin in last one day or two Dec 23 23:39:43 i think mine's ready for the trash unfortunately, my makeshift serial wasn't able to salvage it. Dec 23 23:40:20 rr123: might be as easy as a typo in some script that breaks stuff. Dec 23 23:40:27 Borromini: this is why I recommend breed bootloader Dec 23 23:40:32 impossible to brick that Dec 23 23:41:04 mangix: replacing the bootloader requires serial as well no? :) Dec 23 23:41:09 no Dec 23 23:41:28 requires the mtd-rw driver Dec 23 23:41:31 oh :( Dec 23 23:41:35 there are instructions on the wiki Dec 23 23:41:46 magnus1: what's blocking that? breed or those never-die-uboot-with-webserver-to-upload-new-firmware is very useful Dec 23 23:41:55 well... i tried to replace the bootloader once on the 1043 v1. bricked that one as well :P Dec 23 23:42:18 mangix: frankly, the 1043 wiki page is a mess. Dec 23 23:42:19 I did that by flashing the wrong one once Dec 23 23:42:22 s/magnus1/mangix Dec 23 23:42:29 i absolutely can't type these days Dec 23 23:42:50 rr123: breed is closed source. you're also touching the bootloader, which is potentially dangerous Dec 23 23:43:17 mangix: it's too late i'm afraid. at least the newer stuff i have either has a decent serial connection, or a tftp server, or another sturdy built-in recovery method. Dec 23 23:44:30 mangix: got a link to the breed wiki page? Dec 23 23:44:37 mangix: if memory serves me...the same author did some never-die u-boot before he/she turned into closed breed Dec 23 23:44:41 or are you talking about the project's wiki and not openwrt's Dec 23 23:44:57 OpenWrt wiki has a section on mtd-rw Dec 23 23:44:58 ok found https://openwrt.org/docs/techref/bootloader/breed Dec 23 23:45:17 that i am familiar with, had to repopulate the ART partition on a wndr3700 once :) Dec 23 23:46:20 https://github.com/laoshaw/u-boot_mod that's the original idea which is from https://code.google.com/archive/p/wr703n-uboot-with-web-failsafe/ Dec 23 23:46:23 yeah i see the 1043v2 has a bootloader for it Dec 23 23:46:28 u-boot with a small web UI that never dies Dec 23 23:47:10 https://github.com/pepe2k/u-boot_mod seems the original author Dec 23 23:47:21 is that wat e.g. d-link uses on its mediatek devices? lots of mt7621 devices have a uboot with http server built-in as well Dec 23 23:48:03 hmmm I'm looking for the breed installation guide on the forum that I used. Can't seem to find it. Dec 23 23:48:34 found it Dec 23 23:48:37 * rr123 thinks about spending a few hours to bisect the dead boot Dec 23 23:48:44 https://forum.openwrt.org/t/solved-archer-c7-v2-0-overclock/9757/48?u=neheb Dec 23 23:49:37 I run an Archer C7v2 at 1GHz. stable. Dec 23 23:49:49 with newest master build? Dec 23 23:50:03 a week or 2 old Dec 23 23:50:29 mine is at most 2 days old, 2 days ago it's ok, something bad happened in the last 48 hours checking in Dec 23 23:51:24 my build was from yesterday Dec 23 23:51:35 flashed same day. tits up same day :( Dec 23 23:51:54 so that narrows it down a bit further no? Dec 23 23:52:17 i see breed supports the tl-wr841n v7, that's not bad. I have a few of those 'in the field' still Dec 23 23:52:54 Borromini: the tl-wr1043ndv2 should have push-button tftp recovery from the factory bootloader Dec 23 23:53:06 i saw there is a snapshot download for r15324-920b692667, let me try that Dec 23 23:53:16 only on the v1 you had to retrofit that (by updating the bootloader) Dec 23 23:53:37 might just get a few extra gl.inets Dec 23 23:53:42 the OEM push-button tftp recovery isn't as neat and pretty as uboot-mod, but it works as well Dec 23 23:54:00 pkgadd: i remember flashing a newer OEM firmware for that, but i didn't get it to work Dec 23 23:54:10 pkgadd: yeah so does the archer c7v2. doesn't work. Dec 23 23:54:25 tftp recovery is hit and miss Dec 23 23:54:42 * Borromini hates tp-link recovery procedures Dec 23 23:54:59 mangix: always worked on my tl-wdr4300 and tl-wdr3600 (after retrofitting the necessary OEM update) - I needed to use it multiple times, but I've switched to uboot-mod a couple of years ago Dec 23 23:55:20 I actually bought this router bricked. The guy sold it after he couldn't figure out how to solder a serial connector. Dec 23 23:55:27 mangix: for tplink tftp recovery, it will fail after about 10 recoveries for me, i had to use oem stock firmware once, then it's ok for another 10 runs :) Dec 23 23:55:59 same with my tl-wdr3600, it arrived in bricked state (but fortunately the installed bootloader was recent enough to recover without serial console access) Dec 23 23:56:07 might get something like a GL-MT1300 :) Dec 23 23:56:15 pkgadd: so for the archer c7v2, tp-link had two bootloaders. the first one had a joke tftp recovery that didn't work. the second one fixed it I believe. Dec 23 23:56:31 but I was stuck with the first one. Dec 23 23:56:55 meaning I needed serial. Dec 23 23:56:59 ah, never had a c7 - I always delayed buying one, until I've finally skipped it in favour of ipq806x Dec 23 23:57:43 sad news, it appears the snapshot image from openwrt.org for tplink c7 is broken indeed Dec 23 23:57:50 ipq806x is a special kind of hell. you're lucky if something works :) Dec 23 23:58:23 4 hours "wasted" for me :( Dec 23 23:58:52 rr123: i know how that feels. Dec 23 23:59:03 mangix: I really like my nbg6817, no target specific issues at all - I bought it with 100/40 MBit/s in mind, but it still works nicely with 400/200 MBit/s (although I hope to switch to ipq8071a/ ax3600 in the medium future) Dec 23 23:59:28 pkgadd: the v2's reset button didn't seem to do anything, tried it multiple times. it just kept bootlooping straight through it Dec 24 00:00:31 Borromini: TP-Link and serial console access isn't nice (you usually have to bridge some tiny 0W SMD resistor solder points on the rx line), but it's always worth checking Dec 24 00:01:35 pkgadd: v2 shouldn't need that, it has the holes exposed but not populated Dec 24 00:01:59 i tried with some wire as makeshift pins and then a serial cable but it didn't budge. Dec 24 00:02:06 o.k., even better :) (I had lots of 'fun' recovering my tl-wr941ndv2) Dec 24 00:02:38 it's a 2,4 GHz only device, i was gonna give it to a friend... so it's not a big loss. just too bad it's because of some breakage in master Dec 24 00:02:57 i should have learned from last time i bricked a tp-link with a broken master build :P :P Dec 24 00:03:21 yeah, I didn't really use my tl-wr9641ndv2 either - but I just couldn't accept it remaining bricked Dec 24 00:04:04 although I had literally thrown it into the trash already Dec 24 00:04:25 and slavaged it for parts (soldered-on pigtails, SPI-NOR flash, etc.) Dec 24 00:04:33 :P Dec 24 00:04:45 i'll keep the detachable antennae of the v2 Dec 24 00:05:07 the gl-mt1300 is 32/256, that doesn't sound bad at all. Dec 24 00:05:30 and mt75 Dec 24 00:05:34 * mt7615 Dec 24 00:07:37 for what it's worth, i've been flashing mt7621 images all day, so the breakage looks ath79 specific. Dec 24 00:13:06 night guys **** ENDING LOGGING AT Thu Dec 24 03:00:14 2020