SOLVED Strange registration messages
When I want register a host, I’ve the following message before FOG presentation:
On the Lenovo ThinkCentre E73, I then have the following message (works with FOG 1.2.0) :
The others computers models I own works perfectly: Optiplex 390, 790, 3010 and 7010.
Thanks for your help
PS : FOG git version 6519
Wayne Workman last edited by
Following a discussion with @Sebastian-Roth, we finally found it!
The problem is the speed negotiation with the switch . I’ll update the firmware of the switches and make feedback.
Tom Elliott last edited by
@george1421 This leads me to believe this is NOT an 802.3az issue, but rather something else (STP that is improperly setup for Portfast? Switch module is going bad?
In my case of the 802.3az as the issue I DID see a delay in booting to PXE/TFTP.
So turning off green power has no impact. What happens if you disable auto speed negotiations at the switch? There is no doubt that these network adapters are trouble.
Did we ever have the OP boot using a commercial live distribution of linux to see if we have the same results as with FOS?
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…
@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).
@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).
Wayne Workman last edited by
@aruhuno Could also look through the firmware settings on the target host and disable low power sleep modes.
@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.
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?!
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??
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!
@aruhuno What if you do
ip link set eth0 upand wait for half a minute. LEDs coming up? Chat (right upper corner)?
@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 ethfrom 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 eth0or
/etc/init.d/S40network stop && sleep 2/etc/init.d/S40networkstart, 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.
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.
I have done several tests:
- use of another cable
- use another switch
- use another cable to another switch