Debian 11 install does not have default gateway route?

[Jibun no Kage]

A bit of context, I am a 30 year IT career support person, with over 15 years experience with VMware, not to mention Hyper-V, KVM, etc. And I just built a Debian 11 based VM using VMware Player 16 on Windows 10, and it has no default gateway configured, even though I am using a valid DHCP server that is sending the gateway information request back to the VM. The physical NIC is in bridged mode, not using NAT, I have built 100s if not 1000s of VMs over the years, with various OSes, and this issue is driving me nuts... It is not common but not exactly in frequent, that Linux OS based VMs have some odd quirks at times. But this issue is being really stubborn to resolve.

Here is the VM Network configuration:

Physical Network Adapter.png (23.5 KiB) Viewed 6332 times

Here is the bridging configuration applicable to the above illustrated configuration:

Bridged Network Adapter Bridging.png (7.5 KiB) Viewed 6332 times

Linux OS, Debian 11, configuration of NIC:
# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.154 netmask 255.255.255.0 broadcast 192.168.1.255
ether 00:0c:29:f5:40:3a txqueuelen 1000 (Ethernet)
RX packets 52602 bytes 63536259 (60.5 MiB)
RX errors 0 dropped 3 overruns 0 frame 0
TX packets 8465 bytes 616235 (601.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 46 bytes 3914 (3.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 46 bytes 3914 (3.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Root issue, no pun, if lack of a default route:

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 ens33

# ping www.google.com
ping: connect: Network is unreachable

Running Raspbian OS on Pi, which is an ARM variant of Debian Buster, using the same DHCP server that the above device/configuration is using, receives the correct DHCP configuration including the default (gateway) route. As shown below.

Pi...

# ifconfig
enxb827ebc5e65c: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255
ether b8:27:eb:c5:e6:5c txqueuelen 1000 (Ethernet)
RX packets 893849 bytes 78340061 (74.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 760326 bytes 74150969 (70.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 743133 bytes 39014627 (37.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 743133 bytes 39014627 (37.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 enxb827ebc5e65c
192.168.1.0 0.0.0.0 255.255.255.0 U 202 0 0 enxb827ebc5e65c

So the question remains... why Debian 11 in a VMware VM is not getting a default gateway. So, as a validation test, I installed Debian 11 on true hardware, not in a VM, and sure enough the default gateway route from the common DHCP server, is present. So the issue is VMware Player on Windows 10 and specific to Debian 11, at least for the VM above. Time to create another VM and see if the issue is consistent.

The question is, has anyone else seem this odd behavior, in VMware Player on Windows 10 and attempting to install Debian 11?

[afiadi]

I think windows is too many bug,maybe in this case you get random bug from windows 10.
I sugest you can use linux environment to run linux in VM more reliable and less trouble. I use VMware workstation to install Debian Bullseye and use Virtual Network Editor to assign my wifi internal laptop as bridge network for Guest OS. look at my SS.
In the first SS, My Debian 11 VM can connect internet and has automatically ip gateway, because my wifi router I set to dhcp.


And this SS I set my network guest os as bridge mode with vmnet0 interface

[Jibun no Kage]

Thanks for the response, quite interesting, however if you are using vmnet* you are not using physical NIC bridging as I did in my initial VM configuration. I am mirroring the host system NIC, this gives the VM more direct route to the hardware. This is not always desired or preferred, all depends on how you want your virtual network to be implemented. So we are not comparing the same configuration.

Here is my VM configuration applicable to VM NIC:

Physical Network Adapter Again.png (24.62 KiB) Viewed 6273 times

I have DHCP working fine for everything else in my home. All systems but the Debian 11 systems are getting the default gateway as expected, from my existing believed correct ISC DHCP Server, automatically, by default when using DHCP. Also... I rebuilt again, Debian 11 on hardware, not in a VM, and the first time, the default route seemed present. I then changed the connection to a different NIC on the same hardware, removed all connection profiles (the original one built at installation) and then let DHCP own the new connection on the different NIC... and the route was not established.

So... in my case:

1) Debian 11 in VM (VMware Player 16, latest, on Windows 10 fully patched/updated), initial install, no default gateway on installed OS boot. But NetInst installation did work as expected, no issues with finding and using NIC and ethernet to do the OS install.

2) Debian 11 on hardware, using NIC 1, the default route was established via DHCP, NIC 1 selected as part of the OS install. After removing the connection profile via NIC 1 via GUI in Network Manager, and creating a new profile on different physical NIC, i.e. NIC 2, on same system, no default route exists.

This tells me 3 things at this time:

1) This issue is not dependent on Windows 10
2) This issue is not dependent on virtualization, i.e. VMware Player 16, the physical NIC bridging by default tries to bridge all NICs, the Windows 10 host has multiple NICs.
3) This issue seems to be related on use of multiple physical NICs, or when multiple NICs present, visible to the Debian 11 OS

Next steps:

1) I am going to create a new VM, and make sure that the new VM can only see 1 physical NIC in the hardware NIC to VM NIC bridge configuration.

2) I am going to rebuilt the Debian 11 OS install on hardware using a selected NIC then change the selected NIC post install, so see if the behavior is consistent.

