Could you try without the mdv plugin ?
you need to disable it in /etc/NetworkManager/NetworkManager.conf
After the modification it should be something like :
[main]
plugins=keyfile
you need to restart networkmanager
you can edit the connection settings using nm-connection-editor (it's available in networkmanager-applet rpm ).

If it's working with this setup it's probably more a bug in the ifcfg-mdv plugin support.

CC: (none) => balcaen.john

You're right on the nail, but it's the damndest thing I've seen yet.

Disabling the ifcfg-mdv results in hostname being set correctly.  However, the wireless connection does not come up.  There is no place else on my system where the correct hostname could be gotten (that's the point of having it supplied by DHCP), but if the link doesn't come up, how is it getting it ?

I guess there's something about ifcfg-mdv that is necessary for the connection to come up, but whatever it is, not having it doesn't seem to prevent the DHCP exchange that sets the hostname.

Hmm, I suppose I'm assuming that the panel icon showing the connection down is actually accurate.  It may be that part of what the plugin does is make the icon work correctly.  The network might actually have been up.  Having seen the icon, I was more interested in reverting the change and rebooting than in probing te accuracy of the icon.

(I suggest, if you haven't done so already, you report the issue upstream (i.e. to mdv since plugin is developed by them)).

Will do.  Thinking of MDV as "upstream", while accurate, will take some getting used to :)

In fact mdv is based essentially on the ifcfg-rh plugin so it would be nice to give a try on fedora for example to see if it can be reproduced too.
Also after using kompare between mdv et rh plugin there's no a lot difference (mdv seems to disable a lot of ipv6 related stuff and add some wifi specific functionnality ), so maybe it's possible to report to « real upstream ».

(In reply to comment #4)
> (I suggest, if you haven't done so already, you report the issue upstream (i.e.
> to mdv since plugin is developed by them)).

(In reply to comment #6)
> In fact mdv is based essentially on the ifcfg-rh plugin so it would be nice to
> give a try on fedora for example to see if it can be reproduced too.
> Also after using kompare between mdv et rh plugin there's no a lot difference
> (mdv seems to disable a lot of ipv6 related stuff and add some wifi specific
> functionnality ), so maybe it's possible to report to « real upstream ».

@ Frank
1. is the problem still there in current Cauldron or 1?
2. if so, did you report to MDV? If yes, please give the link

@ Frank @ John
3. and did anyone get a chance to do anything with John's suggestions in  comment 6?

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

The problem is still in Cauldron.

I really don't know enough about NM or its history with either MDV or RedHat to make a coherent bug report.  I was hoping whoever maintains NM under Mageia would deal with (whichever) upstream, since there would be little I could do besides relay responses.

(In reply to comment #8)
> The problem is still in Cauldron.
> 
> I really don't know enough about NM or its history with either MDV or RedHat to
> make a coherent bug report.  I was hoping whoever maintains NM under Mageia
> would deal with (whichever) upstream, since there would be little I could do
> besides relay responses.

@ Frank
At the moment, we don't have a maintainer for networkmanager

@ John Balcaen
Can you find time to help Frank with the upstream bug report?

Keywords: NEEDINFO => (none)

@ Frank

I've been looking in RedHat bugzilla, but after reading bug reports for a while, I get confused. Is your bug one of the following?

https://bugzilla.redhat.com/show_bug.cgi?id=719100
https://bugzilla.redhat.com/show_bug.cgi?id=706094
https://bugzilla.redhat.com/show_bug.cgi?id=706073

Keywords: (none) => UPSTREAM

It's probably the #719100.
Thought franck did not explicity wrote if he did test with the rh plugin, to know if he can reproduce with it or not.
According to the redhat bugreport it should has been fixed with the 0.9.2 nm version for the rh plugin, since franck was not able to reproduce the bug using the keyfile plugin.
Since blino did patch the rh plugin to respect the NM_CONTROLLED option in ifcfg- files, i expect it to be fixed too.

Regarding helping frank to report upstream, i don't know what i could do here : 
I don't have any dhcp server sending hostnames locally so not able to reproduce this bug, if the bug is supposed to be reported against the ifcfg-mdv than it's more probably a WONTFIX since this plugin is not maintained anymore, regarding the ifcfg-rh seems like there's already thoses bugs reported on the fedora's bugzilla,

@ John

Thanks :)

Closing, because I understand this bug was fixed.

@ Frank

feel free to reopen if I'm wrong

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

719100 looks closest, but I think these are all the same bug.  As an aside on some of the comments in them, DHCP can actually return a hostname, in which case that's what should be used.  Doing a reverse DNS lookup on the returned IP address should only happen if DHCP does *not* return a hostname, but the drakconnect box "use DHCP hostname or create one based on IP address" is checked.

I've been out of town for the past week or so, but I have a fresh install with NM enabled as per default ready to test my remaining NM issues.

I have finally gotten a fresh install to a bootable state, so as to be able to test this.  Unfortunately, NM is still unable to bring up the wlan0 interface, so I can't verify that this is fixed for certain.

However, NEEDHOSTNAME is no longer being reset to NO, so I assume the fix is working.

Well, no, it's not.  But I've found out a lot more about what is going on.

The RedHat bugzilla has several bugs, e. g. https://bugzilla.redhat.com/show_bug.cgi?id=706094 , which deal with this.  But the upshot of reading them is that the NM people think they're fixed.

It is true that NM is no longer changing NEEDHOSTNAME to NO.  But it's not clear that NM is paying attention to it.

The NM developers (Dan Williams) at one point were deliberately ignoring hostnames returned by DHCP because they thought that changing the hostname screwed up X applications like GDM.  Dan had put code in NM back in 2009 to set the hostname provided that neither /etc/hostname nor /etc/sysconfig/network had set it to anything other than localhost or localhost.domain, intending to mimic what the network service does.

However, the bug reports indicate that when NM sets the hostname, it issues a message saying so that I do not find in my logs.  However, I do find the following:

Oct 25 11:20:02 ftglap NetworkManager[807]: <info> (wlan0): DHCPv4 state changed preinit -> bound
Oct 25 11:20:02 ftglap NetworkManager[807]: <info>   address 192.168.3.101
Oct 25 11:20:02 ftglap NetworkManager[807]: <info>   prefix 24 (255.255.255.0)
Oct 25 11:20:02 ftglap NetworkManager[807]: <info>   gateway 192.168.3.100
Oct 25 11:20:02 ftglap NetworkManager[807]: <info>   hostname 'ftglap'
Oct 25 11:20:02 ftglap NetworkManager[807]: <info>   nameserver '192.168.3.100'
Oct 25 11:20:02 ftglap NetworkManager[807]: <info>   domain name 'griffin.treehouse.com'
Oct 25 11:20:02 ftglap NetworkManager[807]: <info> Activation (wlan0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...

which tells me that NM is most certainly cognizant of the hostname returned by DHCP.

Initially, I would boot, do a "hostname" and get the result "localhost.localdomain".  Then, I found this set in both /etc/hostname and /etc/sysconfig/network.  I removed the line in /etc/sysconfig/network, and deleted /etc/hostname altogether, and now I boot, do "hostname", and get the result "localhost".

I'm guessing that this is the result of rc.sysinit, which sets HOSTNAME to "localhost" if it can't get it from either of these two sources.

Incidentally, syslog indicates that drakconnect is creating /etc/hostname with this value (and probably /etc/sysconfig/network as well) with "localhost.localdomain", which it should NOT be doing, since "set hostname from DHCP" was specified.

So, it comes down to this.

There's nothing in the NM config files about localhost or localhost.localdomain.  NM recognizes that the DHCP server is returning a hostname.  The hostname ends up being set to something which looks very much like what rc.sysinit sets.

Either NM is not setting the hostname based on what DHCP returns, which is counter to what the NM developer seems to believe, but supported by the fact that no message appears in syslog to say that it's doing it, or else NM is setting the hostname and something in our distro is resetting it to what rc.sysinit set it to.

This is a real cramp, since I like to centralize all of my host info in DHCP and DNS.  Hosts get told by DNS what their hostname is, and if the IP address isn't a static one, DDNS is informed of the link between the hostname and the assigned IP address.

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

Please refer to the discussion in bug#7873 and bug#2160 and see if your problems with NM go away if you either allow GNOME (if you have it installed) to activate it or you install plasma-network-management under KDE, add it to your panel, and use it to configure your SSID.

For NM to handle wireless correctly, it needs to create SSID-specific files of its own by parsing the ifcfg files produced by drakconnect.  GNOME's nm-applet does this automatically, since it has no option to *not* use NM, but since NM isn't the default yet for other desktops, it doesn't happen automatically there.  

You'll need to install NM and let it start, and recreate your wireless interface with drakconnect specifying "Allow NM to control this interface".

Please test and post your results, as whether NM works for all the chips involved when it's properly configured will have a significant impact on how it needs to be handled for non-GNOME desktops in MGA3.

(In reply to comment #16)

n/a here

No action since over 2 yrs ago and still assigned to Bug Squad

Closing as OLD

Please reopen if this report is still valid for _current_ cauldron and/or fully
updated Mageia 4

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

I confirm that this has been fixed.  Several years ago, I worked around this by including 

[keyfile]
hostname=xxxxx

whenever I built a new system.  I just commented that out and rebooted, and got the DHCP hostname.  I no longer use the rh plugin, just the keyfile.

(In reply to Frank Griffin from comment #19)
> I confirm that this has been fixed. 

Thanks, Frank, changing Status to RESOLVED - FIXED, then :-)

> Several years ago, I worked around this
> by including 
> 
> [keyfile]
> hostname=xxxxx
> 
> whenever I built a new system.  I just commented that out and rebooted, and
> got the DHCP hostname.  I no longer use the rh plugin, just the keyfile.

Resolution: OLD => FIXED