@george1421 the amount of machines vary based on what classrooms are not in use, so it’ll range from 2-300 machines based on how large the classroom’s break is.

@sebastian-roth I apologize again they have had me bouncing around all last week so I haven’t had a change to test the
–retries-until-drop option yet. I’ll report back this morning about what I find.

Oh lord I see what I may have done wrong, I need to remove the retries. Let me try this again this morning.

@sebastian-roth the campus has multiple DHCP servers so I am not completely sure, but we use Infoblox as a means of applying settings across networks.

@george1421 I have not yet, unfortunately my office flooded last week so I am just now getting back in. I will attempt to get it today.

@hammett131 the problem occurs when downloading the image from the fog server.

@hammett131 said in UEFI PXE not downloading ipxe.efi file:

@zacadams I have had a few issues with ipxe.efi file boot a couple options I have found one @george1421 already mentioned updating the bios helped but I also legacy booted with an undionly.kpxe and then have it download the uefi image then before it tries to boot into windows change back to uefi. I know it’s alittle annoying but it did work for those that even when I updated the bios was having an issue. (and where I work quick turn around is more important then spending along time on imaging)

So you are saying I should try to boot with undionly.kpxe in UEFI?

I am trying to UEFI PXE boot an Optiplex 7010 and have already changed the boot file from undionly.kpxe to ipxe.efi in the DHCP sever settings. When booted the machine shows:

Start PXE over IPv4.
Station IP address is 129.120.251.101
Server IP address is 129.120.123.171
NBP filename is ipxe.efi*
NBP filesize is 0 Bytes
PXE-E23:Client received TFTP error from server.

I have ran a tcpdump on ports 67,68,69, and 4011 from the FOG server and have included that on this post and have successfully been able to do a TFTP get on the ipxe.efi file from my own machine. Any ideas on what is going on?

@sebastian-roth ok after fixing my error to the multicasttask.class.php I ran the 3 tests you suggested

• do not turn off any of the clients to see if it still is reliable

• pull the network cable of one of the clients while multicast is on for 5 seconds - see if that is enough for it to be dropped already

• turn off one of the clients while multicasting and see how long it takes for it to drop

During the first test, multicast worked normally and the new argument added to multicasttask.class.php was reflecting in the logs. During the second test pulling the network cable did not appear to drop the disconnected host, but upon plugging the network cable back in the session returned to normal speeds. During the last lest of powering a client off during a session, the multicast session came to a near halt and is only transferring at around 100 MBpm. I’ve left the session going all night and the session is still active and moving at the throttled pace.

Oh lord I see what I may have done wrong, I need to remove the retries. Let me try this again this morning.

@sebastian-roth to line 421 I have changed to:

$buildcmd = array(
            UDPSENDERPATH,
            (
                $this->getBitrate() ?
                sprintf(' --max-bitrate %s', $this->getBitrate()) :
                null
            ),
            (
                $this->getInterface() ?
                sprintf(' --interface %s', $this->getInterface()) :
                null
            ),
            sprintf(
                ' --min-receivers %d',
                (
                    $this->getClientCount() ?
                    $this->getClientCount():
                    self::getClass('HostManager')->count()
                )
            ),
            sprintf(' --max-wait %s', '%d'),
            (
                $address ?
                sprintf(' --mcast-data-address %s', $address) :
                null
            ),
            (
                $multicastrdv ?
                sprintf(' --mcast-rdv-address %s', $multicastrdv) :
                null
            ),
            sprintf(' --portbase %s', $this->getPortBase()),
            sprintf(' %s', $duplex),
            ' --ttl 32',
            ' --nokbd',
            ' --nopointopoint',
            ' --retries-until-drop retries 100',
        );

This has been done to the main fog server and the fog storage node that will be performing the multicast session. The udp-sendercalls did look different in the logs as well.

@sebastian-roth that did not appear to do anything.

@sebastian-roth I apologize again they have had me bouncing around all last week so I haven’t had a change to test the
–retries-until-drop option yet. I’ll report back this morning about what I find.