This code is surely unused and there are not even commented out
references to the function name. Drop the code.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

This migrates the last user of the legacy LED API, IMX233-OLinuXino, to
the modern LED framework.

The current implementation does the following:
 - lit the LED when booting,
 - turn off the LED the moment a BOOTP packet is received,

The first step is easily reproduced by using the
/options/u-boot/boot-led property to point at the LED. Unfortunately,
the boot-led is only lit by U-Boot proper at the very end of the boot
process, much later than currently. We can however force the LED on
whenever the GPIO LED driver is bound by marking the LED as
default-state = "on", and this happens slightly before board_init() is
called. We then do not need /options/u-boot/boot-led property for that
anymore.

However, the second step relies on /options/u-boot/boot-led and
CONFIG_LED_BOOT being set to reproduce the same behavior and requires us
to migrate net/bootp.c to the modern LED framework at the same time to
keep bisectability.

I couldn't figure out how to map CONFIG_LED_STATUS_BIT=778 to an actual
GPIO on the SoC but according to the schematics[1] only one LED is
present. I couldn't also map the SoC pin number to an actual GPIO from
the IMX23 manual, but there's already one GPIO LED specified in the
Device Tree so my guess is all of those are one and the same.

This was only build tested as I do not own this device.

[1] https://github.com/OLIMEX/OLINUXINO/blob/master/HARDWARE/iMX233-OLinuXino-Mini/1.%20Latest%20hardware%20revision/iMX233-OLINUXINO-MINI%20hardware%20revision%20E/iMX233-OLINUXINO-MINI_Rev_E.pdf

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>

CVE-2024-42040 describes a possible buffer overflow when calling
bootp_process_vendor() in bootp_handler() since the total length
of the packet is passed to bootp_process_vendor() without being
reduced to len-(offsetof(struct bootp_hdr,bp_vend)+4).

The packet length is also checked against its minimum size to avoid
reading data from struct bootp_hdr outside of the packet length.

Signed-off-by: Paul HENRYS <paul.henrys_ext@softathome.com>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>

It has been over a decade since we had a platform that implemented the
bootp vendor extension support hook. Remove this option due to lack of
use.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Jerome Forissier <jerome.forissier@linaro.org>

The header of LiMon imported files reference a License file which
does not exist in U-Boot. Some files were forgotten when adding the
SPDX-License-Identifier.
The LiMon files were originally licensed under GPLv2 as can be seen in
commit [2ea91039].

Based on this commit, add the correct SPDX license identifier.
While at it drop the reference to the non-existing License file from all
LiMon files and update the SPDX-License-Identifier to SPDX version 3.

Signed-off-by: Max Merchel <Max.Merchel@ew.tq-group.com>

DHCP and DHCPv6 use the same value defined in
https://www.iana.org/assignments/dhcpv6-parameters#processor-architecture
to encode the processor architecture type. We should only use a single
Kconfig symbol for both protocols.

Furthermore we should make the value customizable. This allows for instance
to choose between "x86 BIOS" or "x64 UEFI".

As "x86 BIOS" is encoded as 0, we should not use this value to switch
off transmission of the DHCP option. Use 0xFF instead.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Tom Rini <trini@konsulko.com>

Sean Edmond <seanedmond@microsoft.com> says:

In our datacenter application, a single DHCP server is servicing 36000+ clients.
Improvements are required to the DHCPv4 retransmission behavior to align with
RFC and ensure less pressure is exerted on the server:
- retransmission backoff interval maximum is configurable
  (environment variable bootpretransmitperiodmax)
- initial retransmission backoff interval is configurable
  (environment variable bootpretransmitperiodinit)
- transaction ID is kept the same for each BOOTP/DHCPv4 request
  (not recreated on each retry)

For our application we'll use:
- bootpretransmitperiodmax=16000
- bootpretransmitperiodinit=2000

A new configuration BOOTP_RANDOM_XID has been added to enable a randomized
BOOTP/DHCPv4 transaction ID.

Enhance DHCPv4 sending/parsing option 209 (PXE config file).  A previous
patch was accepted.  A new patch fixes a possible double free() and
addresses latest review comments.

Link: https://lore.kernel.org/r/20240509023918.2504185-1-seanedmond@microsoft.com

The new config option BOOTP_RANDOM_XID will randomize the transaction ID
for each new BOOT/DHCPv4 exchange.

Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

This patch introduces 3 improvements to align with RFC 951:
- retransmission backoff interval maximum is configurable
- initial retranmission backoff interval is configurable
- transaction ID is kept the same for each BOOTP/DHCPv4 request

In applications where thousands of nodes are serviced by a single DHCP
server, maximizing the retransmission backoff interval at 2 seconds (the
current u-boot default) exerts high pressure on the DHCP server and
network layer.

RFC 951 “7.2. Client Retransmission Strategy” states that the
retransmission backoff interval should be limited to 60 seconds.  This
patch allows the interval to be configurable using the environment
variable "bootpretransmitperiodmax"

The initial retranmission backoff period defaults to 250ms, which is
also too small for these scenarios with many clients.  This patch makes
the initial retransmission interval to be configurable using the
environment variable "bootpretransmitperiodinit".

Also, on a retransmission it is not expected for the transaction ID to
change (only the 'secs' field should be updated). Let's save the
transaction ID and use the same transaction ID for each BOOTP/DHCPv4
exchange.

Signed-off-by: Sean Edmond <seanedmond@microsoft.com>

- Enable option 209 by default
- Set pxelinux_configfile to NULL to avoid potential double free
- change hardcoded 209 to a define

Signed-off-by: Sean Edmond <seanedmond@microsoft.com>