2 NIC in host problem (loops at sending discovery...)

[ch3i]

@Knut

Hi,

I’ve the same configuration in my school without problem. You have the problem only in full registration ?

Regards,
Ch3i.

[Knut]

No, this issue persists also when downloading or uploading an image if I register the computer either manually or via the workarounds I mentioned. I can also use the workarounds for imaging tasks.

What is weird is that if I just let it loop for a while (like 15 minutes) it sometimes ends up in the registration screen but other times it does not (did not try it with imaging). But if I use one of the workarounds it works as expected.

Thanks for your input, regards.

[cspence]

Noting this forum post on the git repo issues. I’ll take a closer look at how networking is handled. It would be good for us to handle multiple NICs more gracefully.

Thanks for reporting.

[ch3i]

@Knut Hi, sorry for the late answer… could you upload or download as a debug task. Just check debug after select upload or download.

[cspence]

I just pushed up a potential adjustment as commit 03c9451 on git. @Tom-Elliott is in the process of fixing a nasty bug on the portal. As soon as he finishes that, he’ll be able to get you an SVN to test out.

[Knut]

I did some more troubleshooting with @ch3i and we pretty closely determined the issue.

@cspence , I hope this provides sufficient information to fix this bug correctly.

NIC 1 (Network 1) has access to DHCP and the FOG server.
NIC 2 (Network 2) is completely isolated there is NO DHCP service.

When trying to run a task it loops into “Sending discover…”

The second card has no access to an IP whatsoever. (they are assigned static afterwards)
I set up a temporary DHCP server on Network 2 this completely solves the issue.
Network 1 and Network 2 have different network addresses.

So the issue seems that the host needs an IP address on all active interfaces or else the task loops at “Sending discover…”.
It is desirable for our set-up to not have a DHCP running on the second network, there isn’t much on this network anyway.

Thanks to you both for your support.

[Wayne Workman]

@Knut That is definitely an edge case…

[cspence]

I received word that the init images have been updated. A reinstall of the latest SVN will fix this problem.

I still highly suggest waiting for the next SVN to be released though. The bug that @Tom-Elliott is working on affects multiple NIC setups.

[Knut]

I just tested SVN 3553 on a different server, from what I can tell the issue seems to be solved for this set-up.
@cspence just to be sure, what SVN number can be considered the next SVN?

Really glad to see FOG is so actively maintained, thanks everyone!

[Wayne Workman]

@Knut

I think 3554 was pushed this morning.

[cspence]

The change that fixed the excessive DHCP timeouts was 3541. This may not be the most stable commit, but anything after that point will have it fixed.

[Wayne Workman]

Providing a link in this thread for future readers to a similar problem on a later revision: https://forums.fogproject.org/topic/5928/r4930-fedora-21-unable-to-ignore-mac-for-imaging