From nobody@FreeBSD.org  Tue Aug 13 17:13:22 2002
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 4F93937B400
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 13 Aug 2002 17:13:22 -0700 (PDT)
Received: from www.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0F85F43E65
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 13 Aug 2002 17:13:22 -0700 (PDT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.12.4/8.12.4) with ESMTP id g7E0DLOT089831
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 13 Aug 2002 17:13:21 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.4/8.12.4/Submit) id g7E0DLqC089830;
	Tue, 13 Aug 2002 17:13:21 -0700 (PDT)
Message-Id: <200208140013.g7E0DLqC089830@www.freebsd.org>
Date: Tue, 13 Aug 2002 17:13:21 -0700 (PDT)
From: Jason Li <delphij@163.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ifconfig doesn't accept lladdr along with inet address family
X-Send-Pr-Version: www-1.0

>Number:         41647
>Category:       bin
>Synopsis:       ifconfig(8) doesn't accept lladdr along with inet address family
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-net
>State:          suspended
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 13 17:20:01 PDT 2002
>Closed-Date:    
>Last-Modified:  Sat Sep 23 15:02:25 GMT 2006
>Originator:     Jason Li
>Release:        4.6-STABLE
>Organization:
Frontfree Technology Network
>Environment:
FreeBSD cluster.frontfree.net 4.6-STABLE FreeBSD 4.6-STABLE #40: Tue Aug 13 18:34:38 CST 2002     root@cluster.frontfree.net:/usr/obj/usr/src/sys/FIREWALL  i386
>Description:
When synchronized with RELENG_4, the ifconfig was introduced with a strange behavior. It can't accept lladdr parameter along with inet address. This behavior should be considered as a bug, because when issuing ifconfig seperately with lladdr, then inet address family, it works well.

This problem should be something wrong with the ifconfig.c, when replaced with some version prior to 1.72.3(dated Wed Mar 20 17:55:07 2002 UTC), the problem goes away. I've checked the code, and I think the problem was with the command line parser.
>How-To-Repeat:
run ifconfig with some parameters similar to this(the adapter name could vary):

ifconfig fxp0 inet 10.1.1.254 netmask 0xffffff00 ether 00:20:af:7d:99:dc

but the ifconfig works well when issuing seperately:
ifconfig fxp0 inet 10.1.1.254 netmask 0xffffff00
then
ifconfig fxp0 ether 00:20:af:7d:99:dc

>Fix:
Workaround: Rollback the ifconfig.c to version 1.72.3 or prior, which could be downloaded from http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sbin/ifconfig/ifconfig.c?rev=1.72&content-type=text/plain
>Release-Note:
>Audit-Trail:

From: "Artem 'Zazoobr' Ignatjev" <timon@memphis.mephi.ru>
To: freebsd-gnats-submit@FreeBSD.org, delphij@163.com
Cc:  
Subject: bin/41647: ifconfig doesn't accept lladdr along with inet address family
Date: Wed, 14 Aug 2002 22:07:15 +0400

 	Well, now ifconfig.c is:
      $FreeBSD: src/sbin/ifconfig/ifconfig.c,v 1.51.2.15 2001/12/14 23:36:23 jlemon Exp $
 	And there is no more problem. But in pr you wrote:
 >> How-To-Repeat
 > ifconfig fxp0 inet 10.1.1.254 netmask 0xffffff00 ether 00:20:af:7d:99:dc
 ether keyword is unknown, but the following line works just fine:
 ifconfig fxp0 inet 10.1.1.254 netmask 0xffffff00 lladdr 00:20:af:7d:99:dc
 
 I think this one can be closed...
 			Sinceherely yours, Artem 'Zazoobr' Ignatjev.

