Once the correct IF is set there _and_ shorewall restarted.. above :)

So the question is, what configures shorewall... It's not in the default file and it's not in any shorewall %post script... drakfirewall I presume?

Using eth0 there would seem wrong anyway, as I don't have any eth0 on my machine under mga3 anyway - only wlan0...

But yes, the code needs uptdated.

OK, running things like:

[colin@jimmy drakx (master)]$ perl -I /usr/lib/libDrakX -e 'use detect_devices; use Data::Dumper; print Dumper(detect_devices::get_net_interfaces());'
$VAR1 = 'wlp1s0';
$VAR2 = 'enp0s20u1';
[colin@jimmy drakx (master)]$ perl -I /usr/lib/libDrakX -e 'use detect_devices; use Data::Dumper; print Dumper(detect_devices::get_lan_interfaces());'
$VAR1 = 'wlp1s0';
$VAR2 = 'enp0s20u1';


Both provide useful and correct values for me.

I guess the problem is that this is run from within the installer which does not yet use such names. Does that sound correct?

Can someone confirm that that /mnt/etc/shorewall/interfaces file contains eth0 *before* rebooting at the end of install?

if that is the case then we need work out the best route forward as I'm not sure stage2 would automatically rename any interfaces even if we did include the relevant udev rule... It would be nice if that was all that was needed tho'.

I won't be able to test this more fully until the end of next week, but if someone want to try adding the /usr/lib/udev/rules.d/80-net-name-slot.rules to the stage2 file list and regenerating it, they could try it out and see if this magically fixes things.

All the best.

I'll check /mnt/etc/shorewall/interfaces with this next install

Checked it right after saying No to installing updates and it is set to eth0

Thanks Claire :)

OK, now just need to test if simply adding the udev rule mentioned above to the stage2 lists is sufficient. In retrospect, I think it should actually work fine and be a rather simple fix. I've now committed the change to drakx but I cannot test right now :(

If someone spins a new stage2 then it *should* work (although I cannot guarantee that!)

new stage2 submitted

CC: (none) => tmb

/me hopes it works (crosses fingers)

Nope, didn't work.

However, there is an other option available...

what if we make shorewall(-ipv6) ship a default /etc/shorewall(6)/interfaces

that will allow any interface to pass outgoing traffic ?

that will make this stuff work oob regardless of naming...

this can be done by simply adding the line:

net     +      detect



the "+" acts as a wildcard...

Dang. But yes, that seems like a sensible approach generally.

We will likely have to disable the code that runs in drakx that updates that file on install however to prevent it re-breaking the default. We should also check that the code in drakx-net understand the "+" interface when parsing the files...

