I have been using Mandrake/Mandriva/Mageia for more than 10 years to configure a local network. This is actually the reason that I have stuck with MCC for so long. No other distro makes it posible to configure a LAN without being an expert in networking.
I need some HELP to locate this bug (NOW), or I have to install Mageia3 for the period that it will still have support. I have no idea where the problem is. There is nothing in the window with the logs from drakgw.

Try MCC -> Hardware and run the hardware scan.  See if both network adapters are recognized.  Alternatively, try MCC -> Networking -> Add, choose Wired, and see whether it includes both adapters in the choice list.

If it doesn't, then the problem could be as simple as your eth1 device signature having been left out of a hardware list somewhere along the line.  In that case, do "lspcidrake -vv" and record the PCI info (vendor ID, etc.) for the missing adapter here.

CC: (none) => ftg

2 82574L Gigabit Network Connections are shown after the scan.
The MCC Network Center shows the same 2 82574L as eth0 and eth1.
Yes. I did configure eth1 in the Network Center.

OK, can you run drakgw from a root command line and post/attach the stdout/stderr that results when it fails ?

Created attachment 5019 [details]
drakgw &>drakgw.log

drakgw was run as root. I could select both eth0 and eth1 as net device. I selected eth0. drakgw could not find eth1.

looks like the local interface return is going wrong: http://gitweb.mageia.org/software/drakx-net/tree/bin/drakgw#n126

btw I reproduce on a clean install

CC: (none) => mageia, thierry.vignaud

*** Bug 12887 has been marked as a duplicate of this bug. ***

CC: (none) => gramo.gnu

Mr Hiebel mark my bug as a duplicate, but this one is different because my hardware scan reports both network interfaces, and drakgw in the first screen (when you select interface for internet) shows both network interfaces in order to be choosed.  Then I think they are different bugs, but I left that decition to Manuel.

I ran drakgw as root obtaining the following messages on console:
[root@localhost ~]# drakgw
Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.18.1/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 258.
Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 296.
apmd.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect apmd --level=5
atieventsd.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect atieventsd --level=5
mandi.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect mandi --level=5
microcode_ctl.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect microcode_ctl --level=5
msec.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect msec --level=5
mtinkd.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect mtinkd --level=5
netconsole.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect netconsole --level=5
network-auth.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect network-auth --level=5
network-up.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect network-up --level=5
network.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect network --level=5
partmon.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect partmon --level=5
postfix.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect postfix --level=5
pptp.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect pptp --level=5
preload.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect preload --level=5
resolvconf.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect resolvconf --level=5
smb.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect smb --level=5
smfpd.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect smfpd --level=5
squid.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect squid --level=5
vboxautostart-service.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect vboxautostart-service --level=5
vboxballoonctrl-service.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect vboxballoonctrl-service --level=5
vboxdrv.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect vboxdrv --level=5
vboxweb-service.service is not a native service, redirecting to /sbin/chkconfig.
Executing /sbin/chkconfig --no-reload --no-redirect vboxweb-service --level=5

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

      If you want to list systemd services use 'systemctl list-unit-files'.
      To see services enabled on particular target use
      'systemctl list-dependencies [target]'.

WARNING **: Can't load fallback CSS resource: Failed to import: El recurso en «/org/gnome/adwaita/gtk-fallback.css» no existe at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 1345.
WARNING **: Can't load fallback CSS resource: Failed to import: El recurso en «/org/gnome/adwaita/gtk-fallback.css» no existe at /usr/lib/perl5/vendor_perl/5.18.1/Gtk3.pm line 1345.

(drakgw:11615): Gtk-WARNING **: GtkImage 0x2702610 adjusted size vertical min 47 natural 47 must not decrease below min 48 natural 48

(drakgw:11615): Gtk-WARNING **: GtkImage 0x2702610 attempted to adjust its size allocation from -12,1 540x54 to 0,0 528x55. adjust_size_allocation must keep allocation inside original bounds

