From mboxrd@z Thu Jan  1 00:00:00 1970
From: Alexander Koch <ipfire@starkstromkonsument.de>
To: development@lists.ipfire.org
Subject: Re: [PATCH 0/2] zoneconf: replace the nic-names with eth... and
 wlan... or not?
Date: Wed, 11 Sep 2019 20:34:33 +0200
Message-ID: <149bb937-9a05-f610-56d0-7779195c3910@starkstromkonsument.de>
In-Reply-To: <6377B672-12D6-4FE5-AB08-6B38ADBC849C@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8424540396989733408=="
List-Id: <development.lists.ipfire.org>

--===============8424540396989733408==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

-------- Urspr=C3=BCngliche Nachricht --------
Von: Michael Tremer [mailto:michael.tremer(a)ipfire.org]
Gesendet: Montag, 9. September 2019, 17:04 MESZ
An: Alexander Koch <ipfire(a)starkstromkonsument.de>
Cc: Florian B=C3=BChrle <erdlof(a)protonmail.com>, development(a)lists.ipfire=
.org <development(a)lists.ipfire.org>
Betreff: [PATCH 0/2] zoneconf: replace the nic-names with eth... and wlan... =
or not?

> Hi,
>=20
>> On 7 Sep 2019, at 23:55, Alexander Koch <ipfire(a)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 or=
ange0, 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?
>=20
> 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 ...

>=20
>> To me this is the expected behaviour. I personally don't mind the NIC bein=
g 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 p=
atch 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?
>=20
> No, udev initialised the NICs in the order they come up by the kernel.
>=20
> That could differ from reboot to reboot if you have a NIC where the firmwar=
e 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.

>=20
>> 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 wan=
t 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 sys=
tem.
>=20
> People who are on the console dealing with tcpdump are on their own and hop=
efully 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 name=
s is not good either.
>=20
> If we show the current names you will have a page where =E2=80=9Corange0=E2=
=80=9D is configured as =E2=80=9Cgreen0=E2=80=9D which I also find rather con=
fusing.
>=20
> So that leaves us with showing the vendor and model of the NIC?
>=20

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 woul=
dn't invest any time in changing this for 2.x ... touching this might break o=
ther 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 =E2=80=A6
>=20
> That also has downsides. We do it in IPFire 3, but the whole network archit=
ecture 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 th=
is happen.
>=20
> Best,
> -Michael
>=20
>>
>>
>> Regards, Alex
>>
>>
>> -------- Original Message --------
>> From: Michael Tremer [mailto:michael.tremer(a)ipfire.org]
>> Sent: Thursday, 5 September 2019, 11:27 CEST
>> To: Florian B=C3=BChrle <erdlof(a)protonmail.com>
>> Cc: ipfire(a)starkstromkonsument.de, development(a)lists.ipfire.org <devel=
opment(a)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 =E2=80=9Cold=E2=80=9D 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 t=
o decide which NIC is being assigned to what zone, right?
>>
>> -Michael
>>
>> On 4 Sep 2019, at 07:49, Florian B=C3=BChrle <erdlof(a)protonmail.com> wro=
te:
>>
>> 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 interf=
ace 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, ev=
en 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 brid=
ge-config and want to start a discussion about if this should be changed or n=
ot.
>>
>> 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 et=
hX or wlanX
>> my $ethcount =3D 0;
>> my $wlancount =3D 0;
>>
>> foreach (@nics) {
>> my $nic =3D $_->[1];
>>
>> if (-e "/sys/class/net/$nic/wireless") {
>> $_->[1] =3D "wlan$wlancount";
>> $_->[2] =3D 1;
>> $wlancount++;
>> } else {
>> $_->[1] =3D "eth$ethcount";
>> $ethcount++;
>> }
>> }
>>
>> This renames all the nics to ethX or wlanX for the WUI. When you use any c=
ommandline tool (e.g ip addr or brctl show) the names of the NICs will mismat=
ch 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 dec=
ide 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 w=
ithout 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.pn=
g>
>=20

Regards, Alex

--===============8424540396989733408==--