Message ID | 20190903214624.2280-1-ipfire@starkstromkonsument.de |
---|---|
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 46NLBX5lLvz42Rp for <patchwork@web04.haj.ipfire.org>; Tue, 3 Sep 2019 21:46:44 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail02.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 46NLBQ2kvWz3nD; Tue, 3 Sep 2019 21:46:38 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 46NLBQ0LSLz2yjZ; Tue, 3 Sep 2019 21:46:38 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 46NLBN2wVpz2ych for <development@lists.ipfire.org>; Tue, 3 Sep 2019 21:46:36 +0000 (UTC) Received: from nx101.node02.secure-mailgate.com (nx101.node02.secure-mailgate.com [192.162.87.101]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPS id 46NLBM2Z9wz3nD for <development@lists.ipfire.org>; Tue, 3 Sep 2019 21:46:35 +0000 (UTC) Received: from dehamd003.servertools24.de ([31.47.254.18]) by node02.secure-mailgate.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <ipfire@starkstromkonsument.de>) id 1i5GdA-00065K-RK for development@lists.ipfire.org; Tue, 03 Sep 2019 23:46:29 +0200 Received: from starkstromlahn.spdns.org (dslb-002-205-034-161.002.205.pools.vodafone-ip.de [2.205.34.161]) by dehamd003.servertools24.de (Postfix) with ESMTPSA id 83C9280485 for <development@lists.ipfire.org>; Tue, 3 Sep 2019 23:46:25 +0200 (CEST) Received-SPF: pass (dehamd003.servertools24.de: connection is authenticated) From: Alex Koch <ipfire@starkstromkonsument.de> To: development@lists.ipfire.org Subject: [PATCH 0/2] zonconf: replace the nic-names with eth... and wlan... or not? Date: Tue, 3 Sep 2019 23:46:22 +0200 Message-Id: <20190903214624.2280-1-ipfire@starkstromkonsument.de> X-PPP-Message-ID: <20190903214625.18740.43361@dehamd003.servertools24.de> X-PPP-Vhost: starkstromkonsument.de X-Originating-IP: 31.47.254.18 X-SecureMailgate-Domain: dehamd003.servertools24.de X-SecureMailgate-Username: 31.47.254.18 X-SecureMailgate-Outgoing-Class: ham X-SecureMailgate-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0duM4P579sYYbdH8Mt+sPVWpSDasLI4SayDByyq9LIhVte+A4/Uc+MgA 05+bJJLcA0TNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDjJTO55kJBbv01x7dn2l3rPNh vhTXFC3uEZfNFh1aVkTnx8yeplRO3sLIqUlSH7OGHGyJwuSXNdmA/azRwMYce4MlhcTgOXSCz8qb ysTVYVkaLnpCEJIWxWTJBf3FFLEmu3xsQHMYnlKQ9pcJ+5Uh0/FACMa4l/3pd4b5Oy6wVMG0HaDh DXN/mjGHOfSFZ+g8CzCvRwvqVEAQMkdN/mM3fI6jSvfpO+1kZkomjtjB6X7/nuj3koRhn2BlE7dX oT0pcbRIdQWM2NQMFh4QV224OAeB7iXwS+ET8xu8PinDjLaQeETIza2ISn5dEgBRzdTORAwX31WV Y5lWjWxuGSRuxWXf5NNoWqxwzT7YQb2bq3uDyiKr2bObCttBtO6VKDuO5YE5enyccp7RH4WQio3u GQOhzeGzw2pFTXtxL2RPdTQ0WClL7lPySiyMTFKyJyozybxQmwA+8NxVIq0MJiSKg9jlDHh8k6TT dHl8m1/8O/92QjNLubgZSlcJjVjePeKVzS9GD/IKkRDV2QGlthfHXZ7z1zrJl+/Ib2y8TSiQx4Cp MC3d4GbyCw2XCE8PtpJ5I6UqQkbOhH9gTBoDNiqAuazL2SfQG0dSP4FuiPfFINA+p/Z3NcHxDVIt hQj36LyC1x66Qw3T0UFAji0c5knCvGgNninNOnp9XbMRwMwWrv3zxYP9kzBy945btFBHxykDy3BH QTsHg9ZZ+vQS6KwWvU8t2Jacpo8ygZdB97G1Ie+8MKvTkQnwysOyRzwrAemM0sEmtoqhLjbEtkj9 CuDQRUFlf+gWT7v14rJm2E3PGsbtxOzzT/YWdmD8gywgB151eyyFY8GlmzRmIAOnS+GEXwEKaipO awN0AgJAg/KPUJM4l8rbNA7wj6QG1FXuXiK7N6LaNLb3lhm5MX4VrSl93jbiT9tkDxmwwn3e/+d7 cvas+yPoAIIlCTgNeJ6BI6ZW8USH3dGwLkG46rflwqVsACGdtrRMVGrTPw8oVQPCiJ8= X-Report-Abuse-To: spam@node01.secure-mailgate.com Authentication-Results: mail01.ipfire.org; dkim=none; dmarc=none; spf=pass (mail01.ipfire.org: domain of ipfire@starkstromkonsument.de designates 192.162.87.101 as permitted sender) smtp.mailfrom=ipfire@starkstromkonsument.de X-Rspamd-Queue-Id: 46NLBM2Z9wz3nD X-Spamd-Result: default: False [1.69 / 11.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:192.162.87.0/24]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[development@lists.ipfire.org]; TO_DN_NONE(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[starkstromkonsument.de]; MX_GOOD(-0.01)[cached: mail.starkstromkonsument.de]; MID_CONTAINS_FROM(1.00)[]; IP_SCORE(0.00)[country: DE(0.00)]; RCVD_IN_DNSWL_FAIL(0.00)[101.87.162.192.list.dnswl.org:server fail]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:45031, ipnet:192.162.84.0/22, country:DE]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[161.34.205.2.zen.spamhaus.org : 127.0.0.11] X-Rspamd-Server: mail01.haj.ipfire.org X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
zonconf: replace the nic-names with eth... and wlan... or not?
|
|
Message
Alexander Koch
Sept. 3, 2019, 9:46 p.m. UTC
Hi, I stumbled into this when I was searching for an error in my vlan and bridge-config and want to start a discussion about if this should be changed or not. The zoneconf.cgi contains the following code-snippet: > # Name the physical NICs > # Even though they may not be really named like this, we will name them ethX or wlanX > my $ethcount = 0; > my $wlancount = 0; > > foreach (@nics) { > my $nic = $_->[1]; > > if (-e "/sys/class/net/$nic/wireless") { > $_->[1] = "wlan$wlancount"; > $_->[2] = 1; > $wlancount++; > } else { > $_->[1] = "eth$ethcount"; > $ethcount++; > } > } This renames all the nics to ethX or wlanX for the WUI. When you use any commandline tool (e.g ip addr or brctl show) the names of the NICs will mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs. For example, one of my setups: - WUI name --> real name - eth0 --> red0 - eth1 --> eth1 - eth2 --> orange0 - wlan0 --> blue0 - wlan1 --> wlan1 What is the goal of doing this? I personally think this is more confusing than useful. I would prefer to not rename the NICs. What do you think? I attached a patch to change the naming back to the real names. Please decide to merge it or not, depending on where the discussion ends. Secondly I created a patch to add the current output of "brctl show" and "ip addr" to the zoneconfig page. It's quite useful to have this by the hand without having to open a shell sometimes. Regards, Alex Alex Koch (2): zoneconf: Show real names of NICs in the WUI zoneconf: Add status output of "brctl show" and "ip addr" html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++---------- langs/de/cgi-bin/de.pl | 5 ++++- langs/en/cgi-bin/en.pl | 5 ++++- 3 files changed, 32 insertions(+), 12 deletions(-) -- 2.17.1
Comments
Hi Alex, your point is absolutely correct, however there's some thought behind this: as the udev rules rename the physical interfaces to <zone>0 when the interface accesses the zone directly, it could be quite confusing if the interface is named orange0 for example and you want to assign it to blue in the CGI, even though it would work fine. What do you think? Regards Florian Gesendet von ProtonMail mobile -------- Original-Nachricht -------- An 3. Sep. 2019, 23:46, Alex Koch schrieb: > Hi, > > I stumbled into this when I was searching for an error in my vlan and bridge-config and want to start a discussion about if this should be changed or not. > > The zoneconf.cgi contains the following code-snippet: > >> # Name the physical NICs >> # Even though they may not be really named like this, we will name them ethX or wlanX >> my $ethcount = 0; >> my $wlancount = 0; >> >> foreach (@nics) { >> my $nic = $_->[1]; >> >> if (-e "/sys/class/net/$nic/wireless") { >> $_->[1] = "wlan$wlancount"; >> $_->[2] = 1; >> $wlancount++; >> } else { >> $_->[1] = "eth$ethcount"; >> $ethcount++; >> } >> } > > This renames all the nics to ethX or wlanX for the WUI. When you use any commandline tool (e.g ip addr or brctl show) the names of the NICs will mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs. > > For example, one of my setups: > > - WUI name --> real name > - eth0 --> red0 > - eth1 --> eth1 > - eth2 --> orange0 > - wlan0 --> blue0 > - wlan1 --> wlan1 > > What is the goal of doing this? I personally think this is more confusing than useful. I would prefer to not rename the NICs. What do you think? > > I attached a patch to change the naming back to the real names. Please decide to merge it or not, depending on where the discussion ends. > > Secondly I created a patch to add the current output of "brctl show" and "ip addr" to the zoneconfig page. It's quite useful to have this by the hand without having to open a shell sometimes. > > Regards, Alex > > Alex Koch (2): > zoneconf: Show real names of NICs in the WUI > zoneconf: Add status output of "brctl show" and "ip addr" > > html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++---------- > langs/de/cgi-bin/de.pl | 5 ++++- > langs/en/cgi-bin/en.pl | 5 ++++- > 3 files changed, 32 insertions(+), 12 deletions(-) > > -- > [2.17.1](tel:2171) Hi Alex,<br><br>your point is absolutely correct, however there's some thought behind this: as the udev rules rename the physical interfaces to <zone>0 when the interface accesses the zone directly, it could be quite confusing if the interface is named orange0 for example and you want to assign it to blue in the CGI, even though it would work fine. <br>What do you think?<br><br>Regards<br>Florian<br><br>Gesendet von ProtonMail mobile<br><br><br><br>-------- Original-Nachricht --------<br>An 3. Sep. 2019, 23:46, Alex Koch schrieb:<blockquote class="protonmail_quote"><br><p dir="ltr">Hi,</p> <p dir="ltr">I stumbled into this when I was searching for an error in my vlan and bridge-config and want to start a discussion about if this should be changed or not.</p> <p dir="ltr">The zoneconf.cgi contains the following code-snippet:</p> <p dir="ltr">> # Name the physical NICs<br> > # Even though they may not be really named like this, we will name them ethX or wlanX<br> > my $ethcount = 0;<br> > my $wlancount = 0;<br> ><br> > foreach (@nics) {<br> > 	my $nic = $_->[1];<br> ><br> > 	if (-e "/sys/class/net/$nic/wireless") {<br> > 		$_->[1] = "wlan$wlancount";<br> > 		$_->[2] = 1;<br> > 		$wlancount++;<br> > 	} else {<br> > 		$_->[1] = "eth$ethcount";<br> > 		$ethcount++;<br> > 	}<br> > }</p> <p dir="ltr">This renames all the nics to ethX or wlanX for the WUI. When you use any commandline tool (e.g ip addr or brctl show) the names of the NICs will mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs.</p> <p dir="ltr">For example, one of my setups:</p> <p dir="ltr">- WUI name --> real name<br> - eth0 --> red0<br> - eth1 --> eth1<br> - eth2 --> orange0<br> - wlan0 --> blue0<br> - wlan1 --> wlan1</p> <p dir="ltr">What is the goal of doing this? I personally think this is more confusing than useful. I would prefer to not rename the NICs. What do you think?</p> <p dir="ltr">I attached a patch to change the naming back to the real names. Please decide to merge it or not, depending on where the discussion ends.</p> <p dir="ltr">Secondly I created a patch to add the current output of "brctl show" and "ip addr" to the zoneconfig page. It's quite useful to have this by the hand without having to open a shell sometimes.</p> <p dir="ltr">Regards, Alex<br></p> <p dir="ltr">Alex Koch (2):<br> zoneconf: Show real names of NICs in the WUI<br> zoneconf: Add status output of "brctl show" and "ip addr"</p> <p dir="ltr">html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++----------<br> langs/de/cgi-bin/<a href="http://de.pl">de.pl</a> | 5 ++++-<br> langs/en/cgi-bin/<a href="http://en.pl">en.pl</a> | 5 ++++-<br> 3 files changed, 32 insertions(+), 12 deletions(-)</p> <p dir="ltr">--<br> <a href="tel:2171">2.17.1</a></p> </div>
Hi, I agree with both of you :) Showing the “old” names is confusing. Numbering them again is also not helpful. Is it better if we do not show any device name at all? Nobody needs that to decide which NIC is being assigned to what zone, right? -Michael > On 4 Sep 2019, at 07:49, Florian Bührle <erdlof@protonmail.com> wrote: > > Hi Alex, > > your point is absolutely correct, however there's some thought behind this: as the udev rules rename the physical interfaces to <zone>0 when the interface accesses the zone directly, it could be quite confusing if the interface is named orange0 for example and you want to assign it to blue in the CGI, even though it would work fine. > What do you think? > > Regards > Florian > > Gesendet von ProtonMail mobile > > > > -------- Original-Nachricht -------- > An 3. Sep. 2019, 23:46, Alex Koch schrieb: > > Hi, > > I stumbled into this when I was searching for an error in my vlan and bridge-config and want to start a discussion about if this should be changed or not. > > The zoneconf.cgi contains the following code-snippet: > > > # Name the physical NICs > > # Even though they may not be really named like this, we will name them ethX or wlanX > > my $ethcount = 0; > > my $wlancount = 0; > > > > foreach (@nics) { > > my $nic = $_->[1]; > > > > if (-e "/sys/class/net/$nic/wireless") { > > $_->[1] = "wlan$wlancount"; > > $_->[2] = 1; > > $wlancount++; > > } else { > > $_->[1] = "eth$ethcount"; > > $ethcount++; > > } > > } > > This renames all the nics to ethX or wlanX for the WUI. When you use any commandline tool (e.g ip addr or brctl show) the names of the NICs will mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs. > > For example, one of my setups: > > - WUI name --> real name > - eth0 --> red0 > - eth1 --> eth1 > - eth2 --> orange0 > - wlan0 --> blue0 > - wlan1 --> wlan1 > > What is the goal of doing this? I personally think this is more confusing than useful. I would prefer to not rename the NICs. What do you think? > > I attached a patch to change the naming back to the real names. Please decide to merge it or not, depending on where the discussion ends. > > Secondly I created a patch to add the current output of "brctl show" and "ip addr" to the zoneconfig page. It's quite useful to have this by the hand without having to open a shell sometimes. > > Regards, Alex > > Alex Koch (2): > zoneconf: Show real names of NICs in the WUI > zoneconf: Add status output of "brctl show" and "ip addr" > > html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++---------- > langs/de/cgi-bin/de.pl | 5 ++++- > langs/en/cgi-bin/en.pl | 5 ++++- > 3 files changed, 32 insertions(+), 12 deletions(-) > > -- > 2.17.1 >
Hi Florian,
in the case you describe, the zone orange is of type normal and it has
one NIC assigend as native. This results in that NIC beeing named
orange0. Is this correct so far?
You can not assign multiple zones to one native NIC. If you want to add
orange0, to the blue zone, you can only do this as a VLAN and blue has
to be of type bridge. This will result in an additional interface named
orange0.<VLAN-ID> that is part of the bridge blue0. This offers the blue
zone available as <VLAN-ID> in the orange zone. Do you agree?
To me this is the expected behaviour. I personally don't mind the NIC
being named orange0 in that case. I attached some screenshots and added
the real names of the NICs to the table in brackets to illustrate this
(including my patch for brctl show and ip addr).
My example (IPFire running in a VirtualBox) offers another issue: the
real and the new names of the NICs even have different numbers. I don't
know why this happens. I thought the zoneconf.cgi and udev both sort the
NICs by their MAC-Addresses and start with 0?
Michael, I would not show no names at all. Just keep the real device
names in the WebUI. People need them whenever they are searching for
errors or want to analyse something e.g. with tcpdump. Some people label
their cases with the names. Monitoring systems also show the real names
as returned by the system.
To me, the best solution would be running all zones as bridges per
default. But this is something that will be addressed in IPFire 3.x
anyway so I wouldn't invest any time in changing this for 2.x ...
touching this might break other things and turn out to be an exhausting
task. I accidentally changed the type of the red zone to bridged on my
testing machine (static IP) and broke the zone that way. I didn't find
the cause of this though ...
Regards, Alex
-------- Original Message --------
From: Michael Tremer [mailto:michael.tremer@ipfire.org]
Sent: Thursday, 5 September 2019, 11:27 CEST
To: Florian Bührle <erdlof@protonmail.com>
Cc: ipfire@starkstromkonsument.de, development@lists.ipfire.org
<development@lists.ipfire.org>
Subject: [PATCH 0/2] zonconf: replace the nic-names with eth... and
wlan... or not?
Hi,
I agree with both of you :)
Showing the “old” names is confusing. Numbering them again is also not
helpful.
Is it better if we do not show any device name at all? Nobody needs that
to decide which NIC is being assigned to what zone, right?
-Michael
On 4 Sep 2019, at 07:49, Florian Bührle <erdlof@protonmail.com> wrote:
Hi Alex,
your point is absolutely correct, however there's some thought behind
this: as the udev rules rename the physical interfaces to <zone>0 when
the interface accesses the zone directly, it could be quite confusing if
the interface is named orange0 for example and you want to assign it to
blue in the CGI, even though it would work fine.
What do you think?
Regards
Florian
Gesendet von ProtonMail mobile
-------- Original-Nachricht --------
An 3. Sep. 2019, 23:46, Alex Koch schrieb:
Hi,
I stumbled into this when I was searching for an error in my vlan and
bridge-config and want to start a discussion about if this should be
changed or not.
The zoneconf.cgi contains the following code-snippet:
# Name the physical NICs
# Even though they may not be really named like this, we will name them
ethX or wlanX
my $ethcount = 0;
my $wlancount = 0;
foreach (@nics) {
my $nic = $_->[1];
if (-e "/sys/class/net/$nic/wireless") {
$_->[1] = "wlan$wlancount";
$_->[2] = 1;
$wlancount++;
} else {
$_->[1] = "eth$ethcount";
$ethcount++;
}
}
This renames all the nics to ethX or wlanX for the WUI. When you use any
commandline tool (e.g ip addr or brctl show) the names of the NICs will
mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs.
For example, one of my setups:
- WUI name --> real name
- eth0 --> red0
- eth1 --> eth1
- eth2 --> orange0
- wlan0 --> blue0
- wlan1 --> wlan1
What is the goal of doing this? I personally think this is more
confusing than useful. I would prefer to not rename the NICs. What do
you think?
I attached a patch to change the naming back to the real names. Please
decide to merge it or not, depending on where the discussion ends.
Secondly I created a patch to add the current output of "brctl show" and
"ip addr" to the zoneconfig page. It's quite useful to have this by the
hand without having to open a shell sometimes.
Regards, Alex
Alex Koch (2):
zoneconf: Show real names of NICs in the WUI
zoneconf: Add status output of "brctl show" and "ip addr"
html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++----------
langs/de/cgi-bin/de.pl | 5 ++++-
langs/en/cgi-bin/en.pl | 5 ++++-
3 files changed, 32 insertions(+), 12 deletions(-)
--
2.17.1
Hi, > On 7 Sep 2019, at 23:55, Alexander Koch <ipfire@starkstromkonsument.de> wrote: > > Hi Florian, > > in the case you describe, the zone orange is of type normal and it has > one NIC assigend as native. This results in that NIC beeing named orange0. Is this correct so far? > > You can not assign multiple zones to one native NIC. If you want to add orange0, to the blue zone, you can only do this as a VLAN and blue has to be of type bridge. This will result in an additional interface named orange0.<VLAN-ID> that is part of the bridge blue0. This offers the blue zone available as <VLAN-ID> in the orange zone. Do you agree? blue0 could still be the VLAN device piggy-backing on orange0. There is no bridge required. > To me this is the expected behaviour. I personally don't mind the NIC being named orange0 in that case. I attached some screenshots and added the real names of the NICs to the table in brackets to illustrate this (including my patch for brctl show and ip addr). > > My example (IPFire running in a VirtualBox) offers another issue: the real and the new names of the NICs even have different numbers. I don't know why this happens. I thought the zoneconf.cgi and udev both sort the NICs by their MAC-Addresses and start with 0? No, udev initialised the NICs in the order they come up by the kernel. That could differ from reboot to reboot if you have a NIC where the firmware is already loaded and so on. That is why we cannot depend on NIC names. > Michael, I would not show no names at all. Just keep the real device names in the WebUI. People need them whenever they are searching for errors or want to analyse something e.g. with tcpdump. Some people label their cases with the names. Monitoring systems also show the real names as returned by the system. People who are on the console dealing with tcpdump are on their own and hopefully know how to find the correct NIC. I do not think that the webUI should be accommodating too much for this use-case. However, showing incorrect names is not good either. If we show the current names you will have a page where “orange0” is configured as “green0” which I also find rather confusing. So that leaves us with showing the vendor and model of the NIC? > To me, the best solution would be running all zones as bridges per default. But this is something that will be addressed in IPFire 3.x anyway so I wouldn't invest any time in changing this for 2.x ... touching this might break other things and turn out to be an exhausting task. I accidentally changed the type of the red zone to bridged on my testing machine (static IP) and broke the zone that way. I didn't find the cause of this though … That also has downsides. We do it in IPFire 3, but the whole network architecture is based on a hotpluggable network that changes all the time. IPFire 2 is simply not designed for this and we will break a lot of things to make this happen. Best, -Michael > > > Regards, Alex > > > -------- Original Message -------- > From: Michael Tremer [mailto:michael.tremer@ipfire.org] > Sent: Thursday, 5 September 2019, 11:27 CEST > To: Florian Bührle <erdlof@protonmail.com> > Cc: ipfire@starkstromkonsument.de, development@lists.ipfire.org <development@lists.ipfire.org> > Subject: [PATCH 0/2] zonconf: replace the nic-names with eth... and wlan... or not? > > Hi, > > I agree with both of you :) > > Showing the “old” names is confusing. Numbering them again is also not helpful. > > Is it better if we do not show any device name at all? Nobody needs that to decide which NIC is being assigned to what zone, right? > > -Michael > > On 4 Sep 2019, at 07:49, Florian Bührle <erdlof@protonmail.com> wrote: > > Hi Alex, > > your point is absolutely correct, however there's some thought behind this: as the udev rules rename the physical interfaces to <zone>0 when the interface accesses the zone directly, it could be quite confusing if the interface is named orange0 for example and you want to assign it to blue in the CGI, even though it would work fine. > What do you think? > > Regards > Florian > > Gesendet von ProtonMail mobile > > > > -------- Original-Nachricht -------- > An 3. Sep. 2019, 23:46, Alex Koch schrieb: > > Hi, > > I stumbled into this when I was searching for an error in my vlan and bridge-config and want to start a discussion about if this should be changed or not. > > The zoneconf.cgi contains the following code-snippet: > > # Name the physical NICs > # Even though they may not be really named like this, we will name them ethX or wlanX > my $ethcount = 0; > my $wlancount = 0; > > foreach (@nics) { > my $nic = $_->[1]; > > if (-e "/sys/class/net/$nic/wireless") { > $_->[1] = "wlan$wlancount"; > $_->[2] = 1; > $wlancount++; > } else { > $_->[1] = "eth$ethcount"; > $ethcount++; > } > } > > This renames all the nics to ethX or wlanX for the WUI. When you use any commandline tool (e.g ip addr or brctl show) the names of the NICs will mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs. > > For example, one of my setups: > > - WUI name --> real name > - eth0 --> red0 > - eth1 --> eth1 > - eth2 --> orange0 > - wlan0 --> blue0 > - wlan1 --> wlan1 > > What is the goal of doing this? I personally think this is more confusing than useful. I would prefer to not rename the NICs. What do you think? > > I attached a patch to change the naming back to the real names. Please decide to merge it or not, depending on where the discussion ends. > > Secondly I created a patch to add the current output of "brctl show" and "ip addr" to the zoneconfig page. It's quite useful to have this by the hand without having to open a shell sometimes. > > Regards, Alex > > Alex Koch (2): > zoneconf: Show real names of NICs in the WUI > zoneconf: Add status output of "brctl show" and "ip addr" > > html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++---------- > langs/de/cgi-bin/de.pl | 5 ++++- > langs/en/cgi-bin/en.pl | 5 ++++- > 3 files changed, 32 insertions(+), 12 deletions(-) > > -- > 2.17.1 > > > > <190907_florians_example.png><190907_no_bridges.png><190908_all_bridges.png>
Hi, -------- Ursprüngliche Nachricht -------- Von: Michael Tremer [mailto:michael.tremer@ipfire.org] Gesendet: Montag, 9. September 2019, 17:04 MESZ An: Alexander Koch <ipfire@starkstromkonsument.de> Cc: Florian Bührle <erdlof@protonmail.com>, development@lists.ipfire.org <development@lists.ipfire.org> Betreff: [PATCH 0/2] zoneconf: replace the nic-names with eth... and wlan... or not? > Hi, > >> On 7 Sep 2019, at 23:55, Alexander Koch <ipfire@starkstromkonsument.de> wrote: >> >> Hi Florian, >> >> in the case you describe, the zone orange is of type normal and it has >> one NIC assigend as native. This results in that NIC beeing named orange0. Is this correct so far? >> >> You can not assign multiple zones to one native NIC. If you want to add orange0, to the blue zone, you can only do this as a VLAN and blue has to be of type bridge. This will result in an additional interface named orange0.<VLAN-ID> that is part of the bridge blue0. This offers the blue zone available as <VLAN-ID> in the orange zone. Do you agree? > > blue0 could still be the VLAN device piggy-backing on orange0. There is no bridge required. Oh, sorry. I missed that one. You are right of course ... > >> To me this is the expected behaviour. I personally don't mind the NIC being named orange0 in that case. I attached some screenshots and added the real names of the NICs to the table in brackets to illustrate this (including my patch for brctl show and ip addr). >> >> My example (IPFire running in a VirtualBox) offers another issue: the real and the new names of the NICs even have different numbers. I don't know why this happens. I thought the zoneconf.cgi and udev both sort the NICs by their MAC-Addresses and start with 0? > > No, udev initialised the NICs in the order they come up by the kernel. > > That could differ from reboot to reboot if you have a NIC where the firmware is already loaded and so on. That is why we cannot depend on NIC names. Thanks for correcting me here, I was not aware of this. > >> Michael, I would not show no names at all. Just keep the real device names in the WebUI. People need them whenever they are searching for errors or want to analyse something e.g. with tcpdump. Some people label their cases with the names. Monitoring systems also show the real names as returned by the system. > > People who are on the console dealing with tcpdump are on their own and hopefully know how to find the correct NIC. I do not think that the webUI should be accommodating too much for this use-case. However, showing incorrect names is not good either. > > If we show the current names you will have a page where “orange0” is configured as “green0” which I also find rather confusing. > > So that leaves us with showing the vendor and model of the NIC? > Hm, I think yes. Same way as in the setup on the CLI. Do you want me to send a revised patch? >> To me, the best solution would be running all zones as bridges per default. But this is something that will be addressed in IPFire 3.x anyway so I wouldn't invest any time in changing this for 2.x ... touching this might break other things and turn out to be an exhausting task. I accidentally changed the type of the red zone to bridged on my testing machine (static IP) and broke the zone that way. I didn't find the cause of this though … > > That also has downsides. We do it in IPFire 3, but the whole network architecture is based on a hotpluggable network that changes all the time. IPFire 2 is simply not designed for this and we will break a lot of things to make this happen. > > Best, > -Michael > >> >> >> Regards, Alex >> >> >> -------- Original Message -------- >> From: Michael Tremer [mailto:michael.tremer@ipfire.org] >> Sent: Thursday, 5 September 2019, 11:27 CEST >> To: Florian Bührle <erdlof@protonmail.com> >> Cc: ipfire@starkstromkonsument.de, development@lists.ipfire.org <development@lists.ipfire.org> >> Subject: [PATCH 0/2] zonconf: replace the nic-names with eth... and wlan... or not? >> >> Hi, >> >> I agree with both of you :) >> >> Showing the “old” names is confusing. Numbering them again is also not helpful. >> >> Is it better if we do not show any device name at all? Nobody needs that to decide which NIC is being assigned to what zone, right? >> >> -Michael >> >> On 4 Sep 2019, at 07:49, Florian Bührle <erdlof@protonmail.com> wrote: >> >> Hi Alex, >> >> your point is absolutely correct, however there's some thought behind this: as the udev rules rename the physical interfaces to <zone>0 when the interface accesses the zone directly, it could be quite confusing if the interface is named orange0 for example and you want to assign it to blue in the CGI, even though it would work fine. >> What do you think? >> >> Regards >> Florian >> >> Gesendet von ProtonMail mobile >> >> >> >> -------- Original-Nachricht -------- >> An 3. Sep. 2019, 23:46, Alex Koch schrieb: >> >> Hi, >> >> I stumbled into this when I was searching for an error in my vlan and bridge-config and want to start a discussion about if this should be changed or not. >> >> The zoneconf.cgi contains the following code-snippet: >> >> # Name the physical NICs >> # Even though they may not be really named like this, we will name them ethX or wlanX >> my $ethcount = 0; >> my $wlancount = 0; >> >> foreach (@nics) { >> my $nic = $_->[1]; >> >> if (-e "/sys/class/net/$nic/wireless") { >> $_->[1] = "wlan$wlancount"; >> $_->[2] = 1; >> $wlancount++; >> } else { >> $_->[1] = "eth$ethcount"; >> $ethcount++; >> } >> } >> >> This renames all the nics to ethX or wlanX for the WUI. When you use any commandline tool (e.g ip addr or brctl show) the names of the NICs will mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs. >> >> For example, one of my setups: >> >> - WUI name --> real name >> - eth0 --> red0 >> - eth1 --> eth1 >> - eth2 --> orange0 >> - wlan0 --> blue0 >> - wlan1 --> wlan1 >> >> What is the goal of doing this? I personally think this is more confusing than useful. I would prefer to not rename the NICs. What do you think? >> >> I attached a patch to change the naming back to the real names. Please decide to merge it or not, depending on where the discussion ends. >> >> Secondly I created a patch to add the current output of "brctl show" and "ip addr" to the zoneconfig page. It's quite useful to have this by the hand without having to open a shell sometimes. >> >> Regards, Alex >> >> Alex Koch (2): >> zoneconf: Show real names of NICs in the WUI >> zoneconf: Add status output of "brctl show" and "ip addr" >> >> html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++---------- >> langs/de/cgi-bin/de.pl | 5 ++++- >> langs/en/cgi-bin/en.pl | 5 ++++- >> 3 files changed, 32 insertions(+), 12 deletions(-) >> >> -- >> 2.17.1 >> >> >> >> <190907_florians_example.png><190907_no_bridges.png><190908_all_bridges.png> > Regards, Alex
Hi, > On 11 Sep 2019, at 19:34, Alexander Koch <ipfire@starkstromkonsument.de> wrote: > > Hi, > > -------- Ursprüngliche Nachricht -------- > Von: Michael Tremer [mailto:michael.tremer@ipfire.org] > Gesendet: Montag, 9. September 2019, 17:04 MESZ > An: Alexander Koch <ipfire@starkstromkonsument.de> > Cc: Florian Bührle <erdlof@protonmail.com>, development@lists.ipfire.org <development@lists.ipfire.org> > Betreff: [PATCH 0/2] zoneconf: replace the nic-names with eth... and wlan... or not? > >> Hi, >>> On 7 Sep 2019, at 23:55, Alexander Koch <ipfire@starkstromkonsument.de> wrote: >>> >>> Hi Florian, >>> >>> in the case you describe, the zone orange is of type normal and it has >>> one NIC assigend as native. This results in that NIC beeing named orange0. Is this correct so far? >>> >>> You can not assign multiple zones to one native NIC. If you want to add orange0, to the blue zone, you can only do this as a VLAN and blue has to be of type bridge. This will result in an additional interface named orange0.<VLAN-ID> that is part of the bridge blue0. This offers the blue zone available as <VLAN-ID> in the orange zone. Do you agree? >> blue0 could still be the VLAN device piggy-backing on orange0. There is no bridge required. > > Oh, sorry. I missed that one. You are right of course ... > >>> To me this is the expected behaviour. I personally don't mind the NIC being named orange0 in that case. I attached some screenshots and added the real names of the NICs to the table in brackets to illustrate this (including my patch for brctl show and ip addr). >>> >>> My example (IPFire running in a VirtualBox) offers another issue: the real and the new names of the NICs even have different numbers. I don't know why this happens. I thought the zoneconf.cgi and udev both sort the NICs by their MAC-Addresses and start with 0? >> No, udev initialised the NICs in the order they come up by the kernel. >> That could differ from reboot to reboot if you have a NIC where the firmware is already loaded and so on. That is why we cannot depend on NIC names. > > Thanks for correcting me here, I was not aware of this. No problem… > >>> Michael, I would not show no names at all. Just keep the real device names in the WebUI. People need them whenever they are searching for errors or want to analyse something e.g. with tcpdump. Some people label their cases with the names. Monitoring systems also show the real names as returned by the system. >> People who are on the console dealing with tcpdump are on their own and hopefully know how to find the correct NIC. I do not think that the webUI should be accommodating too much for this use-case. However, showing incorrect names is not good either. >> If we show the current names you will have a page where “orange0” is configured as “green0” which I also find rather confusing. >> So that leaves us with showing the vendor and model of the NIC? > > Hm, I think yes. Same way as in the setup on the CLI. Do you want me to send a revised patch? Yes, I think so. Can you coordinate with Florian, because technically it is his code :) I think it might be a little bit of a challenge to get this into the UI because the NIC names will be very long. When we first considered this we had the table upside down and later changed the orientation of it. That might help you now. Let me know if I can help out with anything here. Best, -Michael > >>> To me, the best solution would be running all zones as bridges per default. But this is something that will be addressed in IPFire 3.x anyway so I wouldn't invest any time in changing this for 2.x ... touching this might break other things and turn out to be an exhausting task. I accidentally changed the type of the red zone to bridged on my testing machine (static IP) and broke the zone that way. I didn't find the cause of this though … >> That also has downsides. We do it in IPFire 3, but the whole network architecture is based on a hotpluggable network that changes all the time. IPFire 2 is simply not designed for this and we will break a lot of things to make this happen. >> Best, >> -Michael >>> >>> >>> Regards, Alex >>> >>> >>> -------- Original Message -------- >>> From: Michael Tremer [mailto:michael.tremer@ipfire.org] >>> Sent: Thursday, 5 September 2019, 11:27 CEST >>> To: Florian Bührle <erdlof@protonmail.com> >>> Cc: ipfire@starkstromkonsument.de, development@lists.ipfire.org <development@lists.ipfire.org> >>> Subject: [PATCH 0/2] zonconf: replace the nic-names with eth... and wlan... or not? >>> >>> Hi, >>> >>> I agree with both of you :) >>> >>> Showing the “old” names is confusing. Numbering them again is also not helpful. >>> >>> Is it better if we do not show any device name at all? Nobody needs that to decide which NIC is being assigned to what zone, right? >>> >>> -Michael >>> >>> On 4 Sep 2019, at 07:49, Florian Bührle <erdlof@protonmail.com> wrote: >>> >>> Hi Alex, >>> >>> your point is absolutely correct, however there's some thought behind this: as the udev rules rename the physical interfaces to <zone>0 when the interface accesses the zone directly, it could be quite confusing if the interface is named orange0 for example and you want to assign it to blue in the CGI, even though it would work fine. >>> What do you think? >>> >>> Regards >>> Florian >>> >>> Gesendet von ProtonMail mobile >>> >>> >>> >>> -------- Original-Nachricht -------- >>> An 3. Sep. 2019, 23:46, Alex Koch schrieb: >>> >>> Hi, >>> >>> I stumbled into this when I was searching for an error in my vlan and bridge-config and want to start a discussion about if this should be changed or not. >>> >>> The zoneconf.cgi contains the following code-snippet: >>> >>> # Name the physical NICs >>> # Even though they may not be really named like this, we will name them ethX or wlanX >>> my $ethcount = 0; >>> my $wlancount = 0; >>> >>> foreach (@nics) { >>> my $nic = $_->[1]; >>> >>> if (-e "/sys/class/net/$nic/wireless") { >>> $_->[1] = "wlan$wlancount"; >>> $_->[2] = 1; >>> $wlancount++; >>> } else { >>> $_->[1] = "eth$ethcount"; >>> $ethcount++; >>> } >>> } >>> >>> This renames all the nics to ethX or wlanX for the WUI. When you use any commandline tool (e.g ip addr or brctl show) the names of the NICs will mismatch with the ones shown in the WUI. Same for the assigened VLAN-IDs. >>> >>> For example, one of my setups: >>> >>> - WUI name --> real name >>> - eth0 --> red0 >>> - eth1 --> eth1 >>> - eth2 --> orange0 >>> - wlan0 --> blue0 >>> - wlan1 --> wlan1 >>> >>> What is the goal of doing this? I personally think this is more confusing than useful. I would prefer to not rename the NICs. What do you think? >>> >>> I attached a patch to change the naming back to the real names. Please decide to merge it or not, depending on where the discussion ends. >>> >>> Secondly I created a patch to add the current output of "brctl show" and "ip addr" to the zoneconfig page. It's quite useful to have this by the hand without having to open a shell sometimes. >>> >>> Regards, Alex >>> >>> Alex Koch (2): >>> zoneconf: Show real names of NICs in the WUI >>> zoneconf: Add status output of "brctl show" and "ip addr" >>> >>> html/cgi-bin/zoneconf.cgi | 34 ++++++++++++++++++++++++---------- >>> langs/de/cgi-bin/de.pl | 5 ++++- >>> langs/en/cgi-bin/en.pl | 5 ++++- >>> 3 files changed, 32 insertions(+), 12 deletions(-) >>> >>> -- >>> 2.17.1 >>> >>> >>> >>> <190907_florians_example.png><190907_no_bridges.png><190908_all_bridges.png> > > Regards, Alex