@george1421
New revelations have been made. As I said I now replicated the whole setup on a local isolated network (with exception of the apparmor modifications, not necessary on a bare-metal installation).

I have my witness-computer connected to both networks with 2 seperate NICs. Only one is active at a time. In both setups I first started wireshark on the witness computer and booted a notebook into pxe.

Main network: No packets or barely some DHCP-ACKs (that were not from the booting laptop). Isolated local network: Discover -> Offer -> Request -> ACK. Laptop got an IP from the router and loaded the appropriate bootrom from the fogserver and booted from it.

Conclusion: Since the witnessing of the DHCP-packets have nothing to do with fog itself it is safe to say that there is some sort of broadcoastfiltering of the DHCP-relevant ports. The (almost) exact same installation worked in an isolated network but not on the main network.

Thank you so much, I finally know the exact cause of the problem and am able to proceed. I now have to write up a request if the networking team would be so kind to allow the broadcoasting of those port-packets to a single static IP that I own (I really hope they’ll allow that. Now that I think of it this makes total sense. If people are able to plug in their own devices into the network that behave like a DHCP-Server and then handle the IPs before the main DHCP does you are in a golden MITM-position and can intercept with the network-packets to your desire). But as far as fog goes, this is nothing from its side.

So I think I can say this is solved for the cause of “troubleshooting”. Even if my journey is not exactly at its end yet. Thanks again!

@Exig3nci said:

@Wayne-Workman Yes.
I’m running tcpdump on the Ubuntu vm, getting the file to my host machine through tftp, then opening it in Wireshark,

If you’re only getting three packets from TCPDump for the entire time that you’re attempting to network boot the target host, then you have a network communications issue with your VM and the target host.

Perhaps it’s a VM configuration, or a switch configuration, a DHCP Helper address configuration, or a DHCP configuration. But something is very wrong somewhere.

You should be seeing TONs of traffic, you should be seeing hundreds of packets.

To further troubleshoot this using TCPDump, we need to see what the target host is doing. For this, you will require a network hub (not a switch, a hub).

Place the hub between the target host and whatever network device it connects to. Then attach a laptop or something to the hub and boot a Live Linux CD on that computer and run TCPDump as you have before. Because the hub replicates all packets to all ports, the extra computer on the hub will be able to see all traffic coming and going to the target host.

If you use a graphical Live Linux distribution, you can even install wireshark directly on it and open the PCAP files right there or alternatively transfer them using a flash drive to a PC with wireshark on it.

Doing this will allow us to see what the client is receiving from DHCP and what - if anything - from dnsmasq.