From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH 0/2] zoneconf: replace the nic-names with eth... and wlan... or not? Date: Thu, 12 Sep 2019 13:01:41 +0100 Message-ID: <4E51AF95-19CC-4CB8-A9B4-5E315E0B76F3@ipfire.org> In-Reply-To: <149bb937-9a05-f610-56d0-7779195c3910@starkstromkonsument.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2626851932872230355==" List-Id: --===============2626851932872230355== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 11 Sep 2019, at 19:34, Alexander Koch = wrote: >=20 > Hi, >=20 > -------- Urspr=C3=BCngliche Nachricht -------- > Von: Michael Tremer [mailto:michael.tremer(a)ipfire.org] > Gesendet: Montag, 9. September 2019, 17:04 MESZ > An: Alexander Koch > Cc: Florian B=C3=BChrle , development(a)lists.ipfi= re.org > Betreff: [PATCH 0/2] zoneconf: replace the nic-names with eth... and wlan..= . or not? >=20 >> Hi, >>> On 7 Sep 2019, at 23:55, Alexander Koch = wrote: >>>=20 >>> Hi Florian, >>>=20 >>> 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? >>>=20 >>> You can not assign multiple zones to one native NIC. If you want to add o= range0, to the blue zone, you can only do this as a VLAN and blue has to be o= f type bridge. This will result in an additional interface named orange0. that is part of the bridge blue0. This offers the blue zone available a= s in the orange zone. Do you agree? >> blue0 could still be the VLAN device piggy-backing on orange0. There is no= bridge required. >=20 > 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 bei= ng 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). >>>=20 >>> My example (IPFire running in a VirtualBox) offers another issue: the rea= l 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 thei= r 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 firmwa= re is already loaded and so on. That is why we cannot depend on NIC names. >=20 > Thanks for correcting me here, I was not aware of this. No problem=E2=80=A6 >=20 >>> Michael, I would not show no names at all. Just keep the real device name= s in the WebUI. People need them whenever they are searching for errors or wa= nt 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 sy= stem. >> People who are on the console dealing with tcpdump are on their own and ho= pefully know how to find the correct NIC. I do not think that the webUI shoul= d be accommodating too much for this use-case. However, showing incorrect nam= es is not good either. >> 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 = confusing. >> 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 sen= d a revised patch? Yes, I think so. Can you coordinate with Florian, because technically it is h= is code :) I think it might be a little bit of a challenge to get this into the UI becau= se 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 >=20 >>> To me, the best solution would be running all zones as bridges per defaul= t. But this is something that will be addressed in IPFire 3.x anyway so I wou= ldn'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 th= e 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 >> That also has downsides. We do it in IPFire 3, but the whole network archi= tecture 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 t= his happen. >> Best, >> -Michael >>>=20 >>>=20 >>> Regards, Alex >>>=20 >>>=20 >>> -------- Original Message -------- >>> From: Michael Tremer [mailto:michael.tremer(a)ipfire.org] >>> Sent: Thursday, 5 September 2019, 11:27 CEST >>> To: Florian B=C3=BChrle >>> Cc: ipfire(a)starkstromkonsument.de, development(a)lists.ipfire.org >>> Subject: [PATCH 0/2] zonconf: replace the nic-names with eth... and wlan.= .. or not? >>>=20 >>> Hi, >>>=20 >>> I agree with both of you :) >>>=20 >>> Showing the =E2=80=9Cold=E2=80=9D names is confusing. Numbering them agai= n is also not helpful. >>>=20 >>> 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? >>>=20 >>> -Michael >>>=20 >>> On 4 Sep 2019, at 07:49, Florian B=C3=BChrle wr= ote: >>>=20 >>> Hi Alex, >>>=20 >>> your point is absolutely correct, however there's some thought behind thi= s: as the udev rules rename the physical interfaces to 0 when the inter= face 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, e= ven though it would work fine. >>> What do you think? >>>=20 >>> Regards >>> Florian >>>=20 >>> Gesendet von ProtonMail mobile >>>=20 >>>=20 >>>=20 >>> -------- Original-Nachricht -------- >>> An 3. Sep. 2019, 23:46, Alex Koch schrieb: >>>=20 >>> Hi, >>>=20 >>> I stumbled into this when I was searching for an error in my vlan and bri= dge-config and want to start a discussion about if this should be changed or = not. >>>=20 >>> The zoneconf.cgi contains the following code-snippet: >>>=20 >>> # Name the physical NICs >>> # Even though they may not be really named like this, we will name them e= thX or wlanX >>> my $ethcount =3D 0; >>> my $wlancount =3D 0; >>>=20 >>> foreach (@nics) { >>> my $nic =3D $_->[1]; >>>=20 >>> if (-e "/sys/class/net/$nic/wireless") { >>> $_->[1] =3D "wlan$wlancount"; >>> $_->[2] =3D 1; >>> $wlancount++; >>> } else { >>> $_->[1] =3D "eth$ethcount"; >>> $ethcount++; >>> } >>> } >>>=20 >>> 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 misma= tch with the ones shown in the WUI. Same for the assigened VLAN-IDs. >>>=20 >>> For example, one of my setups: >>>=20 >>> - WUI name --> real name >>> - eth0 --> red0 >>> - eth1 --> eth1 >>> - eth2 --> orange0 >>> - wlan0 --> blue0 >>> - wlan1 --> wlan1 >>>=20 >>> 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? >>>=20 >>> I attached a patch to change the naming back to the real names. Please de= cide to merge it or not, depending on where the discussion ends. >>>=20 >>> 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. >>>=20 >>> Regards, Alex >>>=20 >>> Alex Koch (2): >>> zoneconf: Show real names of NICs in the WUI >>> zoneconf: Add status output of "brctl show" and "ip addr" >>>=20 >>> 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(-) >>>=20 >>> -- >>> 2.17.1 >>>=20 >>>=20 >>>=20 >>> <190907_florians_example.png><190907_no_bridges.png><190908_all_bridges.p= ng> >=20 > Regards, Alex --===============2626851932872230355==--