you write: "After that, drakgw tells me that can't find any interface connected to LAN and finish the wizzard." 

it's exactly this bug.

So, who is going to fix it?

Thanks Manuel for your explanation, my mistake.

Same problem as Ricardo Naranjo. Please, fix it, or post some usable cl-manual to make it working.

CC: (none) => mojrv

Same Problem

CC: (none) => contact

I found into Mageia 2 and 3 (where eth0, eth1, etc...) the very same problem.

I documented myself and when I edited mannually /etc/shorewall scripts and place into zones and interfaces the right information I can run drakgw with no problems.

So the problem is persistent since first Mageia, I found that also on Mandriva.

I hope that information helps to understand where the problem is and you may fix that easily.

Thanks in advance

BTW: the way I configure my shorewall's zones and interfaces files is as follow:
Zones--------------------------------------------------------------------
#ZONE	TYPE		OPTIONS		IN			OUT
#					OPTIONS			OPTIONS
net	ipv4
loc	ipv4
fw	firewall

Interfaces--------------------------------------------------------------------
net	eth0	detect
loc	eth1	detect


On Mageia 4 I tryed interfaces with:
net	enp2s0	detect
loc	enp7s5	detect

but does not work

I found the original post I made to Mandriva for Mandriva 2009:

http://mandriva.598463.n5.nabble.com/Bug-47096-NEW-The-shorewall-firewall-does-nt-start-td662470.html

There is more information about this bug.

Correction, I found this bug into Mandriva 2008...

https://vb.serverknecht.de/showthread.php?s=485808036e047a80f2023b637fa4fa7a&t=161810

drakgw did find the network adapter on a fresh install of Mageia3.
BUT it generated these 3 lines in squid.conf:

acl manager proto cache_object
acl localhost src 127.0.0.0/8
acl to_localhost dst 127.0.0.0/8

that squid was unhappy about.
The first one is (now) an ERROR, the following 2 lines give warnings.

I simply commented these 3 lines, and then it worked.

Bjarne Thomsen: I did not find the configuration file, I haven't squid installed. It shouldn't be the reason for not finding interface configured for LAN. Drakgw installs squid after configuring connection sharing. But thanks for the comment, maybe it helps somebody to fix it.

I am not imlpying that the 3 lines are the reasons for not finding the interface. drakgw did actually find the interface. It just might be an idea to fix the 3 lines, if drakgw is going to be modified.

You're right

This is part of the problem and I did'nt report that:

When I make drakgw run, after manual editing of shorewall's zones and interfaces files I have to fix /etc/squid/squid.conf by adding my network lines:

	acl TELMEX   src 186.80.0.0/16 # My ISP network
        ...
	http_access allow TELMEX

and restart squid service.

I have installed drakx-net, drakx-net-text, drakx-net-applet and libdrakx-net of the version 1.25-1.mga3 by urpmi --downgrade --allow-nodeps.
NetApplet does not work, it needs more dependencies which I don't want to downgrade, but the sharing of internet connection goes well.

This is interesting. The only thing that has happened is that the perl code is moved from /usr/sbin/drakgw to /usr/libexec/drakgw in drakx-net-text-2.12-1.mga4, which is then called by exec /usr/libexec/drakgw "$@" in /usr/bin/drakgw.

Do we mark 12883 a duplicate of 12542 or do we
mark 12542 a duplicate of 12883?

I been watching 12542 since I reported it and seen no progress.
Which one should I watch?

CC: (none) => rbcourt

none of them are proggressing, but all of them are the same, I prefer to mark 12542 a duplicate of 12883 because here we have more information that can lead bug team in order to solve the issue.

Created attachment 5088 [details]
Difference between the 2 perl modules

Got mine to work by replacing /usr/lib/libDrakX/network/shorewall.pm from Mageia 3
Comment is the diff file between the 2

I confirm that drakgw can find the interfaces, if shorewall.pm is replaced with the one in package libdrakx-net-1.25-1.mga3 of Mageia 3.

do we have to downgrade to libdrakx-net-1.25-1.mga3 or just replace single file?

