MAC Adreses
-
Hello, I am back to FOG after a long period of not using
Now, I have a network of some old PC’s each with 2 NIC’s. The first one is reserved for things like internet and other inside comms, and that network iface will be inaccessible for me, but the second card is accessible for things like FOG. So when I try to register the host, at reboot will say that host is not registered because only the first card’s MAC was registered with the host. I think the normal will be to register the MAC with the server works, and not the first MAC of any order … What do you say, it is hard to implement that? Or maybe to register all the MAC’s indifferent of the state of connection or the order of connection?
Regards and Thanks -
@theodor-scherer what version of fog are you running? Fog will try the first three Mac addresses it sees now. While there is still a primary MAC address, the fog client will send any MAC address it finds and as long as one of those match that approved to a host it will work. So knowing a bit more information will help us help you.
-
I am running the last 1.4.4. It register only one (the first). So after registration when I reboot I see on WebIf only one mac, and the host says it is not registered. No way to capture. If I disconnected the first NIC, and re-performed the registration, it happens with the correct MAC, so all is good. But normally it must work from the start registering the MAC that is used to boot with. Don’t you think so? for now I am not using the fog client, is out of the scope. In the end all I need is only capture and deploy some old WinNT 3.5 systems. My test setup now is for the server an Ubuntu server 16.04 VM with fog 1.4.4 and I use, for testing capture and deploying, another VM with an Ubuntu image. Of course with 2 NICs one in the first VLAN and the second in the Fog’s Vlan. But in the end the real machines are some celerons 533 with Win NT 3.5. May I expect some boot problems on those machines? How can I simulate best those in VM? I use Proxmox as Hypervisor.
Thanks
-
@theodor-scherer It’s not easy for us to diagnose those kind of issues as it seems to be an unusual behavior and we don’t have your hardware available to test and verify. But I’ll try to answer some of your questions.
When registering a machine the FOS system uses Linux commands to gather information like network interfaces and MAC addresses. So we depend on the Linux kernel telling us the NICs. NIC enumeration is not always “in order” (e.g. read here) and for FOG as PXE booting environment it’s kind of impossible to reliably handle this with the concept of “primary MAC” being the key to identify machines (as registered). We are working on changing this behavior. As of now with FOG 1.4.4 there is no easy solution I am aware of other than disabling one of the NICs.
-
I think it may be much more simple… In order to do registration, the host is sending to server the data … So the IP or the MAC from where the registration data comes identify the machine for the server. It is normal … generally that’s the address we want to have … sure the rest of existing eth cards, wireless or other thing maybe they are interesting in particular cases, but the in the most cases we register machines with the interface we want to have it registered … I think so, is it not?
-
@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.
