It looks, to me, like someone fixed a problem in the wrong place. I would certainly entertain the patch, especially if it included logic to make sure mp->hostname doesn’t overrun. Not likely since the DHCP option is limited to the same size but it’s still good practice. What I am not sure of is NUL in DHCP hostname strings – I remember reading somewhere it’s optional, so I suspect that means the TLV length is used to determine the string length; meaning it might be possible to have a hostname that is 64 printable characters long. Maybe.
Chris. From: Jon Loeliger [mailto:[email protected]] Sent: Thursday, April 27, 2017 11:28 To: Luke, Chris <[email protected]> Cc: vpp-dev <[email protected]> Subject: Re: [vpp-dev] A Curious DHCP Hostname Terminator Choice On Wed, Apr 26, 2017 at 3:37 PM, Luke, Chris <[email protected]<mailto:[email protected]>> wrote: Definitely looks spurious to me. Chris. Spurious or wrong? Will folks entertain a patch converting that newline to a 0? jdl From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Jon Loeliger Sent: Wednesday, April 26, 2017 4:24 PM To: vpp-dev <[email protected]<mailto:[email protected]>> Subject: [vpp-dev] A Curious DHCP Hostname Terminator Choice Hi Guys, Way over in src/vnet/dhcp/dhcp_api.c, we find the function clib_memcpy (&mp->hostname, hostname, vec_len (hostname)); mp->hostname[vec_len (hostname) + 1] = '\n'; clib_memcpy (&mp->host_address[0], host_address, 16); clib_memcpy (&mp->router_address[0], router_address, 16);
_______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
