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 8D66BA00E6 for ; Wed, 10 Jul 2019 21:28:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 889E231FC; Wed, 10 Jul 2019 21:28:01 +0200 (CEST) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id BF3762C60 for ; Wed, 10 Jul 2019 21:27:59 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id a93so1705105pla.7 for ; Wed, 10 Jul 2019 12:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=vm+XgNOG/4ldnJBGzbhkl1qmr/vSCiydJV8vlpfn51k=; b=bjc51jzrnSEhGptSP5Zsbz/cP0mRaEqnya/frsLk+Qz2c7c8aeGTpjwmBSAmdAAhd3 H9G9Lnqay6Ynsfr9Q42444FvOOQKjoxs+qT3UliAniBzNDwkQcJ8FsVLjC1PisQlWmYZ pNPsYOUGYCamrMwvyW8wUbXoyjS+Y2UUNwUsjaGBxfdqBKwIPYMYMWp0MZ7dWuEp93N5 jcGuxNqrLGxtO3igwEokVXY+doEV4HQlJO4C01Fem0sv2pFi1d2qfx4BjZwrzA55qcdp 5hTWx26rwhMNnS31VSzCwj08Z1W/O2ojEJ7B70nzaTHgcja+r0KdCDyUCyvbPOVXOCVo ksyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=vm+XgNOG/4ldnJBGzbhkl1qmr/vSCiydJV8vlpfn51k=; b=s4OQ7W33sem0qmrFJ8oWzSBXAL3iNP/qx0HEBQQoOoh1k2lY8s8l2qaazkzzrVEdEs Qnon45ZFG/iOrt7utIT8zwY1IDS/S6R3aD9OnPP16NuQwunZ/Fdxhrp9yICykjmNxco3 vuD1mPwUHpaz8mkUmi45N8I2TklLOusyBJ4cRkGDOO5lUKiwO57rDZ8F+Jl84h31II/H 61/1JWYEr+K4gV010iqN+4C9JgqsPK+TYaPqiNL8+Knzl31q3IWXHWR7WQOEgtBafO9n MbNc6V0BvP6F1CkKL+kMKdyy40tMISb4zhbYowOb07sEBekFKTQzgZe0+k0IA/R9zi8u Jidg== X-Gm-Message-State: APjAAAXWNsqYfyF4m9yKR/1JuorYd/uxnFKRSFAVkIUwBR0oEcTHefGI 6rul1A1fdltxyEt/10r5ivk4AOz4i6w= X-Google-Smtp-Source: APXvYqwQ/uc07GB98Sqp5w1NOUyGfTSoPdY9feCDjR0dtJOXm908nNyc7Uv1oaYzma3sUklIF7dPQA== X-Received: by 2002:a17:902:28c9:: with SMTP id f67mr41217455plb.19.1562786878797; Wed, 10 Jul 2019 12:27:58 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id n98sm3029294pjc.26.2019.07.10.12.27.58 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 10 Jul 2019 12:27:58 -0700 (PDT) Date: Wed, 10 Jul 2019 12:27:56 -0700 From: Stephen Hemminger To: Aaron Conole Cc: dev@dpdk.org, Olivier Matz , Andrew Rybchenko , Ferruh Yigit , Michael Santana Message-ID: <20190710122756.62ec19a9@hermes.lan> In-Reply-To: References: <20190710183342.6459-1-aconole@redhat.com> <20190710114230.7c171c7a@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" On Wed, 10 Jul 2019 15:13:02 -0400 Aaron Conole wrote: > 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. BSD ether_aton is: /* * Convert an ASCII representation of an ethernet address to binary form. */ struct ether_addr * ether_aton_r(const char *a, struct ether_addr *e) { int i; unsigned int o0, o1, o2, o3, o4, o5; i = sscanf(a, "%x:%x:%x:%x:%x:%x", &o0, &o1, &o2, &o3, &o4, &o5); if (i != 6) return (NULL); e->octet[0]=o0; e->octet[1]=o1; e->octet[2]=o2; e->octet[3]=o3; e->octet[4]=o4; e->octet[5]=o5; return (e); }