Build DHCP and PXE servers (IP forwarding and NAT recommended)

2024-08-142024-11-21

Configuring a DHCP server is very useful to streamline network management and eliminate the need for manual IP address configuration. Furthermore, it is also an essential element in building a PXE server for network booting. This article details how to set up a DHCP server and a PXE server to create a seamless network environment.

What is DHCP?

DHCP (Dynamic Host Configuration Protocol) is a mechanism for automatically assigning IP addresses to devices in a network. It eliminates the need to manually set up IP addresses.

Example:

For example, when you connect your phone to your home Wi-Fi, the DHCP server automatically assigns an IP address to your phone. This allows your phone to connect to the Internet.

Why is this important?

Simplicity: When you add a new device to your network, you do not have to manually set its IP address.
Efficiency: Prevents duplicate IP addresses and simplifies network management.
Flexibility: When a device leaves the network and reconnects, it can be assigned a different IP address.

The first step is to install a DHCP server to automatically assign IP addresses. This way, devices in the network are centrally managed and configuration is simplified. We will then move on to how to set up a PXE server and establish a network boot mechanism.

Before starting work, check your current network environment and IP address status. If you check it first, you will be able to clearly see the changes after the configuration. since we want to achieve this using Docker, Docker related information is also displayed. we have already installed Docker on Ubuntu 24.04.

ip a

DHCP Server Installation and Configuration

The installation and configuration of a DHCP server will be explained in detail later, but the point here is that the server PC can act as a DHCP server, automatically assigning IP addresses to client PCs in the network and simplifying network configuration.

We will also show how the server PC can act as a router, allowing client PCs to access the Internet. This is an example of how to separate networks with PCs that have two network devices, a construction that avoids duplicate DHCP. DHCP and PXE can be achieved without any special configuration here. [ Reference URL: https://betelgeuse.work/ip-forwarding-nat/]

PXE Server Configuration

Next, configure the server PC to function as a PXE server; PXE (Preboot Execution Environment) is a standard mechanism for computers to boot over a network, instead of installing an OS from a USB or DVD It can be done over a network.

NetBoot.XYZ is a tool that provides this PXE boot environment, offering menus for booting and installing various operating systems and utilities over the network. XYZ server can be set up to allow OS installation and other booting over the network from any PC connected to the network. This eliminates the need for physical media (USB drives or CD/DVDs) and makes management much easier.

Overview of PXE (Preboot Execution Environment)

DHCP Request:
- When the computer boots, it first sends a DHCP request to obtain an IP address if PXE boot is enabled.
Response from the DHCP server:
- In addition to the IP address, the DHCP server provides the client with information on the next TFTP server to connect to (next-server) and the filename of the boot loader file to be obtained (filename).
Boot loader acquisition from TFTP server:
- The client downloads the specified boot loader (e.g. netboot.xyz.kpxe) from the TFTP server.
Execution of the boot loader:
- The downloaded boot loader is executed and continues the boot process by retrieving the required OS image or installation image further over the network.

Client Computer

1. Send DHCP Request

2. Receive DHCP Response with IP, next-server, boot file name

3. Download boot file from TFTP server

4. Execute boot file, initiate OS install or network boot

—> <--> <--> <---

<---

–<-- --> <--> <--> <--> <--> <--> <---

<---

DHCP Server

Provide IP, next-server, boot file name

–<--- --> <--- DHCP Server

<---

TFTP Server

Provide boot file to client

Using the following two GitHub pages as reference, use Docker to set up a NetBoot.XYZ container and a DHCP server container. The NetBoot.XYZ container will function as a TFTP server, but the DHCP server must be configured separately.

https://github.com/netbootxyz/docker-netbootxyz
https://github.com/wastrachan/docker-dhcpd

I combined them using the docker-compose.yml file (see below). This is also inefficient because if the docker0 network changes on every restart, the dhcpd.conf file must be updated each time. dhcpd.conf is the file that is mounted on the host when the container is launched (see below). To solve this problem, create a fixed network in Docker and configure it to use it (see below).

The dhcpd.conf file is the DHCP server configuration file. This file contains settings that specify how the DHCP server should operate. The following are typical configuration items in the dhcpd.conf file and their descriptions.

Typical configuration items in dhcpd.conf

# Global configuration options
default-lease-time 600; # Default lease time (seconds) 
max-lease-time 7200;    # Maximum lease time (seconds) 

# DNS server and gateway settings
option domain-name-servers 8.8.8.8, 8.8.4.4;
option domain-name "example.com";
option routers 192.168.1.1;

# Per subnet configuration
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.200; # IP address assignment range
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.1.255;
}

