From owner-freebsd-net@FreeBSD.ORG Sat Jan 20 19:40:12 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E2B6816A401 for ; Sat, 20 Jan 2007 19:40:12 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from gw.sandvine.com (sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id 931A813C461 for ; Sat, 20 Jan 2007 19:40:10 +0000 (UTC) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com ([192.168.1.10]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Jan 2007 14:28:08 -0500 Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 20 Jan 2007 14:28:07 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id BD5B011706; Sat, 20 Jan 2007 14:28:07 -0500 (EST) Date: Sat, 20 Jan 2007 14:28:07 -0500 From: Ed Maste To: freebsd-net@freebsd.org Message-ID: <20070120192807.GA1326@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 20 Jan 2007 19:28:08.0075 (UTC) FILETIME=[1D48C5B0:01C73CC9] Subject: inet_pton and oddly-formatted addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2007 19:40:13 -0000 It turns out an application at work is passing an IP address to inet_pton that is formatted slightly strangely; it ends up being something of the form 1.002.3.4. In 4.x inet_pton reports this as valid and returns 1.2.3.4. (I also checked that it's just ignoring the leading zeros, not parsing the octet as octal.) On my 5.x and 6.x machines, inet_pton rejects this string as invalid. I discussed this briefly with bz@, who pointed out two relevant RFCs. RFC 3493 has this to say: The inet_pton() function shall convert an address in its standard text presentation form into its numeric binary form. ... It shall return 0 if the input is not a valid IPv4 dotted-decimal string... The claim can easily be made that 1.002.3.4 is not "standard text presentation form." On the other hand, rfc 820 implies that 1.002.3.4 is a valid dotted decimal form: One commonly used notation for internet host addresses divides the 32-bit address into four 8-bit fields and specifies the value of each field as a decimal number with the fields separated by periods. This is called the "dotted decimal" notation. For example, the internet address of ISIF in dotted decimal is 010.002.000.052, or 10.2.0.52. I think an address like 1.002.3.4 is bizarre, but is our inet_pton incorrect in rejecting it? -ed