[U-Boot] [PATCH 1/2] net: Add bootfile in DHCP Request

[Joe Hershberger]

On Fri, Jan 22, 2016 at 2:08 PM, MESSIER, ALEXANDRE
<amessier at tycoint.com> wrote:
>> -----Original Message-----
>> From: Joe Hershberger [mailto:joe.hershberger at gmail.com]
>> Sent: January-22-16 2:35 PM
>> To: amessier.tyco at gmail.com
>> Cc: u-boot; Joe Hershberger; MESSIER, ALEXANDRE
>> Subject: Re: [U-Boot] [PATCH 1/2] net: Add bootfile in DHCP Request
>>
>> On Fri, Jan 22, 2016 at 1:22 PM,  <amessier.tyco at gmail.com> wrote:
>> > From: Alexandre Messier <amessier at tycoint.com>
>> >
>> > Add the bootfile name in the DHCP Request packet, in addition
>> > to it already being sent in the DHCP Discover.
>> >
>> > This is needed by some DHCP servers so that the bootfile name is
>> > properly returned by the server to the client in the DHCP Ack, as
>> > expected by U-Boot.
>> >
>> > Signed-off-by: Alexandre Messier <amessier at tycoint.com>
>> > ---
>> >  README      | 5 +++++
>> >  net/bootp.c | 3 +++
>> >  2 files changed, 8 insertions(+)
>> >
>> > diff --git a/README b/README
>> > index 0dc657d..05966ab 100644
>> > --- a/README
>> > +++ b/README
>> > @@ -2191,6 +2191,7 @@ CBFS (Coreboot Filesystem) support
>> >                 CONFIG_BOOTP_TIMEOFFSET
>> >                 CONFIG_BOOTP_VENDOREX
>> >                 CONFIG_BOOTP_MAY_FAIL
>> > +               CONFIG_BOOTP_DHCPREQ_BOOTFILE
>> >
>> >                 CONFIG_BOOTP_SERVERIP - TFTP server will be the serverip
>> >                 environment variable, not the BOOTP server.
>> > @@ -2231,6 +2232,10 @@ CBFS (Coreboot Filesystem) support
>> >                 the DHCP timeout and retry process takes a longer than
>> >                 this delay.
>> >
>> > +               CONFIG_BOOTP_DHCPREQ_BOOTFILE - Set the bootfile name in
>> > +               DHCPREQUEST packet, in addition to DHCPDISCOVER. This may be
>> > +               needed by some DHCP servers in specific cases.
>> > +
>> >   - Link-local IP address negotiation:
>> >                 Negotiate with other link-local clients on the local network
>> >                 for an address that doesn't require explicit configuration.
>> > diff --git a/net/bootp.c b/net/bootp.c
>> > index b2f8ad4..8da94cf 100644
>> > --- a/net/bootp.c
>> > +++ b/net/bootp.c
>> > @@ -918,6 +918,9 @@ static void dhcp_send_request_packet(struct
>> bootp_hdr *bp_offer)
>> >         net_write_ip(&bp->bp_giaddr, zero_ip);
>> >
>> >         memcpy(bp->bp_chaddr, net_ethaddr, 6);
>> > +#if defined(CONFIG_BOOTP_DHCPREQ_BOOTFILE)
>>
>> Does it hurt anything to send this in all cases? Does it really need a
>> config option to hide it?
>
> It is done this way to be sure not to impact anyone, in case someone has
> a DHCP server that does not handle the bootfile in the request properly.
>
> It works for us, but we don't have any way to test it more exhaustively.
> If anyone can test and/or confirm it does not impact anything, the config
> option can be removed.

I think if we just add it always and wait for someone to complain that
it can't work for them. If that happens, then we can add a config.

> In the other case, if we keep the option, I'll have to send an update to
> add it to kconfig.
>
>>
>> > +       copy_filename(bp->bp_file, net_boot_file_name, sizeof(bp-
>> >bp_file));
>> > +#endif
>> >
>> >         /*
>> >          * ID is the id of the OFFER packet
>> > --
>> > 1.8.3.1
>> >
>> > _______________________________________________
>> > U-Boot mailing list
>> > U-Boot at lists.denx.de
>> > https://urldefense.proofpoint.com/v2/url?u=http-
>> 3A__lists.denx.de_mailman_listinfo_u-2Dboot&d=CwIBaQ&c=0YGvTs3tT-
>> VMy8_v51yLDw&r=adEdfGeVvAp5D3jUKeOClnVoZZOSb93LtGg4Qgmpmjw&
>> m=CpBoSRS4ye1cP9RQb3QmksXKDd30VxXxno2acTLjzAA&s=i14g-1S2h7qY-
>> RuR6rb8Jot80682EPbPqx-NRB3pUaE&e=
>
> ________________________________
>
> This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.