# Fixed IP to specific host Address assignment
host myclient {
    hardware ethernet 00:11:22:33:44:55;
    fixed-address 192.168.1.50;
}

Description of configuration options

Global configuration options:
- default-lease-time: Default time (in seconds) for the client to lease an IP address from the DHCP server.
- max-lease-time: Maximum time (in seconds) that the client will lease an IP address from the DHCP server.
DNS server and gateway settings:
- option domain-name-servers: DNS server addresses to provide to the client.
- option domain-name: Domain name to provide to the client.
- option routers: Default gateway addresses to provide to clients.
Per-subnet configuration:
- subnet: The range of subnets and netmasks to which the DHCP server assigns IP addresses.
- range: Range of IP addresses that the DHCP server assigns to clients within the subnet.
- option subnet-mask: Subnet mask to be provided to the client.
- option broadcast-address: Broadcast address to be provided to the client.
Assignment of a static IP address to a specific host:
- host: Configuration of a specific host.
- hardware ethernet: MAC address of the host.
- fixed-address: Fixed IP address to be assigned to the host.

What dhcpd.conf does

The dhcpd.conf file configures how the DHCP server assigns IP addresses to clients, which DNS servers and default gateways to provide, how long the lease is, and whether to assign fixed IP addresses to specific hosts. This will allow clients in your network to automatically get network settings.

If you use this configuration to run a DHCP server within a Docker container, you can mount the dhcpd.conf file on a host and use it within the container to easily manage and modify the DHCP server configuration.

As a side note, we use VS Code to remotely connect to the PC we are operating on.

Using VS Code to edit files on the remote server is very convenient. Here are a few reasons why.

Convenience of VS Code

Seamless operation:
- Files on remote servers can be opened and edited as if they were local, making the experience very natural.
Remote – SSH extension:
- VS Code’s Remote – SSH Extension allows you to easily connect and work on a remote server. This allows you to work directly with projects on the server.
Extensive plug-ins:
- VS Code has a large number of plug-ins, providing a wide range of tools for remote development. For example, Git operations and debugging tools can be integrated.
Integrated Terminal:
- VS Code has an integrated terminal that allows you to execute commands on a remote server directly from within the editor. This eliminates the need to switch back and forth between the editor and the terminal.
File system access:
- Use the file browser to visually manipulate the directory structure on the remote server. This makes it easy to move, delete, or create files.
Synchronization and version control:
- As with local work, version control is available via Git. Operations on remote repositories are also seamless.

Network Diagram

TOC

Data Flow Diagram

+——————-+
| Client Computer |
| |
| 1. DHCP Request |
| | |
| v |
| 2. DHCP Response |
| | |
| v |
| 3. PXE Request |
| | |
| v |
| 4. PXE Response |
| | |
| v |
| 5. Boot Image |
| |
+——————-+

Explanation of network diagram

Client PC:
- First, there is a client PC (e.g., a new PC) connected to the network. This PC attempts to boot (start) over the network.
DHCP Server:
- A DHCP server is located in the network. This server is responsible for automatically assigning IP addresses to devices in the network.
PXE Server:
- A PXE (Preboot Execution Environment) server is also located. This server is responsible for providing boot images (OS and utilities) to client PCs over the network.
DHCP Request:
- When a client PC boots, it first sends a request for an IP address to the DHCP server. This is the DHCP Request.
DHCP Response:
- The DHCP server assigns an IP address to the client PC and returns a response. This is the DHCP Response. This response also contains information about the PXE server.
PXE Request:
- The client PC sends a request to the PXE server based on the PXE server information received from the DHCP server. This is the “PXE Request.
PXE Response:
- The PXE server returns boot image information to the client PC. This is the “PXE Response”.
Download the boot image:
- Finally, the client PC downloads a boot image from the PXE server and uses that image to install the OS and perform a network boot.

