Package: bootp
Version: 2.4.3-19.1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: dorf...@est.org
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
We tried to set up a bootpd/bootpc testbed to implement a solution
for a customer who requires bootp support. We installed bootp on one
Debian 12 host, and bootpc on another.
the bootpc process never gets responses from the bootp server,
despite the fact that the responses are sent and received by the
client's NIC.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Packet inspection on server & client. Also ran dropwatch on client.
We can see the kernel dropping the replies. With tcpdump, we can
see that the replies use a DST IP ADDR value of the IP address that
is not yet configured on the client. It is normal behavior for the
kernel to drop packets for non-local IP destinations.
We tried removing the :ip: tag from the client's bootptab entry.
This resulted in DST IP ADDR changing to 0.0.0.0, which is valid,
and bootpc process received and processed the reply. However this
is not an adequate solution, since it does not give the client an
IP address.
We also tried using the --serverbcast option on the client. This
results in bootpd sending replies to the subnet broadcast address.
This fails for the same reason: The client does not have an IP
configuration yet, so the kernel does not consider the subnet
broadcast address local.
We also tried using iptables to NAT addres--map the replies to
255.255.255.255. This works, the kernel delivers the reply to the
bootpc process, and it processes them. However it is a hack that
should not be necessary.
* What was the outcome of this action?
There is no possible configuration of bootpd and the corresponding
bootpc packages on Linux that successfully communicate an IP
configuration from server to client.
* What outcome did you expect instead?
- In unicast (default) mode, bootpd should still use a global broadcast IP
address as the IP destination. This mode should only be a unicast
at the MAC layer
- In broadcast mode, bootpd should use a global rather than subnet IP
broadcast address as the IP destination.
- If there is a valid use case for these destination IP choices,
there should be configuration or command line options to instruct
the server to use global broadcast destination addresses
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 6.1.0-13-arm64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bootp depends on:
ii libc6 2.36-9+deb12u3
ii netbase 6.4
ii update-inetd 4.53
bootp recommends no packages.
bootp suggests no packages.
-- Configuration Files:
/etc/bootptab changed:
.est-default:\
:sm=255.255.255.0:\
:gw=10.0.1.1:\
:ds=10.0.1.1:\
:hn:
gw-est:ht=1:ha=3c5cf167d2ad:ip=10.0.1.1:tc=.est-default
client-ad02-est:\
:ht=1:\
:ha=0xea4a1fad0002:\
:ip=10.0.1.198:\
:tc=.est-default:
-- no debconf information
