Posts made by mageta52

@Wayne-Workman Thanks guys, I’ll try to experiment with these options, again, it will probably have to wait until next week. The schedule is insane right now.

@Wayne-Workman So, we run open dhcp on our main network. What I’m not sure about, is how to point that towards the fog server if a client is PXE booting and looking to connect.

@Wayne-Workman

Why do you limit it to only 2 at a time? Is it faster?

@Sebastian-Roth I’m afraid I have not gotten to imaging multiple clients at once yet, is it possible to image a bunch of them at a time using unicast? If so, what is the purpose of even having the multicast feature?

@Sebastian-Roth

Our engineer does not want the server on the core network. Apparently the switches on the core network are not set up to handle multicast and it creates issues.

I looked at the logs and it said that it wrote 44 leases to to the lease file, there should still be more than enough addresses. Not sure why it’s attempting to hand out 192.168.235.17 with each attempt.

@Wayne-Workman There is another DHCP server on that network, and per security requirements it’s not going to be allowed in the future.

@Sebastian-Roth

Alright, so here’s the deal with the arps for 192.168.235.1; That subnet is actually our production network. I installed FOG on that subnet, and then when I want to image I just put it on an isolated, unmanaged switch with the other clients. The gateway is still there though, so it continues to look for it, even when it’s not connected to the production network.

Regarding the DHCP issue, earlier in the week, I allowed the client machines to boot to their old Windows install, and they were able to get addresses just fine. If it was an issue of exhausting the pool, I should have seen it there. On Monday I can try this again to confirm. I can look at the logs as well to see if there is anything.

Will the logs show how many addresses are leased? Is there some place i can check?

@Sebastian-Roth 0_1463176833850_dhcp_fail.pcap

Never uploaded a file before, but there is my attempt, hopefully it can be salvaged.

This was 1) a successful connection from a machine, with full registration, then 2) unsuccessful connection attempt by second machine. Got hung up looking for a DHCP address.

@Sebastian-Roth I’m completely swamped at work this week, and have to abandon this for a while, but I hope to capture the data on Monday.

Once again, the same pattern, machine 1 gets through and can register, machine 2 fails and stalls out.

I’m not terribly familiar with Tcpdump, but it’s built in, so this is what I got from the second machine…

16:52:11.886022 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:14.893389 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: UDP, length 548
16:52:14.893609 IP 192.168.235.52 > 192.168.235.17: ICMP echo request, id 35325, seq 0, length 28
16:52:15.887222 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:15.894726 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:16.889224 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:17.891224 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:18.902506 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: UDP, length 548
16:52:18.902730 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:19.903230 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:19.903360 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:20.905230 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:22.911623 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: UDP, length 548
16:52:22.911836 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:23.912965 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:23.913229 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:24.915229 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:26.920739 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: UDP, length 548
16:52:26.920963 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:27.922086 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:27.923228 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:28.925225 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:30.929858 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: UDP, length 548
16:52:30.930083 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:31.931204 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:31.931234 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:32.933228 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:34.938973 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: UDP, length 548
16:52:34.939191 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:35.939229 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:35.939363 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:36.941229 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:38.948090 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: UDP, length 548
16:52:38.948310 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:39.949434 IP 192.168.235.52.bootps > 255.255.255.255.bootpc: UDP, length 300
16:52:39.951227 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28
16:52:40.953226 ARP, Request who-has 192.168.235.17 tell 192.168.235.52, length 28

It looks like it wants to assign 192.168.235.17, but is unable to. My guess is that the arp is to make sure that the address is not in use already, but I’m not able to figure out if that’s coming from the PC, or from the fog server? Unfortunately I lost the successful exchange with the first machine. The output got blown away by the data transfer during the machine registration. If more info is needed I can provide it. If there are any switches to turn on with tcpdump for better results let me know and I’ll run the test again.

@Sebastian-Roth I could try analyzing the traffic coming into the fog server during an attempted PXE boot to see what’s going on, I’ll report back in a while with the findings.

@Wayne-Workman So, I took the switch out of there and put in a different one; Trendnet TE100-S16, which is another unmanaged switch.

The pattern I’m seeing is that one host will make it through and get registered, then I move up to the next PC, and it fails to get through DHCP.

I’m not sure what the deciding factor is on whether or not they get through, but I’ve never had more than one get through consecutively

@Sebastian-Roth I checked the manual for this switch and the only mention of spanning tree is in the glossary. It gives no mention of the feature anywhere else, and I don’t think that a flat switch like this even supports it.

Looks like they’re running BIOS, not UEFI. The nic is an Intel NIC.

By modifying the boot file I get the same error for both of your suggestions.
“Waiting for link up on net0… Down (http://ipxe.org/38086101)
DHCP failed, hit S for pxe shell, rebooting in 10 seconds”

These are custom build 1RU’s with an Asrock Z97E motherboard.

The switch is a D-link DGS 1024D switch. I looked it up to confirm that it is indeed unmanaged

The hosts to be imaged all have a previous OS on them, so I can just boot them up and switch them to obtain an address automatically since they’re already hooked up to the server via the switch.

I tried /release /renew a couple of times on the machines that failed to get an address during PXE and they could both get an address when booted into windows. DHCP seems to be working fine.

So I went back to PXE booting, one of the hosts registered fine, I moved onto the next; failed at DHCP, same for the second host.

[root@localhost ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:13:20:04:2f:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.235.52/24 brd 192.168.235.255 scope global enp2s0
       valid_lft forever preferred_lft forever
    inet6 fe80::213:20ff:fe04:2f3d/64 scope link 
       valid_lft forever preferred_lft forever
3: enp4s2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 00:03:47:ad:c3:61 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:62:65:da brd ff:ff:ff:ff:ff:ff
    inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr0 state DOWN group default qlen 500
    link/ether 52:54:00:62:65:da brd ff:ff:ff:ff:ff:ff

[root@localhost ~]# cat /etc/dhcp/dhcpd.conf 
# DHCP Server Configuration file\n#see /usr/share/doc/dhcp*/dhcpd.conf.sample
# This file was created by FOG
#Definition of PXE-specific options
# Code 1: Multicast IP Address of bootfile
# Code 2: UDP Port that client should monitor for MTFTP Responses
# Code 3: UDP Port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
option arch code 93 = unsigned integer 16;
use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
# Specify subnet of ether device you do NOT want service.
# For systems with two or more ethernet devices.
# subnet 136.165.0.0 netmask 255.255.0.0 {}
subnet 192.168.235.0 netmask 255.255.255.0{
    option subnet-mask 255.255.255.0;
    range dynamic-bootp 192.168.235.10 192.168.235.254;
    default-lease-time 21600;
    max-lease-time 43200;
    #option routers 0.0.0.0
    #option routers 0.0.0.0
    next-server 192.168.235.52;
    class "Legacy" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
        filename "undionly.kkpxe";
    }
    class "UEFI-32-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-32-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
        filename "i386-efi/ipxe.efi";
    }
    class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
        filename "ipxe.efi";
    }
    class "UEFI-64-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
        filename "ipxe.efi";
    }
    class "UEFI-64-3" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
        filename "ipxe.efi";
    }
}

I’m sorry, I forgot to post the results! No it still is not working.

If I let the hosts boot into their old OS, I am able to ping the FOG server, so I don’t believe there is a physical communication issue happening.

Checked cables, found a mix of crossover and straight through. Should all be straight through, so I took out the ones that were crossover and verified that their replacements were indeed straight through.

Dhcpd is active and running

firewalld is inactive

selinux is disabled

Fedora workstation 23, FOG trunk rev 7272