From: "Jason Young" <jyoung8607@hotmail.com>
To: freebsd-gnats-submit@freebsd.org
Cc: ru@freebsd.org, jyoung@wantec.com
Subject: Re: bin/41647: ifconfig doesn't accept lladdr along with inet address family
Date: Fri, 29 Aug 2003 14:49:14 -0500

 Revision 1.73 of ifconfig.c implements a fix for bin/31476, permitting
 link-level addresses to be of arbitrary length. In the process, it
 converts 'ether' into an address family instead of an option/command.
 While it's logical to treat 'ether' as a true address family, ifconfig
 doesn't lend itself to configuring multiple address families
 simultaneously, which is what you are doing when you are touching 'inet'
 and 'ether'.
 
 Since bin/41467 indicates people were using this functionality, here is a
 patch against HEAD that turns ether (and link, and lladdr) back into
 options. It is mostly an updated version of Ruslan's first fix posted to
 bin/31476.
 
 All of these commands work now:
 
 ifconfig xl0 inet 10.1.1.1 netmask 255.255.255.0 lladdr 00:11:22:33:44:55
 ifconfig xl0 inet 10.1.1.1 netmask 255.255.255.0 link 00:11:22:33:44:55
 ifconfig xl0 inet 10.1.1.1 netmask 255.255.255.0 ether 00:11:22:33:44:55
 ifconfig xl0 lladdr 00:11:22:33:44:55
 ifconfig xl0 link 00:11:22:33:44:55
 ifconfig xl0 ether 00:11:22:33:44:55
 
 *** ifconfig.c.orig     Mon Apr 28 11:37:38 2003
 --- ifconfig.c  Fri Aug 29 00:59:36 2003
 ***************
 *** 168,178 ****
   c_func  setip6vltime;
   c_func2       setip6lifetime;
   c_func        setip6eui64;
   #endif
   c_func        setifipdst;
 ! c_func        setifflags, setifmetric, setifmtu, setifcap;
   c_func        clone_destroy;
 
 
   void clone_create(void);
 
 --- 168,178 ----
   c_func  setip6vltime;
   c_func2       setip6lifetime;
   c_func        setip6eui64;
   #endif
   c_func        setifipdst;
 ! c_func        setifflags, setifmetric, setifmtu, setiflladdr, setifcap;
   c_func        clone_destroy;
 
 
   void clone_create(void);
 
 ***************
 *** 282,291 ****
 --- 282,294 ----
         { "-netcons",   -IFCAP_NETCONS, setifcap },
         { "normal",     -IFF_LINK0,     setifflags },
         { "compress",   IFF_LINK0,      setifflags },
         { "noicmp",     IFF_LINK1,      setifflags },
         { "mtu",        NEXTARG,        setifmtu },
 +       { "ether",      NEXTARG,        setiflladdr },
 +       { "link",       NEXTARG,        setiflladdr },
 +       { "lladdr",     NEXTARG,        setiflladdr },
         { 0,            0,              setifaddr },
         { 0,            0,              setifdstaddr },
   };
 
   /*
 ***************
 *** 335,350 ****
         { "ipx", AF_IPX, ipx_status, ipx_getaddr, NULL,
              SIOCDIFADDR, SIOCAIFADDR, C(ridreq), C(addreq) },
   #endif
         { "atalk", AF_APPLETALK, at_status, at_getaddr, NULL,
              SIOCDIFADDR, SIOCAIFADDR, C(addreq), C(addreq) },
 -       { "link", AF_LINK, link_status, link_getaddr, NULL,
 -            0, SIOCSIFLLADDR, NULL, C(ridreq) },
 -       { "ether", AF_LINK, link_status, link_getaddr, NULL,
 -            0, SIOCSIFLLADDR, NULL, C(ridreq) },
 -       { "lladdr", AF_LINK, link_status, link_getaddr, NULL,
 -            0, SIOCSIFLLADDR, NULL, C(ridreq) },
   #if 0 /* XXX conflicts with the media command */
   #ifdef USE_IF_MEDIA
         { "media", AF_UNSPEC, media_status, NULL, NULL, }, /* XXX not real!! 
 */
   #endif
   #ifdef USE_VLANS
 --- 338,347 ----
 ***************
 *** 1030,1039 ****
 --- 1027,1068 ----
   {
         strncpy(ifr.ifr_name, name, sizeof (ifr.ifr_name));
         ifr.ifr_mtu = atoi(val);
         if (ioctl(s, SIOCSIFMTU, (caddr_t)&ifr) < 0)
                 warn("ioctl (set mtu)");
 + }
 +
 + void
 + setiflladdr(val, dummy, s, afp)
 +       const char *val;
 +       int dummy __unused;
 +       int s;
 +       const struct afswtch *afp;
 + {
 +       struct ether_addr       *ea;
 +       char *newval;
 +       struct sockaddr_dl      sdl;
 +
 +       if ((newval = malloc(strlen(val) + 1)) == NULL)
 +               errx(1, "malloc failed");
 +       newval[0] = ':';
 +       strcpy(newval + 1, val);
 +       sdl.sdl_len = sizeof(sdl);
 +       link_addr(newval, &sdl);
 +       free(newval);
 +       if (sdl.sdl_alen > sizeof(ifr.ifr_addr.sa_data)) {
 +               warn("malformed link-level address");
 +               return;
 +       }
 +       strncpy(ifr.ifr_name, name, sizeof (ifr.ifr_name));
 +       ifr.ifr_addr.sa_len = sdl.sdl_alen;
 +       ifr.ifr_addr.sa_family = AF_LINK;
 +       bcopy(LLADDR(&sdl), ifr.ifr_addr.sa_data, sdl.sdl_alen);
 +       if (ioctl(s, SIOCSIFLLADDR, (caddr_t)&ifr) < 0)
 +               warn("ioctl (set lladdr)");
 +
 +       return;
   }
 
   #define       IFFBITS \
   "\020\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6SMART\7RUNNING" \
   
 "\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX\15LINK0\16LINK1\17LINK2" 
 \
 
 Jason Young, CCIE #8607, MCSE
 Sr. Network Technician, WAN Technologies
 (314)817-0131
 http://www.wantec.com
 
 _________________________________________________________________
 Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige 
 using MSN Messenger http://entertainment.msn.com/imastar
 
