**** BEGIN LOGGING AT Tue Jun 16 03:06:38 2020 Jun 16 06:14:36 build #147 of sunxi/cortexa7 is complete: Failure [failed pkgbuild] Build details are at http://buildbot.openwrt.org/openwrt-19.07/images/builders/sunxi%2Fcortexa7/builds/147 blamelist: Daniel Gonz?lez Cabanelas Jun 16 06:47:39 blocktrron: Just seen "mac80211: ath9k: enable MFP capability unconditionally" - does it mean that I do not need to add the "nohwcrypt=1" module param anymore to setup WAP3? Jun 16 06:47:49 aparcar[m]: yes, this was done when SMP support was introduced for bcm63xx. There were some issues with SMP such as JFFS2 corruption and also the PCI (BCM6368) driver could have some potential issues with SMP for the current implementation Jun 16 06:49:02 afaik KanjiMonster was planning to move the generic subtarget to legacy and smp to generic, reorganizing all the devices in bcm63xx Jun 16 06:49:21 that's why I added NAND support for smp subtarget only Jun 16 06:50:52 jow: most likely, mac80211 should detect some key failure on runtime and switch to software automatically Jun 16 06:52:02 jow: https://www.spinics.net/lists/linux-wireless/msg199093.html Jun 16 06:57:14 mangix: then kindly revert the zstd change if you do not plan to backport zstd support Jun 16 07:12:44 mangix: actually nevermind, I'll just fork it Jun 16 08:12:51 jow: yes, exactly Jun 16 08:13:35 jow: is there any documentation on *what* to put in rc.local to make VLAN work on DSA? Jun 16 08:13:45 dengqf6 was trying to talk me through it last week but I didn't get it working Jun 16 08:14:50 from my perspective, the current limitation does not make a lot of sense, as there's already a fallbock to se_crypto implemented for And on AR9160, there's also no hardware acceleration used for management frames. Jun 16 08:15:52 dwmw2_gone: as far as I understood the general approach seems to be to bridge all ports together, then do "bridge v" vlan filter commands on top of this bridge Jun 16 08:16:25 dwmw2_gone: but so far I didn't really grasp the config entirely, it seems way more complex compared to swconfig Jun 16 08:16:48 This case is also handled in ath9k_set_key Jun 16 08:26:20 dwmw2_gone: If your e-mail was about a swconfig->DSA migration script, that has been requested in past Jun 16 08:27:01 but looks like nobody is interested in doing that and it may not be a nice job (if entirely possible) after all Jun 16 08:33:36 If I could get it working even manually I might have a go :) Jun 16 08:34:48 the problem is not so much the core config but the fact that one needed to adjust all package/user scripts as well; and the changes would be device-specific ... Jun 16 08:35:23 anyway, I'd give this lower priority than integrating the vlan stuff properly into config Jun 16 08:35:27 but then, the switch from swconfig to DSA is platform-specific anyway. Although not quite device-specific. Jun 16 08:35:49 yeah, it's got to be *possible* to express the vlan stuff in config, before we can even contemplate migrating (at least with vlans) anyway. Jun 16 08:36:20 although I suppose migration even without vlan support would be useful anyway. Jun 16 08:36:25 One might just provide a simple script for what's exchanged by what, the problem is how to find and adjust all config files Jun 16 08:36:59 we already had a similar discussion for migrating from ar71xx to ath79, where we had an eth0/eth1 swap for quite a number of devices Jun 16 08:37:05 most configs outside /etc/config/network should be operating on logical interfaces, surely? Jun 16 08:37:13 it just led to nothing Jun 16 08:37:59 well, what would you do if somebody adds a vlan port in script? Jun 16 08:38:38 can this be reasonably migrated? or is it that we just can only upgrade part of setup, which might be worse that no migration at all? Jun 16 08:38:40 Why would anyone do that? :) Jun 16 08:38:59 It seems reasonable to upgrade the *standard* setup; those things which you can do through config. Jun 16 08:39:06 any random scripting, and you're on your own Jun 16 08:39:26 downstream will do that, e.g. to reconfigure ports Jun 16 08:39:54 why can't that be done in config? Jun 16 08:40:06 so, if we say "there is migration", there might be tears Jun 16 08:40:17 "there is migration of the standard config" Jun 16 08:40:21 well, it is done in config, by changing it via uci commands Jun 16 08:40:56 like platform preinit scripts or initial config? Jun 16 08:41:14 yes, exactly. Typically /etc/uci-defaults Jun 16 08:41:28 So, technically speaking, it's only applied at start and one could ignore it Jun 16 08:41:50 as it should be updated for newer releases with DSA anyway Jun 16 08:41:55 and after the start, it's just a subset of the "configurations supported by standard uci config" that should be migratable. Jun 16 08:42:09 One might argue that that's the config to be *particularly* careful we migrate properly :) Jun 16 08:43:43 that's when I tried to start this discussion for ar71xx/ath79: http://lists.infradead.org/pipermail/openwrt-devel/2019-September/018794.html Jun 16 08:44:08 jow: not sure what you mean. the buildbots are not failing. Jun 16 08:44:31 it's a slightly different problem, but the general idea would be the same Jun 16 08:44:59 of course, vlans will make this more complicated Jun 16 08:46:34 I think the problem of migrating more than once is probably fixable just by having another uci key to record that the migration has been done. Jun 16 08:48:24 for swconfig → DSA migration we end up having to read the switch config, work out which external ports are on which vlan, then put the right wan/lan0/lan1/etc devices into the right logical interfaces Jun 16 08:48:38 e.g. my lantiq has Jun 16 08:48:40 config switch_vlan Jun 16 08:48:40 option device 'switch0' Jun 16 08:48:40 option vlan '1' Jun 16 08:48:40 option ports '0 1 2 4 6t' Jun 16 08:48:47 and eth0.1 in br-lan. Jun 16 08:49:01 So lan0 lan1 lan2 lan4 (or whatever they're numbered) will need to go into br-lan Jun 16 08:49:44 That's having to deal with vlans even before there was any vlan on the wire (which would have been eth0.1.1) Jun 16 08:50:08 Note that we cannot guarantee that switch members will be labelled lanX at the moment Jun 16 08:50:20 The might have any name. Jun 16 08:50:34 it's platform-specific Jun 16 08:50:59 might be even device specific, since kernel accepted different things even for similar devices Jun 16 08:51:11 in an ideal world, the infrastructure for migration would happen early and we can add the platform-specific parts as we convert platforms. Jun 16 08:51:31 rather than trying to go back and fix it up later. Jun 16 08:51:39 I also asked that question on a general level here (the naming): http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022988.html Jun 16 08:51:42 This is partly why I heckled at the lantiq DSA PR Jun 16 08:54:31 Don't know when that one will make it in anyway. I won't merge it, and there seem to be not many people interested in lantiq anymore. Jun 16 08:55:33 I'm connected through a hh5a, and I have a tdw8970 as a hotswap replacement sitting behind me. Jun 16 08:55:38 I care a little about lantiq :) Jun 16 08:55:52 neoraider: hey, wanted to ask for your opinion on https://patchwork.ozlabs.org/project/openwrt/cover/20200608141445.309-1-fff@bareminimum.eu/ . i'd like to bring vxlan forward. and to get started on documentation, i'd like to see at least these patches get into openwrt first in some way Jun 16 08:57:48 dwmw2_gone: well, of course you may speed things up there by testing/reviewing. if you provide a reviewed-by when it's ready, I would be willing to merge it ... Jun 16 08:58:22 well, that's where I started. "It's not ready until I can sysupgrade to it and it still works" :) Jun 16 08:58:39 but before even that, "I can't even work out *how* to make it work with vlans" :) Jun 16 08:58:47 let alone automatically on upgrade Jun 16 09:42:58 dwmw2_gone: there's a couple of VLAN trunk examples using bridge vlan filter in this thread: https://forum.openwrt.org/t/er-x-sfp-vlans-not-working-properly-with-kernel-5-4/60002/25 Jun 16 09:43:17 dwmw2_gone: I guess a generic configuration concept can be deduced from that Jun 16 09:44:37 once implemented, uci support for bridge vlan filter will likely look very similar to the current swconfig syntax (config switch_vlan) just with port numbers swapped out for device names (e.g. eth1.t instead of 0t) Jun 16 09:45:13 or lan1.t rather Jun 16 09:46:19 basic approach seems to be: form a bridge of all per-port netdevs (maybe conveniently call this bridge "switch0") Jun 16 09:46:25 enable vlan filtering on this bridge Jun 16 09:46:45 program per-port vlan tags on the bridge members Jun 16 09:48:28 and do the bridge vlan add dev switch0 self vid xxx thing to wire up vlans to the router itself (I guess this is what the "CPU port" was in swconfig) Jun 16 09:49:30 what is unclear to me however is if you then use switch0.123 to refer to vlans or if you keep using the per-port netdevs directly, leaving the vlan filter bridge around but not directly referenced in the configuration Jun 16 09:50:24 (the latter would again be similar to swconfig, you configure an abstract switch entity somewhere but interact with it through one or more cpu ports) Jun 16 09:53:08 okay, it appears one uses switch0.123 to refer to vlan port groups then Jun 16 09:53:11 https://github.com/openwrt/openwrt/pull/2942#issuecomment-629374851 Jun 16 09:53:35 (@lan.XY is used in this example which resolves to br-lan.XY) Jun 16 10:00:00 given that, a potential migration could be as easy as changing port numbers for netdev names and changing the swconfig cpu port netdev to switch0 Jun 16 10:00:37 (and maybe change `config switch_vlan` into `config dsa_vlan` or similar to avoid confusion) Jun 16 10:01:42 what would be needed though would be the device specific mapping of swconfig port numbers to dsa port netdev names Jun 16 10:02:01 (e.g. 0 -> lan1, 1 -> lan2, 2 -> lan3, 4 -> lan4) Jun 16 10:03:22 it could be added to board.d by expanding ucidef_add_switch Jun 16 10:06:58 e.g. ucidef_add_switch switch0 "0:lan" "1:lan" "2:lan" "3:lan" "4:wan" "5@eth0" to something like ucidef_add_switch switch0 "1:lan#sw0p1" "2:lan#sw0p2" "3:lan#sw0p3" "4:wan#sw0p4" "5@eth0" where the part after "#" would refer to the port's netdev name with DSA which differs with each model (sometimes lanX, sometimes swXpY, sometimes ethX) Jun 16 10:22:18 I would prefer to put this in a separate migration script Jun 16 10:22:45 so we don't have copy/paste stuff for new devices, and if it's only the mapping one might easily build blocks for migration Jun 16 10:23:00 the migration script would create the uci config from the previous config Jun 16 10:23:07 but the new setup has to be expressable in uci config first. Jun 16 10:23:19 not just with random script hacks Jun 16 10:23:23 right, lets focus on the uci expressibility first Jun 16 10:23:26 and board.d won't help anyway, as config_generate is not triggered when /etc/config/network exists Jun 16 10:23:35 ignore the migration aspect for now Jun 16 10:23:56 yeah, making it possible to work sanely even for new installations would be a good start Jun 16 10:23:56 we can maybe ven offer some kind of attended migration through the ui or an interactive script or something Jun 16 10:24:08 although designing the config such that it makes migration *easier* might be a useful design constraint Jun 16 10:27:11 another config design quesiton would be if we make the "self" (CPU port in swconfig speak) explicit or implicit Jun 16 10:28:05 I would prefer implicit, I think Jun 16 10:28:09 I'd prefer implicit (always assign self to port vlan groups) even if it means that we take away the possibility to declare a switch vlan port group whose traffic does *not* touch the local system/cpu port Jun 16 10:28:31 Shouldn't I be able to go to my shiny new installation and just add 'lan0.5' to a br-lan or other logical interface, and have it just work ? Jun 16 10:29:17 you mean arrange the vlan filtering in background as needed? Jun 16 10:29:21 yeah Jun 16 10:29:34 uff... not sure how hairy that gets if multiple bridges are involved Jun 16 10:29:39 if it even works this way Jun 16 10:30:25 it would also mean that netifd would need to gain dsa awareness, it needs to know that lan0 is dsa port so that it can arrange for tagging/vlan filtering etc. in background Jun 16 10:30:30 If not just "add lan0.5 to the br-lan like you did before"... tell me how you envisage me as a clueless end user configuring this in your DSA+uci future. Jun 16 10:30:44 Please imagine me bashing my head against the wall in time to your words, after the first sentence. Jun 16 10:30:50 because there should be only one sentence. Jun 16 10:31:59 For a vlan group that *doesn't* touch the local system, perhaps we need another IP configuration for the corresponding logical interface. Not static, not dhcp, not even "none", but "don't even connect it". Jun 16 10:33:11 I guess that being able to "just bridge portnetdev.X somewhere" we'd need a lot of complexity behind the scenes which I cannot fully estimate atm Jun 16 10:33:45 it's either behind the scenes and we get our heads around it. Or we inflict it on all the users. Jun 16 10:33:47 years ago when I first heard about DSA I always thought that this ways the design intent of it Jun 16 10:34:22 but apparently it only works this way on a small subset of DSA capable switch (?) because it needs a special tag format or double tagging support (?) Jun 16 10:34:25 I think we create the switch0 bridge behind the scenes, and manage the vlan filtering on it. Jun 16 10:34:48 and allegedly the majority of DSA supported switches is dumb (?) and you need to work with VLAN filters to emulate thaz behaviour (??) Jun 16 10:34:49 Then the actual logical interfaces (br-lan, etc.) can have switch0.1 and similar added to those? Jun 16 10:35:12 Do we have a way to bridge *different* things to (e.g.) lan0.1 and lan1.1 ? Jun 16 10:35:38 swconfig did Jun 16 10:35:54 ... on some boards Jun 16 10:36:20 and perhaps different wan.1 and lan0.1 on more boards Jun 16 10:36:34 not sure we really need to care too much about that use case. Jun 16 10:36:46 at least not for trivial out-of-the-box naive user setup Jun 16 10:36:48 we should Jun 16 10:37:09 its a standard requirement for iptv / voip kind of internet setups Jun 16 10:37:18 build #162 of bcm63xx/generic is complete: Failure [failed updatefeeds] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/162 blamelist: Christopher Hill Jun 16 10:37:23 I'd really like the user experience to be "just add lan0.X to your br-lan" and for it to JustWork™ Jun 16 10:37:49 vlan trunk on wan, terminate one vlan locally with pppoe, bridge one vlan to a dedicated ethernet port for the stb, iptv either locally or forwarded on the third vlan Jun 16 10:38:12 yes but do those vlan numbers *have* to overlap? Jun 16 10:38:28 I concede it's best if we can make that possible. Jun 16 10:38:36 Just seemed hard with DSA; I can't see how it works. Jun 16 10:39:29 I suppose if the CPU does the 8021q encap and sends encapsulated packets out the port, the switch's idea of vlan is irrelevant. Jun 16 10:40:24 Instead of "packets from the CPU tagged vlan 101 go out the wan port tagged 101", we say "packets from the CPU tagged XXX go out the wan port untagged". And then the CPU sends its PPPoE not in switch0.101, but in switch0.XXX.101 Jun 16 10:41:03 right, double tagging Jun 16 10:41:10 perhaps that should be the default setup — a different vlan per port, and 8021q encap in software. And then anything else is an *optimisation* we apply automatically? Jun 16 10:41:27 "Oh look all those are using the same vlan# we can just let the bridge do that" Jun 16 10:41:30 101 being the intended one and XXX an internally allocated one to express the port group membership Jun 16 10:42:02 right Jun 16 10:42:46 I think I like the idea of a setup which allocates internal vlan IDs, and *tries* to make them match the intended one (to use hw accel) but then falls back to double-encap when it needs to. Jun 16 10:42:55 okay, assuming we're allocating a unique vlan per port, maybe something with a large offset, e.g. 4000 Jun 16 10:43:25 how many of these devices have limits on the size of the vlan tag? Jun 16 10:43:27 erm brainfart, no offset, use 1, 2, 3, 4 etc. Jun 16 10:43:38 1 is lan1, 2 is lan2, 3 is lan3 etc. Jun 16 10:43:57 I would have gone for the offset, I think. Jun 16 10:43:58 then you'd simply use switch0.1, switch0.2, switch0.3, ... from a user pov? Jun 16 10:44:13 and bridge e.g. switch0.1 .. switch0.4 into br-lan ? Jun 16 10:44:21 well, what if I want vlan1 to be bridged on all of lan0 lan1 lan2 etc. Jun 16 10:44:54 hm, ignore that Jun 16 10:45:13 what if I have vlans on my actual network. Jun 16 10:45:21 double tag Jun 16 10:45:23 lan0.1 lan1.1 lan2.1 are bridged (br-lan) Jun 16 10:45:31 lan0.2 lan1.2 likewise Jun 16 10:45:41 we would prefer not to double tag for that. Jun 16 10:45:57 just let all those ports be in vlan 1 *and* 2. Jun 16 10:46:15 I'd prefer not to end up in a situation where the user has to use vlan #4001 and #4002 to get hw accel Jun 16 10:46:24 understood Jun 16 10:46:27 but if they start at 1 that conflicts with the internal numbering so they get double tagging Jun 16 10:46:49 so it boils down to allocating a high random vid for untagged traffic Jun 16 10:46:51 I don't know that we need internal numbering at all in the start of a setup Jun 16 10:46:56 yeah Jun 16 10:47:32 and then, only if it's needed; if a port's untagged traffic is assigned to any logical interface. Jun 16 10:47:33 swconfigs config model was "declare a vlan number, attach ports to it" Jun 16 10:48:02 that prevented vlan renumbering, e.g. have port1.456 bridged to port2.789 Jun 16 10:48:21 except with double tagging. Jun 16 10:48:39 but you could declare a vlan 456 contaning port1 + cpu and a vlan 789 containing port2 + cpu Jun 16 10:48:47 right Jun 16 10:48:59 then bridge cpunetdev.456 with cpunetdev.789 Jun 16 10:49:22 so... when bringing up a logical interface (br-lan), we get a list of physical interfaces e.g. wan.1, lan0, lan2 Jun 16 10:49:27 we consult the switch setup. Jun 16 10:50:03 if the vlan IDs in that list *are* all the same, and if that VLAN ID isn't used on the switch yes, we can try for hardware accel. Jun 16 10:50:23 adding the vlan filtering and lan0,lan2 as untagged pvid 1, etc. Jun 16 10:50:40 otherwise we fall back to double-tagging, assigning a high VLAN ID for the ports we need to include Jun 16 10:51:08 we also need to know if lan0, lan2 are used elsewhere in tagged mode Jun 16 10:51:20 iirc DSA does not or not always (?) support tagged + untagged operation Jun 16 10:51:50 ok, so we'd always have to do double-tagging in that case for the tagged ones. Jun 16 10:52:02 having e.g. a br-lan with (lan0, lan2) and a br-foo with (lan0.123, whatever) Jun 16 10:52:11 That complicates it a little because we'd want to do a pass over the net config to find out first Jun 16 10:52:48 or an explicit flag on the physical dev in config, which could be set automatically when it's needed perhaps Jun 16 10:55:08 I aimed for an explicit port-vlan-membership configuration similar to swconfig instead of a fully implicit vlan filter config because it is easier and more robust to realize , plus users are used to from swconfig (program switch first, then use tagged cpu port as needed) Jun 16 10:55:33 it would also allow for further configuration flags which are hard to express in an "option ifname 'port1 .. portN'" list Jun 16 10:56:29 but I agree that an implicit config would be the most user friendly and more importantly, intuitive, configuration approach Jun 16 10:57:03 I am just not sure if we manage to generate an efficient enough config this way which properly exploits the hw accelleration Jun 16 10:58:57 plus we need to teach netifd about the dsa switch topology (not sure if a DSA port netdev on the netlink/sysfs level is distinguishable from a non-DSA netdev) Jun 16 11:04:10 Users only needed to bother with swconfig before if they wanted to change the defaults, which are broadly expressed as "these ports are ethXX, that one is ethYY" Jun 16 11:04:21 right Jun 16 11:04:38 I'd agree that vlan trunking in any form is an advanced feature Jun 16 11:04:42 Mostly they only needed to add ethXX or ethYY or ethXX.1 as desired to their logical interfaces. Jun 16 11:05:01 the most common usecase is "separating ports" for untagged traffic into multiple logical interfaces Jun 16 11:05:17 yeah Jun 16 11:06:58 I'm going to finish off the "install from sdcard to internal eMMC" for Banana Pi that I'm working on, then have a play with coming up for at least a flowchart for how we'd turn config into real switch config Jun 16 11:07:16 (well, first trying to get a vlan-based switch config working at all, based on the links you gave me above; thanks) Jun 16 11:07:50 I plan to have play with my Mir3G too, it uses DSA in master now Jun 16 11:27:46 dwmw2_gone: ping Jun 16 11:34:19 dengqf6: hi Jun 16 11:34:52 dwmw2_gone: your previous configuration does not work? Jun 16 11:35:27 I didn't get it working but will try again and look harder at https://github.com/openwrt/openwrt/pull/2942#issuecomment-629374851 which seems to make it a bit clearer what I'm doing Jun 16 11:35:54 btw I'm not sure I understand bridge v add dev br-lan self vid 5 pvid untagged in that Jun 16 11:36:02 that doesn't seem to match the table provided two comments above Jun 16 11:36:08 shouldn't it be tagged? Jun 16 11:39:31 dwmw2_gone: If you were to configure a managed switch, what would the VLAN configuration be like? Jun 16 11:39:52 I'm not actually using vlan yet. But was about to start. Jun 16 11:40:35 I only have 64 public Legacy IP addresses at home, and with each TV and even my watch having one it's getting a bit tight. Jun 16 11:40:43 dwmw2_gone: "br-lan" in "bridge vlan" is like "eth0" in swconfig Jun 16 11:41:35 So I was going for 'vlan 1 on the house network is the normal public network (and one IPv6 /64). vlan 2 is IPv6-only with a second /64, vlan 3 I finally concede to having NAT, with a third IPV6 /64" Jun 16 11:41:40 dwmw2_gone: you got static IPv4 addresses (/26) at home? Jun 16 11:41:47 yeah Jun 16 11:42:11 On the main router I already a br-lan6 for the IPV6-only network. Jun 16 11:42:30 I just can't share that from the other APs easily unless I add vlan on the house wired network for it. Jun 16 11:43:38 so my first use case would be that. Jun 16 11:54:12 I use my IPv6-only network for reviews like https://www.amazon.co.uk/review/R2H3Q8TO6ARRST/ref=cm_cr_srp_d_rdp_perm?ie=UTF8 Jun 16 11:54:39 And any prototype device which gets sent to my home for testing gets put on it first. Jun 16 12:56:36 dwmw2_gone: what was your swconfig setting? Jun 16 15:03:33 dengqf6: I don't have a previous swconfig setting for the new Asus RT-AC85P that I started playing with vlan on. Jun 16 15:03:44 the hh5a has swconfig but doesn't use vlan yet. Jun 16 15:18:18 build #163 of bcm63xx/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm63xx%2Fgeneric/builds/163 Jun 16 18:53:05 build #75 of mpc85xx/p1020 is complete: Failure [failed tools] Build details are at http://buildbot.openwrt.org/openwrt-18.06/images/builders/mpc85xx%2Fp1020/builds/75 blamelist: Daniel Gonz?lez Cabanelas Jun 16 23:50:44 is there any support for band-steering in openwrt? For instance, if I load 5Ghz radio, should OpenWrt force stations onto 2.4? Jun 17 00:54:31 greearb_: maybe https://github.com/berlin-open-wireless-lab/DAWN/ goes into that direction (I know there's also been work done on the netifd/ hostapd side to use a single hostapd instance in the future); no, I'm not quite sure if it does the intended job yet (the package is in the normal feeds) Jun 17 01:46:23 what is this dawn thing? **** ENDING LOGGING AT Wed Jun 17 02:59:57 2020