MAC Adreses
-
@sebastian-roth and this behaviour is much like a bug, to register on an eth card at random. If you want to register olny one card, for sure is one that can communicate with the server(any other way your host will complain about not being registered at the next pxe boot - that is buggy). So in the register process we can call for example an arp -a with the IP addresses from the host, to know the MAC we are talking with … Is one method, and for sure not the only one. I am sure that we can know also from the host on which eth it is talking to the server…
-
I’m not sure I understand the issue.
You said the host IS indeed registered with the interface that receives the ip address, or at least that’s what I understood.
That said, the bootmenu uses the first 3 mac’s it finds, if it can find them. I don’t know what order those interfaces will come in from the bootmenu.
So it showing as unregistered seems a bit problemattic though how are we supposed to address it? We don’t know how mac’s a machine will have, and we try to grab the first three as I’m not aware of many machines with multiple lan mac’s.
Are you saying the host is not registered at all, or not registering with the mac address that’s actually got an IP address on it?
-
Here’s the basic premise of registration:
Boot into init’s
Attempt getting an ip address on any mac address that can communicate with the fog server. (If one nic cannot it will try to use another interface, while the one failing to communicate does receive an ip.)We assume, yes as that’s really the only approach we can take for this currently, that the first mac address sent (typically eth0) is the “primary mac”. This means that if eth0 was brought up, but is not the one that connects to fog, we still use eth0 as the “primary” mac address. The additional mac addresses should be sent with registration, though the registration script ultimately only cares about the primary mac for simplicity.
What happens if all mac’s associated with a host is attached to the host? Does it show as registered then?
Registering with the mac that will communicate with fog is the easiest mechanism (which is why disconnecting the non communicating NIC and then registering is working).
-
Also, is the bootmenu the only thing causing problems? Is this because the nic that’s not-communicating is the one actually booting to FOG? I guess I’m just fully trying to understand.
-
@tom-elliott no, I think you did not understand correctly I think:
So I perform registration. The first NIC’s MAC only is registered on server and i can see that the MAC is from the NIC that has not communication with FOG. It is on another VLAN and so… For that when I want to capture, at the next host boot the host is saying that it is not registered. Is that more clear now? It registers on server with a MAC which has nothing to do with our task and with the server
-
@theodor-scherer I still don’t think I understand. You have stated that machines are registering. If you disconnect the non communicating nic the host registers properly. If you leave it plugged in it’s not registering the host with the communicating nics MAC address.
I’ve tried explaining why this is the case. I don’t know what else to say or what to request to get the information.
I’ve also asked if you register all nics with the host, does the host show up properly?
I’ve also asked what nic is booting to fog? If it’s the nic that’s not communicating back to fog,this would explain why the host is showing unregistered.
-
Also I think you are not understanding what registration is doing.
When it sends the information to the server it’s sending all macs that it finds. The order the macs are sent is based on how it comes into the machine.
So a machine with two Ethernet cards might come up with: eth0 and eth1
When fog pulls the macs it pulls it in order. So eth0, eth1 would be sent.
If eth0 is the nic that’s not communicating it doesn’t matter. It’s just sending information it’s finding. You could work this by disconnecting the nic that doesn’t communicate to fog, or switch the ports around so eth0 is the nic communicating to fog.
Either way, this isn’t something we can fix with a simple arp as we need to know which nic is communicating to the fog server, not the fog servers MAC address.
This likely will not be addressed for 1.5.0 as we really are trying to get a machenism that doesn’t rely on the MAC address. While we could make this work, it would not be a simple thing, and would only be used for a very short amount of time.
-
@tom-elliott Hello, Tom. Sorry for yesterday, I was all day in a hurry and very pressed. I will take it again because I see it is hard to understand.
“You have stated that machines are registering.” - Yes, If I do the quick registration I can see on server in the list of hosts, that I have 1 host with a single MAC. But the MAC is from the eth0 which is not attached to the fog network. Eth0 has other purposes, another switch, Vlan, etc. (that maybe responds to your questions about what nic is booting fog). So I have the host registered on server.
But If I reboot (the host) after registration, in order to capture or something, on the host’s screen I have the message that “The host is not registered”. While it is on the server, but it doesn’t recognize itself, I think because the MAC registered which is eth0 MAC.
That’s the bug. I hope you understand now …Maybe I can add manually the eth1 MAC’s also, but this is a thing which must work on auto not to workaround with it.
In the end I do not Understand this: “I’ve also asked what nic is booting to fog? If it’s the nic that’s not communicating back to fog,this would explain why the host is showing unregistered.”
If the first nic is connected elsewhere, it cannot boot from it, so, of course it is booting from the second nic connected to Fog … Or maybe I don’t get the sense of the phrase …
Today I will try directly on one machine, I will skip the simulation on VM.
Thanks -
@tom-elliott said in MAC Adreses:
“> When it sends the information to the server it’s sending all macs that it finds.”
Sorry, I see only one MAC registered the one that has no connection with FOG. Are you sure that I must see them all, after quick registration?“If eth0 is the nic that’s not communicating it doesn’t matter. It’s just sending information it’s finding. You could work this by disconnecting the nic that doesn’t communicate to fog, or switch the ports around so eth0 is the nic communicating to fog.”
I cannot do that on all machines, they are embedded in some boxes, locked, etc. Neither to switch the ports … The Nics are different, and it must be that way. The nic for fog anyway is 1G and the other is 10/100. What I can do is manually add the MAC in fog server.“Either way, this isn’t something we can fix with a simple arp as we need to know which nic is communicating to the fog server, not the fog servers MAC address.”
I was referring to an arp from the server to the IP address of the host in the course of registration … As the host is sending data for registration - for sure the IP address is in the data, and the server is doing an arp on that. It maybe simple methods also. Only from host you can bet that the eth reported by ifconfig with a greater TX or RX is the one which was booted that will be very, very simple “This likely will not be addressed for 1.5.0 as we really are trying to get a machenism that doesn’t rely on the MAC address. While we could make this work, it would not be a simple thing, and would only be used for a very short amount of time.”
I have seen that 1.5.0 is out, this is good news. And I understand that you cannot do something so quick … For me the MAC was and is yet a great way to identify something in network, I am curious about what are you trying to do …
Regards, I will go for boot one of them now. -
@theodor-scherer you can set a network to boot across vlans. I don’t know your environment, but it is entirely possible for the eth0 to boot to fog, using iphelpers while also maintaining communication to the fogserver as unusable. How? When the boot file is loaded there’s an embedded script. It pulls that script from tftp as well. That script then tells your machine to reestablish dhcp. It will try to do this until it can reach your fog server, which your other nic might be coming up and giving the information we need to move forward.
The bug you are referring to is not a bug. It’s how the system works. It’s how it has worked for years. While I understand the problem you’re having, what I’m not understanding is how do we fix it? Yes we could fix it, but it really would take a lot of time.
The reason I keep asking which interface is booting to fog is because network booting is not the same as reaching a webpage. Is it the nic0 coming up and booting to fog pxe or the other nic?
How hard would it be to establish routes allowing nic0 to see the fog server? I guess what I’m asking is the problem at the boot menu or the actual wrong nic is associated to the host?
Is it possible to put the eth1 nic on your vlan, and have eth0 connect to the fog side? I understand that flipping a cable is difficult if a vlan is MAC address specific.
I want to add, that I’m sure others have seen similar issues in the past, what you’re describing is not something we typically see/hear about.
I understand you are saying fog isn’t doing it how you might expect. I’m just trying to say that you flipping a cable out is much simpler than us trying to find a nic, test all up nics to communicate to the server, gather only those macs that can reach the server, then register that. (This is the only time that would even be relevant.) what I’m trying to say is it may take a few days, weeks, hours, months (who knows) to make this adjustment, when it would take you literally minutes to enter the other macs you want associated to a host, or seconds to flip a cable.
-
Using an arp request from the server side could work, but could also prove to be inaccurate. An arp request from the server would only work if the machine commuticating to the fog server is on the same network segment.
For example:
Class C network…
192.168.1.0 network and 192.168.2.0 network can be configured to communicate to one another, but .1.0 would not be able to see Mac addresses of .2.0, and vice versa. So this approach would only work in self contained networks.This isn’t to say there’s not other ways the server could find this information, but I think making the client send their relevant macs would be the more appropriate solution. That said, however, relying on the MAC address for the identifier is proving to be extremely problematic with all the new machines coming without an onboard nic, and people using usb nics for pxe booting. The idea of the usb nic is that you can reuse it on many machines, making it more or less useless for maintaining a pool of your machines.using usb nics multiple times is cost efficient as you could buy 10 and us then on 100 machines. For fogs used, it is a bane to our existence lol.
-
@tom-elliott
eth0 has link in a network we have not rights to mess with. And no reason for that as we have an interface just for us.
eth1 has link in the fog network. We can boot from it, and we can do anything we want.“How hard would it be to establish routes allowing nic0 to see the fog server? I guess what I’m asking is the problem at the boot menu or the actual wrong nic is associated to the host?”
There is no way to mess with the lan connected to eth0. Of course the problem is that the registered MAC is the eth0’s MAC, and we boot from eth1, so that is the problem. The servers only register a MAC we don’t boot and spoke to. And we don’t want to do it.The vlans are not mac related but think at 2 networks where you have rights only in one, the other is a different thing, it just need to coexist. You can not modify, switch cables, etc. Do not insist anymore it is for anything else, other network, other dhcp, other all. And other switch and infrastructure. Fog has it’s infrastructure and it is connected to eth1 how I said. I will add in the end it’s MAC by hand. But for an app to insist to register and work only with a nic, just for existing and not to talk to a nic that has the connection to it, that is a bug, no matter how many years that app is working
I was working with FOG many years ago in XP time. It was and it is a great piece of work, but that is a thing I discover and it works bad, in this conditions, it can be replicated, and it may be a normal thing for one from now on, to have multiple interfaces that must not have a link with fog server. The app must not limit somebody to boot with the first, second or any other interface in order to work well … Otherwise is buggy … If I can add manually the correct MAC, and if it will work that way after, will be an workaround that not exclude the bug. -
I tried now on one real machine. After boot in the menu and chose quick registration I got this:
The PC is a celeron 533MHz.
Which is the recommended boot method for such a PC? Must I return at an old pxelinux?
It is better to open another topic maybe or staying here is good as are related?
Thanks -
@theodor-scherer I found this topic about PC’s with 128MB Ram. ( https://sourceforge.net/p/freeghost/support-requests/10/ )I didn’t think that RAM will be such a problem, it seems to be. So in the end somebody said that it is a version that rolls a bit over 60MB and that seems to be perfect. Which version of fog may be?
-
@theodor-scherer You can set the amount of ram space usable in FOG already.
FOG Configuration->FOG Settings->Expand all, look for ramdisk size or something.
I believe it’s set to 127000 as a default. (127mb) I don’t know what your ram size available is, but maybe that could help.
-
@tom-elliott So, I tried many values. If I set a lower then 100M value then even if the menu will load and memtest will work the rest of the menu options will run into kernel panic. The PC’s are Celeron 533/128MB.
In VM I tested with 220 MB RAM, 100 for the ramdisk, it works and that seems to be a minimum. So minimum requirement for a PC will be 256 MB :(. That is pretty much I think for the task of capture and deploy a PC. The registration anyway must be done by hand, so I did not test the quick registration requirement. May I change something and renounce at ramdisk? and work somehow as memtest mode? without ramdisk? Or use a network disk for loading what is possible?
Or there is an older version that is running by default with small memory?
thanks. -
@theodor-scherer The best luck you “might” have would be with 0.32. That said, this is a very uncommon thing we have to work with, so I’m still not sure that this is an init problem, but rather a kernel problem.
Can you try an older kernel? These being such old machines, I’m guessing they automatically load the bzImage32/init_32.xz files?
-
@tom-elliott yes, you are right it loads the _32 version. I tried to load many of the kernels i could from kernel updates, with no luck. The kernels and image seems to load fine, and the menu is ok. But after when it realy tries to work, running the commands for registration, or deploying (partimage), it crashes because lack of memory.
