Strange registration messages

[aruhuno]

@Sebastian-Roth
I’ve updated FOG this morning:

@Sebastian-Roth said:

Edit: Found an interesting parameter for the udhcpc. Tom added it to the inits. You might want to upgrade and run the installer again to get the latest inits. This might possibly fix things for you…

So, I’m making init with updated script

@Wayne-Workman said:

@aruhuno Just an FYI, the E73 is in our working hardware list: https://wiki.fogproject.org/wiki/index.php?title=WorkingDevices

On FOG 1.2.0, yes, but not on 1.3.0 and I need it to deploy Windows 10 with FOG Client.

[george1421]

@aruhuno The devs worked on the init scripts over the weekend. Since you just upgraded to the current trunk release, does the network interface come up when you try to register this Lenovo today?

If the updates inits do not work. Could you repeat the same steps from earlier with this modification?

Use this udhcpc command
udhcpc -i eth0 --now

Then when the command times out (or better picks up an up address)
cat /sys/class/net/eth0/carrier

If the carrier value is still 0 wait 30 seconds and issue the udhcpc command again. What they were looking at is to find a way to detect if the network adapter has a slow startup. They are working hard to find a way to get these network adapters to init right.

[Wayne Workman]

@aruhuno said:

On FOG 1.2.0, yes, but not on 1.3.0 and I need it to deploy Windows 10 with FOG Client.

What I meant was if it worked before, we can get it working again.

[aruhuno]

@george1421
Sorry for the wait. This morning, I’ve updated FOG (now in 6651) and problem persist:

@Wayne-Workman
I hope so.

Even if it’s not finished, thanks everybody for the help!

[george1421]

@aruhuno That is disappointing the 30 second delay between the first dhcp request and the second chance request did not resolve the issue.

One last request if you still have this setup (as you have pictured), its probably been several minutes now sitting at the second chance dhcp request. Would you please try one more time for the udhcpc command? If it does not come up after 5 minutes the network link will never come up and we are back to a linux driver issue why this interface is not becoming ready.

I do have to ask this just to eliminate the obvious. “Can you plug another known good device into the network cable to check to see if the cable or network port is defective?” I doubt this is the case since you are getting into the Fog Operating System.

[aruhuno]

@george1421

I have done several tests:

• use of another cable
• use another switch
• use another cable to another switch

[george1421]

Well you have done as much as possible. I think the developers are going to have to look into the realtek driver and how its being activated. There seems to be something missing in the FOS client.

[Sebastian Roth]

@aruhuno This looks like the interface is not coming up at all?!?! In your posts last week you were able to somehow get it up/working simply be running udhcpc -i eth from the shell!!

After new test, when I’m run in debug:

• NIC is on everytimes
• ifconfig no IP
• ping no response

If I run udhcpc -i eth0 or /etc/init.d/S40network stop && sleep 2/etc/init.d/S40network start, everything is working.

So something must have changed I suppose… Please take a look at your older postings and see if you can reproduce what you had back then.

[aruhuno]

@george1421
Perhaps, but as @Sebastian-Roth points out , last week I could go up the interface with the udhcpc command.

@Sebastian-Roth
I’ve already tested and impossible to reproduce, something has change (script? kernel?).

[Sebastian Roth]

@aruhuno What if you do ip link set eth0 up and wait for half a minute. LEDs coming up? Chat (right upper corner)?

[aruhuno]

With the help of @Sebastian-Roth, it works!

I had actually tried other switch but had not returned to the original swith (the one I was at the opening of this topic).

Solved by mini-switch and the new init script, thanks all!

[george1421]

Interesting, so this “could be” what Tom talked about 802.3az (green ethernet) issue? http://www.excitingip.com/2534/an-introduction-to-ieee-802-3az-energy-efficient-ethernet/

Putting a dumb mini-switch in between the building switch and the target device broke (blocked) so the target goes into active mode. This is only speculation. I wonder if there is a command switch to turn this “feature” off when we init the network adapter??

[Sebastian Roth]

@george1421 said:

Putting a dumb mini-switch in between the building switch and the target device broke (blocked) …

Actually it was the other way round!! We couldn’t get the NIC up (LED stayed off) whatever we tried. Then I suggested to put a mini switch in between. And that made it work right away! What is really strange about the whole thing is that iPXE (as well as PXE ROM) can actually bring the NIC up, send packets and receive an IP… Only the kernel seams to have an issue when bringing up the NIC. But as soon as you use dump network equipment it seams to work. I still wonder if this is related to spanning tree or something else?!

[george1421]

@Sebastian-Roth No I still think I’m thinking right. On the house or building switch you could not wake up the port. If the nic and the building switch support 802.3az then they will negotiate a low power mode. But if you plug in a switch that doesn’t support 802.3az the discussion will end and the port will remain in high power mode the whole time.

[Wayne Workman]

@aruhuno Could also look through the firmware settings on the target host and disable low power sleep modes.

[Sebastian Roth]

@george1421 I do understand what you are saying and it sounds logical to one end. But why does PXE boot work ??? Well PXE ROM ok (BIOS magic) - but iPXE ???

Edit: Hmmm, maybe I am looking at it the wrong way round. Possibly the kernel r8169 driver actually is 802.3az/EEE capable and puts the NIC in power save mode. Sorry if that’s what you meant all the time. Didn’t get to my mind until now. There is EEE mentioned in comments a couple of times in that driver - but not very obvious looking to me. Maybe it’s in the firmware files (closed source).

[george1421]

@Sebastian-Roth The only thing I can think is that iPXE is not that smart to support 802.3az protocol but the 4.x linux kernel drivers are. That may explain while the older linux kernels worked on this box (because they did not support this feature).

[aruhuno]

@Wayne-Workman
This is disabled since Tom to me suggested in a previous post.

@Sebastian-Roth
Unfortunately, as I said yesterday , Spanning Tree is active on all switch ports:

[Sebastian Roth]

@aruhuno See my chat messages! For further references and other users: Check out your switch manual! In case you have the same DELL switch take a look here (search for EEE - e.g. page 499). Thanks Tom for pointing this out and George for bringing it up again so I understood as well…

[Sebastian Roth]

Playing with the switch settings it seams to be the auto-negotiation that is causing the problem in this case. Disabling EEE on the client port did not help unfortunately. Then I remembered reading about auto-neg issues here, here and here. Some have less speed and some have no connection at all. Those NICs are not my friend I suppose!

@aruhuno Please check your cabling again! This might help but I am not sure…