From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9B563A00E6 for ; Wed, 10 Jul 2019 21:13:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3CBA431FC; Wed, 10 Jul 2019 21:13:06 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 371563195 for ; Wed, 10 Jul 2019 21:13:05 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 79AFA7FDF8; Wed, 10 Jul 2019 19:13:04 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.208]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E8D81001B02; Wed, 10 Jul 2019 19:13:03 +0000 (UTC) From: Aaron Conole To: Stephen Hemminger Cc: dev@dpdk.org, Olivier Matz , Andrew Rybchenko , Ferruh Yigit , Michael Santana References: <20190710183342.6459-1-aconole@redhat.com> <20190710114230.7c171c7a@hermes.lan> Date: Wed, 10 Jul 2019 15:13:02 -0400 In-Reply-To: <20190710114230.7c171c7a@hermes.lan> (Stephen Hemminger's message of "Wed, 10 Jul 2019 11:42:30 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 10 Jul 2019 19:13:04 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] rte_ether: force format string for unformat_addr X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Stephen Hemminger writes: > On Wed, 10 Jul 2019 14:33:42 -0400 > Aaron Conole wrote: > >> rte_ether_unformation_addr is very lax in what it accepts now, including >> ethernet addresses formatted ambiguously as "x:xx:x:xx:x:xx". However, >> previously this behavior was enforced via the my_ether_aton which would >> fail ambiguously formatted values. >> >> Reported-by: Michael Santana >> Fixes: 596d31092d32 ("net: add function to convert string to ethernet address") >> Signed-off-by: Aaron Conole >> --- >> lib/librte_net/rte_ether.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/lib/librte_net/rte_ether.c b/lib/librte_net/rte_ether.c >> index 8d040173c..4f252b813 100644 >> --- a/lib/librte_net/rte_ether.c >> +++ b/lib/librte_net/rte_ether.c >> @@ -45,7 +45,8 @@ rte_ether_unformat_addr(const char *s, struct rte_ether_addr *ea) >> if (n == 6) { >> /* Standard format XX:XX:XX:XX:XX:XX */ >> if (o0 > UINT8_MAX || o1 > UINT8_MAX || o2 > UINT8_MAX || >> - o3 > UINT8_MAX || o4 > UINT8_MAX || o5 > UINT8_MAX) { >> + o3 > UINT8_MAX || o4 > UINT8_MAX || o5 > UINT8_MAX || >> + strlen(s) != RTE_ETHER_ADDR_FMT_SIZE - 1) { >> rte_errno = ERANGE; >> return -1; >> } >> @@ -58,7 +59,8 @@ rte_ether_unformat_addr(const char *s, struct rte_ether_addr *ea) >> ea->addr_bytes[5] = o5; >> } else if (n == 3) { >> /* Support the format XXXX:XXXX:XXXX */ >> - if (o0 > UINT16_MAX || o1 > UINT16_MAX || o2 > UINT16_MAX) { >> + if (o0 > UINT16_MAX || o1 > UINT16_MAX || o2 > UINT16_MAX || >> + strlen(s) != RTE_ETHER_ADDR_FMT_SIZE - 4) { >> rte_errno = ERANGE; >> return -1; >> } > > NAK > Skipping leading zero should be ok. There is no need for this patch. Is it intended to skip the leading 0? Why not the trailing 0? I'm not familiar with the format that is used here (example - X:XX:X:XX:X) It isn't described in any RFC I could find (but I only did a small search). Even in IEEE, the format is always a full octet. > The current behavior is superset of what standard ether_aton accepts. Okay, but it introduces a test failure for the cmdline tests and then that test will need a few lines removed for 'unsuccessful' formats. ether_aton is much more rigid in the formats it accepts, so the test case is enforcing that. I guess either the current behavior of this function changes (and since it is a new behavior of the cmdline parser, I would think it should be changed) or the test case should be changed to adopt it.