The flow of the client PC booting over the network is explained.

DHCP request:
- The client PC requests an IP address from a DHCP server on the network.
DHCP Response:
- The DHCP server assigns an IP address to the client PC and returns this information.
PXE Request:
- The client PC then requests the PXE server for the data needed to start up.
PXE Response:
- The PXE server returns the data for startup to the client PC.
Boot Image Acquisition:
- Finally, the client PC downloads a boot image from the PXE server and uses it to install the OS or boot directly from the network.

Creating a Fixed Network

First, create a fixed custom network in Docker. This will give the network a fixed IP range. The reason for creating it has been mentioned above, but we’ll reiterate the reason again: if the docker0 network changes every time it is rebooted, the dhcpd.conf file will have to be updated each time, which is inefficient.

Creating a fixed network: Run the following command to create a fixed custom network
docker network create --subnet=172.20.0.0/16 my_custom_network
This will create a fixed network named my_custom_network, with subnet 172.20.0.0/16.

docker0 network (reiterated)

Default bridge network:
- docker0 is the default bridge network automatically created by Docker.
- When a Docker container is launched, this network will be used unless otherwise specified.
Automatic IP address assignment:
- The docker0 network typically uses the address range 172.17.0.0/16, but this may vary from system to system.
- IP addresses are automatically assigned to containers.

IP address on restart

Restart container:
- A new IP address may be assigned each time the container is restarted; Docker’s default behavior is to assign a new IP address for each restart.
Configure a static IP address:
- If desired, containers can also be assigned a fixed IP address. This can be accomplished by creating a custom network and setting a static IP for that network.

The created network can be viewed with the following command

docker network ls

Create a docker-compose.yml file to use the created static network.

version: "2"

services:
  docker-dhcpd:
    image: wastrachan/dhcpd
    container_name: docker-dhcpd
    environment:
      - PUID=1111
      - PGID=1112
    volumes:
      - /home/mamu/netboot/dhcpconfig:/config
    network_mode: "host"  # use host network mode
    restart: unless-stopped

  netbootxyz:
    image: ghcr.io/netbootxyz/netbootxyz
    container_name: netbootxyz
    environment:
      - MENU_VERSION=2.0.47
      - NGINX_PORT=80
      - WEB_APP_PORT=3000
    volumes:
      - /home/mamu/netboot/config:/config
      - /home/mamu/netboot/assets:/assets
    networks:
      - my_custom_network
    ports:
      - 3000:3000
      - 69:69/udp
      - 8080:80
    restart: unless-stopped

networks:
  my_custom_network:
    external: true

docker compose up -d

If you check the IP address, you will see the following

ip a

1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00 brd 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 noprefixroute
valid_lft forever preferred_lft forever
2: enp1s0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether f0:76:1c:88:14:76 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.1/24 brd 10.0.0.255 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::f276:1cff:fe88:1476/64 scope link
valid_lft forever preferred_lft forever
3: wlp2s0: mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether ac:b5:7d:87:8e:90 brd ff:ff:ff:ff:ff:ff:ff
inet 192.168.0.107/24 brd 192.168.0.255 scope global wlp2s0
valid_lft forever preferred_lft forever
inet6 fe80::aeb5:7dff:fe87:8e90/64 scope link
valid_lft forever preferred_lft forever
4: docker0: mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:e2:46:ea:31 brd ff:ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: br-a180cb5a6bfa: mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:6a:7c:7c:8f brd ff:ff:ff:ff:ff:ff:ff
inet 172.20.0.1/16 brd 172.20.255.255 scope global br-a180cb5a6bfa
valid_lft forever preferred_lft forever
inet6 fe80::42:6aff:fe7c:7c8f/64 scope link
valid_lft forever preferred_lft forever
7: veth68ca453@if6: mtu 1500 qdisc noqueue master br-a180cb5a6bfa state UP group default
link/ether aa:4f:ef:fc:fc:fb:ff brd ff:ff:ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::a84f:efff:fefc:fbff/64 scope link
valid_lft forever preferred_lft forever