I just replaced the single file. No dependencies to worry about.

I just tried drakgw again, and now it works! I have the latest updates_testing installed. I noticed that drakx-net-text-2.12-1.mga4 has not been changed, so why is it now working? As with mga3 I had to uncomment a line in squid.conf to get squid running.

I'm updated and I try again drakgw... it can't detect the second network interface and breaks the process with no alternative.

Maybe you install something different?

I have only used
urpmi --auto-update
on
Core Release
Core Updates
Core Updates Testing
Core Backports
Core Backports Testing

I can, however, not exclude that I have some perl program installed that required an update of a perl module also used by drakx-net-text.
My current kernel is 3.12.21-desktop-2 (i686).

Is there a way of listing updated packages sorted by dates?

To Maarten & Colin: people are pointing to your changes between mga3 & mga4 for the breakage

To reporters: can one of you do the following:
- cp /var/log/explanations /tmp
- run failing drakgw
- run "diff -u /tmp/ /var/log/explanations>/tmp/ko.txt"
- attach this /tmp/ko.txt file here

- copy back mga3 shorewall.pm back in place
- cp /var/log/explanations /tmp
- run failing drakgw
- run "diff -u /tmp/ /var/log/explanations>/tmp/ok.txt"
- attach this /tmp/ok.txt file here

Keywords: (none) => NEEDINFO
CC: (none) => alien

Comment on attachment 5088 [details]
Difference between the 2 perl modules