Will update this thread with what I discover in queue course. But all help, suggestions, comments, welcome of course.

[Jibun no Kage]

Update:

I confirmed that the install of Debian 11 in a VM as noted above, does not by default establish a default gateway route. This behavior is consistent. This is not the behavior I recall under Debian 10, Raspbian OS based on Debian 10, etc.

Here is what I did:

1) Only VM VMX file customization was to set the BIOS delay to 10 seconds, i.e. 10000 milliseconds
2) Confirmed, configured VM can only see a single NIC, via VM BIOS configuration, using physical NIC bridging, not NAT or any other abstracted NIC features as noted above.
3) Used Graphical Install from Debian 11 NetInst AMD64 Disc ISO

Here is the result:

root@test:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 100 0 0 ens33

root@test:~# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.154 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::20cfef5:403a prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:f5:40:3a txqueuelen 1000 (Ethernet)
RX packets 588 bytes 78730 (76.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 71 bytes 7724 (7.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 50 bytes 3968 (3.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 50 bytes 3968 (3.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I am staring to think that because the installation media installer, on NetIst ISO image, for example, is illustrating the behavior as well since the following warning is appearing during the installation:


4) Installation, Configure the Network, Network Configuration was successful. But no default route was
set warning? Why is this happening? So the (new) installer does not by default see external networks.
If this lack of default route is carried to the installed OS, that is a real problem. Answered No,
Because using NetInst ISO Image

5) Why is the installation asking to retry network autoconfiguration? The previous screen configured the
network configuration was successful? No other warnings are display about the network from this point forward
and all internet downloads work as expected.

No setting a default route during OS installation should have no impact on the setting of a default route in the installed OS, IMHO, if this is root cause for no default route established OS installation, this makes no sense to me at all.

Still have installation on actual hardware pending. Updates to follow.

[Jibun no Kage]

Well, for those that find this topic interesting if not helpful, after some extensive testing, have found one solution to the missing default gateway route, when Debian 11 is installed in a VM via VMware Player 16.

Black listing the SMBus support, via blacklisting the i2c-piix4 driver, seems to allow the default route to be established via DHCP as expected. This in the past, the lack of SMBus support, which is evidenced in the boot log of the Linux VM, visible via dmesg, in the past has been a passive issue, that could be ignored.

Apparently, there is something in Debian 11 or a significant change between it and Debian 10, that the lack of an SMBus on a virtual machine, trips something up with the network configuration, or such?

Once I added a conf file under /etc/modprobe.d as say /etc/modprobe.d/i2c-piix4.conf, which includes the just the line 'blacklist i2c-piix4' then rebooted the VM. The default gateway route appeared as expected, desired.

Maybe someone that has extensive knowledge applicable, can explain why or how this appears to at least one possible work-around if not a solution? And, or, why this is an issue for Debian 11, but the SMBus enabled error was benign in the past?

[afiadi]

Oke I follow what you setup NIC in your VM in windows 10, I don’t use vmnet0 interface anymore, so my Vmware choose random between my 2 network interface one is ethernet and the other is wifi card, I don’t know what my VM choice.

And after I full booting and login in my Debian 11 LXDE, there is still get IP address from my host OS. So this is confirm this not about host os or Virtual Machine software but I think this is about your host os maybe trully has too many bug. I sugest you must try Virtual Machine of Debian 11 in linux environment more better and more reliable.
Look at my SS, my VM has Ip address and also get default gateway ip address so my VM Guest can connected to the internet.


I also have home server installed Debian Bullseye 11. I upgrade from Debian Buster 10.This Debian Builseye works normally with multi NIC, I have two NIC ethernet card. And always get ip address and default gateway from my wifi router, because this server connected directly to Modem Wifi router. So this is confirm Debian Bullseye doesn’t has problem when installed in real hardware or baremetal even with multi NIC.

But for note. If i restart or start this server, when it’s full booting actually only one NIC automatically get IP address but of course get too default gateway. The other NIC I must assing IP address and default gateway with this command:

sudo dhclient eno1

Look my SS below:


Done.

[rh009]

A bit of context, I am a 30 year IT career support person, with over 15 years experience with VMware, not to mention Hyper-V, KVM, etc. And I just built a Debian 11 based VM using VMware Player 16 on Windows 10, and it has no default gateway configured, even though I am using a valid DHCP server that is sending the gateway information request back to the VM. The physical NIC is in bridged mode, not using NAT, I have built 100s if not 1000s of VMs over the years, with various OSes, and this issue is driving me nuts... It is not common but not exactly in frequent, that Linux OS based VMs have some odd quirks at times. But this issue is being really stubborn to resolve.

[...]

The question is, has anyone else seem this odd behavior, in VMware Player on Windows 10 and attempting to install Debian 11?

@Jibun no Kage, I wonder if you found an explanation.

I see the same symptoms, but also have some differences in my circumstances:

- I have lots of linux experience (redhat/ubuntu), but this is my first Debian install
- my hypervisor is Proxmox 8.1 (nested under Vmware Workstation 16, running on Win 10 LTSC)
- VM is Debian 12, installed also from the debian-12.5.0-amd64-netinst.iso image, with all options at default, except no desktop environment
- Proxmox VM uses the q35 chipset, all other VM options default.
- my DHCP server is dnsmasq running on another reliable linux box, and the debian install was served the following lease (uses option 121/classless routing):

Code: Select all

lease {
  interface "enp6s18";
  fixed-address 192.168.7.197;
  option subnet-mask 255.255.255.0;
  option routers 192.168.7.11;
  option dhcp-lease-time 180;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.7.11;
  option dhcp-server-identifier 192.168.7.11;
  option dhcp-renewal-time 79;
  option rfc3442-classless-static-routes 24,192,168,20,192,168,20,11,0,192,168,20,10;
  option broadcast-address 192.168.7.255;
  option dhcp-rebinding-time 143;
  option host-name "dock";
  option domain-name "br8.sun.[redacted]";
  renew 4 2024/04/25 06:32:39;
  rebind 4 2024/04/25 06:33:57;
  expire 4 2024/04/25 06:34:34;
}

The dmesg ends with the following suspicious messages:

Code: Select all

[    3.286916] audit: type=1400 audit(1714023676.988:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=464 comm="apparmor_parser"
[    3.286921] audit: type=1400 audit(1714023676.988:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=464 comm="apparmor_parser"
[    3.286923] audit: type=1400 audit(1714023676.988:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=464 comm="apparmor_parser"

They are suspicious because the paths '/usr/lib/NetworkManager/nm-dhcp-helper' and '/usr/lib/connman/scripts/dhclient-script' do not exist, although '/usr/sbin/dhclient-script' does exist.
However, '/usr/sbin/dhclient-script' is not installed by any package ('dpkg -S /usr/sbin/dhclient' reports 'dpkg-query: no path found matching pattern /usr/sbin/dhclient-script').
The files named 'nm-dhcp-client.action' and 'nm-dhcp-helper' do not exist anywhere (i.e., 'find / -name nm-dhcp-helper' finds nothing; dpkg -S finds no owner package)

On my network, as seen in the lease above from option 121/rfc3442-classless-static-routes, the default prefix /0 is routed via 192.168.20.10 which is not in the same subnet as the lease address 192.168.7.197/24; this is arguably a misconfiguration for leases in the 192.168.7.0/24 subnet, but other DHCP clients correctly use the the 192.168.7.11 default router, and I would expect the debian dhcp client hooks to also see 192.168.20.10 as a "non-applicable" configuration, and not a reason to leave the machine in an unusable state.

The absence of '/usr/lib/connman/scripts/dhclient-script' seems like a smoking gun to me.

If I reinstall from the same ISO, but with the default Desktop environment (gnome):
- the dmesg suspicious messages do not appear.
- the 'network-manager: /usr/lib/NetworkManager/nm-dhcp-helper' ownership exists in dpkg
- the '/usr/lib/connman/scripts/dhclient-script' file still does not exist
- the dhclient process is not running
- the routing table reflects option 121 supplied by the DHCP server, while the 192.168.7.11 is still not used as default, as shown below
- there are no (lease) files in '/var/lib/dhcp/'

Code: Select all

root@dock:~# ip route list
default via 192.168.20.10 dev ens18 proto dhcp src 192.168.7.127 metric 100
192.168.7.0/24 dev ens18 proto kernel scope link src 192.168.7.127 metric 100
192.168.20.0/24 via 192.168.20.11 dev ens18 proto dhcp src 192.168.7.127 metric 100
192.168.20.10 dev ens18 proto dhcp scope link src 192.168.7.127 metric 100
192.168.20.11 dev ens18 proto dhcp scope link src 192.168.7.127 metric 100

In this case (with a desktop environment), the network system is more functional, but dhclient is not running.

[FreewheelinFrank]

@rh009

Output should be in code tags please, not formatted text. Please edit your post. Thank you.

[rh009]

I see the same symptoms, but also have some differences in my circumstances:

[...]

Code: Select all

lease {
  interface "enp6s18";
  fixed-address 192.168.7.197;
  option subnet-mask 255.255.255.0;
  option routers 192.168.7.11;
  option dhcp-lease-time 180;
  option dhcp-message-type 5;
  option domain-name-servers 192.168.7.11;
  option dhcp-server-identifier 192.168.7.11;
  option dhcp-renewal-time 79;
  option rfc3442-classless-static-routes 24,192,168,20,192,168,20,11,0,192,168,20,10;
  option broadcast-address 192.168.7.255;
  option dhcp-rebinding-time 143;
  option host-name "dock";
  option domain-name "br8.sun.[redacted]";
  renew 4 2024/04/25 06:32:39;
  rebind 4 2024/04/25 06:33:57;
  expire 4 2024/04/25 06:34:34;
}

Following up with additional discoveries:

During the graphical installation, I opened another console and inspected the default routes and lease, and they are as I would expect, with some notable differences:

Code: Select all

~ # cat /var/lib/udhcp/udhcpc.leases
lease {
  interface "ens18";
  fixed-address 192.168.7.139;
  filename "";
  option subnet-mask 255.255.255.0;
  option domain-name "br8.sun.[redacted]";
  option host-name "";
  option domain-name-servers 192.168.7.11;
  option dhcp-server-identifier 192.168.7.11;
  option dhcp-lease-time 180;
  option routers 192.168.7.11;
  option ntp-servers ;
}
~ # ip route list
default via 192.168.20.11 dev ens18
192.168.7.0/24 dev ens18 scope link  src 192.168.7.139

So, during installation, the relevant lease file is /var/lib/udhcp/udhcpd.leases (compared to /var/lib/dhcp... on finished installation) and does not include option 121. Does udhcpd ignore the unrecognized option? Without option 121 support, the default route is set to 192.168.7.11 as I would expect.

My conclusion so far is that the installer uses a different dhcp client that the installed distro, and the 'network-manager' package is absent when the desktop environment is not installed, but present when GNOME is selected (although, in this case, the dhcpclient is not running - how can the system maintain a valid ip? does it periodically call dhcpclient in one-shot mode?). Further, the installed state relies on some files like '/usr/lib/connman/scripts/dhclient-script' and '/usr/sbin/dhclient-script' which are not owned by any package, but seem to have been hacked in at some stage.

Given all this insight, I'm certain I could devise a workaround/fix, but I feel no hacking should be necessary.

[CwF]

Further, the installed state relies on some files like '/usr/lib/connman/scripts/dhclient-script' and '/usr/sbin/dhclient-script' which are not owned by any package, but seem to have been hacked in at some stage.

Code: Select all

~$  dpkg -S dhclient-script
isc-dhcp-client: /usr/share/man/man8/dhclient-script.8.gz
isc-dhcp-client: /sbin/dhclient-script

[rh009]

Further, the installed state relies on some files like '/usr/lib/connman/scripts/dhclient-script' and '/usr/sbin/dhclient-script' which are not owned by any package, but seem to have been hacked in at some stage.

Code: Select all

~$  dpkg -S dhclient-script
isc-dhcp-client: /usr/share/man/man8/dhclient-script.8.gz
isc-dhcp-client: /sbin/dhclient-script

Your output does not explain the paths '/usr/lib/connman/scripts/dhclient-script' and '/usr/sbin/dhclient-script'

The compooter would not mistake '/usr/lib/connman/scripts/dhclient-script' or '/usr/sbin/dhclient-script' for '/sbin/dhclient-script', would it?

What does 'dpkg -S /usr/sbin/dhclient-script' output on your compooter ?

To be clear, I use the made-up word 'compooter' to express irritation. I posted here in search of an intelligent answer to the same question that the OP had in 2021, not the I received above.

[CwF]

The dmesg ends with the following suspicious messages:

Code: Select all

[    3.286916] audit: type=1400 audit(1714023676.988:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=464 comm="apparmor_parser"
[    3.286921] audit: type=1400 audit(1714023676.988:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=464 comm="apparmor_parser"
[    3.286923] audit: type=1400 audit(1714023676.988:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/connman/scripts/dhclient-script" pid=464 comm="apparmor_parser"

They are suspicious because the paths

I don't think they are suspicious. It's a simple query about default config info that may or may not be relevant if found. If not installed, not found.

[dlu2021]

My conclusion so far is that the installer uses a different dhcp client that the installed distro, and the 'network-manager' package is absent when the desktop environment is not installed, but present when GNOME is selected (although, in this case, the dhcpclient is not running - how can the system maintain a valid ip?

When you install without a DE, it defaults to using the ifupdown package:

https://wiki.debian.org/NetworkConfiguration

[rh009]

When you install without a DE, it defaults to using the ifupdown package:

https://wiki.debian.org/NetworkConfiguration

Thanks for this explanation.

I have looked a bit more into the issue, and found a root cause and two solutions. I marked this post as [solved] because it solves my problem, but I don't know if it would solve the OP's issue.

My conclusion:

• the isc-dhcp-client package is used when the DE is not installed, and this package has broken rfc3442 (static classless routes) error handling. The included rfc3442-classless-routes exit hook script fails to install the routes if the link has multiple subnets configured. The ISC has EOL'd this client, so this bug probably won't be fixed upstream.
• the udhcpcd package is used by the debian installer. It does not support RFC3442 at all, so it uses the regular router option.
• the network-manager package is used when DE is installed, and it uses a DHCP client based on nettools n-dhcp4 library, it supports RFC3442 and handles complex static classless routes correctly, unlike the ISC client.

The solution I am adopting, ("works for me") is:

1. apt-get remove isc-dhcp-client && apt-get install udpcpcd && reboot - ie, switch to the busybox client, udhcpcd, and,
2. change my DHCP server configuration to serve ISC-compatible routes, and make a note of the needed compatibility workaround, in case other Debian/derivative computers are added to my network for which I do not control the DHCP client (BYOD).

[CwF]

apt-get install udpcpcd

Code: Select all

$  apt policy udpcpcd
N: Unable to locate package udpcpcd

?
https://packages.debian.org/search?suit ... ds=udpcpcd
?

[fabien]

Code: Select all

$  apt policy udpcpcd
N: Unable to locate package udpcpcd

?
https://packages.debian.org/search?suit ... ds=udpcpcd
?

Probably udhcpc

Code: Select all

Package: udhcpc
Source: busybox (1:1.35.0-4)
Version: 1:1.35.0-4+b3
Installed-Size: 23 kB
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Architecture: amd64
Depends     ▼
 busybox (>>1:1.35.0)|busybox-static (>>1:1.35.0)
Description-en: Provides the busybox DHCP client implementation
 Busybox contains a very small yet fully functional RFC compliant DHCP
 client formerly known as udhcpc.
 .
 This package contains the glue to use the busybox udhcpc as DHCP
 client in the system by providing the appropriate symbolic links and
 scripts.
Multi-Arch: same
Homepage: http://www.busybox.net
Tag: network::client, protocol::dhcp, role::program
Section: net
Priority: optional
Filename: pool/main/b/busybox/udhcpc_1.35.0-4+b3_amd64.deb
Size: 6.3 kB


Package: udhcpd
Source: busybox (1:1.35.0-4)
Version: 1:1.35.0-4+b3
Installed-Size: 39 kB
Maintainer: Debian Install System Team <debian-boot@lists.debian.org>
Architecture: amd64
Pre-Depends ▼
 init-system-helpers (>=1.54~)
Depends     ▼
 busybox (>>1:1.35.0)|busybox-static (>>1:1.35.0), lsb-base
Provides    ▼
 dhcpd
Description-en: Provides the busybox DHCP server implementation
 Busybox contains a very small yet fully function RFC compliant DHCP
 server formerly known as udhcpd.
 .
 This package contains the glue to use the busybox udhcpd as DHCP
 server in the system by providing the appropriate symbolic links and
 scripts.
Homepage: http://www.busybox.net
Tag: interface::daemon, network::server, protocol::dhcp, role::program
Section: net
Priority: optional
Filename: pool/main/b/busybox/udhcpd_1.35.0-4+b3_amd64.deb
Size: 9.1 kB

Since isc-dhcp-client could be removed in Trixie, I test dhcpcd-base and it works fine and is lighter. I don't know if this would be a solution to @rh009's problem.

Code: Select all

Package: dhcpcd-base
Status:  install ok installed - manually
Source: dhcpcd5
Version: 9.4.1-24~deb12u3
Installed-Size: 501 kB
Maintainer: Martin-Éric Racine <martin-eric.racine@iki.fi>
Architecture: amd64
Depends     ▼
 adduser, libc6 (>=2.34), libudev1 (>=183)
Recommends  ▼
 wpasupplicant
Suggests    ▼
 resolvconf|openresolv|systemd-resolved
Provides    ▼
 dhcp-client
Conflicts   ▼
 dhcpcd5 (<<9.4.1-2)
Description-en: DHCPv4 and DHCPv6 dual-stack client (binaries and exit hooks)
 dhcpcd provides seamless IPv4 and IPv6 auto-configuration:
  * DHCPv4 client
  * DHCPv6 client with Prefix Delegation (PD) support
  * IPv4 LL support (ZeroConf)
  * IPv6 SLAAC support
  * ARP address conflict resolution
  * ARP ping profiles
  * Wireless SSID profiles
 .
 This package provides the binaries, exit hooks and manual pages.
 .
 It offers a dual-stack substitute for ISC DHCP Client (dhclient) on systems
 where interfaces are configured by ifupdown via </etc/network/interfaces>
 using the DHCP method.
 .
 The init.d script and systemd service required for systems without ifupdown
 are packaged separately as dhcpcd.
 .
 Since Debian 12 (Bookworm), dhcpcd uses Predictable Network Interface Names
 on Linux ports. See NEWS.Debian for more details.
Homepage: https://roy.marples.name/projects/dhcpcd
Section: net
Priority: optional
Filename: pool/main/d/dhcpcd5/dhcpcd-base_9.4.1-24~deb12u3_amd64.deb
Size: 199 kB