[SLOF] [PATCH v2 6/7] net-snk: Use transaction IDs in DHCPv4, too
Thomas Huth
thuth at redhat.com
Mon Jan 4 20:07:26 AEDT 2016
On 23.12.2015 03:00, Alexey Kardashevskiy wrote:
> On 12/22/2015 09:08 PM, Thomas Huth wrote:
>> Generate a proper transaction ID before sending DHCPv4 packets
>> and check whether the DHCPv4 replies contain that correct XID, too.
>>
>> Signed-off-by: Thomas Huth <thuth at redhat.com>
>> ---
>> clients/net-snk/app/netapps/netboot.c | 2 ++
>> clients/net-snk/app/netlib/dhcp.c | 17 +++++++++++++++--
>> clients/net-snk/app/netlib/dhcp.h | 1 +
>> 3 files changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/clients/net-snk/app/netapps/netboot.c
>> b/clients/net-snk/app/netapps/netboot.c
>> index 8592156..7edc35f 100644
>> --- a/clients/net-snk/app/netapps/netboot.c
>> +++ b/clients/net-snk/app/netapps/netboot.c
>> @@ -335,6 +335,8 @@ int dhcp(char *ret_buffer, filename_ip_t * fn_ip,
>> unsigned int retries, int flag
>> printf(" Requesting information via DHCP%s: ",
>> flags == F_IPV4 ? "v4" : flags == F_IPV6 ? "v6" : "");
>>
>> + if (flags != F_IPV6)
>> + dhcpv4_generate_transaction_id();
>> if (flags != F_IPV4)
>> dhcpv6_generate_transaction_id();
>>
>> diff --git a/clients/net-snk/app/netlib/dhcp.c
>> b/clients/net-snk/app/netlib/dhcp.c
>> index 5f26f3a..bd9c104 100644
>> --- a/clients/net-snk/app/netlib/dhcp.c
>> +++ b/clients/net-snk/app/netlib/dhcp.c
>> @@ -178,11 +178,18 @@ static uint32_t dhcp_server_ip = 0;
>> static uint32_t dhcp_siaddr_ip = 0;
>> static int8_t dhcp_filename[256];
>> static int8_t dhcp_tftp_name[256];
>> +static uint32_t dhcp_xid;
>>
>> static char * response_buffer;
>>
>> /*>>>>>>>>>>>>>>>>>>>>>>>>>>>> IMPLEMENTATION
>> <<<<<<<<<<<<<<<<<<<<<<<<<<<*/
>>
>> +void
>> +dhcpv4_generate_transaction_id(void)
>
> I'll apply it as is (thanks for this work :) ) but small nit for the
> future: since the initial commit, most changes in SLOF used the style
> when return value is on the same line as the function name, I'd suggest
> using this style.
I simply tried to adapt to the coding style in this file - most
functions are declared that way. But I certainly can do it differently
in the future if that's what is preferred. But maybe you should simply
commit a patch to fix up the coding style in that file? (and if you do,
please also change these ">>>>>> XXXX <<<<<<" comments there since these
">>>" and "<<<" are always confusing when you try to resolve a merge
conflict in these files).
Thomas
More information about the SLOF
mailing list