@ Sorry for responding so late.

Is this still a problem in current cauldron or Mageia 1 ?

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

This is a Mageia 1 problem. 
Unfortunately, I can't say about Cauldron since I want to stay with Mageia 1 to keep a stable system.
I worked around it starting dhcpd by hand when needed so, for me, there's no emergency to fix it. When Mageia 2 is out, I will perform a new test and will let you know if it's still here (just post again here to ask, if ever I was long to do it myself)
Regards,

Denis

@ Denis

Thanks for replying :)

If you encounter the same problem in Mageia 2, please put that in a seperate bug report (because it's a different version of Mageia), but it would be nice if you could give a link to this one.

Closing this bug as old

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

OK Marja, I'll do it.

Still present in mageia1 and cauldron too I think (as no commit fox that)

Keywords: NEEDINFO => (none)
Status: RESOLVED => REOPENED
Resolution: OLD => (none)
Source RPM: drakx-net-text-0.97-1.mga1.src.rpm => drakx-net
Severity: normal => minor

I recently performed new tests that made me find the reason for my problem :

my network is only composed with two computers, one client and one gateway linked with a simple ethernet cable. So, when the client computer is not powered on, the ethernet network appears to the gateway as if it was down, that's the reason why dhcpd refuses to start on it when I configure the internet connection sharing (ICS).

As soon as the client computer is on when configuring the ICS, dhcpd starts properly.

By the way, the same problem appears everytime I start the gateway as the client is off. dhcpd is not started at boot time and I have to start it by hand later when the client is powered on by someone else
.
It would be nice if dhcpd start could succeed even if the network appears to be down at the time it starts, so as to never have to start it later by hand. But I did not find any place in the MCC ICS configuration dialog to achieve this. Maybe this is not possible ?

Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.

Problem is still here. As a workaround, I had to include a script in /etc/rc.local which tries to start dhcpd every few seconds until it succeeds.
Not very clean nor compatible with the beginner-friendly "all config through GUI" Mageia way.

I think the proper fix for this would be to add scripts to
/etc/sysconfig/network-scripts/ifup.d and
/etc/sysconfig/network-scripts/ifdown.d
that will start the server if /etc/sysconfig/dhcpd contains
#INTERFACES="" (i.e. it's still commented out), or
INTERFACES="" contains $1 (the interface being started).

I'll put together test scripts later today.

CC: (none) => davidwhodgins

Created attachment 2088 [details]
Script to start/restart dhcpd server on interface start

Try saving the attached script, and copying it to
/etc/sysconfig/network-scripts/ifup.d/dhcpd
then run
chmod a+x /etc/sysconfig/network-scripts/ifup.d/dhcpd

I'm not sure if this is appropriate for general usage,
but should work for your specific case.

Please test it, and report if it works for you or not.

I'll let the maintainer of dhcpd decide if it's appropriate
for general usage, or not.

Just tested it on Mageia 1, it works, thanks !

I've updated the rpm field.

Could be bugsquad assign this bug to the maintainer of dhcp, so they can
decide if the script would be appropriate for general use?

Connecting two computers directly via an ethernet cable, rather then
using a router is a relatively rare case, and the script may cause
unneeded restarts of dhcpd on systems with multiple interfaces where
a router is used.

Source RPM: drakx-net => dhcp

no maintainer, added the committers

Keywords: NEEDINFO => PATCH
CC: (none) => dmorganec, guillomovitch, lists.jjorge, pterjan, stewbintn, thierry.vignaud
Assignee: mageia => bugsquad

well, using /etc/sysconfig/network-scripts/ifup.d/ is a sysinit-specific solution: it won't works with systemd. So that's a bit short-termed solution.

Anyway, the bug title is a bit misleading. According of my own (flawed) understanding, the point is that dhcpd server should be automatically restarted when any bound interfaces configuration changes, and is not specifically tied to mcc network sharing wizard. However, I can't figure why it isn't true when dhcpd is not bound to any specific interface, but listen on all available ones (aka no specific interface set in /etc/sysconfig/dhcpd).

in my case, dhcpd was bound to eth0, since /etc/sysconfig/dhcpd contained :
---------
OPTIONS="-q"

INTERFACES="eth0"
INTERFACES="eth0"
INTERFACES="eth0"
-------
(don't know why there were three times the same line, I never edited that file, always performed network configuration through MCC)

So the problem did not seem to be related to the fact that dhcpd was not bound to any specific interface... but the solution provided in comment #10 solved the it !

I don't really understand the problem.

Is it that dhcpd starts to fail after being setup? Because the interface is not yet correctly setup and so needs to be started later when it becomes available?
It will refuse to start if you don't have an interface up with an address in the proper range.

I think restarting it anytime an interface gets up is a bad idea. Do we really want dhcp to restart each time you get disconnected/reconnected from an unrelated interface (for example wifi)?

here is a short description of the problem :

my network is only composed with two computers, one client and one gateway
linked with a simple ethernet cable. So, when the client computer is not
powered on, the ethernet network appears to the gateway as if it was down,
that's probably the reason why dhcpd fails starting on the gateway though ICS is configured.

Later, when the client computer is powered on by someone, it cannot get an IP address and access to the internet, since dhcpd does not run on the gateway : I have to start dhcpd by hand to solve the problem.

the proper behaviour, to avoid this non user-friendly operation, should be :
- either that dhcpd starts automatically as soon as the client computer is powered on (i.e. as soon as the local ethernet network is up).
- or that it is able to start even if the local network is down, so that it is always running

>So, when the client computer is not
powered on, the ethernet network appears to the gateway as if it was down
The interface status on the gateway should not depend on the presence of a peer on the network, that's your real issue. It should be up, and the dhcp server also, permanently. BTW, 'network down' is quite approximative terminology.

Also, if you have no reason to explicit restrict dhcpcd to eth0, don't do it. If MCC add uneeded crap in /etc/sysconfig/dhcpd, just remove it manually, and eventually report a bug against it.

Sorry for the approximative terminology, I'm just trying to explain things from the user point of view, but don't have enough knowledge to completely understand what's behind and use the right words.

Just to make sure I understand well what you say when you tell "It 'should' be up", do you mean that this is something that needs to be fixed on Mageia, or that I should fix it myself by using another local network implementation than a direct ethernet cable between my two computers (in other words, that Mageia is not supposed to support such an implementation) ?

About your last point, I'm going to clean /etc/sysconfig/dhcpd by hand and remove the restriction to eth0. If I can identify what in MCC put these three same lines it, I will report a bug.

There is no reason your local network shouldn't work. If your network interface is properly configured, it should be automatically activated at boot time, whether the other computer is plugged or not. You can check the status with 'ifconfig eth0'.

Now, if dhcpcd doesn't start while eth0 is up, whereas also configured to be started at boot time, there is a problem in your configuration, and that's ought to be fixed.

Given that this is connected directly with a cable (and not through some switch) it is indeed expected that the interface will be down thanks to ifplugd.

I believe there is an option to ignore link status on a given interface but forgot it.

MII_NOT_SUPPORTED=yes in ifcfg-eth0

you got it ! I made that change and now dhcpd starts on the gateway computer even if the client computer is powered off. Thanks !
By the way, does that option corresponds to some option somewhere in MCC ? If not, would it be harmless to alway set it by default in Mageia, so that not to have to modify the file by hand after each new Mageia fresh install ?

(In reply to comment #23)
> By the way, does that option corresponds to some option somewhere in MCC ? If
> not, would it be harmless to always set it by default in Mageia, so that not to
> have to modify the file by hand after each new Mageia fresh install ?

This option is the wizard to configure network cards : 
connection control -> advanced -> network hotplugging.

Thinking about it, maybe it makes sense drakwizard automaticaly adds this option to the NIC dhcpd listens : it is expected to not be configured in DHCP...

(In reply to comment #24)
> (In reply to comment #23)
> > By the way, does that option corresponds to some option somewhere in MCC ? If
> > not, would it be harmless to always set it by default in Mageia, so that not to
> > have to modify the file by hand after each new Mageia fresh install ?
> 
> This option is the wizard to configure network cards : 
> connection control -> advanced -> network hotplugging.
> 

Thanks for the tip ! Nice to see almost everything can be configured through GUI in Mageia...

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Ping!

It is very important for us to know whether this bug is still valid for Mageia 2 or for *current* cauldron (so from after Mageia 2 was released).

Please tell us. If you don't reply, we'll have to close this bug as old.

Actually, that was not a bug, but an expected behaviour.

Status: REOPENED => RESOLVED
Resolution: (none) => INVALID

Yes, I don't understand : the bug is already closed as invalid!