FOG server with dhcp client registration

[Pikmin]

I was trying BIOS first, then I thought I try UEFI, same issue with both

I am using the internal adapter yes.

I get an ip address in Windows from the fog isc-dhcp-server

First time I configured fog I used a router address of 192.168.158.1 but since that ip isn’t valid I removed it, also not using dns since not connected to Internet after initial configuration
server ip 192.168.158.68
client range 192.168.158.100-254

[george1421]

@pikmin so just to be sure, your fog server is 192.168.158.68?

If that is the case, the error is actually in the dhcp up check.

[Pikmin]

@george1421 server is 192.168.158.68 assigned statically
EDIT: I’ve picked the debug option and tried to get an ip manually which worked and I can ping 68

[george1421]

@pikmin Sorry I had to step away for a moment. The issue is in the url being called. It doesn’t appear to be structured correctly. note the // in the url path. Unsure your fog settings look similar to this

[Pikmin]

@george1421 No worries at all

I thought the second / was a problem until I saw it elsewhere on the forum, appears to be normal, could be wrong.

In any case the Web server settings look exactly like yours

So the issue is not being able to get an ip address from the server but not being able to access index.php

When I try to wget http://192.168.158.68/fog/index.php it works from a Linux laptop fine but from the debug console in fog I can’t get to it
wget 192.168.158.68/index.php however does work

[george1421]

@pikmin

Just a second you can get to index.php I see that but that is in the root of the apache directory. You have two different test conditions

wget http://192.168.158.68/fog/index.php no go

wget 192.168.158.68/index.php works.

I’m not disputing there is a problem here, I’m just not sure why/where it it. There is a url path off some place.

edit: I just confirmed that index.php exists in /var/www/html and in /var/www/html/fog directories.

[Sebastian Roth]

@george1421 Though the // isn’t nice and might be confusing - that’s not an issue.

@Pikmin To me this sound very similar to what we had just a couple of days ago here: https://forums.fogproject.org/topic/11093/resgistration-issues (read through all of it and take a look at the pictures!
Try using a mini switch to connect between client and your network - see if that makes it work.

[george1421]

I did not ask this and I probably should have before now. What version of FOG are you using? The latest doesn’t tell us much of anything.

[Pikmin]

@george1421
Thanks for that, yeah not quite sure what’s going on
It appears when I wget http://192.168.158/test.php it downloads a file even though it doesn’t exist and the file contents are that of index.php
I see a link in /var/www/fog pointing to /var/www/html/fog
Compared the 001-fog.conf from apache to that of a production server here and appear identical, other than having ssl on one and http on this test server
Will report back if I find anything
Why is it detecting a . in wget I wonder

[Pikmin]

@george1421 said in FOG server with dhcp client registration:

I did not ask this and I probably should have before now. What version of FOG are you using? The latest doesn’t tell us much of anything.

My bad,
1.5.0-RC-10
SVN Revision: 6080

[Pikmin]

@sebastian-roth said in FOG server with dhcp client registration:

@george1421 Though the // isn’t nice and might be confusing - that’s not an issue.

@Pikmin To me this sound very similar to what we had just a couple of days ago here: https://forums.fogproject.org/topic/11093/resgistration-issues (read through all of it and take a look at the pictures!
Try using a mini switch to connect between client and your network - see if that makes it work.

I was using a cisco switch with a default config, so no vlans, nothing, tried with a dumb tplink, same thing.
It does look very similar after seeing the pictures attached

Is it worth mentioning that I have a proxy server at work, so when I was originally configuring the fog and downloading packages I have a few exports for git, apt.conf and wgerc so I can get to the Internet.
None of these appear to be on the fogclient

I’ve manually registered the client from the web interface and tried to capture the image that way but same error when it tries to start
I wasn’t paying attention, from the web it failed because Windows wasn’t shutdown or hibernation, testing that now, it’s up to the Resizing Filesystem… so might work
I’d still like to know why it’s failing through quick registration so I will try and upload the pcap file

I’ve also enabled portfast on all the ports

[Sebastian Roth]

@Pikmin I don’t like guessing much so we should just take a look at the facts - the packets on the network that is. So get your client ready but don’t start it yet. Go to your FOG server and install tcpdump (sudo apt-get install tcpdump or sudo yum install tcpdump). Then run the following command and substitute x.x.x.x with the client’s IP address: tcpdump -w /tmp/boot_issue.pcap host x.x.x.x

Leave that command sitting there, boot up the client till it shows the error “Either DHCP failed or …”. Now stop tcpdump (Ctrl+c). Upload the generated file /tmp/boot_issue.pcap to your dropbox/google drive and post a link here or send me a private message if you don’t want to share this with the rest of the world.

[Pikmin]

@sebastian-roth said in FOG server with dhcp client registration:

@Pikmin I don’t like guessing much so we should just take a look at the facts - the packets on the network that is. So get your client ready but don’t start it yet. Go to your FOG server and install tcpdump (sudo apt-get install tcpdump or sudo yum install tcpdump). Then run the following command and substitute x.x.x.x with the client’s IP address: tcpdump -w /tmp/boot_issue.pcap host x.x.x.x

Leave that command sitting there, boot up the client till it shows the error “Either DHCP failed or …”. Now stop tcpdump (Ctrl+c). Upload the generated file /tmp/boot_issue.pcap to your dropbox/google drive and post a link here or send me a private message if you don’t want to share this with the rest of the world.

I just went through the process of doing this when I discovered that after issuing spanning-tree portfast on all the interfaces it appears to be working now, so that’s the solution like in the other thread.
Thanks again for all your help george1421 and Sebastian Roth, I won’t forget the porfast setting ever again