This is useless (missing header & not in unified format).
Better point to  http://gitweb.mageia.org/software/drakx-net/log/lib/network/shorewall.pm
and http://gitweb.mageia.org/software/drakx-net/diff/lib/network/shorewall.pm?id2=689748d41b3691f0142c387b4357f43f80352863
(from http://gitweb.mageia.org/software/drakx-net/diff/?id2=689748d41b3691f0142c387b4357f43f80352863&id1=81c4c24c36195d3d5b6ee03d57bfdbc7a38ab9e0)

Attachment 5088 is obsolete: 0 => 1

Why are there not generated any /var/log/explanations file on some of my mga4 systems? There is none on the system where I am testing drakgw. drakgw does for some strange reason now detect eth1. I have done nothing apart from updating the system on a regular basis.

so, afaiu: this is after a default install with mga4, executing the drakgw (internet sharing) with 2 connected interfaces? if so, it should be easily debuggable...

some thoughts on the code/diff:

1. we shouldn't do masq for ipv6, and drakgw itself should skip ipv6 unless a global link ipv6 address is there...

2. on top of that, multiple interfaces could be lan internet shared. (so, not choose one, but choose multiple)?

3. as some extra it would be nice if multiple internet links could be used too... (same thing if you have a IPv6 tunnel(s) on a different interfaces...)

4. the only changed code that i see that could have effect would be either a forgotten $ver in a function call outside of shorewall.pm or something in drakgw that accidentally also runs twice (once more for ipv6). The code change itself is quite minimal...

I didn't have testing repositories and I have not yet changed mga4 original /usr/lib/libDrakX/network/shorewall.pm to mga3 style.

I ran drakfw and no explanation file is generated. I check step by step if any explanation file finding nothing.

cat /var/log/explanations
cat: /var/log/explanations: No existe el fichero o el directorio (no such file or directory)

i did a test on a VM, and drakgw doesn't make a /var/log/explanations file (maybe systemd is responsible or something, i donno...

it could indeed not find any loc interfaces, even though it had 2 options for net interface...

i'm putting in some debug values locally to see what happens...

@reporters, try this patch on drakgw, and make sure to have the normal shorewall.pm from mga4:

http://gitweb.mageia.org/software/drakx-net/commit/?id=6bbe345c419ed296362020145c99967bd3614323

i'm not sure if the difference pointed out, actually has an effect, to me it looks like the local zone is unconfigured (or has the interface that would be the net zone interface in it).

(it looked like net zone interfaces are '+' and loc zone interfaces is 'eth0', which is the selected one for net zone...)

this change seems more sane to me... whatever the case, all interfaces get selected for local zone (except the chosen net zone one)

I replaced /usr/libexec/drakgw with your modified version and reconfigured eth1 as the subnet and kept eth0 unmodified as the internet.
systemctl status squid.service
gave, as before, the error:
Bungled /etc/squid/squid.conf line 15: acl manager proto cach_object
As before I commented this line, and squid started successfully.

However, dhcpd would not start, and I got this status:
systemctl status dhcpd.service
Not configured to listen on any interface.

named is running.

It looks as if the situation is unchanged.

@bjarne ... no, i'm just looking at the ethernet interface part, the shorewall part of drakgw. (which is where i contributed in the change from mga3 to mga4).

you didn't get the "no interface found for LAN" error... which is what was introduced (possibly) and this part is what i fixed. that's why you need to test this with the new shorewall.pm (and not the one you've overwritten from older mga3).

i'm not fixing the squid part, nor the dhcpd configuration part or whatnot...

let's take this one step at a time...

Sorry, I had completely forgotten shorewall.pm. It is now back to the mga4 version. I can still select eth1 for the local net with your new drakgw.
But I discovered that shorewall is not nunning due to this ERROR:
Duplicate Interface (eth1) /etc/shorewall/interfaces (line 15).
eth1 appears as both loc and net, and it does not like that.
It runs when I delete one or the other.

dhcpd, however, still gives the error:
Not configured to listen on any interface.

you selected eth1 as network interface and then again as local interface?

ah, i understand now...

eth1 was in locals before, so you could pick it again... maybe i should grep that out again...

Created attachment 5190 [details]
additional test patch

try this additional patch on drakgw... this should not make it possible to keep selecting eth1 as local interfaces if it's already chosen for network interface...

I have never selected eth1 as net device. Is it possible that NetworkManager (it is running) automatically selected all devices as net? Should I start by deleting all devices and start from scratch?

no, no, drakgw should just work in most cases...


ok, so in the last tests you selected eth0 as net? and eth1 as local?

and shorewall didn't work?

can you show me the interfaces file?

was eth1 in local zone? if you chose eth0 as net device, why would eth1 be in the net zone???

I think that I have figured out what happened
1) first I removed all connections in "Manage your network devices".
2) then I set up eth0 for dhcp to the external world.
Interfaces:
net     eth0    detect
net     wlan0   detect
net     eth1    detect
3) then I used "Set up your personal firewall" to disable eth1 and wlan0.
Interfaces:
net     eth0    detect
loc     wlan0   detect
loc     eth1    detect
4) then I configured eth1 to a fixed IP number by "Set up a new network interface"
The interface file was unchanged as in 3).
Then I used "Share the internet connection.....".
Interfaces:
net     wlan0   detect
net     eth0    detect
net     eth1    detect
loc     eth1    detect
For some strange reason "internet sharing" (drakgw) has inserted a "net eth1".
5) I then again used "set up your personal firawall" to disable the firewall
on eth1, and I returned to interfaces as under 3).
Now shorewall is able to start, but dhcpd still has a problem.
To repeat your question: why would eth1 be in the net zone???
A very good question!

Created attachment 5191 [details]
updated patch

matching /^$foo$/ is more readable as eq $foo
Also here one can use a shared variable for readability.
See attached revised but untested patch.

Of course, it should be committed in two steps for history readability in 6 months (first, introducing $if variable for existing test, then adding the new filtering).



Alternatively we could split the grep call into a new filter_chosen_net_interface() function:

sub filter_chosen_net_interface {
   my (shorewall, $reflist) = @_;
   $shorewall->{loc_zone} = [ grep { $_ ne $shorewall->{masq}{net_interface} } @reflist;
}	  

Instead of grep, we could use MDK::Common::difference2()
(see http://search.cpan.org/~tvignaud/MDK-Common-1.2.30/lib/MDK/Common.pm)

@thierry, so, you think the problem with filtering out the network, is because i used regex with $shorewall->{masq}{net_interface} in it, so it doesn't work?

@bjarne: you should test this patch, so that we know that this was the problem...

@thierry? you think we should make one patch and redo the history on the git?

diff drakgw.4 /usr/libexec/drakgw
128,132d127
<                 my $if = $shorewall->{masq}{net_interface};
<                 # filter out net interface
<                 $shorewall->{loc_zone} = [ grep { $_ ne $if } @{$shorewall->{loc_zone}} ];
<                 # if loc_zone is unconfigured and has no interfaces, have all interfaces be local (except the chosen net interface)
<                 $shorewall->{loc_zone} = [ sort grep { $_ ne $if } keys %{$net->{ifcfg}} ] if scalar(@{$shorewall->{loc_zone}}) == 0;

Then I configured eth0 and eth1 as above, and used "Share the internet...":
net     wlan0   detect
net     eth1    detect
net     eth0    detect
loc     eth1    detect

It did not work, or I did something wrong.

looking at this, it appears the net zone is at fault here... maybe we should remove the loc interfaces from the net zone at the end of the choice

maybe we should make the whole thing alot simpler...

keep all interfaces in net zone at install time. (option +)?
(watch out for expansion of interfaces)

- drakgw giving option to select all interfaces where you want to share internet to. (this can mean there are some other interfaces that can give internet, but those aren't masqueraded)
- drakgw giving option to select all local interfaces which you want to share internet from.

iow: 
- at install time, all interfaces should be in net.
- at drakgw start, the choice is: all net interfaces (or all interfaces if net is empty)
- after net choices (multiple ones), the choice is all local interfaces (or all interfaces if loc is empty) (except chosen net interfaces)
- after local choices: all the whole loc zone should be removed from net zone.

My box does not have eth* style, instead it shows interfaces as enp*s*... nothing you write here seems to work.

(In reply to AL13N from comment #50)
> @thierry, so, you think the problem with filtering out the network, is
> because i used regex with $shorewall->{masq}{net_interface} in it, so it
> doesn't work?

No, I'm just talking about nicer cleaner code

> 
> @thierry? you think we should make one patch and redo the history on the git?

We NEVER redo git history, else we break other people's git clones

I do not see it as a big problem that there is a mix up of net and loc after running "Sharing the internet...". After all, it finishes by this statement:
Warning! An existing firewalling configuration has beendetected. You may need some manual fixes after installation.
Indeed, the net lines are removed by applying "Set your personal firewall".
After that shorewall is running.

My real problem is that dhcpd is NOT running due to the mysterious error:

Not configured to listen on any interfaces.

Now, it is supposed to read options from /etc/sysconfig/dhcp
This file contains these options:
OPTIONS="-q"
INTERFACES="eth1"

For some reasons it does not accept these options.
Why?

systemctl status dhcpd.service:
dhcpd.service - DHCPv4 Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled)
   Active: failed (Result: exit-code) since Thu 2014-06-12 21:14:16 CEST; 17min ago
  Process: 3140 ExecStart=/usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf $CONFIGFILE -lf $LEASEFILE $OPTIONS $INTERFACES (code=exited, status=1/FAILURE)

Very strange. The environment parameters are not expanded to their actual values.

On my mga3 system I get:
dhcpd.service - DHCPv4 Server Daemon                                                                                                       
          Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled)                                                                  
          Active: active (running) since Wed, 2014-06-11 13:43:55 CEST; 1 day and 8h ago                                                   
        Main PID: 1539 (dhcpd)                                                                                                             
          CGroup: name=systemd:/system/dhcpd.service                                                                                       
                  â 1539 /usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf /etc/dhcpd.conf -lf /var/lib/dhcpd/dhcpd.leases -q eth1

you should check with journalctl -u dhcpd.service to see why it failed with status 1.

the execstart is literally shown... it's normal that at this point the variables aren't expanded.

the environmentfile seems to be fine... perhaps there's a bug in your environmentfile?

the only other thing i see, is that in the service file, there's both Environment and EnvironmentFile ... perhaps one excludes the other in mga4.

it's either that, or something in the configfile is wrong and thus it would be excluded?

I found the dhcpd problem. eth1 was not configured to any IP address.
This was solved by the command
ifconfig eth1 192.168.15.1

"Sharing the internet connection.." showed this address, so why does drakgw not actually configure eth1 to this address?

maybe we need some fresh tests... with the necessary patches, after a fresh install to see where the real problem lie...

Maybe you can remind me exactly how I am supposed to configure a local subnet using the MCC graphical interfaces?
a) First I set up a new network interface like eth0 to use dhcp.
b) then I am bringing it up connecting to the internet, or actually to my existing local network (running on mga3).
c) I then set up a new interface like eth1 to serve as LAN with a fixed IP address. But should I also bring it up? This makes no sense as the dhcpd server has not been configured.
d) Now I share the internet with the local net, but that requires that eth1 belongs to the local zone. This can be done by the personal firewall. But where is the "ifconfig eth1 IP" comming into the picture?

