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:j...@netgate.com] Sent: Thursday, April 27, 2017 11:28 To: Luke, Chris <chris_l...@cable.comcast.com> Cc: vpp-dev <vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] A Curious DHCP Hostname Terminator Choice On Wed, Apr 26, 2017 at 3:37 PM, Luke, Chris <chris_l...@comcast.com<mailto:chris_l...@comcast.com>> wrote: Definitely looks spurious to me. Chris. Spurious or wrong? Will folks entertain a patch converting that newline to a 0? jdl From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> [mailto:vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>] On Behalf Of Jon Loeliger Sent: Wednesday, April 26, 2017 4:24 PM To: vpp-dev <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> 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 vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
