Resgistration Issues
-
Also here is the full text behind the tcpdump command Sebastian provided. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue If you can narrow down your capture to the time you are trying to boot the client that would be helpful.
The pcap you provided did not give any intelligence to what is going on here. What I can tell is that your fog server is on one subnet and the pxe booting client is on another subnet. Also it appears your real dhcp server is also on another subnet from the fog server. It almost appears that you have a dhcp-relay service running on your vlan router and you are sending dhcp inform packets to your FOG server. Are you running dnsmasq on your FOG server? That is the only reason why I can think your router is sending a unicast dhcp inform and discovery packets directly to your FOG server.
-
@sebastian-roth So, this is my first time setting up a fog server, but apparently there used to be one that covered all our clients. It should work.
Both the server and the client are connected to the same switch already, would that matter as far as capturing the packets?
As far as the network, the DHCP server isn’t even in the same building. Sorry i didn’t mention that, i didn’t know it was important.
-
@george1421 You seem to understand the problem exactly. You are also correct that the server itself, the client, and the DHCP server are all on different vlans. This is important to the way our network is set up, and i really need this to be able to work across vlans. If it matters, i could move the fog server to the same vlan as the DHCP server, but the client absolutely will not be on that vlan.
I don’t think that the fog server is running dhsmasq, unless it automatically installed when i install fog.
ps -ef | grep dnsmasq
The above only shows the command itself. I’m not an expert (obviously), but i think it isn’t running. If there is something else you’d like me to check, just let me know. -
@cklemm I’m only working from the perspective of what is in the pcap file you captured.
Because we are dealing with broadcasts, and unicast messages, ideally we would like to see the fog server, dhcp server, and pxe booting computer on the same subnet so we can get an accurate picture of what is going wrong. We can get what we need captured in a round about way.
FOG WILL work in the setup as you described.
OK just to reconfirm, you did change the fog server IP address after FOG was installed? This is important since when FOS boots (custom linux that runs on the pxe booting computer), part of its network testing for dhcp is to try to communicate with the FOG server. FOS will report that it doesn’t have an IP address, but what is really happening is that it’s trying to ping the FOG server and its getting no response. So FOS assumes it doesn’t have a good network connection.
-
@sebastian-roth said in Resgistration Issues:
The best to go about this would be to capture the full traffic right at the client. You can either do this by configuring a monitoring port on the switch where you client is directly connected to. The other usually easier option is to grab an old network hub and connect that between your client and the network switch. Jack in another PC/notebook to that hub and you can capture all the network traffic being send forth and back from and to the client.
-
@george1421 I did not change the IP after FOG was installed. Is there something i can check that would show which IP FOS is pointing at so i can be sure that is correct?
@sebastian-roth Ok, i’m working on it. I’m finding it hard to get a working hub, but i’ll post here when i have it.
-
So i still don’t have the packet info from the hub, but i restarted the computer while it was hooked into the hub, and just for kicks i decided to try to register the client. It worked.
A month of restarting the client and as soon as i plug it into a hub of all things it works. Right now it is capturing the image (at least, i’m pretty sure that’s what it’s doing). Does that give you any information? it makes me think it is a network configuration issue. I’m still going to try to capture the packets, but i thought this was worth posting.
-
@cklemm Nice one! Don’t bother about capturing the network packets.
Read up on spanning tree and port fast settings. It’s either that or even possible EEE (ethernet energy saving stuff) or an Auto-negotiation issue.
-
@sebastian-roth Just an update, i was able to get this to work even in another building. Apparently this was a problem specific to the random old switch i was using to test this stuff. Thanks so much Sebastian and George.
-
@cklemm You are welcome and thank you for letting us know.