Testers

@3mu Will you show us a screen shot of the fog configuration->multicast settings page. I’m confused where its getting the dev name from. You don’t have the network interface setup as /dev/ens3 for some reason?

@3mu said in Wiki errors - "Troubleshooting a multicast":

still reporting “–interface dev”

When you start a multicast stream, on the linux server console run the ps command to look to see what the running image is saying. ps aux|grep udp-send See if the running command also has the incorrect interface.

Now there is also a multicast service that is running in the background too that may be holding onto the value when it was started. But you said it was set correctly in the fog settings to begin with???

There is also in the storage node configuration for the master node, it also calls out an interface. But, the mutlcasting should be using the one from the fog configuration, I believe the storage node is only used for bandwidth calculations.

@anon01013 The pcap doesn’t match what should have been captured. Its not possible to generate this pcap from the screen shot you provided.

Hint if you reply to my posts, the forum will ping me when you post.

@anon01013 Sorry I didn’t see this til now for some reason. Let me have a look.

Some of your post is not clear so I have a few questions.

1. You have ~40 computers that are M92p.
2. They are all the same model?
3. If they are all of the same model, do I read some work and some no?

General observations
Lets make it clear PXE booting is a separate process then booting into windows. So having windows 7 or windows 10 have no impact on PXE boot up.

If you have both bios and uefi computers on your network, your dhcp server must be configured for dynamic boot file names. If not and you have a static dhcp option 67 you can either boot bios or uefi computer. If you need to boot the other, then you will need to update dhcp option 67.

Since you mentioned Lenovo computers, I would suggest that you upgrade the computers to the latest bios release. This will do 2 things for you: 1. We have seen some very bad early release bios on Lenovo computers. Updating the bios usually corrects random behavior. 2. You will then be sure that you are on the same bios version so if one computer acts bad we can rule out the bios as the cause. Right now if your bios is all on different versions one version may work and the other not.

Lastly, on your network switches, make sure you have one of the fast spanning tree protocols enabled (portfast, RSTP, MSTP, fast-stp). Where you will see the problem is with pxe booting, where pxe booting will work and ipxe gets running on the target computer, but iPXE can not get an IP address. Or if you get past iPXE when you boot into imaging it won’t get an IP address. You can test if its a spanning tree issue by placing a dumb (cheap, unmanaged switch) between the target computer and the building network switch. If that dumb switch fixes the problem then its probably a spanning tree issue.

There are a couple of things here.

1. By default pfsense sets up the dhcp server on the LAN interface and not the WAN.
2. Also in the network booting section on pfsense you will need to setup the uefi boot file of ipxe.efi if you want to pxe boot uefi based computers.

The error in the bios boot screen is a bit telling. Run through the following tutorial and capture a pcap of the pxe booting process. If you want to look at the pcap your self, transfer the pcap from the fog server to a computer with wireshark installed. Look at the second packet the one that has DHCP DISCOVER. In the ethernet header it will list the boot server and boot file name. My bet one of those are wrong. If you don’t know how to read wireshark post the pcap here and I’ll look at it for you. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@3mu said in Wiki errors - "Troubleshooting a multicast":

I’m not saying this is the issue, but I would remove any special characters out of the file name. While the dot is a legal characters for both http and linux, I would still remove that out of the name. The simplest way is to go into the linux console on the fog server and use the mv command something like mv /images/T500Linux19.10desktopclean /images/T500Linux19-10desktopclean then go into the web ui and image definition and update it there.

How many systems are you going to image at one time? A single subnet is good. That eliminates a lot of the issues. Its possible that unmanaged switch will cause us a problem (not being fast enough to send the data out to multiple ports at the same time). We can do some debugging by putting the target computer into debug mode then load udp-receiver and then issue the udp-sender command from the fog server.

I also noticed that you need to FIX your interface settings in the fog configuration->FOG Settings page. Your interface is dev that’s not right. You need to get the network name of the ethernet interface. You can get the interface name with ip addr show.

# This is wrong >> dev <<
/usr/local/sbin/udp-sender --interface >> dev << --min-receivers 2 --max-wait 600 --portbase 60328

Depending on the network adapter it should be something like ens192 or eth0 You will find this under FOG Configuration->FOG Settings->Multicast Settings->UDPCAST INTERFACE

@george1421 Never mind, I just got excited for finding nothing. Still looking into the setup.

@lebrun78 Hey, I was just comparing your dhcp config file with an example ubuntu dual interface example. I loaded your configuration into notepad++ and it pointed out you have an extra curly brace at the end of your config file. I don’t know if this was a type-o when you pasted it in or you do have an extra curly brace in the config.

@george1421 said in UEFI pxe boot problem from a network:

I really don’t understand how this is possible. I can understand the dhcp server giving its a new IP address as its booting. I’ve seen it before. What I don’t understand is how it would give it information that is not from its pool. That is totally confusing. If it was giving the complete information from the wrong pool I might understand, but the original pcap has the right IP address range and the wrong router and subnet information.

Can you grab a pcap from a witness computer on this vlan 10 using this new capture filter. PXE boot it to the error and then let it boot into windows. I want to see the response from both dhcp requests.

port 67 or port 68 and ether host 10:65:30:83:5c:4b

The only thing I can think that we might do is create a second instance of the dhcp server, adjust the dhcp config files accordingly, and then bind each instance with config file to the proper interface. Your setup is not a traditional one using dhcp helper services and a single dhcp interface on the server. Its possible that the dhcp server is getting confused to where the bootp request is coming from. Right now I’m just grabbing at ideas, because what you are reporting should not be.