I hope that you are not suggesting a fresh install of the whole mga4 distribution, but only relevant mcc component.

well, if it isn't up, then it can't get an ip address... now can it?

it's not because a network is up (without having dhcp in that network) that it should be down...

think about it, what if you already had an existing dhcp server in that network already?

It turns out that durin setup of a new interface. I get this error:
Problems occurred during the network connectivity test.
This can be caused by invalid network configuration, or problems with your modem or router.

If I try to bring it up manually by ifup eth1 I get this error:
Error: Connection activation failed: Device not managed by NetworkManager or unavailable

/etc/sysconfig/network-scripts/ifcfg-eth1
does exist!

When I manually type
ifconfig eth1 192.168.15.1
dhcpd kan be started.

Could there be a bug in initscripts?

Please edit error message to
..., or problems with your modem, router or switch.

There MUST be some active equipment at the end of the ethernet cable connected to the port of eth1 in order to bring it up. This may be obvious, but I did not think of it before this morning.

When it "suddenly" worked, as described above, I had a running PC connected. Now I have a running switch connected.

Also, the "View Log" of the MCC must be activated in order to create the file
/var/log/explanations
A certain package must be installed (the old syslog?).

well,

this is a change which is due to NetworkManager ...

the old scripts never had trouble configuring a device that had NO-CARRIER for static ip...

you should file a bug with upstream NetworkManager to either fix that, or fix their error message (the message comes from NetworkManager)

Well, I startet from scratch, again (disabling sharing and removed eth1).
I still have a problem (with a switch connected) while setting up a new interface (eth1).
When I selected "Yes" to "Do you want to start the connection now?" I stil got this error message:
Problems occured during network connectivity test.

But this time eth1 was actually up, I could bring it down and up by hand.
Is this also related to NetworkManager? Or is it something else?

I still have eth1 belonging to both Zone "net" and "loc" in
/etc/shorewall/interfases
after applying "Share the internet connection..".

It would still be nice to have the "net" filtered out.

I should add that eth1 is in the loc zone, only, when I enter "share the internet" (drakgw), but it is in both loc an int zone, when I exit drakgw.

I am using the latest drakgw patch that is supposed to filter out other devices than the chosen net device.

Could drakgw insert it again at a later position in the code?

do you mean that before you start drakgw: eth1 (your loc device) is in both loc and net zone.

then you start drakgw, it is in loc zone only? then after exiting, it is in both loc and net zone? again? afaik, drakgw only writes to shorewall at the end...?

Let me explain with more details:
a) I first configure eth0, which is connected to the local net of a mga3 PC.
b) Next I configure eth1, which is connected to a running PC.
cat /etc/shorewall/interfaces
#ZONE           INTERFACE               OPTIONS
net     wlan0   detect
net     eth1    detect
net     eth0    detect

c) I now use drakfirewall to un-protect eth1 and wlan0.
cat /etc/shorewall/interfaces
#ZONE           INTERFACE               OPTIONS
net     eth0    detect
loc     eth1    detect
loc     wlan0   detect