Responsible-Changed-From-To: freebsd-bugs->bms 
Responsible-Changed-By: bms 
Responsible-Changed-When: Wed 1 Oct 2003 03:10:36 PDT 
Responsible-Changed-Why:  
I'll look into this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=41647 
State-Changed-From-To: open->analyzed 
State-Changed-By: bms 
State-Changed-When: Wed 1 Oct 2003 06:48:49 PDT 
State-Changed-Why:  
See feedback above 

http://www.freebsd.org/cgi/query-pr.cgi?pr=41647 

From: Bruce M Simpson <bms@spc.org>
To: freebsd-gnats-submit@FreeBSD.org, delphij@163.com
Cc: ru@freebsd.org, jyoung@wantec.com, harti@freebsd.org
Subject: bin/41647: ifconfig doesn't accept lladdr along with inet address family
Date: Wed, 1 Oct 2003 14:48:18 +0100

 I discussed the issue with nectar@ briefly.
 The submitter regards the issue as a regression and therefore a bug.
 
 The original motivation for the change may have been to ensure that an
 administratively-scoped link-layer address could be set from within
 rc.conf, but this is utter speculation on my part. I'd like to see
 feedback from committers who regularly use FreeBSD with link layers
 other than Ethernet on this point (harti@ Cc'd).
 
 nectar@ indicated that 'ifconfig foo <address-family>' must continue to
 work, as many scripts may depend on it (this is certainly true of the
 RC framework). The patch(es) submitted use the NEXTARG parameter to
 indicate that an argument must exist for the 'lladdr' option. Unfortunately
 this breaks the above requirement.
 
 Rather than further complicate the parser (KISS principle), the issue is
 probably better addressed from within the RC framework. The manual page
 should be updated to indicate that only a single address family can be
 configured per invocation of ifconfig(8).
 
 BMS

From: Harti Brandt <brandt@fokus.fraunhofer.de>
To: Bruce M Simpson <bms@spc.org>
Cc: freebsd-gnats-submit@FreeBSD.org, delphij@163.com,
	ru@FreeBSD.org, jyoung@wantec.com
Subject: Re: bin/41647: ifconfig doesn't accept lladdr along with inet address
 family
Date: Wed, 1 Oct 2003 17:42:48 +0200 (CEST)

 On Wed, 1 Oct 2003, Bruce M Simpson wrote:
 
 BMS>I discussed the issue with nectar@ briefly.
 BMS>The submitter regards the issue as a regression and therefore a bug.
 BMS>
 BMS>The original motivation for the change may have been to ensure that an
 BMS>administratively-scoped link-layer address could be set from within
 BMS>rc.conf, but this is utter speculation on my part. I'd like to see
 BMS>feedback from committers who regularly use FreeBSD with link layers
 BMS>other than Ethernet on this point (harti@ Cc'd).
 BMS>
 BMS>nectar@ indicated that 'ifconfig foo <address-family>' must continue to
 BMS>work, as many scripts may depend on it (this is certainly true of the
 BMS>RC framework). The patch(es) submitted use the NEXTARG parameter to
 BMS>indicate that an argument must exist for the 'lladdr' option. Unfortunately
 BMS>this breaks the above requirement.
 BMS>
 BMS>Rather than further complicate the parser (KISS principle), the issue is
 BMS>probably better addressed from within the RC framework. The manual page
 BMS>should be updated to indicate that only a single address family can be
 BMS>configured per invocation of ifconfig(8).
 
 Either way is no problem for the ATM stuff. ATM cards have ethernet
 addresses to form ATM addresses and those are handled at higher layers.
 Those adresses have to be configured with special tools.
 
 harti
 -- 
 harti brandt,
 http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
 brandt@fokus.fraunhofer.de, harti@freebsd.org

From: Ruslan Ermilov <ru@FreeBSD.org>
To: Bruce M Simpson <bms@spc.org>
Cc: bug-followup@FreeBSD.org, delphij@163.com, jyoung@wantec.com,
	harti@FreeBSD.org, "Jacques A. Vidrine" <nectar@FreeBSD.org>
Subject: Re: bin/41647: ifconfig doesn't accept lladdr along with inet address family
Date: Thu, 2 Oct 2003 11:28:02 +0300

 On Wed, Oct 01, 2003 at 02:48:18PM +0100, Bruce M Simpson wrote:
 > I discussed the issue with nectar@ briefly.
 > The submitter regards the issue as a regression and therefore a bug.
 > 
 > The original motivation for the change may have been to ensure that an
 > administratively-scoped link-layer address could be set from within
 > rc.conf, but this is utter speculation on my part. I'd like to see
 > feedback from committers who regularly use FreeBSD with link layers
 > other than Ethernet on this point (harti@ Cc'd).
 > 
 > nectar@ indicated that 'ifconfig foo <address-family>' must continue to
 > work, as many scripts may depend on it (this is certainly true of the
 > RC framework). The patch(es) submitted use the NEXTARG parameter to
 > indicate that an argument must exist for the 'lladdr' option. Unfortunately
 > this breaks the above requirement.
 > 
 I also insist this should continue to work.
 
 > Rather than further complicate the parser (KISS principle), the issue is
 > probably better addressed from within the RC framework. The manual page
 > should be updated to indicate that only a single address family can be
 > configured per invocation of ifconfig(8).
 > 
 I objected to your proposed "change" in another email, as this would be
 backwards -- this will barely revert my ifconfig.c,v 1.73 change, which
 turns "ether" into a generic "link" address family, and I don't want it
 to be reverted for a bunch of reasons.
 
 What you probably want to look into, is to teach ifconfig(8) to accept
 several "address" arguments (of different or of the same address family)
 in one invocation, so this command would work:
 
 ifconfig rl0 inet 192.168.4.115 inet 192.168.4.116/32 alias \
     ether 01:02:03:04:05:06
 
 This can be tricky to code, but would do what you want without breaking
 anything else.  The synopsis would become:
 
 ifconfig [-L] [-m] interface [create]
          [[address_family] [address [dest_address]] [parameters]] ...
 
 I'd be more than happy to review such a change for you.  ;)
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software Ltd,
 ru@FreeBSD.org		FreeBSD committer
State-Changed-From-To: analyzed->suspended 
State-Changed-By: bms 
State-Changed-When: Sat Sep 23 15:00:03 UTC 2006 
State-Changed-Why:  
Not a serious problem. These limitations can be worked around e.g. by 
using /etc/start_if.<ifname> scripts to set the ethernet addresses. 


Responsible-Changed-From-To: bms->freebsd-net 
Responsible-Changed-By: bms 
Responsible-Changed-When: Sat Sep 23 15:00:03 UTC 2006 
Responsible-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=41647 
>Unformatted:
