[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