d) I am now ready to share the interne by running drakgw.
cat /etc/shorewall/interfaces
#ZONE           INTERFACE               OPTIONS
net     eth0    detect
net     eth1    detect
net     wlan0   detect
loc     eth1    detect

Note, eth1 is now in both zone net and zone loc.
e) to make sure that eth1 is in the local zone, only, I call drakfirewall again to unprotect eth1 and wlan0.
cat /etc/shorewall/interfaces
#ZONE           INTERFACE               OPTIONS
net     eth0    detect
loc     eth1    detect
loc     wlan0   detect

It looks as if shorewall automatically tries to protect all interfaces by putting them into the net zone.
After these steps the local network works on the connected PC.

I copied the patched drakgw onto enother PC with these 2 devices:
ethernet: enp2s0
WiFi: wlp3s0
I configured wlp3s0 to connect to the internet, and configured
enp2s0 to a static IP address and not to be controlled by NetworkManager.

Then I followed the procedure using drakgw and drakfirewall as described above.

squid, shorewall, named and dhcpd is now running as a local
subnet on device enp2s0.

So it is possible to use a net device not called eth*

This bug has formally been solved by the updated patch, but eth1 is both in zone net and zone loc, so shorewall refuses to run. Should I file a new bug report for that problem?

imho that's still part of the problem so, hold off on that... if i find some time, i'm gonna try a new patch for you to test...

It must now be time to finish this bug. I have still a fitpc2i running in order to test drakgw patches to Mageia4.

I'm still having the problem... and my system is up to date

I can't set up gateway automatically, it still needs lots of handwork before get started.

As I explained above the applied patches nearly worked as expected. The only remaining problem is that eth1 end up in both net and loc zones.

I rebooted my fitpc2i system after updating to kernel 3.14.19. For som, maybe not so bad, reason the firewall was activated for my local net device eth1.
Could I yet again urge you to submit the abowe patches to updates-testing. drakgw is useless as it is, and is is unlikely that the free time will ever be found. It may even be a good thing to have to actively remove the firewall from the local net. It is always better to be safe than sorry.

Ok same problem with Mageia 5 / Cauldron.

I used the same fix as I did berfore copied /usr/lib/libDrakX/network/shorewall.pm
from Mageia 3

I believe it's more of an isssue with perl more than anything else. I had to make perl changes at work based on the latest perl version.

Yes, it would be most desirable to have a fix before Mageia5.

I can get it started. Now have to reconfigure it every time I reboot.
What I didn't heve to do in Mageia 4.

I am running a local network on Mageia3. Now that Mageia3 is running out of support it is critical that the modifications above be applied to Mageia4 so that I can upgrade to Mageia4. It would also be timely to correct this bug in Mageia5. I am running a test box with 2 ethernet connections, so I can quickly test the modification.

see also 12542 and 14357

The one line addition to drakgw in mga5 actually works in mga4.

It seams to be working after installing the first beta and upgrade. Now the only problem is I have to start shorewall after every reboot.

This also happens to me. But it has been like this for quite some time, and the text says something like "apparently the firewall was configured, so you would probably have to make some modifications". It looks as if the firewall is enabled for all devices in order to be on the safe side.

I just start shorewall and only the external network card is proctedted no reconfiguration needed.

this is a problem for mga4 only, right? or is this a problem with mga5?

and, this is still about sharing network? or is this now about something else?

i'm getting confused here...

mga5. 4 I only capied the shorewall.pm file from mga3 into the mga4 tree

I am actually satisfied with sharing network in mga5 without any changes, but only regarding the subject of this bug. The sharing network configuring of squid is quite another matter. See Bug 14775 about a change in how squid is now configured, as compared with the current Mageia "network sharing"-configuration of squid.conf. This relates to mga4, but as drakgw has not been changed in mga5, apart from the 1 line mentioned above, it must also be present in mga5.

since this bug is not about mga5, what exactly is wrong with mga4? i thought we fixed the network sharing part (not talking about squid)

Some of the confusion is probably due to hot-plugging of interfaces.
I consider this bug as fixed.

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