You can see that the network state has changed as a result of launching the container. In particular, it reflects the custom network created by the docker network create command. A specific explanation is given below.

Network state changes

The custom network my_custom_network created by docker network create --subnet=172.20.0.0/16 my_custom_network command is reflected as interface br-a180cb5a6bfa The status of this network is described below. This section describes the status of this network.

Interface Details

br-a180cb5a6bfa interface:
- IP address: 172.20.0.1/16
  - Gateway address for subnet 172.20.0.0/16.
- MAC address: 02:42:6a:7c:7c:8f
  - MAC address of the bridge interface.
- Broadcast address: 172.20.255.255
  - Address for sending packets to all devices in the subnet.
- IPv6 address: fe80::42:6aff:fe7c:7c8f/64
  - Link-local address.
veth68ca453@if6 interface:
- MAC address: aa:4f:ef:fc:fb:ff
  - This is one interface of a virtual Ethernet pair.
- IPv6 address: fe80::a84f:efff:fefc:fbff/64
  - Link-local address.
- This interface is connected to the container’s network interface.

Let’s explain a little more about the interface in 2. The role of the veth interface is as follows.

The veth interface is a kind of virtual Ethernet interface, which is mainly used to connect Docker container networks. Specifically, it plays the following roles

Virtual network bridge:
- veth interfaces work in pairs, with one end connected to the container and the other end connected to the host’s network bridge. This way, communication between the container and the host or other network resources is possible.
Network packet forwarding:
- Through the veth interface, data is sent and received between the container and other networks in the host. This allows the container to access the Internet and other services in the host.

Explanation with concrete examples

To understand the veth interface, consider the following.

A container is like a virtual machine, with its own network interface.
The veth interface is like a cable, which is connected to the container at one end and to the host’s network at the other end.
Through this cable, the container can communicate with the host and the Internet.”

Actual Role

Specifically, the interface named veth68ca453@if6 plays the following roles

Communication: The packets that the container needs to access the external network pass through this veth interface. In other words, it serves as a tunnel to connect the container’s internal network with the host’s network.”

Connection: This interface is paired with the host’s bridge interface br-a180cb5a6bfa. One side of this pair is on the host side and the other side is on the container side.

There is more work to be done. Add a subnet declaration for the new fixed network; based on the IP information, the description is as follows: edit the DHCP server configuration file, /home/mamu/netboot/dhcpconfig/dhcpd.conf. Since we are mounting the container directory, we edit this file on the host. If you use docker0, you will get 172.18.0.X or 172.19.0.X when you restart the container and you will have to edit this file. That is why we created a custom network.

default-lease-time 600;
max-lease-time 7200;

# Subnet declaration for 10.0.0.x (enp1s0)
subnet 10.0.0.0 netmask 255.255.255.0 {
  range 10.0.0.100 10.0.0.200;
  option routers 10.0.0.1;
  option broadcast-address 10.0.0.255;
  next-server 10.0.0.1;  # IP address of NetBoot.XYZ container
  filename "netboot.xyz.kpxe";
}

# Subnet declaration for 172.20.0.x (my_custom_network)
subnet 172.20.0.0 netmask 255.255.0.0 {
  range 172.20.0.10 172.20.0.100;
  option routers 172.20.0.1;
  option broadcast-address 172.20.255.255;
  # next-server 172.20.0.2;  # configure as needed
  # filename "pxelinux.0";
}

When I edited the file with VS code and tried to overwrite and save it, I got the following message. This is because the logged in user does not have write permission to the file.

