Created attachment 2196 [details]
Wireshark capture log

This is probably what causes it to fail the connectivity test when setting up the network on the Summary page too. Nice find Derek :)

Created attachment 2200 [details]
More complete wireshark log

Here is a better wireshark log filtered on mac address so we can see the full DHCP exchange.

At line 3 the DHCP server offers the IP address and declares the DNS server to be 192.168.1.254

The Mageia installer ignores the DNS server and tests the connection by sending a DNS request to 127.0.0.1

At 77 seconds the connectivity test times out and the user tells the installer to continue, which the installer does by making a correct DNS request to the DNS server already declared.

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

A bit more information to help with debugging.
While the network test is in progress /mnt/etc/resolv.conf contains the correct DNS server address.  /etc/resolv.conf does not exist.

If I symlink between the two and repeat the network test it still fails. It is still trying to use 127.0.0.1 as the DNS server
However a 'ping' on the command line works with the symlink in place.

As far as I can tell with my appalling perl skills, the test is initiated in /usr/lib/libDrakX/network/netconnect.pm  line 329  but I do not see what is wrong. It simply calls a subroutine which runs
gethostbyname("www.mageia.org")

Created attachment 2230 [details]
Test script

OK I think I understand where the test is going wrong.
I read in a perl forum that gethostbyname() only reads /etc/resolv.conf once per process so if resolv.conf is not present when the test begins, writing it later is not going to help.

I verified this with the perl script test1.pl attached. If I run it on my desktop computer with perl test1.pl  and while the test is running rename /etc/resolv.conf then at the end of the test I can see the results are all the same regardless of changing the contents of resolv.conf

As far as fixing this bug is concerned problably all that is required is to copy /mnt/etc/resolv.conf to /etc/resolv.conf so the test works on the first pass of the loop.  A better fix might be to copy resolv.conf over, and then in the loop make a system call to ping instead of gethostbyname

Unfortunately I cannot try out any fix because I cannot write to the squashfs used in the installer.

Yes you can:
See https://wiki.mageia.org/en/Drakx-installer_tips_and_tricks#modifying_the_stage2

Thanks for that. Very useful

drakx-in-chroot skips the network setup stage, but I have managed to set up a VBox with a  patch-oem.pl  file in the iso image.  I should be able to try out a patch now :-)

Created attachment 2235 [details]
Patch File

patch-oem.pl file attached

This works for me.

If the DNS server is unavailable or ping fails then it times out as before after 60 seconds.  If ping succeeds then the user gets a success message. 

If drakx-net is being run after installation it uses gethostbyname() as previously. (Probably not necessary but I wanted to avoid any regression)

Created attachment 2238 [details]
patch for drakx-net

Created attachment 2239 [details]
can you check this patch works as well?

Confirming patch in attachment 2239 [details] works OK
It also fixes bug 4958

There is a very similar and almost certainly related bug for which I have just raised bug 5830.

I tried this patch without the if $::isInstall statement to see if it fixed 5830 but it did not so I have raised a separate bug report.

Fixed in SVN

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

This is not a proper fix, since it won't work from behind firewalls.

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

We should keep the previous check, and maybe run res_init() before.
There is a commented res_init call in drakx-net, I'll check history.

Fixed in drakx 4459 and drakx-net 4460, both will need to be released though.

Tried out drakx-net-1.12-1mga2
Sorry it does not fix the standalone error Bug 5830,  nor does it fix the installer.

At the end of the installer network test a window pops up saying that c::res_init() cannot be found.

In the standalone network test there is no alarm from perl, but the test does not pass. If I apply the patch in attachment 2269 [details]  the test passes.

Back to ping?
FWIW the subroutine check_link_beat() does precisely the same ping test. (But using Net::Ping which also does not work in the installer)
 
While many firewalls will block an incoming ping, I have never heard of one blocking outgoing pings.

Olivier I just want to check I applied your patch correctly in the installer.
I can only patch the installer with a patch-oem.pl file

The patch file I used was :-

use network::tools;

package network::tools;

undef *connected;
*connected = sub {
                c::res_init();
                gethostbyname("www.mageia.org") ? 1 : 0;
}


Correct Yes?

It's not.
It rely on an updated c module.
You need to test latest stage2 image.

I have put mdkinst.sqfs onto my iso from drakx-installer-stage2-14.21-3.mga2
On the command line I can see the res_init() command in tools.pm so I am confident I have used the correct file.  

When I run the network test in the installer I do not get the alert I saw in Comment 18 so I assume it is finding res_init() OK. However it still does not work. 
Wireshark confirms it is still using 127.0.0.1 as the DNS server.

Ok. The problem is because /etc/resolv.conf still does not exist.

If I copy /mnt/etc/resolv.conf to /etc/resolv.conf  then the test passes.

Created attachment 2303 [details]
write resolver conf in both chroot & installer root

blino we need to update installer conf as well

I put attachment 2303 [details] into a patch file, but it did not make any difference.
The patch file loaded without any errors, but resolv.conf is still not written.
I then put a log message into the patch to confirm the code was being executed and the log message did not appear in ddebug.log.

So either I have implemented the patch file wrong, or write_resolv_conf() is not being called at this point.

Attachment #2303 [details] is a patch againt SVN, to be commited in, not a patch file for drakx which would need undefine then re-define the function

Created attachment 2308 [details]
live patch for drakx

In order to live test, you would need sg like this

I should have made Comment 25 clearer. I had made a patch-oem.pl file which was identical to your attachment 2308 [details].

Just to be sure I have tried again using attachment 2308 [details]. Same results.
/etc/resolv.conf is not written.

Created attachment 2309 [details]
symlink chrooted /etc/resolv.conf into installer

so we're back to this, then

Created attachment 2310 [details]
Working patch

Almost, but not quite.
The symlink has to be made before the res_init()

The attached patch file works OK for me

Attachment 2309 is obsolete: 0 => 1

Thierry, Can this bug be closed yet?  I have not seen a commit in SVN.

(In reply to comment #31)
> Thierry, Can this bug be closed yet?  I have not seen a commit in SVN.

It's still failing in all of the latest iso images, so it should
not be closed.

CC: (none) => davidwhodgins

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

This bug is in the installer. It is therefore no longer possible to fix it for Mageia 2, so I am leaving it assigned to Cauldron.

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

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

CC: (none) => paiiou

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

OK, after reviewing, on second though, this is fine.
Commited in git.

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