**** BEGIN LOGGING AT Mon Jun 08 02:59:58 2020
Jun 08 03:06:33 <stintel> blogic: https://git.openwrt.org/3744b1cb9de7ae09deaeca05d50e4c439a87ff58 any thoughts ??
Jun 08 03:11:58 <stintel> ah, the commit message is not correct. I have those files now even though I do not use the feature
Jun 08 04:05:10 <blogic> stintel: thanks !
Jun 08 05:03:45 <aparcar[m]> jow: I'm trying to understand the new luci JS implementation but keep getting a 'this.children[i].load is undefined' error, even though I got the function defined. Does it mean an error within the load function?
Jun 08 05:30:18 <stintel> heh and there is an accidental change in there also
Jun 08 05:51:00 <stintel> blogic: https://git.openwrt.org/357ff627 this is with correct message. can I get an ACK? :)
Jun 08 05:55:58 <Borromini> stintel: how do you get that short url with the openwrt git?
Jun 08 05:56:08 <stintel> Borromini: just shorten the hash manually
Jun 08 05:56:25 <stintel> if there are no dupes, it will be magically translated
Jun 08 05:57:17 <blogic> stintel: ack
Jun 08 05:57:38 <Borromini> stintel: neat, thanks.
Jun 08 05:57:44 <stintel> so I've been trying to port the D-Link DAP-2695-A1 from ar71xx to ath79. I have it working, but there is one issue: all the MAC addresses are kept in ASCII in the bdcfg partition. it's impossible to get them via DTS. for the eth0/eth1 and ath10k I can use board.d and hotplug.d/firmware to patch them in.
Jun 08 05:58:24 <stintel> unfortunately for the ath9k integrated in the qca9558 soc, there is no firmware so I cannot patch it either. the phy ends up with what is in the caldata: 00:03:8f:00:01:00
Jun 08 05:58:37 <stintel> are there any other ways to get around this?
Jun 08 05:58:50 <stintel> blogic: thanks
Jun 08 06:00:36 <stintel> one I idea I have is to rewrite the mac in the caldata via a defaults script, but that seems a bit nasty to me
Jun 08 06:09:24 <gch981213> stintel: Isn't it already a common practice to patch mac addresses in caldata?
Jun 08 06:10:32 <stintel> gch981213: I haven't seen that. I know we patch the firmware in /lib/firmware/.. this is what I'm doing for the ath10k chip on the SoC, but I cannot use this for the ath9k chip as it doesn't have any firmware
Jun 08 06:10:39 <gch981213> stintel: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom;h=e0fa5ff35472750d65e465b313e5e427e0f99fe8;hb=HEAD
Jun 08 06:11:11 <stintel> gch981213: yeah that's not going to work, the test on line 3 renders that script unusable due to no firmware
Jun 08 06:11:37 <stintel> wait
Jun 08 06:11:42 <stintel> am I misreading that script
Jun 08 06:12:13 <stintel> ahh
Jun 08 06:12:15 <gch981213> I guess so :) It exits when there *is* a firmware.
Jun 08 06:12:19 <stintel> yes
Jun 08 06:12:28 <stintel> maybe I should think of some coffee
Jun 08 06:13:32 <stintel> actually pkgadd also suggested that and I made the same error with the -e test
Jun 08 06:13:41 <stintel> gch981213: thanks
Jun 08 06:17:39 <stintel> should be able to finish this up before I start day job, neat
Jun 08 06:24:10 <Borromini> :)
Jun 08 06:29:46 <stintel> hmm looks like the eth1 interface has problems communicating still
Jun 08 06:30:23 <stintel> right. there's one thing I didn't find
Jun 08 06:31:45 <stintel> in ar71xx, dap2695_ar8327_pad6_cfg: .mode = AR8327_PAD_MAC_SGMII and .sgmii_delay_en = true
Jun 08 06:31:51 <stintel> I did not find sgmii_delay_en
Jun 08 06:32:37 <stintel> right, this I can find in the code
Jun 08 06:33:06 <stintel> ah that says bit19 and in the datasheet this says reserved
Jun 08 06:56:24 <jow> aparcar[m]: not enough context to answer
Jun 08 07:03:09 <aparcar[m]> jow: Fair. Problem was that the `load` function failed but the red error message would only show the "latest" error. So a rpc call failed but the error message says no load message found
Jun 08 07:03:54 <aparcar[m]> jow: overall really cool JavaScript framework you created there :)
Jun 08 07:34:44 <stintel> hmm, can't seem to figure that 10-ath9k-eeprom thing out
Jun 08 07:37:23 <stintel> https://git.openwrt.org/fbdb7c16
Jun 08 07:38:03 <stintel> if I use the 10-ath9k-eeprom script to extract the caldata from the mtd, do I need to remove "mtd-cal-data = <&art 0x1000>;" from &wmac{} ?
Jun 08 07:42:09 <gch981213> stintel: no. you'll need qca,no-eeprom instead.
Jun 08 07:42:49 <stintel> gch981213: ahh, so keep the mtd-cal-data and add qca,no-eeprom, or replace the former with the latter?
Jun 08 07:43:11 <gch981213> replace the former with the latter
Jun 08 07:43:20 <stintel> gch981213: gotcha, thanks again
Jun 08 07:48:31 <stintel> gch981213: that worked like a charm
Jun 08 08:17:10 <stintel> lol I restore that thing to the stock firmware and apparently still had my settings from before I OpenWrt'd it
Jun 08 08:51:42 * dwmw2_gone ponders abusing the rwho protocol to get a coherent list of which stations are associated to *all* APs in the network, instead of just one at a time.
Jun 08 08:51:47 <dwmw2_gone> Or do we have something that does that already?
Jun 08 08:52:21 <zorun> isn't that one of the things "dawn" is doing?
Jun 08 08:53:39 <dwmw2_gone> oh, shiny.
Jun 08 08:53:44 <dwmw2_gone> yes, looks like it is. Thanks.
Jun 08 09:36:02 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:308, expected len:872480768
Jun 08 09:36:02 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:308, expected len:872480768
Jun 08 09:36:02 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:308, expected len:872480768
Jun 08 09:36:02 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:308, expected len:872480768
Jun 08 09:36:03 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:1016, expected len:3288465408
Jun 08 09:36:03 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:1016, expected len:3288465408
Jun 08 09:36:05 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:1016, expected len:3288465408
Jun 08 09:36:06 <dwmw2_gone> Mon Jun  8 10:35:42 2020 daemon.err dawn[19742]: not complete msg, len:1016, expected len:3288465408
Jun 08 09:36:32 <dwmw2_gone> Type "apropos word" to search for commands related to "word".
Jun 08 09:36:32 <dwmw2_gone> (gdb) p/x 3288465408
Jun 08 09:36:32 <dwmw2_gone> $1 = 0xc4020000
Jun 08 09:36:32 <dwmw2_gone> (gdb) p 0x2c4
Jun 08 09:36:34 <dwmw2_gone> $2 = 708
Jun 08 09:36:34 <dwmw2_gone> OK then
Jun 08 09:41:24 <dwmw2_gone>             final_len = *(size_t*)str;
Jun 08 09:41:24 <dwmw2_gone>             if(len < final_len) {//not complete msg, wait for next recv
Jun 08 09:41:24 <dwmw2_gone>                 fprintf(stderr,"not complete msg, len:%d, expected len:%zu\n", len, final_len);
Jun 08 09:41:35 <dwmw2_gone> That's just.... utterly bogus in more ways than one.
Jun 08 09:41:46 <dwmw2_gone> not only host-endian but also host-sizeof-size_t
Jun 08 10:18:51 <johnf> has anyone taken a look at #3154 yet? https://bugs.openwrt.org/index.php?do=details&task_id=3154
Jun 08 10:21:07 <johnf> I'm going to try to build removing a large ipsec patch
Jun 08 10:43:52 <dwmw2_gone> Can someone merge my Domoticz PR in https://github.com/openwrt/packages/pull/12407 please?
Jun 08 10:57:06 <tmn505> 	
Jun 08 11:00:52 <baka> fg
Jun 08 11:05:30 <bakana> Hi, I have a mi router 3..I accidently touch the circuit board with a screw driver when testing something (near the cpu)..I probably short circuit or something..now the router won't boot and the ram chip (Nanya) gets real hot whenever I plug in the router..is there any hope for this device ?
Jun 08 11:06:09 <bakana> If I replace the Nanya chip or something ?
Jun 08 11:15:00 <ldir> bakana: It's an impossible question to answer.  The ram chip getting hot my well be a symptom of another, more serious, fault induced by the short term short circuit.  Realistically I'd say put it in recycling and get a new one.
Jun 08 11:54:45 <stintel> hmmm need to read about dawn it seems
Jun 08 11:55:52 <stintel> home-assistant does presence detection via rpcd/ubus over http
Jun 08 12:11:40 <Tapper> stintel I cant work out how to use dawn.
Jun 08 12:11:55 <stintel> never tried
Jun 08 12:12:36 <Tapper> stintel the luci app is confusing to me.
Jun 08 12:13:24 <Tapper> How gos it ldir?
Jun 08 12:25:28 <vanrein> The download site is down on IPv6, I think: 2a01:4f8:150:6449::2 is not responding and opkg blocks on it
Jun 08 12:25:49 <vanrein> (Last week I noticed the same thing)
Jun 08 12:27:38 <zorun> vanrein: seems fine from here
Jun 08 12:27:51 <vanrein> traceroute then...
Jun 08 12:30:38 <vanrein> nothing from home [XS4ALL, NL] but ok from my Hetzner box [next door to it], so it's a routing thing
Jun 08 12:31:55 <vanrein> a 3rd site in NL can also reach it; so yes, this is nearer to me than to you.  thanks zorun.
Jun 08 13:40:41 <barhom> I've got this new AX router board now that is running IPQ6018, kernel 4.4.60 on chaos chalmer 15.05.1. Looks nice, time to try to add support to openwrt master. Any good reads anyone can point me in in regards to begin to learn how to add support for a new device?
Jun 08 14:12:44 <johnf> you seem to already have a good idea of what you're doing barhom, you might get a lot out of a commit for the addition of a similar device
Jun 08 14:13:41 <barhom> johnf, yeh, I'll be reading many commits with the DTS files. I'll probably need #openwrt-devel's support along the way
Jun 08 14:34:40 <hbug_> it get an "Failed command: iw phy phy0 set antenna 0xffffffff 0xffffffff" when i try to use an wifi usb stick on my router.
Jun 08 14:36:02 <hbug_> its openwrt 19.07. the wifi usb stick is rtl8812au based. here is the wireless config and the syslog, which is a little spammed with 'iw phy' usage warnings > https://paste.debian.net/1150948/
Jun 08 14:37:10 <hbug_> the configuration parameters i use should be fine, as the same parameters work on a desktop.
Jun 08 14:38:32 <hbug_> do i need to read the netifd source to determine at which part the non working 'iw phy' commands are issued? or is there an way to adapt the config in a way that works?
Jun 08 14:42:17 <adrianschmutzler> hbug_: the antenna thing has been there for a long time, there should be also at least one bug report about it on bugs.openwrt.org
Jun 08 14:42:51 <adrianschmutzler> however, I think there has been some fix in master recently, but I'm not really sure
Jun 08 14:42:52 <hbug_> adrianschmutzler: thanks. will have a look.
Jun 08 14:43:29 <adrianschmutzler> I think the message can just be ignored anyway
Jun 08 14:44:18 <stintel> adrianschmutzler: thanks for your thorough review :)
Jun 08 14:44:51 <stintel> I should have known moving D-Link devices to another file would open a can of worms :P
Jun 08 14:46:06 <adrianschmutzler> stintel: moving the make file contents actually is not a problem, it's just cosmetic after all
Jun 08 14:47:39 <adrianschmutzler> reaching a two-digit number of devices, having such a file is easily justified (though I'd still just have kept the devices in generic.mk)
Jun 08 14:48:08 <adrianschmutzler> and checking the build recipes should be a five-minute work
Jun 08 14:48:51 <stintel> I'll just drop the move to generic-dlink.mk for now and focus on getting the device support right so I can push it
Jun 08 14:48:59 <stintel> leave the cosmetic stuff for another day
Jun 08 14:49:23 <hbug_> adrianschmutzler: seems the antenna is not the problem but this: "Failed command: iw phy phy0 interface add wlan0 type managed"
Jun 08 14:50:00 <dwmw2_gone> hm, umdns seems to be misbehaving
Jun 08 14:50:02 <adrianschmutzler> stintel: might make your life easier indeed. the remaining stuff should be easy to implement as well
Jun 08 14:50:30 <dwmw2_gone> two boxes only list a link-local IPv6 address instead of their global address, and the third (running OpenWRT master) doesn't show up at all.
Jun 08 14:51:11 <adrianschmutzler> hbug_: I barely remember the details, I just remember this as I always wondered about the warning myself, but never was able to find the root cause
Jun 08 14:51:53 <stintel> adrianschmutzler: yeah, I had a week off last week hence some motivation to figure out the porting of this device to ath79. back to day job and limited time, so let's avoid too much unneeded work
Jun 08 14:54:55 <adrianschmutzler> stintel: okay. so if you get stuck with the LED stuff, just tell and I will quickly put it together for you :-)
Jun 08 15:07:54 <dwmw2_gone> blogic?
Jun 08 15:10:55 <stintel> adrianschmutzler: actually I started a first attempt a while ago, and I didn't really look into the LED and partition part after that. for the switch setup, I would like to keep it identical to how it is in ar71xx
Jun 08 15:11:38 <stintel> adrianschmutzler: and the ath9k part, that really does work (see discussion earlier today). this is the only way, as there is no way to grab ASCII MAC from MTD
Jun 08 15:11:51 <stintel> + in the DTS
Jun 08 15:11:57 <stintel> looking forward to see that implemented :)
Jun 08 15:13:26 <adrianschmutzler> ah, okay, so if you discussed it, it's fine
Jun 08 15:13:44 <stintel> adrianschmutzler: and about the distinct addresses ... the bdcfg partition contains 3x the same MAC for lanmac wanmac wlanmac. I think stock uses the same MAC on all three, but in my head that doesn't work, no interfaces should use the same mac imo, unless they are bridged or VLAN interfaces or so
Jun 08 15:14:04 <stintel> that's why I did +1 and +2 when I added support for this device to ar71xx
Jun 08 15:14:48 <adrianschmutzler> with the leds, it would be fine to just update it to current common use in ath79, as it will be easy and not really change the leds' behavior, just the implementation
Jun 08 15:15:25 <stintel> I'll try to have a go at it one of the coming evenings and send a V2
Jun 08 15:15:37 <stintel> thanks again for the review - it was clearly necessary ;)
Jun 08 15:16:52 <adrianschmutzler> regarding the macs, I'm a big fan of keeping it as close to the vendor as possible. adding additional addresses will only raise the risk of real collisions between different devices.
Jun 08 15:17:37 <adrianschmutzler> and having the same MAC address for different interfaces is not only common, but seems to be even the majority of the devices I've been dealing with so far-
Jun 08 15:18:22 <stintel> actually I believe the stock firmware only supports AP mode even though it has 2 interfaces
Jun 08 15:18:24 <stintel> oh well
Jun 08 15:18:55 <adrianschmutzler> but that MAC thing might induce a bigger discussion than I've time for right now
Jun 08 15:19:29 <stintel> ;)
Jun 08 15:20:32 <adrianschmutzler> I just tend to be careful since I've seen consecutive MAC addresses on devices in the same network already in the real world, and therefore also typically request vendor setup for addresses in Pull Requests ...
Jun 08 15:21:08 <stintel> ok
Jun 08 15:22:11 <adrianschmutzler> but that's separate from your PR anyway, the nucleus of my comment was just where to read the address from, without changing the outcome
Jun 08 15:22:19 <adrianschmutzler> and that's of course cosmetic again
Jun 08 15:22:27 <stintel> understood
Jun 08 15:22:39 <stintel> actually in a typical router usage the wan port would be connected to the modem and the lan port to a switch, so in this case I don't think it's a problem as they are going to be on a different segment
Jun 08 15:22:57 <stintel> and for lan and wlan .. they're going to be bridged most likely so again not a problem
Jun 08 15:23:07 <stintel> I think
Jun 08 15:23:55 <adrianschmutzler> I think so too, yes. From vendor perspective it's easy to save addresses, as the use of the device is restricted.
Jun 08 15:24:47 <adrianschmutzler> But our default use case is the same ...
Jun 08 15:25:20 <adrianschmutzler> Anyway, I have to leave now. I'd be happy if you would pick up the suggested changes for the phyXtpt trigger and the led aliases, though.
Jun 08 15:25:47 <stintel> adrianschmutzler: I'll cc you in the next series
Jun 08 15:26:33 <adrianschmutzler> thanks. should be able to copy/paste that from most of the other devices in ath79 without much thinking.
Jun 08 15:27:16 <ldir> Not as much fun as identical mac addresses on the same lan.  But that was 30 years ago with some Spider Systems Spiderports (terminal servers... yeah terminals and rs232 and network... remember that?)  When they crashed they sometimes took the MAC out as well, reverting to a default.  Spider Systems claimed it couldn't happen.
Jun 08 15:30:26 <dwmw2_gone> how do we submit PRs to umdns? ldir you did this last?
Jun 08 15:39:31 <stintel> dwmw2_gone: umdns is git-send-email to openwrt-devel with [umdns] prefix afaik
Jun 08 15:39:37 <dwmw2_gone> ok, ta.
Jun 08 15:40:10 <stintel> afaik this is the case for all projects hosted on https://git.openwrt.org
Jun 08 15:40:24 <stintel> openwrt itself is a special case ;)
Jun 08 15:48:49 <dwmw2_gone> sent
Jun 08 15:49:01 <dwmw2_gone> 	"_dawn._tcp": {
Jun 08 15:49:03 <dwmw2_gone> 		"garden.infradead.org": {
Jun 08 15:49:03 <dwmw2_gone> 			"ipv4": "90.155.92.198",
Jun 08 15:49:03 <dwmw2_gone> 			"ipv6": "2001:8b0:10b:1:aa5e:45ff:fe92:c4cc",
Jun 08 15:49:03 <dwmw2_gone> 			"port": 1026
Jun 08 15:49:05 <dwmw2_gone> 		}
Jun 08 15:49:05 <dwmw2_gone> better :)
Jun 08 15:49:11 <dwmw2_gone> link-local addresses less useful.
Jun 08 15:49:54 <dwmw2_gone> Suppose that shouldn't be wide open to the Internet really.
Jun 08 15:50:07 <dwmw2_gone> link-local addresses might have been useful after all, if the link specifier was actually preserved
Jun 08 16:20:34 <ldir> dwmw2_gone: apols, was out walking an overexcited spaniel - what stintel said :-)
Jun 08 16:21:06 <dwmw2_gone> I stopped caring now anyway; looks like dawn can just multicast its data instead of using mdns and then direct TCP
Jun 08 16:21:14 <dwmw2_gone> but I sent the patch to fix it already.
Jun 08 16:21:15 <dwmw2_gone> thanks
Jun 08 16:44:41 <ldir> dwmw2_gone: I note that "ubus call umdns hosts" returns link-local ipv6 for my mac & hp printer hosts - it also returns global.  Not saying that Apple & HP have got it right.
Jun 08 16:49:56 <ldir> That suggests to me that the mdns resolver has to work out how that link local address relates to its own interface scope.
Jun 08 16:57:17 <PaulFertser> It kinda makes sense given that mdns is supposed to be useful in serverless networks, so there might be no addreses at all but the LL. Apparently the resolver is supposed to assume the same scope the reply was received on.
Jun 08 17:10:50 <stintel> hmmm, how would one start debugging this
Jun 08 17:10:51 <stintel> [    4.350648] Run /sbin/procd as init process
Jun 08 17:10:51 <stintel> open: No such file or directory
Jun 08 17:13:15 <PaulFertser> https://github.com/lathiat/nss-mdns/blob/master/NEWS.md <- "_nss_mdns_gethostbyname3_r and _nss_mdns_gethostbyname4_r are now implemented" which means the mdns resolver starts to add appropriate scope_id.
Jun 08 17:20:15 <PaulFertser> dwmw2_gone: https://github.com/lathiat/nss-mdns/commit/5fa5f9686edab0562f4e4e4b2b635d162245a2d6#diff-44fa1944c5679dc98b39ebae77e221a4R97
Jun 08 17:25:26 <ldir> PaulFertser: which all suggests to me that no addresses should be elided from our umdns response
Jun 08 17:26:01 <PaulFertser> ldir: reading the MDNS RFC makes me think only LL should be present in the response.
Jun 08 17:28:54 <ldir> ha brilliant - ok so in that case Apple & HP are wrong, umdns is correct and the submitted umdns patch is wrong.
Jun 08 17:29:04 <PaulFertser> ldir: no, you're right: "it MUST include all addresses that are valid on the interface on which it is sending the message"
Jun 08 17:35:53 <PaulFertser> So both resolver and responder should be fixed to behave like the RFC says.
Jun 08 17:36:12 <greearb> any general suggestions for things to be aware of when taking a backports driver and trying to put it in the main kernel as normal module?  For instance, looks like I need to remove "CPT" from the front of lots of ifdefs?
Jun 08 17:36:26 <greearb> I'm trying to get ax200 working again...
Jun 08 17:37:59 <dwmw2_gone> ldir: do your mac and printer hosts have global IPv6?
Jun 08 17:38:24 <ldir> dwmw2_gone: yes
Jun 08 17:38:26 <dwmw2_gone> my other Linux boxes publish global addresses
Jun 08 17:38:32 <dwmw2_gone> Android publishes ll and global
Jun 08 17:39:36 <ldir> I see ll and global
Jun 08 17:40:45 <PaulFertser> On a typical OpenWrt network there will also be a ULA address.
Jun 08 17:41:43 <dwmw2_gone> I have no objection to revising the patch to publish both
Jun 08 17:42:05 <dwmw2_gone> for mdns ll addresses do make sense on the wire; it's a client-side issue if you "forget" which interface it came in.
Jun 08 17:42:16 <dwmw2_gone> umdns giving me a string which is just a ll address is completely pointless
Jun 08 17:42:25 <dwmw2_gone> fe80::6a54:fdff:feab:d299%br-lan would be OK though.
Jun 08 17:43:10 <PaulFertser> Or something like %2 should work too.
Jun 08 17:44:29 <ldir> so there's an oversight in the server bit of umdns and it should report both ll, ula & gla addresses - currently it is filtering non ll addresses
Jun 08 17:45:19 <dwmw2_gone> right. And a oversight client side which makes ll addresses unusable because we don't tell which link
Jun 08 17:45:46 <ldir> there's also an issue in the resolver part in that it should be appending a scope to received ll addresses
Jun 08 17:48:34 <ldir> dwmw2_gone: if you revise your patch for the server side I'll apply that and bump the owrt package.
Jun 08 17:50:11 <ldir> the 'client' side of umdns will probably require someone smarter than me to fix
Jun 08 17:55:03 <dwmw2_gone> ldir: ok, ta.
Jun 08 17:55:26 <dwmw2_gone> I do like dawn. Been wanting this for ages.
Jun 08 17:55:47 <dwmw2_gone> would be a little bit nicer if the per-station info was shown like it is on the luci overview page.
Jun 08 17:56:04 <dwmw2_gone> including host info and speeds.
Jun 08 18:50:45 <dwmw2_gone> ldir: resent.
Jun 08 18:58:35 <ldir> dwmw2_gone: applied - working on a package bump
Jun 08 18:58:40 <dwmw2_gone> ta
Jun 08 19:09:57 * ldir resists for the 3rd time in not responding "cpio" ... ... dammit!
Jun 08 19:44:10 <barhom> How does support on AX routers from qualcomm stand today? Would that be ath10k (-ct) or ath11k? How do you see it progressing? I would really liketo avoid staying on QSDK
Jun 08 20:00:14 <Borromini> AX is ath11k
Jun 08 20:15:47 <dwmw2_gone> hm, doing vlan over a DSA port seems non-trivial.
Jun 08 20:16:34 <dwmw2_gone> adding the implicit 'wan.1' to a bridge as seems to be shown at the bottom of https://openwrt.org/docs/guide-user/network/vlan/switch_configuration doesn't work
Jun 08 21:39:17 <pkgadd> barhom: right now there's only basic target support for ipq807x in OpenWrt, but no devices actually supported. ath11k is present, but afaik wired ethernet will need additional work/ patches and probably quite a few other things. it's happening, but will still need quite some work
**** ENDING LOGGING AT Tue Jun 09 02:59:57 2020