**** BEGIN LOGGING AT Fri Sep 25 02:59:57 2020 Sep 25 07:41:32 kab-el: First of all I'm using the latest kernel for everything. I made many private modifications to the switch driver and other drivers (for a different device) and managed to link the link the bridge interface to the switch driver in a way that allows for a fully managed & offloaded configuration. I'm going to do experiments with bridge-vlan and uci configuration now. Sep 25 07:43:59 kab-el: I have one omnia here for testing with Turris OS 4.0.1 / Linux 4.14 and I'd be interested in testing it with Linux >= 5.4 at the least and seeing some progress in the advanced configuration. I mean, I understand that it's primarily a home router/device but then I'd like to at least get bridge-vlan confguration and similar stuff done right. Sep 25 07:45:55 pavlix: bridge-vlan config should already be implemented in netifd Sep 25 07:46:04 you just need to bump it to the latest Git head Sep 25 07:46:33 related luci support is pending here: https://github.com/openwrt/luci/pull/4307 Sep 25 07:47:17 jow: Since when? Sep 25 07:47:25 pavlix: one or two months Sep 25 07:47:52 https://git.openwrt.org/?p=project/netifd.git;a=commit;h=0e8cea0f2acdae3812f9603ee046055acd89d717 Sep 25 07:48:55 jow: That is a great news! Thanks. I'm using the latest but missed that piece of information. Sep 25 07:49:19 there's another patch pending which allows to consolidate our default config Sep 25 07:49:25 which is not yet merged though Sep 25 07:51:10 jow: I will have to modify netifd to *not* destroy my bridge when it's „down“. The !IFF_LOWER_UP on a bridge doesn't say much and especially not that I want to destroy the bridge. Sep 25 07:51:42 did you try "option force_link 1" or "option bridge_empty 1" ? Sep 25 07:51:50 jow: I actually have a pre-created bridge with special configuration *before* netifd even starts. Sep 25 07:52:02 maybe I misunderstand your particular case, but netifd did not destroy bridges for me so far Sep 25 07:52:04 jow: I didn't know about those options. Sep 25 07:52:08 ah okay Sep 25 07:52:21 you should migrate to "config device" configuration Sep 25 07:52:30 and let netifd create the bridge Sep 25 07:52:35 jow: I saw an ifdown event in the console. Sep 25 07:52:49 it will nuke and recreate things on startup Sep 25 07:53:25 jow: Actually I have experimental changes to the linux kernel bridging code. The current way bridge works with DSA switches simply doesn't give the results I expect. Sep 25 07:54:08 can you elaborate? Sep 25 07:55:14 jow: The bridge always tries to be clever and send everything over the virtual switch ports. That means e.g. multicast gets sent multiple times to the switch, abusing the CPU-switch link. Sep 25 07:55:41 jow: What I do is that I send everything from the bridge directly to the switch and let it handle the traffic. Sep 25 07:56:37 jow: I also lock the bridge to *only* include the switch ports right now and disallow any changes to the port list. Sep 25 07:57:25 sounds quite invasive Sep 25 07:57:31 (All of that in preinit. But I still allow the bridge to be destroyed just in case I want to experiment with a classic bridge.) Sep 25 07:57:47 jow: It sound very invasive but it wasn't that difficult. Sep 25 07:58:12 whats the usecase for disallowing port changes? Sep 25 07:58:29 is your idea to "map" the switch IC using an immutable bridge? Sep 25 07:59:38 jow: That is exactly what I'm doing. I'm disallowing any configuration that might be invalid. It e.g. seems that creating br0 with lan1,lan2 and br1 with lan3,lan4 might be an invalid config for the hardware, especially if vlans get involved. Sep 25 08:00:30 hm yes, I understand Sep 25 08:01:38 the approach we're targeting for the OpenWrt defualt config is somewhat similar, the plan is to have a bridge called "switch0" which contains all ports and the let the user use bridge-vlan filters to build logical interfaces on top, e.g. a switch0.1 which targets the lan ports and a switch0.2 which targets the wan port (in case wan is not a separate nic) Sep 25 08:02:05 jow: Plus I want to start the bridge configured for user-space STP and then later run mstpd to take over it. Sep 25 08:02:08 we didn't aim for an immutable bridge though, we simply put it as normal bridge declaration in the default config Sep 25 08:02:16 jow: I also planned to rename br-lan to switch0. Sep 25 08:02:56 it seems to go contrary to the orginal DSA design philosophy though Sep 25 08:03:28 they way I understood it at least is that you simply bridge netdevs together to achieve your goal, so I would've expected br0(lan1,lan2) + br1(lan3,lan4) to be a perfectly valid, working config Sep 25 08:03:31 jow: Yes, it somewhat diverges but in a good way in my opinion. Sep 25 08:04:36 jow: In my case the br-lan (will be switch0) already knows about eth0 (renamed to dsa0) and sends all frames directly to the switch so that they don't get duplicated via the virtual ports. Sep 25 08:04:42 I also find the concept of a central bridge abstracting the switch more natural compared to having multiple bridges covering different "portions" (as in ports+vid) of the switch Sep 25 08:06:26 jow: Also if you look e.g. at tag_edsa.c in the kernel, you'll see that you are receiving „forward“ and „to cpu“ frames but are only sending „from cpu“ and not „forward“. I'm already sending the bridge traffic as „forward“. Sep 25 08:06:47 jow: did you see https://patchwork.ozlabs.org/project/openwrt/patch/20200827090442.251759-2-mail@aparcar.org/ ? Sep 25 08:06:56 Image builder reproducibility Sep 25 08:15:52 aparcar[m]: no, didn't see it yet Sep 25 08:18:28 jow: Do we have a config example for the whole /etc/config/network with switch0? Sep 25 08:21:58 And by the way, bridge has named ports while swconfig has numbered ports, how is that gonna merged? Sep 25 08:22:10 (switch has named ports) Sep 25 08:32:48 jow: also please have a look at the opkg patches. I run tested them and packages would install fine etc. I'll try to look at the dependency issue tomorrow Sep 25 08:49:01 pavlix: we changed the syntax from "[0-9]+[ut]?" (e.g. 0u, 3t, 4) to "\w+(:[ut*])?" (e.g. lan1:t*, lan2:u, wan) Sep 25 08:51:27 pavlix: this proposal has been implemented: http://lists.infradead.org/pipermail/openwrt-devel/2020-July/030152.html Sep 25 08:52:06 pavlix: then refer to "option ifname switch0.1", "option ifname switch0.2" etc. in the various "config interface" sections Sep 25 08:52:30 (and ensure that "config interface lan" is declared without the "option type bridge" legacy hack) Sep 25 08:54:13 pavlix: and the switch0 bridge port list is automatically built as the union of all bridge-vlan section ports Sep 25 09:03:48 jow: That's perfect. Is there a way to run a custom command after bridge creation but before setting the bridge or any switch ports up? Or should I stick with the pre-created bridge? Sep 25 09:09:02 there's no command hooks unfortunately. But depending on how you did you kernel modifications it might be easier to simply patch netifd to toggle any custom knobs you implemented here: https://lxr.openwrt.org/source/netifd/system-linux.c#L1212 Sep 25 09:10:58 or add something like a dirty system("/bin/setup-my-bridge.sh") hack Sep 25 09:24:12 jow: Thx. Sep 25 09:26:44 jow: Oh, netifd is designed as a cross-platform thing! Sep 25 09:27:03 I did that with NetworkManager looong ago. Sep 25 10:11:09 Hey everyone, I tried installing the latest snapshot on a mikrotik rb750gr3 and the result was a non-functioning system. I bisected to the point where I found the first bad commit (7081b1704e978414cf8e9ea10bf77be9787aa338). I tried doing a git revert, but that led to conflicts. So I just went ahead a deleted the patch which was added by that commit, built, and the image works. My question is, how should I go about this? Should the patch (tar Sep 25 10:11:09 get/linux/generic/pending-5.4/770-11-net-ethernet-mtk_eth_soc-avoid-rearming-interrupt-if.pa) be removed or updated somehow? Unfortunately I'm not familiar with kernel code. Sep 25 10:18:51 With the current snapshot, on the serial console I only get the following https://pastebin.com/UTaUKmsF Sep 25 10:22:01 pmelange: someone reported recently that adding some spaces (about 16?) to the kernel command line helped and that it's the problem with lzma-loader command line handling code. Sep 25 10:22:54 This sound like a messed up fix. Anyhow, I don't get into uboot and can't change the kernel command line anyhow. Any other ideas? Sep 25 10:23:21 pmelange: the command line is hardcoded in DTS and the one from u-boot is ignored. Sep 25 10:24:15 Ok, that's good to know. I'll give it a try. But somehow that doesn't seem like a good solution. Sep 25 10:25:30 pmelange: it's just a hacky workaround indeed, not a real solution. Sep 25 10:32:07 Hihi, DSL outage at home once again, hotline: "Did you try turning off/on again?" - "Yes" - "Did you check the cable connections?" - "Yes" - "What lamps are lighting up?" - "Definitely not the 'DSL synced' one - look, I know you gotta ask those questions and I'm happy to answer them. But I'm also having some more technical details about the line state directly provided by the modem in case that might Sep 25 10:32:14 help.." - "How did you retrieve those information?!" - "Well, I'm working with routers.." - "THEN WHY DON'T YOU MAKE THEM *ACTUALLY* WORK?!" .. touché :) Sep 25 10:35:36 mirko: "Because you haven't provided me access to the DSLAM." :P Sep 25 10:46:23 Ok, I added a new "chosen" section for the rb750gr3 and added 16 spaces to the end. Yup, It boots. So, what would be a proper fix? Sep 25 12:18:44 zorun: i've got an unused alix2f18 laying around. want it? Sep 25 12:19:06 (or, same offer to anyone else in france who might have a good use for it) Sep 25 12:19:50 https://www.pcengines.ch/alix2f18.htm this thing Sep 25 12:21:25 Hauke: with my latest lantiq DSA PR - LAN3 and LAN4 (both driven by the external PHYs) work for you? they don' Sep 25 12:21:33 ... don't for me Sep 25 12:29:52 pavlix: omnia is used by enterprise as well, many of our client who are buying it are bigger companies, not just end users Sep 25 12:29:57 pavlix: afaik Sep 25 12:30:38 pavlix: I am using 5.4 on my omnia as well. Bridging/vlaning should be offloaded to hardware on that switch even in 4.14, though Sep 25 12:32:48 pavlix: I am currently trying to get TurrisOS hbd to build, which is based on openwrt master, so with 5.4 Sep 25 12:32:56 pavlix: ... 5.4 kernel Sep 25 12:46:05 kab-el: When I asked about VLAN configuration for Turris I got a suggestion to put e.g. p1.22 to the bridge to get VLAN 22 working. That's the old-school VLAN, not the offloaded VLAN, right? Sep 25 12:54:49 pavlix: but you need this for DSL SFP module, right? Sep 25 13:26:38 kab-el: Nope. I'm only using omnia for testing out the switch. Also the bridge vlan support in icu/netifd wasn't in openwrt before the June commit already mentioned. Sep 25 13:27:51 kab-el: I suspect the features simply aren't part of any released version of Turris OS. Sep 25 13:56:50 pavlix: its possible Sep 25 13:58:11 pavlix: its possible that it is not supported by released versions. I am trying to get all stuff work on upstream kernel and than backporting for 5.4, but all released stable versions are based on 4.14 Sep 25 13:58:23 pavlix: you can try hbd branch, that is based on 5.4 Sep 25 15:02:39 pavlix: q Sep 25 16:12:44 kab-el: Okay, why not! Sep 25 16:15:02 rmilecki: I fear there's more brokeness introduced by your uhttpd api rework Sep 25 16:15:45 rmilecki: I keep getting reports about random luci packages and views throwing "Unexpected reply data format." exceptions which are caused by the fs.js module if an ubus reply does not contain expected data Sep 25 16:16:46 rmilecki: also this seems to be new: https://github.com/openwrt/luci/issues/4467 Sep 25 16:17:08 given the fact that there's been no related changes in LuCI for weeks I'd suspect that uhttpd is to blame Sep 25 16:29:01 jow: can you have a quick look here: https://patchwork.ozlabs.org/project/openwrt/patch/20200920053140.35255-3-rosenp@gmail.com/ Sep 25 16:29:34 I think this is valid. I just wonder whether one can use a non-negated statement for the default-case instead? Sep 25 16:29:52 But it appears like select-case has no syntax for repeated characters like regex? Sep 25 16:32:32 using positive instead sounds ismpler to me :) Sep 25 16:33:01 but what's the positive expression for "all characters are A-Za-z0-9_ ? Sep 25 16:33:39 just take out the ^/! ? Sep 25 16:34:00 then it will match if only one character is like that Sep 25 16:34:13 but it must be ALL characters Sep 25 16:34:20 what sort of cruft is coming in? Sep 25 16:34:21 that would be very easy in regex Sep 25 16:34:37 just an uci section or option name Sep 25 16:34:56 so "section" would be valid but "invalid-section" wouldn't be valid Sep 25 16:35:02 is that even true though? busybox ash isn't dash, even if shellcheck thinks it is mostly. Sep 25 16:35:06 (since minus is invalid character) Sep 25 16:35:29 that's the commit introducing it: Sep 25 16:35:30 https://github.com/openwrt/openwrt/commit/4a6795409d1520fd3da3e909a8bcf9d7fd0927bb Sep 25 16:37:07 revert the original and let the syntax error flow up instead of squelshing it to a "you got an empty variable with no warning" Sep 25 16:37:40 there is no syntax error, but just broken return values Sep 25 16:37:53 " -ash: eval: syntax error: bad substitution" Sep 25 16:38:04 config_get var1 abcd-ad def Sep 25 16:38:07 gets you Sep 25 16:38:13 "ad_def:-" Sep 25 16:38:28 if you're passing a bad option, and hoping to get the default, I thnk you're being misled, Sep 25 16:38:32 Seems like minus sign is more special here Sep 25 16:38:55 I presume this only actually comes up with people are generating the options to look for or something Sep 25 16:39:26 if you pass a badoption, i'd rather it fialed earlier so I fixed the option check, not discovered later than I unexpectedly got a default, but hey, *shrugs* Sep 25 16:41:01 That's why I pinged jow, as it's his patch initially Sep 25 16:41:27 But I'm still curious whether I can have multiple characters checked in a select-case Sep 25 16:41:46 like regex ^[A-Za-z0-9_]+$ Sep 25 16:54:06 zorun: ping Sep 25 17:05:17 xdarklight: the UART conenction on my BTHH5a is currently broken, what is not working for you, do you find the PHYs? Do you get a link up? Sep 25 17:06:40 Hauke: oh okay. yes, it finds the PHYs and I get a link up/down even when (un)plugging the cable. but data doesn't seem to flow (neither with ping nor with anything else) Sep 25 17:07:26 what does "ethtool -S" (MAC counters in switch) show? Sep 25 17:08:17 Hauke: I'll check it in an hour or so. I'm currently debugging why Ethernet is not working on some Amlogic board ;-) Sep 25 17:08:55 xdarklight: ;-) Sep 25 17:09:14 (fixing) broken Ethernet is my motto for today ;-) Sep 25 17:14:57 Afternoon Sep 25 17:22:09 Hauke: the MAC thinks that everything is fine on lan4 (where I have currently connected the cable): https://pastebin.com/92kmhqWu Sep 25 18:13:05 adrianschmutzler: pong Sep 25 18:13:46 zx2c4: not interested, sorry (compared to an APU2, this is just too slow) Sep 25 18:14:41 even APU2 is getting too slow for me :( Sep 25 18:15:18 now if only I could manage to boot a kernel on this Firebox M300, I might be able to replace it soon Sep 25 18:36:32 zorun: no problem. if ya meet anyone who wants a free alix, send em my way! Sep 25 18:40:19 zorun: regarding these patches: Sep 25 18:40:50 https://patchwork.ozlabs.org/project/openwrt/patch/20200903211907.654588-1-baptiste@bitsofnetworks.org/ Sep 25 18:41:05 As I understand it, what you are changing is only the fallback? Sep 25 18:41:27 but we use $BRANCH in the line before to do exactly the same Sep 25 18:43:45 jow: sure, I agree I'm the most likely to blame Sep 25 18:44:13 jow: i don't see how else I could handle that, that patch was on ML for months, I kept asking on IRC for testing Sep 25 18:44:29 jow: i guess there's no other way than just pushing change to get it really tested Sep 25 18:44:36 jow: i will fix remaining regressions Sep 25 18:51:02 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_kirkwood.html has been updated. (100.0% images and 99.7% packages reproducible in our current test framework.) Sep 25 19:27:44 nbd: can I pre compile the buildsystem tools and drop them as a cache into toolchain builds without causing the toolchain build to rebuild tools? Sep 25 19:28:14 Use case is to build tools first and then use them for multiple parallel toolchain builds Sep 25 20:57:00 adrianschmutzler: indeed, openwrt-19.07 is used as the fallback branch, because using master as fallback doesn't make sense Sep 25 20:57:17 adrianschmutzler: $BRANCH is the current branch, it can be anything (local branch) Sep 25 20:57:50 like "my_local_19.07_hacks" Sep 25 20:59:40 but is there a practical relevance except for tidyness? Sep 25 21:00:31 the patch gives meaningful version numbers Sep 25 21:01:00 r11192+6-8b0278a17e instead of r10194+1004-c53f62b111 Sep 25 21:01:13 but the line you change only affects a situation where you have not checked out any branch at all Sep 25 21:01:20 ? Sep 25 21:01:55 if you have checked out any branch, you will use Sep 25 21:01:58 it affects the situation where you are working in a local branch like "my_local_19.07_hacks" based off openwrt-19.07 Sep 25 21:02:00 ORIGIN="$(git rev-parse --verify --symbolic-full-name ${BRANCH}@{u} 2>/dev/null)" Sep 25 21:02:20 this line fails with: fatal: no upstream configured for branch 'my_local_19.07_hacks' Sep 25 21:02:30 because there is no upstream Sep 25 21:03:20 yes, but when that was the case, openwrt-19.07 failed for me as well Sep 25 21:03:48 what defines the upstream? Sep 25 21:04:33 look at .git/config Sep 25 21:04:47 an upstream is automatically configured from a branch when you clone or fetch it from a server Sep 25 21:04:58 *for a branch Sep 25 21:05:17 it's what allows you to simply type "git pull" and it pulls from the right server Sep 25 21:05:48 so, usually, the local openwrt-19.07 branch would have an upstream (the openwrt git repo) Sep 25 21:06:18 okay, so that seems to be missing at my repo and therefore my test went wrong Sep 25 21:07:52 okay, but apart from my configuration issues, I think I understood the point of the patch now Sep 25 21:08:14 cool :) Sep 25 21:10:19 that being said, I realize now that there are corner cases Sep 25 21:11:13 if you are on a local branch that has a private repository as upstream, getver.sh will compute a meaningless version number Sep 25 21:11:46 (it will show a number of "upstream commits" that includes all commits in the branch from the private repository) Sep 25 21:11:48 Ah, the finer points of things of which I have no idea of :D I actually enjoy it Sep 25 21:11:50 but that's already the case now Sep 25 21:12:23 that's what I'm thinking about right now: since I've understood the intention, I wonder whether it makes sense conceptually Sep 25 21:12:25 I mean, my patch doesn't change anything about this issue Sep 25 21:12:39 probably this was never intended to be used like this, but only for the buildbots? Sep 25 21:13:37 the "r11192+6-8b0278a17e" format is meant to help troubleshooting issues Sep 25 21:14:09 Does anyone know, offhand, what the size of UART serial pins are in a traditional 4-pin header? Sep 25 21:14:10 it means that the build is based on r11192 (upstream openwrt rev) / commit 8b0278a17 (upstream openwrt commit) + 6 local commits Sep 25 21:14:44 so if somebody has an issue, you know it's not a pure upstream openwrt build Sep 25 21:15:48 zorun: okay, I will think about it. as you say, it does not make anything worse Sep 25 21:16:00 conversely, if it's "r11192-8b0278a17e", you're pretty sure it's a build without local commits, and you know which upstream commit Sep 25 21:16:34 at least that's the way I understand it Sep 25 22:46:20 zorun: ping Sep 25 23:17:05 PaulFertser: ping Sep 26 00:18:22 * mangix grabs popcorn Sep 26 00:18:43 people raging with text is hillarious Sep 26 00:20:03 mangix: Oooo.. Where? Sep 26 00:20:10 I love a good popcorn moment Sep 26 00:21:34 https://github.com/openwrt/packages/issues/12812 Sep 26 00:22:10 * mangix this package is not maintained because of you Sep 26 00:22:12 interesting Sep 26 00:22:40 he keeps editing his posts with more and more anger Sep 26 00:22:46 something's going on Sep 26 00:28:25 They'll get over it Sep 26 00:28:44 ¯\_(ツ)_/¯ Sep 26 00:29:01 They should be running an official build if they want to have consistency anyway Sep 26 00:29:45 good point Sep 26 00:29:56 none of the changes he or I mention are in 19.07 Sep 26 00:30:10 You take your build in own hands when you rebase or git pull or update the feeds Sep 26 00:30:17 and you best be ready to roll them back when you do Sep 26 00:31:03 well w/e. the condition of canutils is the same as in 19.07. Sep 26 00:31:15 just newer version and more utilities Sep 26 00:31:23 eh, in any case, it was fixed Sep 26 00:34:39 oh boy Sep 26 00:34:46 I don't want to feed the troll Sep 26 01:07:06 Sigh Sep 26 01:10:22 :) Sep 26 01:37:02 See, that worked out well **** ENDING LOGGING AT Sat Sep 26 02:59:57 2020