Re: DSA Mini-tutorial still marked as Work In Progress
> - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" > - VLAN filtering disabled Bridging virtual 802.1q interfaces might fail in some scenarios, like when you use vlan1 or mix tagged with untagged traffic (https://github.com/openwrt/openwrt/issues/9066) I do recommend bridge-vlan as the first option, although ip-bridge is not installed by default. I know that it is a little bit off topic but I would love some transitioning code that could mimic swconfig devices as if they were DSA. Instead of using swconfig settings for tagged vlans/isolated ports, just create fake lan1, lan2, wan interfaces (802.1q) and derive the swconfig settings from that. I've been doing that for some time, creating switch_vlan configs from bridge+bridge-vlan and replacing the user ports with the CPU port in every related bridge-vlan. This way I can share the config with swconfig, DSA and even devices without switches (VM like gns3) if I rename eth0, eth1, eth2 to lan1, wan, lan2. The only downsides are that untagged bridging is done using software bridge and the config is generated as a single-shot step (uci-default). However, if that mapping is done inside netifd, I believe it might be able to better handle those cases. Regards, Luiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
On 9/7/2022 3:00 PM, Sebastian Moeller wrote: Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? It is incorrect. DSA offloads the bridge to the switch hardware whether you have VLAN filtering or not. When the bridge is not VLAN aware (vlan_filtering=0) what it means is that the Linux bridge, and the underlying switch MUST accept both VLAN and non-VLAN tagged frames. If you do want VLAN tagged frames in that bridge, then you are supposed to terminate VLAN traffic by creating upper VLAN devices such as lan1.10, lan2.10 etc. but the switching between lan1.10 and lan2.10 still happens in hardware because those VLAN devices are offloaded into the switch hardware. When vlan_filtering=1 is set, the hardware is configured to only accept untagged PVID frames as well as whichever VLAN tagged frames you have configured. For instance, if you configured your bridge this way with: lan1, lan2, lan3 and lan4 part of br-lan with vlan_filtering=1, each switch port will be programmed to be in the bridge's default_pvid (1, unless changed), and if you sent a VLAN tagged frame with VLAN ID 2 towards any of those ports, and assuming the switch hardware is capable of it, that VLAN ID 2 frame creates an egress VID violation and is discarded. If not discarded in hardware it would be discarded in software. Hope this helps. Regards Sebastian *) Not sure where I got that impression from On Sep 7, 2022, at 23:48, Jo-Philipp Wich wrote: Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: DSA Mini-tutorial still marked as Work In Progress
On 9/7/2022 3:17 PM, David Lang wrote: with DSA, do you HAVE to go through the cpu interface and kernel to bridge different ports on the switch? or can you still do vlan routing inside the switch? DSA offloads the bridge to the switch hardware, so if the hardware switch can do its job and forward frames in hardware from port A to port B, it will do it. DSA has little significance here, the same constraints apply/applied to swconfig as well. for the Scale conference, I've done a lot of work using the switch for passing vlan tagged traffic on to other systems while only sending some of it to the CPU (the CPU would be a very significant bottleneck if I tried to send everything though it) David Lang On Wed, 7 Sep 2022, Jo-Philipp Wich wrote: Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Firewall questions
Hi, A couple of firewall questions. I'll start with something easy. If I'm ssh'd into my router and I restart the firewall (I'm using firewall3 and iptables), then on one router I get dropped from my shell after a timeout... but on another router, I stay connected. In both cases, I'll be doing this on adjacent hosts (i.e. on the same subnet), and inside the firewall. What would cause the firewall to not persist my connection state when restarting? 2nd question: how do I trace a packet flowing through my firewall? I have two firewalls, in to different locations, connected by an IPsec tunnel. Location A has the public IP address of my site. Location B has a dynamic (but routable) address on a different ISP. Unfortunately, my servers are on a sandbox at Location B and therefore can't egress via this address (the local firewall's WAN address), so I do policy routing over the IPsec tunnel (via xfrm tunnels) to have their traffic egress (and ingress, via redirects) via Location A. Things mostly work: HTTP, HTTPS, SMTP, IMAPS, Submission all work fine. But port forwarding Ssh to my servers doesn't. I've used tcpdump to see the ssh traffic arriving on the xfrm0 tunnel interface, but it then gets silently dropped and never appears on the terminal ethernet interface. No idea why. And no log messages get generated about it being DROPped or REJECTed. So I need to trace it through the rules to see if it's implicitly hitting a chain with a DROP or REJECT policy. I tried something like: iptables -t raw -D PREROUTING -s 72.104.76.181/32 -d 192.168.8.0/24 -p tcp -m tcp --dport 22 -j TRACE And get traces like: Sep 6 22:25:07 OpenWrt3 kernel: [526070.718061] TRACE: raw:PREROUTING:rule:3 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.739550] TRACE: raw:PREROUTING:rule:7 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.761691] TRACE: raw:zone_vpn_helper:rule:12 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.783690] TRACE: raw:PREROUTING:rule:8 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.805671] TRACE: nat:PREROUTING:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.827115] TRACE: nat:prerouting_rule:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.848978] TRACE: nat:PREROUTING:rule:6 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.870409] TRACE: nat:zone_vpn_prerouting:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.892639] TRACE: nat:prerouting_vpn_rule:rule:1 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.915444] TRACE: nat:zone_vpn_prerouting:rule:2 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) Sep 6 22:25:07 OpenWrt3 kernel: [526070.937704] TRACE: nat:PREROUTING:rule:7 IN=xfrm0 OUT= MAC= SRC=72.104.76.181 DST=192.168.8.12 LEN=48 TOS=0x00 PREC=0x00 TTL=45 ID=0 DF PROTO=TCP SPT=53442 DPT=22 SEQ=3707460739 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (0204056C0402) But then nothing more. What am I missing? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: DSA Mini-tutorial still marked as Work In Progress
with DSA, do you HAVE to go through the cpu interface and kernel to bridge different ports on the switch? or can you still do vlan routing inside the switch? for the Scale conference, I've done a lot of work using the switch for passing vlan tagged traffic on to other systems while only sending some of it to the CPU (the CPU would be a very significant bottleneck if I tried to send everything though it) David Lang On Wed, 7 Sep 2022, Jo-Philipp Wich wrote: Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] arm-trusted-firmware-mvebu: stop cluttering Image Builder
W dniu 7.09.2022 o 22:57, Hauke Mehrtens pisze: > On 9/7/22 19:23, Tomasz Maciej Nowak wrote: >> W dniu 7.09.2022 o 00:15, Hauke Mehrtens pisze: >>> On 8/31/22 17:03, Tomasz Maciej Nowak wrote: From: Tomasz Maciej Nowak All contents of staging_dir/image are included in Image Builder (IB) in case some binary needs to be included in final image. But in case of this package, all sources are stored there and those clutter the final tarball of IB for no reason. Those sources are not used during image creation and are just dead weight. To put it in perspective, the IB for 21.02.0 is 158 MiB, 22.03.0-rc6 is 366 MiB and snapshot is over 620 MiB! To fix it, put them in package build directory, so they won't end up included in IB tarball. With that, the custom clean definition can be removed, as the default one will take over. Signed-off-by: Tomasz Maciej Nowak Reviewed-by: Andre Heider --- v1 -> v2 - as pointed by Andre, we can use default clean definition - add his review tag >>> >>> I think the build times are much higher with this change compared to before. >> >> Yes, that's correct, since all source is extracted/rebuilt for each variant. >> The toolchain tarball is huge and it takes lot of time to extract. The second >> culprit is cryptopp. It's rebuilt for each variant with one job. >> >>> I haven't found the time to do real measurements. I used this configuration >>> to test: >>> CONFIG_TARGET_mvebu=y >>> CONFIG_TARGET_mvebu_cortexa53=y >>> CONFIG_TARGET_mvebu_cortexa53_DEVICE_globalscale_espressobin=y >> >> I did measurements, before change: >> time make -j4 package/arm-trusted-firmware-mvebu/compile >> [ ... ] >> real 13m17,046s >> user 25m24,272s >> sys 1m49,963s >> >> with the change: >> time make -j4 package/arm-trusted-firmware-mvebu/compile >> [ ... ] >> real 28m26,566s >> user 79m45,906s >> sys 4m6,547s >> >> As You can see it's more than double. I also did test where $(BUILD_DIR) >> was used: >> time make -j4 package/arm-trusted-firmware-mvebu/compile >> [ ... ] >> real 13m19,462s >> user 25m21,511s >> sys 1m53,047s >> >> which looks same as in current state (ignore spinning rust hiccups). Should >> I use $(BUILD_DIR) for the sources? > > did you mean a common folder in $(BUILD_DIR) with your $(BUILD_DIR) approach? Simply $(BUILD_DIR), which in our example translates to "build_dir/target-aarch64_cortex-a53_musl" without any subdir. Naturally each source is untarred to own subdir. > I think it would be better to place the bootloader toolchain in some common > place and not duplicated for each variant. That's with current state using STAGING_DIR_IMAGE or with using BUILD_DIR, so I'll use BUILD_DIR instead of PKG_BUILD_DIR. > Is cryptopp also common for all variant and only used on the host? Yes to both. > Maybe we can make this all a host package? That would make sense if we would untangle the whole TF-A build for mvebu, which at current form, needs work, as we already discussed that [1]. Having a second look at the build flow of it, I saw it's even more entangled than what I described in that topic. Anyway, lets keep it in current state, until me/someone finds time to fix it. 1. http://lists.openwrt.org/pipermail/openwrt-devel/2020-October/031677.html > Hauke Regards, Tomek -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Jo, I was under the impression* that bridge-vlan filtering is something that can be relegated to the switch hardware, while creating a bridge between VLAN interfaces happens in software. Is that wrong? Regards Sebastian *) Not sure where I got that impression from > On Sep 7, 2022, at 23:48, Jo-Philipp Wich wrote: > > Hi Rich, > > that tutorial is good ground work imho. One thing I repeatedly noticed (not in > the document, but in forum and irc chatter) is that over the time, DSA and > bridge VLAN filtering became conflated into one concept while they're actually > different pieces; one can do bridge VLAN filtering without DSA and one can > utilize DSA without doing bridge VLAN filtering. > > Bluntly speaking, DSA is the thing that gives you one Linux network device per > switch port and bridge VLAN filtering is the stuff that allows you declaring > swconfig-esque VLAN port groups on top of an arbitrary bridge interface. > > I think this is something we should try to better convey in the documentation. > > For example simple common use cases like: > > - Making each switch port it's own independent interface with own subnet > > or > > - Break out one switch port to turn it into some kind of restricted IoT or > guest network access port > > or > > - Bridge each ethernet port to another SSID > > don't require bridge VLAN filtering or touching VLANs in general at all (in > contrast to former swconfig). The per-port net devices just have to be taken > out of the br-lan bridge and either be put into another bridge or configured > as independent network devices. > > Bridge VLAN filtering on the other hand is only actually needed if you want to > deal with VLAN tagged traffic inside the bridge. And even then there's > sometimes alternative ways, for example the following two scenarios should be > functionally equivalent: > > - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" > - VLAN filtering disabled > > vs. > > - Bridge device "br-lan" containing "lan1 lan2 lan3" > - VLAN filtering enabled > - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged > - VLAN device br-lan.10 on top of br-lan > > > In the former case you would put your IP address settings onto the dedicated > "br-vlan10" bridge device while in the latter case you would configure the IP > addressing on the "br-lan.10" subinterface of the "br-lan" bridge. > > So maybe it makes sense to focus on the "with DSA, your switch just becomes a > linux bridge over a bunch of netdevs" aspect in the mini tutorial and break > out any bridge-VLAN related information into a separate advanced VLAN > tutorial. > > Another conceptual issue I see is that people came to expect a dedicated > "switch" configuration ui which is something that does not really work with > DSA devices anymore since there is no dedicated switch hardware entity to > interact with anymore (DSA takes care of completely abstracting this away from > the user point of view) and that bridge-vlans just happen to be a > configuration detail of a bridge, and that there happens to be a bridge > "br-lan" by default, but a system could have multiple bridges, or none at all. > > So we should also explain why there is no central "switch configuration" > anymore and that this does not translate into a loss of functionality, but > that the former semi opague swconfig switch configuration entity was dissolved > into a bunch of ethernet devices inside a bridge... > > > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Terminology
Hi jow, thanks for weighing in. I'm glad that I'm not unnecessarily confused - the naming *is* inconsistent. It sounds as if different "contexts" have varying definitions for the terms "interface", "network", "device", etc... (LuCi, /etc/config/network, the kernel.org article about DSA configuration, others?) When this has happened to me in other lives, it was useful to pause and agree on what we would *like* the end state to be. We can then figure out the technical means to get there. In parallel, we can work on definitions and descriptions that support the end state. Regrettably, I don't understand enough about this to make a stab at it. Anyone want to leap in? Thanks. Rich PS I changed the subject line to "DSA Terminology" since that's really what we're talking about > On Sep 7, 2022, at 5:12 PM, Jo-Philipp Wich wrote: > > Hi, > >>> I wrote this mostly because the LuCI interface itself makes a distinction >>> between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the >>> best way to describe what goes there. >> >> I agree that there are inconsistencies in LuCI. The only place I see the >> terminology correctly stated is on the wireless section: >> >> Network: Lists all entries on the Interfaces section. >> >>> Choose the network(s) you want to attach to this wireless interface or > >> fill out the custom field to define a new network. >> >> Which correctly states that: >> >> Interfaces section should be called Networks. >> Devices section should be called Interfaces. > > I agree that there's inconsistencies, I eventually want to clean that up. > Part of the terminology stems from uci itself, where `config interface` > declares logical *networks* while *interfaces* (as in Linux netdevs) are > referred to as `config device` (and `config wifi-*iface*` for wireless, which > probably should be named differently too). > > Personally I am fine with rebranding the logical network entities (lan, wan, > loopback etc.) to "networks" but I am unsure about renaming what is currently > "devices" to "interfaces" as it would then intersect with the current meaning > of interfaces... > > Anyhow, so while I agree that: > >> Interfaces section should be called Networks. >> Devices section should be called Interfaces. > > ... it will directly contradict /etc/config/network, where networks are called > `config interface` and interfaces are called `config device` likely leading to > even more confusion. > > > ~ Jo > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial still marked as Work In Progress
Hi Rich, that tutorial is good ground work imho. One thing I repeatedly noticed (not in the document, but in forum and irc chatter) is that over the time, DSA and bridge VLAN filtering became conflated into one concept while they're actually different pieces; one can do bridge VLAN filtering without DSA and one can utilize DSA without doing bridge VLAN filtering. Bluntly speaking, DSA is the thing that gives you one Linux network device per switch port and bridge VLAN filtering is the stuff that allows you declaring swconfig-esque VLAN port groups on top of an arbitrary bridge interface. I think this is something we should try to better convey in the documentation. For example simple common use cases like: - Making each switch port it's own independent interface with own subnet or - Break out one switch port to turn it into some kind of restricted IoT or guest network access port or - Bridge each ethernet port to another SSID don't require bridge VLAN filtering or touching VLANs in general at all (in contrast to former swconfig). The per-port net devices just have to be taken out of the br-lan bridge and either be put into another bridge or configured as independent network devices. Bridge VLAN filtering on the other hand is only actually needed if you want to deal with VLAN tagged traffic inside the bridge. And even then there's sometimes alternative ways, for example the following two scenarios should be functionally equivalent: - Bridge device "br-vlan10" containing "lan1.10 lan2.10 lan3.10" - VLAN filtering disabled vs. - Bridge device "br-lan" containing "lan1 lan2 lan3" - VLAN filtering enabled - Bridge VLAN #10 containing lan1 as tagged, lan2 as tagged, lan3 as tagged - VLAN device br-lan.10 on top of br-lan In the former case you would put your IP address settings onto the dedicated "br-vlan10" bridge device while in the latter case you would configure the IP addressing on the "br-lan.10" subinterface of the "br-lan" bridge. So maybe it makes sense to focus on the "with DSA, your switch just becomes a linux bridge over a bunch of netdevs" aspect in the mini tutorial and break out any bridge-VLAN related information into a separate advanced VLAN tutorial. Another conceptual issue I see is that people came to expect a dedicated "switch" configuration ui which is something that does not really work with DSA devices anymore since there is no dedicated switch hardware entity to interact with anymore (DSA takes care of completely abstracting this away from the user point of view) and that bridge-vlans just happen to be a configuration detail of a bridge, and that there happens to be a bridge "br-lan" by default, but a system could have multiple bridges, or none at all. So we should also explain why there is no central "switch configuration" anymore and that this does not translate into a loss of functionality, but that the former semi opague swconfig switch configuration entity was dissolved into a bunch of ethernet devices inside a bridge... ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
Hi, >> I wrote this mostly because the LuCI interface itself makes a distinction >> between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the >> best way to describe what goes there. > > I agree that there are inconsistencies in LuCI. The only place I see the > terminology correctly stated is on the wireless section: > > Network: Lists all entries on the Interfaces section. > >> Choose the network(s) you want to attach to this wireless interface or > > fill out the custom field to define a new network. > > Which correctly states that: > > Interfaces section should be called Networks. > Devices section should be called Interfaces. I agree that there's inconsistencies, I eventually want to clean that up. Part of the terminology stems from uci itself, where `config interface` declares logical *networks* while *interfaces* (as in Linux netdevs) are referred to as `config device` (and `config wifi-*iface*` for wireless, which probably should be named differently too). Personally I am fine with rebranding the logical network entities (lan, wan, loopback etc.) to "networks" but I am unsure about renaming what is currently "devices" to "interfaces" as it would then intersect with the current meaning of interfaces... Anyhow, so while I agree that: > Interfaces section should be called Networks. > Devices section should be called Interfaces. ... it will directly contradict /etc/config/network, where networks are called `config interface` and interfaces are called `config device` likely leading to even more confusion. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] arm-trusted-firmware-mvebu: stop cluttering Image Builder
On 9/7/22 19:23, Tomasz Maciej Nowak wrote: W dniu 7.09.2022 o 00:15, Hauke Mehrtens pisze: On 8/31/22 17:03, Tomasz Maciej Nowak wrote: From: Tomasz Maciej Nowak All contents of staging_dir/image are included in Image Builder (IB) in case some binary needs to be included in final image. But in case of this package, all sources are stored there and those clutter the final tarball of IB for no reason. Those sources are not used during image creation and are just dead weight. To put it in perspective, the IB for 21.02.0 is 158 MiB, 22.03.0-rc6 is 366 MiB and snapshot is over 620 MiB! To fix it, put them in package build directory, so they won't end up included in IB tarball. With that, the custom clean definition can be removed, as the default one will take over. Signed-off-by: Tomasz Maciej Nowak Reviewed-by: Andre Heider --- v1 -> v2 - as pointed by Andre, we can use default clean definition - add his review tag I think the build times are much higher with this change compared to before. Yes, that's correct, since all source is extracted/rebuilt for each variant. The toolchain tarball is huge and it takes lot of time to extract. The second culprit is cryptopp. It's rebuilt for each variant with one job. I haven't found the time to do real measurements. I used this configuration to test: CONFIG_TARGET_mvebu=y CONFIG_TARGET_mvebu_cortexa53=y CONFIG_TARGET_mvebu_cortexa53_DEVICE_globalscale_espressobin=y I did measurements, before change: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real13m17,046s user25m24,272s sys 1m49,963s with the change: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real28m26,566s user79m45,906s sys 4m6,547s As You can see it's more than double. I also did test where $(BUILD_DIR) was used: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real13m19,462s user25m21,511s sys 1m53,047s which looks same as in current state (ignore spinning rust hiccups). Should I use $(BUILD_DIR) for the sources? did you mean a common folder in $(BUILD_DIR) with your $(BUILD_DIR) approach? I think it would be better to place the bootloader toolchain in some common place and not duplicated for each variant. Is cryptopp also common for all variant and only used on the host? Maybe we can make this all a host package? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
On 07/09/2022 21:32, Rich Brown wrote: On Sep 6, 2022, at 5:33 PM, Florian Fainelli wrote: I don't see much content to document DSA. All DSA does is creating a network interface for each switch port. What I think should be properly documented is the Bridge VLAN filtering feature. I have made some efforts to do that on my playground here: https://openwrt.org/playground/arinc9/start ... Maybe this is enough to reference since it contains basic use cases, and not so basic ones, too: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst -- I have the sense that the terminology surrounding DSA is very murky. But in the DSA Mini-tutorial, (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) I made a distinction between "Devices" and "Interfaces in the Terminology section. - Devices are things that 'send bits' without regard for IP address or subnets - Interfaces correspond to IP subnet ranges, and the routing function within the router moves packets between interfaces. I wrote this mostly because the LuCI interface itself makes a distinction between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the best way to describe what goes there. I agree that there are inconsistencies in LuCI. The only place I see the terminology correctly stated is on the wireless section: Network: Lists all entries on the Interfaces section. > Choose the network(s) you want to attach to this wireless interface or > fill out the custom field to define a new network. Which correctly states that: Interfaces section should be called Networks. Devices section should be called Interfaces. Perhaps we could get the designer of the LuCI interface and other networking gurus to weigh in on how to describe this. Thanks. Rich PS I don't have a dog in this fight. If the entire Mini-tutorial were scrapped, and replaced with a description of what's true and correct, I would be happy. Thanks again Arınç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: DSA Mini-tutorial
> On Sep 6, 2022, at 5:33 PM, Florian Fainelli wrote: > >> I don't see much content to document DSA. All DSA does is creating a network >> interface for each switch port. What I think should be properly documented >> is the Bridge VLAN filtering feature. I have made some efforts to do that on >> my playground here: >> https://openwrt.org/playground/arinc9/start >> ... > > Maybe this is enough to reference since it contains basic use cases, and not > so basic ones, too: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/dsa/configuration.rst > -- I have the sense that the terminology surrounding DSA is very murky. But in the DSA Mini-tutorial, (https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial) I made a distinction between "Devices" and "Interfaces in the Terminology section. - Devices are things that 'send bits' without regard for IP address or subnets - Interfaces correspond to IP subnet ranges, and the routing function within the router moves packets between interfaces. I wrote this mostly because the LuCI interface itself makes a distinction between the "Devices" tab and the "Interfaces" tab. But maybe this isn't the best way to describe what goes there. Perhaps we could get the designer of the LuCI interface and other networking gurus to weigh in on how to describe this. Thanks. Rich PS I don't have a dog in this fight. If the entire Mini-tutorial were scrapped, and replaced with a description of what's true and correct, I would be happy. Thanks again ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] arm-trusted-firmware-mvebu: stop cluttering Image Builder
W dniu 7.09.2022 o 00:15, Hauke Mehrtens pisze: > On 8/31/22 17:03, Tomasz Maciej Nowak wrote: >> From: Tomasz Maciej Nowak >> >> All contents of staging_dir/image are included in Image Builder (IB) in >> case some binary needs to be included in final image. But in case of >> this package, all sources are stored there and those clutter the final >> tarball of IB for no reason. Those sources are not used during image >> creation and are just dead weight. To put it in perspective, the IB for >> 21.02.0 is 158 MiB, 22.03.0-rc6 is 366 MiB and snapshot is over 620 MiB! >> To fix it, put them in package build directory, so they won't end up >> included in IB tarball. With that, the custom clean definition can be >> removed, as the default one will take over. >> >> Signed-off-by: Tomasz Maciej Nowak >> Reviewed-by: Andre Heider >> --- >> v1 -> v2 >> - as pointed by Andre, we can use default clean definition >> - add his review tag > > I think the build times are much higher with this change compared to before. Yes, that's correct, since all source is extracted/rebuilt for each variant. The toolchain tarball is huge and it takes lot of time to extract. The second culprit is cryptopp. It's rebuilt for each variant with one job. > I haven't found the time to do real measurements. I used this configuration > to test: > CONFIG_TARGET_mvebu=y > CONFIG_TARGET_mvebu_cortexa53=y > CONFIG_TARGET_mvebu_cortexa53_DEVICE_globalscale_espressobin=y I did measurements, before change: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real13m17,046s user25m24,272s sys 1m49,963s with the change: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real28m26,566s user79m45,906s sys 4m6,547s As You can see it's more than double. I also did test where $(BUILD_DIR) was used: time make -j4 package/arm-trusted-firmware-mvebu/compile [ ... ] real13m19,462s user25m21,511s sys 1m53,047s which looks same as in current state (ignore spinning rust hiccups). Should I use $(BUILD_DIR) for the sources? > > Hauke Regards, Tomek -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build: fix grep v3.8 "stray \" warning
This fixes the reoccuring warning: grep: warning: stray \ before / Signed-off-by: Andre Heider --- Makefile | 2 +- target/sdk/files/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3ac110367d..c1b0b0a840 100644 --- a/Makefile +++ b/Makefile @@ -14,7 +14,7 @@ $(if $(findstring $(space),$(TOPDIR)),$(error ERROR: The path to the OpenWrt dir world: -DISTRO_PKG_CONFIG:=$(shell $(TOPDIR)/scripts/command_all.sh pkg-config | grep -E '\/usr' | head -n 1) +DISTRO_PKG_CONFIG:=$(shell $(TOPDIR)/scripts/command_all.sh pkg-config | grep -E '/usr' | head -n 1) export PATH:=$(TOPDIR)/staging_dir/host/bin:$(PATH) ifneq ($(OPENWRT_BUILD),1) diff --git a/target/sdk/files/Makefile b/target/sdk/files/Makefile index a710ca5f51..d1d97d4287 100644 --- a/target/sdk/files/Makefile +++ b/target/sdk/files/Makefile @@ -14,7 +14,7 @@ export TOPDIR LC_ALL LANG SDK world: -DISTRO_PKG_CONFIG:=$(shell $(TOPDIR)/scripts/command_all.sh pkg-config | grep -E '\/usr' | head -n 1) +DISTRO_PKG_CONFIG:=$(shell $(TOPDIR)/scripts/command_all.sh pkg-config | grep -E '/usr' | head -n 1) export PATH:=$(TOPDIR)/staging_dir/host/bin:$(PATH) ifneq ($(OPENWRT_BUILD),1) -- 2.35.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