(In reply to Thomas Backlund from comment #9)
> this can be done by simply adding the line:
> 
> net     +      detect
> 
> 
> 
> the "+" acts as a wildcard...

Sounds like a good idea as we had similar problems with Mageia 3 too where NM controlled 3G modems were blocked by shorewall.

What impact will this have on drakgw, for sharing the internet
connection with other local machines?

(In reply to Sander Lepik from comment #11)
> (In reply to Thomas Backlund from comment #9)
> > this can be done by simply adding the line:
> > 
> > net     +      detect
> > 
> > 
> > 
> > the "+" acts as a wildcard...
> 
> Sounds like a good idea as we had similar problems with Mageia 3 too where
> NM controlled 3G modems were blocked by shorewall.

Seems to work fine on alpha1 live medias, so I've pushed a shorewall-4.5.10.1-5.mga4 with the change...


(In reply to Dave Hodgins from comment #12)
> What impact will this have on drakgw, for sharing the internet
> connection with other local machines?

That we need to review / test / fix... 
I guess drakgw should nuke that line when configuring shared internet connection...

(In reply to Thomas Backlund from comment #13)
> (In reply to Sander Lepik from comment #11)
> > (In reply to Thomas Backlund from comment #9)
> > > this can be done by simply adding the line:
> > > 
> > > net     +      detect
> > > 
> > > 
> > > 
> > > the "+" acts as a wildcard...
> > 
> > Sounds like a good idea as we had similar problems with Mageia 3 too where
> > NM controlled 3G modems were blocked by shorewall.
> 
> Seems to work fine on alpha1 live medias, so I've pushed a
> shorewall-4.5.10.1-5.mga4 with the change...
> 

I just finished a network install with boot.iso, and it now works oob.

drakx has added a: "net eth0 detect" to the line, even if drakx-net knows it by its real name, so a few fixes is needed to match but it does not break down for now atleast...

and I wonder if some of the issues are more related to timing issues with new systemd/udev/kernel than to the dropping og the "renaming part"

I just did an install, and found that :-

On running drakfirewall for the first time afer the install drakfirewall listed three interface for me to choose to protect +, enp0s3, and eth0

If I select either +, or enp0s3 then the firewall works as expected, but if I select eth0 the firewall does not protect from incoming connections, but outgoing connections work OK.


Since most users will be expecting their interface to be eth0 I would expect them to automatically select eth0 while wondering what on earth this enp0s3 is.

The second time I start drakfirewall the '+' interface has vanished leaving just enp0s3 and eth0.

CC: (none) => derekjenn

Yeah eth0 likely shouldn't be shown at all. As of the the other interfaces, + is special shorewall syntax so drakfirewall should be taught about that and handle it accordingly (e.g. selecting it automatically greys out+selects the others).

As for the enp0s3, this should likely be replaced with the nicer name for the interface e.g. on my system I have a wlp1s0 device, one which I can do:

[root@jimmy ~]# udevadm info --query=all --path=/class/net/wlp1s0
P: /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/wlp1s0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/wlp1s0
E: DEVTYPE=wlan
E: ID_BUS=pci
E: ID_MM_CANDIDATE=1
E: ID_MODEL_FROM_DATABASE=Centrino Advanced-N 6235 AGN
E: ID_MODEL_ID=0x088e
E: ID_NET_NAME_MAC=wlxc8f7338386eb
E: ID_NET_NAME_PATH=wlp1s0
E: ID_OUI_FROM_DATABASE=Intel Corporate
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Network controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_VENDOR_ID=0x8086
E: IFINDEX=2
E: INTERFACE=wlp1s0
E: SUBSYSTEM=net
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/wlp1s0
E: TAGS=:systemd:
E: USEC_INITIALIZED=3424


So I'd suggest we use ID_MODEL_FROM_DATABASE, which in my case would be "Centrino Advanced-N 6235 AGN" which should be much more user friendly.

I spent far too long playing with the stage2 installer today trying to work out what is happening.

Just before the service summary, steps.pm sets up the firewall by calling net/shorewall.pm write()  which sets the interfaces according to cat /proc/net/dev or detect_devices::get_net_interfaces()

At this time the interface has already been enumerated as eth0

I tried to define a udev rule to force the interface to a different name but nothing worked.  There does not appear to be a udev rule already setting the name to eth0 so I do not understand the process by which it gets named.

>So I'd suggest we use ID_MODEL_FROM_DATABASE, which in my case would be "Centrino >Advanced-N 6235 AGN" which should be much more user friendly.

I don't think I would like to have to type that on the command line too often.
A long name might also cause probs for some apps like the network applet if they have limited space to display the name.

(In reply to Derek Jennings from comment #17)
> I spent far too long playing with the stage2 installer today trying to work
> out what is happening.
> 
> Just before the service summary, steps.pm sets up the firewall by calling
> net/shorewall.pm write()  which sets the interfaces according to cat
> /proc/net/dev or detect_devices::get_net_interfaces()
> 
> At this time the interface has already been enumerated as eth0
> 
> I tried to define a udev rule to force the interface to a different name but
> nothing worked.  

Ahh sorry you spent time on this, as we were already aware that this was the problem.

I actually already committed a udev rule that *should* have named the network interfaces accordingly http://gitweb.mageia.org/software/drakx/commit/?id=14e4a36465175c7a761d212905e02eb4fd28531b, but it seems something is preventing it from working. Perhaps the network is already initialised when udev is started and we don't call an appropriate udevadm trigger or something to kick the rules into life.

> There does not appear to be a udev rule already setting the
> name to eth0 so I do not understand the process by which it gets named.

This is the default scheme used by the kernel. We will likely add a patch to the kernel that will allow us to specify a starting point number different from 0 i.e. eth1000 as this will allow us to keep the old naming rules on upgrade without introducing a race condition in userspace (which has always been present and sometimes results in eth0_rename interfaces existing on some boots...

> > So I'd suggest we use ID_MODEL_FROM_DATABASE, which in my case would be "Centrino >Advanced-N 6235 AGN" which should be much more user friendly.
> 
> I don't think I would like to have to type that on the command line too
> often.

No, not on the command line. It's just what IMO should be shown to the user when selecting interfaces in GUIs like drakfirewall.

> A long name might also cause probs for some apps like the network applet if
> they have limited space to display the name.

The network applet already shows nice friendly names IIRC. But not poked at it for a while.

fixed http://gitweb.mageia.org/software/drakx/commit/?id=00c8fea70d10e3738b70d9eeb2cc9413bdf58eaf ?

beta 1 was certainly able to connect OK so I think so yes.

I'll close this one :)

Thanks

Status: NEW => RESOLVED
Resolution: (none) => FIXED

(for reference, it's more the stage1 refactor, but the above commit did help too!)