Could not save ‘dhcpd.conf’. Unable to write file ‘vscode-remote://ssh-remote ub2404dhcp/home/mamu/netboot/dhcpconfig/dhcpd.conf’ (NoPermissions (FileSystemError): Error: EACCES: permission denied, open ‘/home/mamu/netboot/dhcpconfig/dhcpd.conf’)

So, I installed a plugin called “Save as Root in Remote – SSH”. This plugin allows you to save files directly on VS Code using root permissions. It saves you the trouble of changing file ownership and permissions. Now that you have edited the file, restart the container.

docker compose down
docker compose up -d

Now that it should function as a DHCP server, connect a Windows PC via a hub to verify: If a DHCP server is running on the network, clients can automatically obtain an IP address using Internet Protocol version 4 (IPv4). Since the client will automatically obtain an IP address from the DHCP server, there should be no need to do anything special to configure the network.

It appears that the Windows PC has obtained a private IP address of 10.0.0.100.

Steps to obtain an IP from a DHCP server

Initialize the DHCP client:
- When the client PC is connected to the network, the DHCP client is automatically started. This is done as soon as the network interface is enabled.
DHCP discovery messages are sent:
- The client sends a broadcast message (DHCP Discover) to the network to find an available DHCP server.
Receive DHCP Offer message:
- A DHCP server in the network receives this Discovery message and sends back an IP address offer (DHCP Offer) to the client.
Sending DHCP Request Message:
- The client selects one of the offers received and sends a request message (DHCP Request) requesting that IP address.
Receive DHCP Acknowledge Message:
- The DHCP server receives the request and sends an acknowledgement message (DHCP Acknowledge) confirming the lease of the specified IP address.
IP Address Configuration:
- The client uses the received information such as IP address, subnet mask, default gateway, and DNS server to configure network settings.

Why assign an IP without doing anything special?

Automatic configuration:
- Many operating systems (Windows, Linux, macOS, etc.) automatically start the DHCP client and initiate the process of obtaining an IP address when the network interface is enabled.
Default Configuration:
- Normally, “Automatic (DHCP)” is set as the default method of obtaining an IP address in the network interface settings. Therefore, an IP address is automatically assigned simply by connecting to the network, without any special configuration by the user.

How to check in Windows

