**** BEGIN LOGGING AT Tue May 12 03:00:16 2020 May 12 05:22:50 build #97 of bcm27xx/bcm2710 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/bcm27xx%2Fbcm2710/builds/97 May 12 05:55:06 jow: we just got fstools crash fix from Daniel that i need for 19.07 :| May 12 05:55:26 does Daniel use IRC? May 12 05:55:47 https://patchwork.ozlabs.org/project/openwrt/patch/20200511234549.GA574432@makrotopia.org/ May 12 05:57:24 rmilecki: he is sometimes in here as dangole May 12 05:57:34 thanks DonkeyHotei May 12 06:02:12 build #399 of oxnas/ox820 is complete: Failure [failed] Build details are at http://buildbot.openwrt.org/master/images/builders/oxnas%2Fox820/builds/399 blamelist: Koen Vandeputte May 12 06:36:21 build #395 of lantiq/ase is complete: Failure [failed dirupload] Build details are at http://buildbot.openwrt.org/master/images/builders/lantiq%2Fase/builds/395 blamelist: Koen Vandeputte May 12 07:53:08 Hi, I am using the latest trunk version for the lantiq xrx200 (zyxel 2812). However after install the ethernet ports are not available. I get a 'lantiq.xrx200-net probe of 1e108000.eth failed with error -22' Switching to the 19.07 branche works ok. I also tried to update the config with diffconf, but made no difference. Any clues? May 12 08:37:59 rmilecki: why did you revert the hierarchical mount fixes? May 12 08:38:16 not again ... :D give me a sec May 12 08:38:51 https://patchwork.ozlabs.org/comment/2422023/ May 12 08:38:55 and what about that fstools segfault? May 12 08:39:10 this really wasn't proper implementation May 12 08:39:13 so you reverted it because you don't like it May 12 08:39:30 wiuthout replacement May 12 08:39:31 because of few arguments i lister May 12 08:39:33 *listed May 12 08:40:14 I told Daniel to push is ASAP, but I'm not sure what timezone he lives in (EU, US?) May 12 08:40:18 ldir verified his fix May 12 08:40:24 *push it May 12 08:40:28 is it failing for all people now? May 12 08:40:56 there's a lot of reports of opkg upgrade on 19.07 bricking devices May 12 08:41:04 and I wonder if that fstool update is the reason May 12 08:41:11 it's a crash in a single "block" call that is realted to notifications May 12 08:41:25 jow: do you have some report with log? May 12 08:41:49 only one where dmesg simply stops midway May 12 08:42:10 jow: it's a crash happening when "blockd" starts and it calls "block autofs start" to get notifications about discovered devices May 12 08:42:10 all others are just handwaving May 12 08:42:24 whats the impact? May 12 08:42:49 blockd doesn't provide a list of devices ("ubus call block info") and it doesn'tcall hotplug.d "mount" scripts May 12 08:43:11 hm May 12 08:43:14 it happens late during boot process so i don't believe it can stop booting May 12 08:43:56 (OpenWrt doesn't come with "mount" hotplug.d scripts by defualt - there is one official for "samba36" (droppged from master now) and ppl may have custom ones) May 12 08:55:22 hey guys. is ath79 already on DSA in master or not? is there a table somewhere? May 12 08:56:00 a matrix of which targets already use DSA i mean, and which don't yet May 12 08:57:58 what about grep CONFIG_NET_DSA=y target/linux/*/*config* May 12 08:58:03 should that be reliable? May 12 08:59:26 let me check thanks :) May 12 09:00:23 rmilecki: i think it's not. mt7621 is on DSA, grep doesn't show it May 12 09:00:41 ar71xx pops up in that list though, which is a bit weird for a target about to be deprecated May 12 09:01:21 Certainly not all ath79 boards can use DSA now. I'd check by swconfig presence. May 12 09:01:50 hmmm let me try with git grep. subtargets aren't taken into account with just a single regular grep May 12 09:02:07 ath79/Makefile shows swconfig enabled by default but some targets have -swconfig May 12 09:02:41 does anyone know tmomas's irc nick? May 12 09:02:43 is it just tm? May 12 09:02:50 he's not on irc May 12 09:03:00 oh :( May 12 09:03:05 pm him via the forum, he's quite responsive May 12 09:03:14 i'll ping him on the forum then. i think it would be handy to have such a matrix no? May 12 09:03:35 here, to know which devices to avoid :) May 12 09:03:38 https://paste.debian.net/1146283/ < rmilecki thanks for the tip. git grep shows the following :) May 12 09:03:49 jow: how do you mean? May 12 09:04:11 dsa is barely functional, bugged and not properly integrated May 12 09:04:26 and in some cases a feature regression compared to swconfig May 12 09:04:45 oh yes, well... :P May 12 09:05:20 i had to trash my buildroot to get it going for my mt7621 device, but it works atm :) May 12 09:05:53 but I guess you don't have any sophisticated setup, like vlan trunks or the like? May 12 09:06:09 CONFIG_NET_DSA=y is set in target/linux/ath79/config-5.4 as well so I assume it's on for ath79 in master as well May 12 09:06:40 jow: no, at least, not on the devices i'm testing with. i've been told e.g. ipq40xx would be able to do proper VLAN'ing with DSA at long last though. May 12 09:07:06 right but apparently it requires some arcane series of bridge vlan filter commands May 12 09:07:15 hich right now requires manual scripting in rc.local or similar May 12 09:07:18 the only device where I'm actively using VLANs on OpenWrt with is an APU2, I assume DSA works well on x86/64. May 12 09:07:45 great. do you happen to have a link to a forum topic about that or sth? or did it pop up on the mailing list? May 12 09:07:48 thats not DSA at all on the apu, just "software" vlans on top of normal ethnet nics May 12 09:08:11 yes... sorry. the APU2 has no switch, just separate NICs. I was confused since I bridged them >_> May 12 09:23:51 jow: my puny brain can reason about DSA easier than swconfig at least. May 12 09:24:49 mangix: so how do you configure a vlan trunk in dsa? May 12 09:26:22 no idea. I just know bridge these ports. May 12 09:26:58 ... May 12 09:28:01 make simple things default and complex things impossible, sounds like a good approach May 12 09:28:41 :D May 12 09:28:51 almost sounds like gnome :P May 12 09:30:11 well, the goal is to abstact away the switch as far as I understand May 12 09:30:50 yeah, sure. instead of ip and swconfig you now need ip and bridge May 12 09:31:01 and still an abstraction on top May 12 09:32:23 and you still need intrinsic hardware details to know which configuration to apply May 12 09:33:02 Such as? May 12 09:33:10 https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#configuration-without-tagging-support May 12 09:33:22 vs. May 12 09:33:24 https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#configuration-without-tagging-support May 12 09:33:30 sorry https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#configuration-with-tagging-support May 12 09:35:14 * rmilecki is back online May 12 09:35:24 interesting... May 12 09:35:45 so, jow, what's your preferred way to go there in this matter? May 12 09:35:53 which switched lack tagging? May 12 09:35:55 go back to swconfig? May 12 09:36:06 *switches May 12 09:36:14 add abstraction on top in openwrt as discussed earlier? May 12 09:36:23 find somebody to make DSA better? May 12 09:36:26 mangix: various ones supported by swconfig now. Iirc the one found in the ER-X too May 12 09:36:58 ER-X is mt7621? May 12 09:37:00 adrianschmutzler: my plan is to support a variant of the current swconfig uci syntax for dsa May 12 09:37:04 mangix: yes? May 12 09:37:08 it is May 12 09:37:44 Interesting... May 12 09:38:21 I don't really care about which network userspace tool of the month is the one to use, as long as we have a somewhat unified high level network config May 12 09:39:13 which doesn't leak too much hardware details (the swconfig one in its current form also leaks a lot of hardware details, such as vid vs. vlan / vlan table size etc.) May 12 09:39:18 jow: hahaha I'm sure you'll love iwd May 12 09:39:40 as far as I understood iwh is just nih for wpa-supplicant May 12 09:39:44 *iwd May 12 09:39:53 why is that easier with swconfig BTW? because it was built with the abstraction concept in mind? or because I am used to it and don't see the abstraction anymore? May 12 09:39:56 oh it gets better May 12 09:40:12 iwd handles or will handle DHCP by itself May 12 09:40:32 sorry, IP assignment May 12 09:40:33 adrianschmutzler: I don't mean swconfig, I mean a variation of the uci syntax consumed by swconfig May 12 09:40:43 mangix: so nih + layer violation May 12 09:41:13 WPA3 apparently can send IP information for clients. May 12 09:42:10 anecdotally, it works better on my desktop than supplicant May 12 09:45:20 adrianschmutzler: we need a configuration syntax that is able to encode certain information in a somewhat consistent manner, such as ingress/egress vlan tags on ports May 12 09:46:20 the major difference of dsa compared to swconfig that I see is that instead of programming vlan table entries in the hardware (swconfig) to tie ports together, you use bridges in dsa May 12 09:47:03 that part is already covered by the existing interface uci (e.g. config interface lan; option type bridge; option ifname "lan1 lan2 lan3") May 12 09:49:08 however, if the underlying dsa switch does not happen to support a tagging proto, we need to somehow deal with programming helper vlans and bridge filtering as shown in https://www.kernel.org/doc/html/latest/networking/dsa/configuration.html#configuration-without-tagging-support May 12 09:51:42 a somewhat common scenario I use as "benchmark" is the following: May 12 09:51:42 hmm, don't look like it will be much fun to have a comprehensive syntax for both swconfig-based and dsa-based devices. We might be lucky if we can find a good solution for all DSA ... May 12 09:52:13 vlan trunk on wan: vid 10 is ppp, vid 20 is multicast, vid 30 some voip service May 12 09:52:47 wan.10 should terminate on the router to run pppoe on, wan.20 tagged should be bridged lan1 untagged to bridge multicast traffic to a stb connected to lan1 May 12 09:54:53 I would expect something like this to just work: https://pastebin.com/guE4qDN9 May 12 09:55:15 if it doesn't, the necessary details need to be implemented in a transparent manner to do whatever is needed for DSA May 12 09:57:31 I'm not sure whether I get all the implementation details yet, but it looks like your solution is bringing us forward May 12 09:57:45 oh and ideally "lan1 .. lan4" and "wan" should be device-agnostic May 12 09:58:36 but that might bring a lot of confusion since "option ifname" so far only takes raw linux netdev names (or the "@alias" notation) May 12 09:58:49 so we have to use whatever upstream settled on May 12 09:58:54 that might be quite if we have separate port May 12 09:58:58 *ports May 12 09:59:24 e.g. lan1 lan2 _and_ some eth0 eth2 May 12 09:59:35 or we add a new syntax element like "#lan1" "#wan" to refer to symbolic port names May 12 09:59:36 *quite hard May 12 10:00:02 but these are just preliminary thoughts May 12 10:00:18 the problem with the latter is that we are doing assumtions here May 12 10:00:37 but from a user pov you want to somehow connect port 2 with port 4 or wan vlan 10 with lan port 3 May 12 10:00:42 and if some device with an atypical setup shows up, it might not match that May 12 10:01:04 yes May 12 10:01:05 you don't want to know if your particular device calls its lan3 rj45 plug "ethernet2" or "lan3" or "eth3" May 12 10:02:45 I'm on your side for this one in general, I've just made the experience downstream that if you put too much assumptions to a problem, it will blow later May 12 10:03:27 but of course, after all we assign to lan or wan eventually anyway May 12 10:03:27 so a hypothetical solution would be having a mapping somewhere (similar to all that ucidef_add_switch lines of 02_network for swconfig) plus a syntax like that: https://pastebin.com/NQxtRxdE May 12 10:03:40 *assign everything May 12 10:04:11 maybe chose another character than `#` because that one is complicated in shell May 12 10:04:39 or introduce a different uci option (option port vs. option ifname) May 12 10:05:09 without having thought it through, I'd go for the latter May 12 10:05:23 https://pastebin.com/gDT1BTxG May 12 10:07:33 btw, i know this is just an example, but do we still have devices that can only manage 16 vlans? May 12 10:07:49 yeh, I think so May 12 10:08:24 rt8366s comes to mind (or rtl8366rb) May 12 10:08:37 not sure, but one of these two had a limited vlan table size May 12 10:10:14 swconfig had a design weakness there, because it exposed these limitations directly by using vlan ids as taqble indexes, then adding a kludge to let the user specify the table id manually (option vid + option vlan) instead of simply allocating slots internally and failing with -ENOBUF or whatever if the table is full May 12 10:13:38 and I'm never sure what is a hw limitation and what is an swconfig backend driver limitation May 12 10:14:05 so, swconfig has it's downsides, too ;-) May 12 10:14:27 I never said it hasn't, its just not better or worse than swconfig May 12 10:14:32 than dsa I mean May 12 10:15:03 because the "dsa means you can simply mange your switch by bridging per-port-netdevs" meantra does not appear to be true (as far as I understand the situation) May 12 10:15:56 and (at least a while back) there were actual limitations like inability to handle multiple cpu ports May 12 10:16:04 might be adressed already May 12 10:16:48 at least for the recent OpenWrt implementations, it seemed to still apply May 12 10:17:12 and we also haven't made friends with the hwnat crowd May 12 10:17:51 (despite that it might be broken in 19.07 anyway) May 12 10:18:46 adrianschmutzler: jow: quick question May 12 10:19:22 I've tested the Mikrotik series for 19.07 from f00b4r0 on a ton of devices and all seems well. Also Aredn seems to have published it so it got more testing already May 12 10:19:25 another big design weakness with swconfig in the general config perspective was that it always was kind of "tacked on", means the network config was split into two distinct parts - one was programming the switch ic through config switch / config switch_vlan sections, the other was aranging bridges and ip config by referencing implicitely created ethX.Y netdevs May 12 10:19:33 would you also feel comfortable to publish it for 19.07.3? May 12 10:20:07 in an ideal config model, the switch config should be interleaved and transparent to the user May 12 10:20:25 xback: I'm agnostic there May 12 10:20:32 at least as far as it is sanely possible and not violating too much expectations May 12 10:21:01 xback: please do May 12 10:21:53 xback: but please apply those two ar71xx at the end to master as well, so it doesn't deviate further May 12 10:22:03 *two ar71xx patches May 12 10:22:06 adrianschmutzler: will do May 12 10:22:24 I'll also push the latest kernels bumps. compile tests finished this morning May 12 10:24:08 xback: and could you please look at my backported platform.sh for routerboard here: May 12 10:24:09 https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=commitdiff;h=aeba7d8fdc9af792256b8959e1d195bca88c0419 May 12 10:24:39 It's already in master, but the code was adjusted in master between, so I'm not really confident on merging this without testing May 12 10:24:46 adrianschmutzler: Thanks for the reminder. will check this after lunch May 12 10:24:58 i'' give it a test on actual boards May 12 10:25:29 From the code, it's not complicated, and I'm quite sure it will work, just want to get the last 5 % safety ... May 12 10:27:58 jow: after all, I think we should get this DSA abstraction sorted out, so we have a clean solution for 20.xx. I'm all in for unifying stuff there and making it easier for the user. However, my abilities are limited, so I can only look at it from high-level perspective and won't be much help despite that. May 12 10:31:11 side note: is there an interest in testing a treewide switch to use this https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=02a9d3d6a932cdf707f8bcf4555d095839ce8d24 ? May 12 10:31:25 It feels like it could save precious KB on flash-constrained devices May 12 10:31:54 and might be a nice feature for 20.x May 12 10:32:52 f00b4r0: but this would be done on each boot while the previous solution only was done on firstboot? May 12 10:33:27 adrianschmutzler: correct. But it's actually faster than the previous version May 12 10:33:28 at the expense of wasting jffs2 space (afair) May 12 10:33:35 ^ May 12 10:37:03 as this is a generic kernel interface it _should_ work transparently in all cases, but of course only a widespread test can confirm that May 12 10:38:43 how does mac address patching work with that mechanism? did we do that with the mikrotik devices? May 12 10:39:05 mac patching relies on https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=8f4735297bbfb24976e06bb4f2f115be29a99404 May 12 10:39:29 and it works like this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=9242d691ec847e20b68a2dcfca3ae3a7f6674be2 May 12 10:39:33 ah, that's what you needed the $target for IIRC May 12 10:39:38 yup May 12 10:41:36 looks less clean in code, but I don't think this is a real issue if we get used to it May 12 10:42:24 actual space requirements would be tiny though, both in flash and in RAM? some 1-4 kB ...? May 12 10:42:27 it's only 2 more lines of script :) May 12 10:42:39 adrianschmutzler: it uses a full EB tho May 12 10:42:41 so an increase by 100 % :-) May 12 10:43:28 do we still actually need that mac patching crap? May 12 10:43:55 i thought the ath10k issue triggered by changing the mac address via sysfs was fixed by now May 12 10:44:00 "it uses a full EB tho" does it really? that would be an argument indeed May 12 10:45:00 jow: currently DSA does not support bridgeing untagged and tagged ports well, either the frames cannot flow between ports or they can but tag/untag operation is done by CPU. VLAN filtering has to be used. May 12 10:47:39 dengqf6: so one reason more to abstract these pecularities away in a higher level uci config May 12 10:49:17 dengqf6: I assume the same limitation applies if you want to to tag one vlan on one port to another vlan on another port May 12 10:49:32 like a bridge over lan1.20 and lan2.40 May 12 10:49:34 jow: We should abstract **VLAN filtering** in the bridge interface because software ports such as wlan0 can be a member too May 12 10:49:45 adrianschmutzler: i would expect "less flash wasted and faster boot" to be quite a pair of arguments already :) May 12 10:49:47 not just DSA May 12 10:50:04 dengqf6: I agree May 12 10:50:28 jow: changing VLAN tags is not supported yet May 12 10:50:47 Though I think the hw supports tag swap (CVLAN/SVLAN swap) May 12 11:01:19 dengqf6: do you have any opinion on how such an abstracted uci configuration could look like? May 12 11:04:16 dedeckeh: is there some way to configure the prefix odhcpd will serve to a relayed DHCPv6 request? May 12 11:06:16 stintel:you can set the ip6prefix uci option on the wan interface May 12 11:08:16 dedeckeh: I have that, but the problem is that it replies with the subnet that is configured on the interface where the request comes in. for dhcpv6 request relayed from another network that obviously does not work May 12 11:14:08 build #360 of at91/sama5 is complete: Failure [failed dirupload] Build details are at http://buildbot.openwrt.org/master/images/builders/at91%2Fsama5/builds/360 blamelist: Koen Vandeputte , Daniel Golle May 12 11:23:21 jow: would there be room for something like /lib/functions.sh:config_get_bool() in the LuCI.uci function set? to handle a "correct" coercion to js booleans? May 12 11:40:02 karlp: sure May 12 11:43:26 jow: have you used `bridge vlan show`? May 12 12:21:34 dengqf6: did you not CC any OpenWrt mailing list for your 'net: dsa: mt7530: fix roaming from DSA user ports' patch or am i mistaken? May 12 12:22:07 Borromini: I created a PR May 12 12:22:25 ah! May 12 12:23:08 https://github.com/openwrt/openwrt/pull/2942 < this one right? May 12 12:25:38 Borromini: yup May 12 12:29:11 dengqf6: thanks. i have added this into the wiki atm: https://openwrt.org/docs/techref/hardware/switch#dsa_distributed_network_switch May 12 12:29:35 jow: if you can take a quick look at that as well and if either of you can let me know if it contains any half-truths/incorrect info May 12 13:06:10 dengqf6: yep May 12 13:10:25 Hi, I am using the latest trunk version for the lantiq xrx200 (zyxel 2812). However after install the ethernet ports are not available. I get a 'lantiq.xrx200-net probe of 1e108000.eth failed with error -22' Switching to the 19.07 branche works ok. I also tried to update the config with diffconf, but made no difference. Any clues? May 12 14:06:58 jow: it's just like swconfig: br-lan = CPU port, lan1 = port 1, etc. May 12 14:07:37 jow: Except that it allows multiple untagged VLANs on a single port May 12 14:07:54 jow: PVID is unique tho May 12 15:06:20 xback: ping: routerboard sysupgrade May 12 15:06:38 adrianschmutzler: testing atm :-) May 12 15:43:06 adrianschmutzler: look ok May 12 15:43:11 looks* May 12 15:46:46 thanks, then I will push it to 19.07 May 12 15:50:07 since we don't have ath79 mikrotik in 19.07, I don't think it's necessary to push it to 18.06 as well? May 12 15:50:17 it applies cleanly there, though ... May 12 16:03:41 true, I would also skip 18.06 May 12 16:03:54 there is no gain, so let's avoid a risk May 12 16:04:14 technically, there would be for 18.06 to 20.xx updaters ... May 12 16:04:27 but I also tend to say it's not worth it May 12 16:05:19 sounds like a luxury issue May 12 16:45:10 ok from what i gather it seems there's one device in ath79/tiny on DSA somehow (?) but ath79/generic is still fully swconfig. May 12 16:45:56 build #357 of armvirt/32 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/armvirt%2F32/builds/357 May 12 17:06:01 Borromini: which? May 12 17:06:40 wr941n v2 which is currently broken if I remember correctly May 12 17:25:29 What’s Yousong’s handle? May 12 17:26:16 jow: what did you think of his suggestion about --contiguous? May 12 18:42:35 philipp64: his suggestion makes sense. one could argue whether the default meaning of that extra flag should be "true" or "false" but I agree that "--contiguous" should be toggleable somehow May 12 18:43:10 for those cases were people need the previous, usually undesired behaviour of two distinct timeframes May 12 18:43:10 okay. i’ll redux with the default being true. May 12 18:47:36 build #294 of mpc85xx/p2020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp2020/builds/294 May 12 18:50:24 Hi all May 12 19:54:47 micmac1: Hi micmac1! May 12 19:55:20 ynezz: ping May 12 20:07:08 ynezz: I had to restart some of the osuosl builders since 19.07 phase1 and phase2 got out of sync May 12 22:38:48 build #301 of rb532/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/rb532%2Fgeneric/builds/301 May 12 23:19:21 build #302 of x86/64 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/x86%2F64/builds/302 May 12 23:37:10 build #317 of mpc85xx/p1020 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/mpc85xx%2Fp1020/builds/317 May 13 00:35:24 build #315 of gemini/generic is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/gemini%2Fgeneric/builds/315 May 13 01:16:06 build #316 of ramips/rt305x is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/ramips%2Frt305x/builds/316 **** ENDING LOGGING AT Wed May 13 02:59:58 2020