Check the network settings:
- [Go to Control Panel > Network and Internet > Network and Sharing Center.
- [Click “Change Adapter Settings,” then right-click the network adapter you are using and select “Properties.
- [Select “Internet Protocol Version 4 (TCP/IPv4)” and click “Properties.
- Make sure “Obtain IP address automatically” and “Obtain DNS server address automatically” are checked.
Release and reacquire IP address:
- Open a command prompt and execute the following command
  ipconfig /release
  ipconfig /renew

How to check on Linux

Check Network Manager:
- Usually, services such as NetworkManager or systemd-networkd automatically manage DHCP clients.
Manual release and reacquisition:
- Open a terminal and run the following command
  sudo dhclient -r
  sudo dhclient

Next, check that it is functioning properly as a PXE server. The client PC should be set to network boot as the highest priority in the boot order on the BIOS screen.

When setting up PXE boot, you will need to select the UEFI and Legacy Support options in the BIOS settings. Each option is briefly described below.

UEFI and Legacy Support

UEFI (Unified Extensible Firmware Interface):
- UEFI is a firmware interface designed as a successor to the legacy BIOS, offering faster boot times and improved security features UEFI supports the GPT (GUID Partition Table) partition style.
Legacy Support:
- Legacy support provides a traditional BIOS (Basic Input/Output System) compatible boot mode. Legacy mode uses the MBR (Master Boot Record) partition style.

Legacy Support Advanced Options

UEFI First:
- With this setting, the system will attempt a UEFI boot first, and if that fails, it will attempt a legacy boot.
Legacy First:
- With this setting, the system will attempt a legacy boot first, and if that fails, it will attempt a UEFI boot. Legacy boot is given priority.

Which option should I choose?

UEFI:
- We recommend using UEFI if possible; UEFI is newer, has enhanced security features, and supports GPT partitions. It is also more compatible with the latest hardware and software.
Legacy support:
- Select Legacy Support if you are using older hardware or a non-UEFI-compatible system. Also, some older operating systems and tools can only be booted in legacy mode.
UEFI First vs. Legacy First:
- UEFI First: Preferred for UEFI-compatible boot media and recommended for compatibility. Useful when installing a new system or operating system.
- Legacy First: Use when supporting older hardware or legacy boot only. Useful when compatibility is required.

Actual configuration example

PXE boot in UEFI mode:
- Select UEFI in BIOS settings and enable the network boot option.
- Ensure that the PXE server supports UEFI PXE boot.
PXE boot in legacy mode:
- Select Legacy Support in BIOS settings and select Legacy First if necessary.
- Ensure that the PXE server supports legacy PXE boot.

Note that the above DHCP configuration file will only boot well with legacy support. We will describe later the configuration that allows booting with UEFI.

I checked the logs once I tried PXE boot.

docker logs docker-dhcpd

This log shows that the DHCP server has started successfully and is accepting requests on the specified network interface.

Starting up using the following:.

UID: 1111
GID: 1112

Internet Systems Consortium DHCP Server 4.4.3-P1
Copyright 2004-2022 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Config file: /config/dhcpd.conf
Database file: /config/dhcpd.leases
PID file: /run/dhcp/dhcpd.pid
Wrote 1 leases to leases file.

No subnet declaration for veth69ce47c (no IPv4 addresses).
** Ignoring requests on veth69ce47c.
If this is not what you want, please write a subnet declaration
If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment
If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment to which interface veth69ce47c is attached.

Listening on LPF/br-a180cb5a6bfa/02:42:6a:7c:7c:8f/172.20.0.0/16
Sending on LPF/br-a180cb5a6bfa/02:42:6a:7c:7c:8f/172.20.0.0/16

No subnet declaration for docker0 (172.17.0.1).
** If this is not what you want, please write a subnet declaration for docker0 (172.17.0.1).
If this is not what you want, please write a subnet declaration
If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment
If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment to which interface docker0 is attached.

No subnet declaration for wlp2s0 (192.168.0.107).
** If this is not what you want, please write a subnet declaration for wlp2s0 (192.168.0.107).
If this is not what you want, please write a subnet declaration
If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment
If this is not what you want, please write a subnet declaration in your dhcpd.conf file for the network segment to which interface wlp2s0 is attached.

Listening on LPF/enp1s0/f0:76:1c:88:14:76/10.0.0.0/24
Sending on LPF/enp1s0/f0:76:1c:88:14:76/10.0.0.0/24
Sending on Socket/fallback/fallback-net
Server starting service.
DHCPREQUEST for 10.0.0.100 from 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPACK on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.101 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPREQUEST for 10.0.0.101 (10.0.0.1) from 54:e1:ad:33:d8:e2 via enp1s0
Wrote 2 leases to leases file.
DHCPACK on 10.0.0.101 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPREQUEST for 10.0.0.100 (10.0.0.1) from 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPACK on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.101 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPREQUEST for 10.0.0.101 (10.0.0.1) from 54:e1:ad:33:d8:e2 via enp1s0
DHCPACK on 10.0.0.101 to 54:e1:ad:33:d8:e2 via enp1s0
reuse_lease: lease age 126 (secs) under 25% threshold, reply with unaltered, existing lease for 10.0.0.100
DHCPDISCOVER from 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPOFFER on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
reuse_lease: lease age 127 (secs) under 25% threshold, reply with unaltered, existing lease for 10.0.0.100
DHCPDISCOVER from 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPOFFER on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
reuse_lease: lease age 129 (secs) under 25% threshold, reply with unaltered, existing lease for 10.0.0.100
DHCPREQUEST for 10.0.0.100 (10.0.0.1) from 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPACK on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.102 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPREQUEST for 10.0.0.102 (10.0.0.1) from 54:e1:ad:33:d8:e2 via enp1s0
DHCPACK on 10.0.0.102 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.100 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.100 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPREQUEST for 10.0.0.100 (10.0.0.1) from 54:e1:ad:33:d8:e2 via enp1s0
DHCPACK on 10.0.0.100 to 54:e1:ad:33:d8:e2 via enp1s0
reuse_lease: lease age 71 (secs) under 25% threshold, reply with unaltered, existing lease for 10.0.0.102
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.102 to 54:e1:ad:33:d8:e2 via enp1s0
reuse_lease: lease age 75 (secs) under 25% threshold, reply with unaltered, existing lease for 10.0.0.102
DHCPREQUEST for 10.0.0.102 (10.0.0.1) from 54:e1:ad:33:d8:e2 via enp1s0
DHCPACK on 10.0.0.102 to 54:e1:ad:33:d8:e2 via enp1s0
DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0
DHCPOFFER on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPREQUEST for 10.0.0.100 (10.0.0.1) from 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0
DHCPACK on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0

This log shows the process by which the DHCP server receives requests from clients and assigns IP addresses.

Displaying startup information:.

The first part of the log shows the User ID (UID) and Group ID (GID) used by the DHCP server. This indicates the access rights on the system.

Starting up using the following: 
UID: 1111 
GID: 1112

DHCP server version and copyright information:.

This shows the version and copyright information of the DHCP server. This information is used to identify which version of the software you are using.

Internet Systems Consortium DHCP Server 4.4.3-P1 
Copyright 2004-2022 Internet Systems Consortium. 
All rights reserved. 
For info, please visit https ://www.isc.org/software/dhcp/

Configuration and database files

Shown are the configuration file (/config/dhcpd.conf ) used by the DHCP server and the database file (/config/dhcpd.leases ) that stores lease information. These files hold information necessary for the operation of the DHCP server.

Config file: /config/dhcpd.conf 
Database file: /config/dhcpd.leases 
PID file: /run/dhcp/dhcpd.pid 
Wrote 0 leases to leases file.

Missing subnet declarations:

Because there is no subnet declaration for the network interfaces veth69ce47c and docker0, requests from this interface will be ignored. This indicates that the interface is not covered by the DHCP server.

No subnet declaration for veth69ce47c (no IPv4 addresses). 
** Ignoring requests on veth69ce47c. If this is not what 
 you want, please write a subnet declaration 
 in your dhcpd.conf file for the network segment 
 to which interface veth69ce47c is attached. ** 

No subnet declaration for docker0 (172.17.0.1). 
** If this is not what 
 you want, please write a subnet declaration 
 in your dhcpd.conf file for the network segment 
 to which interface docker0 is attached. ** 

No subnet declaration for wlp2s0 (192.168.0.107). 
** If this is not what 
 you want, please write a subnet declaration 
 in your dhcpd.conf file for the network segment 
 to which interface wlp2s0 is attached.

Listening state:

Shows on which interface the DHCP server is accepting requests. It is listening on the following interfaces:
- br-a180cb5a6bfa (172.20.0.0/16)
- enp1s0 (10.0.0.0/24)

Listening on LPF/br-a180cb5a6bfa/02:42:6a:7c:7c:8f/172.20.0.0/16 
Sending on LPF/br-a180cb5a6bfa/02:42:6a:7c:7c:8f/172.20.0.0/16 

 Listening on LPF/enp1s0/f0:76:1c:88:14:76/10.0.0.0/24
 Sending on LPF/enp1s0/f0:76:1c:88:14:76/10.0.0.0/24

Starting Server:.

Finally, it indicates that the DHCP server has started service.

Server starting service.

Processing client requests:.

The DHCP server receives DHCP requests from clients and assigns IP addresses accordingly.
DHCPDISCOVER indicates that the client is looking for an IP address to join the network.
DHCPOFFER indicates that the server is offering an IP address to the client.
DHCPREQUEST indicates that the client is requesting the provided IP address.
DHCPACK indicates that the server is confirming the IP address with the client.

DHCPDISCOVER from 54:e1:ad:33:d8:e2 via enp1s0 
DHCPOFFER on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0 
DHCPREQUEST for 10.0. 100 (10.0.0.1) from 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0 
DHCPACK on 10.0.0.100 to 54:e1:ad:33:d8:e2 (LAPTOP-U2IPTTLE) via enp1s0

In summary, it would look something like this This log indicates that the DHCP server has started successfully and is providing IP addresses to clients. Due to missing subnet declarations for some network interfaces, requests from those interfaces are ignored, but this is normal behavior.

Let’s try the actual installation.
Connect the client to the DHCP cum PXE server we built, connected via a HUB. Leave the network boot as the top priority. The boot screen is as shown in the following screenshot.

However, none of the distributions have the latest version and the installation fails.

Solution
As you can see from the description in docker-compose.yml, you can log in to the netboot.xyz management screen by entering the following URL into your browser.

http://Server IP address:3000/

This administration screen allows you to update files, so be sure to run it. I found the following

Files like netboot.xyz-arm64-snp.efi are likely to be updated. This file is a netboot image specifically for the ARM64 architecture. There are other files as well. After much searching I was able to find the following URL. Here is a description of the file.

https://github.com/netbootxyz/netboot.xyz/releases

File details

netboot.xyz-arm64-snp.efi:
This is the netboot image for the ARM64 architecture used in the UEFI (Unified Extensible Firmware Interface) environment. snp stands for Simple Network Protocol and is used during network boot. netboot.xyz is a tool to make various Linux distributions and utilities bootable over the network using this image.

This update often contains new boot options and fixes, and may have added the following features and bug fixes

Addition of new options such as ZFSBootMenu and VanillaOS: Users will be able to boot these new systems over the network.
Bug fixes and performance improvements to existing netboot options: for example, problems with the installation of Ubuntu 24.04 may have been fixed.

Updating this file will reflect these new features and fixes during network booting, ensuring a smoother boot process.

Extra
The following files are DHCP configuration files for both UEFI and legacy support

default-lease-time 600;
max-lease-time 7200;

# Subnet declaration for 10.0.0.x (enp1s0)
subnet 10.0.0.0 netmask 255.255.255.0 {
  range 10.0.0.100 10.0.0.200;
  option routers 10.0.0.1;
  option broadcast-address 10.0.0.255;
  option domain-name-servers 8.8.8.8, 8.8.4.4;
  next-server 10.0.0.1;  # IP address of NetBoot.XYZ container

  # Boot file selection
  if exists user-class and option user-class = "iPXE" {
      filename "netboot.xyz.kpxe";
  } else {
      if substring(option vendor-class-identifier, 0, 9) = "PXEClient" {
          if option vendor-class-identifier = "PXEClient:Arch:00000:UNDI:002001" {
              filename "netboot.xyz.kpxe";  # Legacy BIOS
          } else {
              filename "netboot.xyz.efi";  # UEFI
          }
      } else {
          filename "netboot.xyz.kpxe";  # Other
      }
  }
}

# Subnet declaration for 172.20.0.x (my_custom_network)
subnet 172.20.0.0 netmask 255.255.0.0 {
  range 172.20.0.10 172.20.0.100;
  option routers 172.20.0.1;
  option broadcast-address 172.20.255.255;
  option domain-name-servers 8.8.8.8, 8.8.4.4;

  # Select boot file
  if exists user-class and option user-class = "iPXE" {
      filename "netboot.xyz.kpxe";
  } else {
      if substring(option vendor-class-identifier, 0, 9) = "PXEClient" {
          if option vendor-class-identifier = "PXEClient:Arch:00000:UNDI:002001" {
              filename "netboot.xyz.kpxe";  # Legacy BIOS
          } else {
              filename "netboot.xyz.efi";  # UEFI
          }
      } else {
          filename "netboot.xyz.kpxe";  # Other
      }
  }
}

https://github.com/superdoccimo/notepc

Please share if you like it!

Copied the URL !

Copied the URL !