From dr146992@sac.sfbay.sun.com Wed May 5 17:29:15 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o460TEkF011307 for ; Wed, 5 May 2010 17:29:14 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o460TEdl006267; Wed, 5 May 2010 19:29:14 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00A012OQCJ00@brm-avmta-1.central.sun.com>; Wed, 05 May 2010 18:29:14 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00H1M2OP8Q80@brm-avmta-1.central.sun.com>; Wed, 05 May 2010 18:29:14 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o460TDiw013618; Wed, 05 May 2010 17:29:13 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o460TCXT011302; Wed, 05 May 2010 17:29:12 -0700 (PDT) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o460TCqR011298; Wed, 05 May 2010 17:29:12 -0700 (PDT) Date: Wed, 05 May 2010 17:29:12 -0700 (PDT) From: Darren Reed Subject: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] To: PSARC-ext@sun.com Message-id: <201005060029.o460TCqR011298@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2162 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: SIOCGIFHWADDR for PF_INET and PF_INET6 1.2. Name of Document Author/Supplier: Author: Darren Reed 1.3 Date of This Document: 05 May, 2010 4. Technical Description This case seeks to introduce a new ioctl for PF_INET and PF_INET6 sockets, SIOCGIFHWADDR. This ioctl is already supported for PF_PACKET sockets and is being brought into IP for better compatibility with open source projects. This case seeks minor binding. As this case is rather obvious and straight forward, I'm filing it as automatic approval. Details ======= For better or worse, various open source applications configure themselves at build time by looking for various symbols in header files. The presence of this particular symbol, SIOCGIFHWADDR, is taken to indicate that the kernel supports it on all of the relevant networking sockets. This becomes a problem when an attempt is made to compile open source applications such as nmap[1]. Without supporting this ioctl for PF_INET/PF_INET6, it would be necessary for an application wanting to use PF_PACKET (or BPF) to link against the DLPI library in order to lookup the MAC address of a network interface. Whilst functional, it is hardly desirable to develop in this fashion and most applications expect to function entirely with PF_PACKET, BPF or DLPI. At present, only the "struct ifreq" version of SIOCGIFHWADDR is planned as the primary focus of this effort is compatibility and a "struct lifreq" version of this ioctl is not present in other implementations. The work in this case does not preclude such an extension at a later time. The classification, semantics and stability for this ioctl on PF_INET and PF_INET6 sockets are the same as in PSARC/2009/232. [1] - nmap-dev mailing list http://seclists.org/nmap-dev/2010/q2/49 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From peter.memishian@oracle.com Thu May 6 00:22:48 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o467Mm3m006542 for ; Thu, 6 May 2010 00:22:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o467MmBo003324 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 May 2010 00:22:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00C07LU0D500@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 May 2010 00:22:48 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z00AELLTZOO00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 May 2010 00:22:48 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o467MlXX826513 for ; Thu, 06 May 2010 00:22:47 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o467Mljr826501; Thu, 06 May 2010 00:22:47 -0700 (PDT) Date: Thu, 06 May 2010 00:22:47 -0700 From: Peter Memishian Subject: re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] To: psarc-ext@sun.com Reply-to: peter.memishian@oracle.com Message-id: <19426.28231.837156.505510@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 356 I looked at the documentation for 2009/232 but didn't see the answer to a couple of semantic issues: * Does the SIOCGIFHWADDR fail if the given interface is not plumbed for the requested address family? * Does the SIOCGIFHWADDR fail if the given interface does not have a hardware address (e.g., IFF_LOOPBACK/IFF_IPMP interfaces)? -- meem From erik.nordmark@oracle.com Thu May 6 01:02:24 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4682O1l007300 for ; Thu, 6 May 2010 01:02:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4682OGg010796 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 01:02:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00607NO02S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 02:02:24 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z004JHNNZNF70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 02:02:24 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4682IhJ015970; Thu, 06 May 2010 08:02:18 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4682AVh013328; Thu, 06 May 2010 08:02:10 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 241753221273132845; Thu, 06 May 2010 01:00:45 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 01:00:44 -0700 Date: Thu, 06 May 2010 01:00:41 -0700 From: Erik Nordmark Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <201005060029.o460TCqR011298@sac.sfbay.sun.com> To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <4BE27729.8090209@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE27789.018F:SCFMA4539814,ss=1,fgs=0 References: <201005060029.o460TCqR011298@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 647 On 05/ 5/10 05:29 PM, Darren Reed wrote: > At present, only the "struct ifreq" version of SIOCGIFHWADDR is planned > as the primary focus of this effort is compatibility and a "struct lifreq" > version of this ioctl is not present in other implementations. The work > in this case does not preclude such an extension at a later time. If struct ifreq sufficiently large to return the hardware address (GUID) used for InfiniBand? Or do we need the larger struct lifreq for that? A sockaddr is only 16 bytes, which doesn't have room for a (20 byte?) GUID AFAICT. Thus I think it makes sense defining these ioctls using struct lifreq. Erik From Darren.Reed@sun.com Thu May 6 16:26:59 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46NQxMt020915 for ; Thu, 6 May 2010 16:26:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o46NQwpF003522 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 17:26:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000M05UGYFD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 16:26:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20006A5UGXQ820@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 16:26:58 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o46NQvrR006333 for ; Thu, 06 May 2010 23:26:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2000C00U98AH00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 00:26:50 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2000C0JUGOP200@fe-emea-09.sun.com>; Fri, 07 May 2010 00:26:49 +0100 (BST) Date: Thu, 06 May 2010 16:27:04 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE27729.8090209@oracle.com> Sender: Darren.Reed@sun.com To: Erik Nordmark Cc: Darren Reed , PSARC-ext@sun.com Message-id: <4BE35048.80706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201005060029.o460TCqR011298@sac.sfbay.sun.com> <4BE27729.8090209@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 841 On 6/05/10 01:00 AM, Erik Nordmark wrote: > On 05/ 5/10 05:29 PM, Darren Reed wrote: > >> At present, only the "struct ifreq" version of SIOCGIFHWADDR is planned >> as the primary focus of this effort is compatibility and a "struct >> lifreq" >> version of this ioctl is not present in other implementations. The work >> in this case does not preclude such an extension at a later time. > > If struct ifreq sufficiently large to return the hardware address > (GUID) used for InfiniBand? Or do we need the larger struct lifreq for > that? > > A sockaddr is only 16 bytes, which doesn't have room for a (20 byte?) > GUID AFAICT. > > Thus I think it makes sense defining these ioctls using struct lifreq. I will add SIOCGLIFHWADDR to the case (a "struct lifreq" version of the ioctl) and update PF_PACKET to support it as well. Darren From Darren.Reed@sun.com Thu May 6 17:31:03 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o470V3PZ022222 for ; Thu, 6 May 2010 17:31:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o470V1Ka007440 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 May 2010 19:31:02 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000H15XFQGM00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 17:31:02 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20006XVXFPQ640@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 17:31:01 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o470V0ji009287 for ; Fri, 07 May 2010 00:31:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2000J00XE90Q00@fe-emea-13.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 01:30:49 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2000B4EXFBVED0@fe-emea-13.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 01:30:49 +0100 (BST) Date: Thu, 06 May 2010 17:31:04 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19426.28231.837156.505510@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: peter.memishian@oracle.com Cc: psarc-ext@sun.com Message-id: <4BE35F48.3010902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 803 On 6/05/10 12:22 AM, Peter Memishian wrote: > I looked at the documentation for 2009/232 but didn't see the answer to a > couple of semantic issues: > > * Does the SIOCGIFHWADDR fail if the given interface is not plumbed > for the requested address family? > For PF_PACKET, the interface must be known to GLD, so it doesn't need to be plumbed, as such. For PF_INET and PF_INET6, yes, the interface must at least be plumb'd. > * Does the SIOCGIFHWADDR fail if the given interface does not have > a hardware address (e.g., IFF_LOOPBACK/IFF_IPMP interfaces)? > It will fail but for different reasons. For PF_PACKET, loopback and IPMP interface names are unknown to GLD, whereas at IP, the interface is not a hardware interface so there is no information to return. Darren From peter.memishian@oracle.com Thu May 6 17:56:44 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o470uiv3022768 for ; Thu, 6 May 2010 17:56:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o470ugYg006878; Thu, 6 May 2010 17:56:42 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000409YMI0X00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 17:56:42 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20002BSYMI5P20@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 17:56:42 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o470ueva773070; Thu, 06 May 2010 17:56:40 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o470uexh773058; Thu, 06 May 2010 17:56:40 -0700 (PDT) Date: Thu, 06 May 2010 17:56:40 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE35F48.3010902@Sun.COM> To: Darren Reed Cc: peter.memishian@oracle.com, psarc-ext@sun.com Reply-to: peter.memishian@oracle.com Message-id: <19427.25928.510001.563613@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 812 > > I looked at the documentation for 2009/232 but didn't see the answer to a > > couple of semantic issues: > > > > * Does the SIOCGIFHWADDR fail if the given interface is not plumbed > > for the requested address family? > > > > For PF_PACKET, the interface must be known to GLD, so it doesn't need to > be plumbed, as such. For PF_INET and PF_INET6, yes, the interface must > at least be plumb'd. That sounds like a datalink, not an interface. Given that the protocol family is PF_INET/PF_INET6, it seems like the namespace should be objects in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note that it is possible (though certainly not recommended) to have a datalink named foo0 and an interface named foo0 that have no relationship to one another.) -- meem From Darren.Reed@sun.com Thu May 6 18:33:59 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o471Xxm9023128 for ; Thu, 6 May 2010 18:33:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o471XxnX020321 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 May 2010 18:33:59 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L21004050CNQP00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 19:33:59 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L21009IG0CMYE60@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 19:33:58 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o471XuCj012913 for ; Fri, 07 May 2010 01:33:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2100000049HW00@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 02:33:35 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2100AQE0BP3000@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 02:33:27 +0100 (BST) Date: Thu, 06 May 2010 18:33:42 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19427.25928.510001.563613@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: peter.memishian@oracle.com Cc: psarc-ext@sun.com Message-id: <4BE36DF6.1090106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1004 On 6/05/10 05:56 PM, Peter Memishian wrote: > > > I looked at the documentation for 2009/232 but didn't see the answer to a > > > couple of semantic issues: > > > > > > * Does the SIOCGIFHWADDR fail if the given interface is not plumbed > > > for the requested address family? > > > > > > > For PF_PACKET, the interface must be known to GLD, so it doesn't need to > > be plumbed, as such. For PF_INET and PF_INET6, yes, the interface must > > at least be plumb'd. > > That sounds like a datalink, not an interface. Given that the protocol > family is PF_INET/PF_INET6, it seems like the namespace should be objects > in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note > that it is possible (though certainly not recommended) to have a datalink > named foo0 and an interface named foo0 that have no relationship to one > another.) I'm not sure that I understand what you're trying to say. Please expand and include an example. Darren From peter.memishian@oracle.com Thu May 6 20:17:35 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o473HZxv024397 for ; Thu, 6 May 2010 20:17:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o473HWsq049527; Thu, 6 May 2010 21:17:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2100H0D559GU00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 20:17:33 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L21006N8558Q8B0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 20:17:32 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o473HU1p412312; Thu, 06 May 2010 20:17:30 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o473HUnq412299; Thu, 06 May 2010 20:17:30 -0700 (PDT) Date: Thu, 06 May 2010 20:17:30 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE36DF6.1090106@Sun.COM> To: Darren Reed Cc: peter.memishian@oracle.com, psarc-ext@sun.com Reply-to: peter.memishian@oracle.com Message-id: <19427.34378.624185.251688@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 1469 > > That sounds like a datalink, not an interface. Given that the protocol > > family is PF_INET/PF_INET6, it seems like the namespace should be objects > > in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note > > that it is possible (though certainly not recommended) to have a datalink > > named foo0 and an interface named foo0 that have no relationship to one > > another.) > > I'm not sure that I understand what you're trying to say. I presume you're asking about the disjoint namespaces. Since IP interfaces are not necessarily instantiated from datalinks (e.g., vni(7D), loopback, and IPMP interfaces all exist only at the IP layer), there may be dormant datalinks with the same name. For instance, someone might create an IPMP interface named foo0 and may also have an unplumbed datalink named foo0 that has nothing do with that IPMP interface. If the admin has no need to use the datalink named foo0 for IP traffic, the two foo0's peacefully coexist. However, a PF_INET SIOCGIFHWADDR for foo0 unambiguously refers to the only IP object with that name (the IPMP interface), not the foo0 datalink that's unused. It seems like what you've proposed will erroneously return the hardware address for foo0 in this case. Note that this issue is particular to PF_INET/PF_INET6 -- other protocol families (e.g., PF_PACKET) are free to define the namespace associated wieth their objects -- which may well be datalinks. -- meem From Darren.Reed@sun.com Thu May 6 21:27:25 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o474ROXI025208 for ; Thu, 6 May 2010 21:27:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o474ROBX010702 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 May 2010 21:27:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2100L1B8DO3H00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 May 2010 22:27:24 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L21009WX8DMXSD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 May 2010 22:27:22 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o474RL4t024148 for ; Fri, 07 May 2010 04:27:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2100E008ACFG00@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 May 2010 05:27:08 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2100CTL8D7P220@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 May 2010 05:27:08 +0100 (BST) Date: Thu, 06 May 2010 21:27:22 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19427.34378.624185.251688@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: peter.memishian@oracle.com Cc: psarc-ext@sun.com Message-id: <4BE396AA.4090404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 2664 On 6/05/10 08:17 PM, Peter Memishian wrote: > > > > That sounds like a datalink, not an interface. Given that the protocol > > > family is PF_INET/PF_INET6, it seems like the namespace should be objects > > > in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note > > > that it is possible (though certainly not recommended) to have a datalink > > > named foo0 and an interface named foo0 that have no relationship to one > > > another.) > > > > I'm not sure that I understand what you're trying to say. > > I presume you're asking about the disjoint namespaces. > > Since IP interfaces are not necessarily instantiated from datalinks (e.g., > vni(7D), loopback, and IPMP interfaces all exist only at the IP layer), > there may be dormant datalinks with the same name. For instance, someone > might create an IPMP interface named foo0 and may also have an unplumbed > datalink named foo0 that has nothing do with that IPMP interface. If the > admin has no need to use the datalink named foo0 for IP traffic, the two > foo0's peacefully coexist. However, a PF_INET SIOCGIFHWADDR for foo0 > unambiguously refers to the only IP object with that name (the IPMP > interface), not the foo0 datalink that's unused. It seems like what > you've proposed will erroneously return the hardware address for foo0 in > this case. Note that this issue is particular to PF_INET/PF_INET6 -- > other protocol families (e.g., PF_PACKET) are free to define the namespace > associated wieth their objects -- which may well be datalinks. In this case, a SIOCGIFHWADDR on foo0 for PF_INET will return details for the IPMP interface (i.e. an error because there is no such thing as a hardware address for an IPMP interface). A SIOCGIFHWADDR on foo0 for PF_PACKET would return the hardware address associated with the physical interface that was rename to foo0. If an IP network interface could exist, without it having a datalink behind it, and have a physical address associated with it, then that would be returned. Whether or not that makes sense, is another matter and is not the subject of this case. I think the correct summary is: For PF_INET/PF_INET6, IP network interfaces are used. If no hardware address is available with the IP network interface then an error is returned. (This is what I meant by "it must be at least plumb'd", although perhaps that implied a datalink was involved when that isn't necessarily the case.) For PF_PACKET, datalinks are used and the primary unicast MAC address is returned. (There is no scope within this ioctl, as it is currently defined, for anything else to be returned.) Darren From peter.memishian@oracle.com Thu May 6 23:34:19 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o476YJaY026493 for ; Thu, 6 May 2010 23:34:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o476YGk9013281; Fri, 7 May 2010 00:34:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L210010FE94BO00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 23:34:16 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2100IWKE93G250@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 23:34:15 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o476YD2C635709; Thu, 06 May 2010 23:34:13 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o476YDHo635698; Thu, 06 May 2010 23:34:13 -0700 (PDT) Date: Thu, 06 May 2010 23:34:13 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE396AA.4090404@Sun.COM> To: Darren Reed Cc: peter.memishian@oracle.com, psarc-ext@sun.com Reply-to: peter.memishian@oracle.com Message-id: <19427.46181.476578.148719@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> <4BE396AA.4090404@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 1585 > In this case, a SIOCGIFHWADDR on foo0 for PF_INET will return > details for the IPMP interface (i.e. an error because there is > no such thing as a hardware address for an IPMP interface). > > A SIOCGIFHWADDR on foo0 for PF_PACKET would return the > hardware address associated with the physical interface > that was rename to foo0. Yes -- though established Solaris terminology considers the object a "datalink" instead of "physical interface" in the PF_PACKET case. > If an IP network interface could exist, without it having a > datalink behind it, and have a physical address associated > with it, then that would be returned. Whether or not that > makes sense, is another matter and is not the subject of > this case. Yes. > I think the correct summary is: > > For PF_INET/PF_INET6, IP network interfaces are used. If no > hardware address is available with the IP network interface > then an error is returned. (This is what I meant by "it must > be at least plumb'd", although perhaps that implied a datalink > was involved when that isn't necessarily the case.) > > For PF_PACKET, datalinks are used and the primary unicast MAC > address is returned. (There is no scope within this ioctl, as > it is currently defined, for anything else to be returned.) Yes. One final consideration: in the PF_INET / PF_INET6 case, if the interface is e.g. only plumbed for PF_INET and one performs a PF_INET6 SIOCGIFHWADDR, will ENXIO be returned? For consistency with with other SIOC* ioctls I'd expect so, but it is not explicitly stated above. -- meem From Darren.Reed@Sun.COM Fri May 7 14:09:29 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47L9Tu0005857 for ; Fri, 7 May 2010 14:09:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o47L9TrK012875 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 May 2010 14:09:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2200H01IRT7D00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 15:09:29 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2200AMZIRSD550@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 15:09:28 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o47L9RL0018447 for ; Fri, 07 May 2010 21:09:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2200L00IISJ800@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 22:08:52 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L22006AWIQQGY90@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 22:08:52 +0100 (BST) Date: Fri, 07 May 2010 14:09:08 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19427.46181.476578.148719@gargle.gargle.HOWL> Sender: Darren.Reed@Sun.COM To: peter.memishian@oracle.com Cc: psarc-ext@Sun.COM Message-id: <4BE48174.9070405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> <4BE396AA.4090404@Sun.COM> <19427.46181.476578.148719@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1758 On 6/05/10 11:34 PM, Peter Memishian wrote: > > In this case, a SIOCGIFHWADDR on foo0 for PF_INET will return > > details for the IPMP interface (i.e. an error because there is > > no such thing as a hardware address for an IPMP interface). > > > > A SIOCGIFHWADDR on foo0 for PF_PACKET would return the > > hardware address associated with the physical interface > > that was rename to foo0. > > Yes -- though established Solaris terminology considers the object a > "datalink" instead of "physical interface" in the PF_PACKET case. > > > If an IP network interface could exist, without it having a > > datalink behind it, and have a physical address associated > > with it, then that would be returned. Whether or not that > > makes sense, is another matter and is not the subject of > > this case. > > Yes. > > > I think the correct summary is: > > > > For PF_INET/PF_INET6, IP network interfaces are used. If no > > hardware address is available with the IP network interface > > then an error is returned. (This is what I meant by "it must > > be at least plumb'd", although perhaps that implied a datalink > > was involved when that isn't necessarily the case.) > > > > For PF_PACKET, datalinks are used and the primary unicast MAC > > address is returned. (There is no scope within this ioctl, as > > it is currently defined, for anything else to be returned.) > > Yes. > > One final consideration: in the PF_INET / PF_INET6 case, if the interface > is e.g. only plumbed for PF_INET and one performs a PF_INET6 > SIOCGIFHWADDR, will ENXIO be returned? For consistency with with other > SIOC* ioctls I'd expect so, but it is not explicitly stated above. > Yes, it will. Darren From Darren.Reed@sun.com Fri May 7 14:13:16 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47LDGHA005973 for ; Fri, 7 May 2010 14:13:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o47LDFkl051109 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 May 2010 15:13:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2200H0XIY34O00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 14:13:15 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2200745IY2HC20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 14:13:14 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o47LDDbx018633 for ; Fri, 07 May 2010 21:13:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2200600ILLUH00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 22:13:01 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L22002O1IXO6Y70@fe-emea-13.sun.com>; Fri, 07 May 2010 22:13:01 +0100 (BST) Date: Fri, 07 May 2010 14:13:17 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <201005060029.o460TCqR011298@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <4BE4826D.5050207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201005060029.o460TCqR011298@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1947 I've updated the spec as follows below. Darren This case seeks to introduce a new ioctl for PF_INET and PF_INET6 sockets, | SIOCGIFHWADDR. In addition, SIOCGLIFHWADDR will be introduced as a mate to | SIOCIGHWADDR. SIOCIFHWADDR ioctl is already supported for PF_PACKET sockets | and is being brought into IP for better compatibility with open source | projects. This case seeks minor binding. As this case is rather obvious | and straight forward, I'm filing it as automatic approval. Details ======= For better or worse, various open source applications configure themselves at build time by looking for various symbols in header files. The presence of this particular symbol, SIOCGIFHWADDR, is taken to indicate that the kernel supports it on all of the relevant networking sockets. This becomes a problem when an attempt is made to compile open source applications such | as nmap[1]. SIOCGLIFHWADDR is required to support Infiniband interfaces | where the hardware address will not fit inside the structure used by | SIOCGIFHWADDR. Without supporting these ioctls for PF_INET/PF_INET6, it would be necessary for an application wanting to use PF_PACKET (or BPF) to link against the DLPI library in order to lookup the MAC address of a network interface. Whilst functional, it is hardly desirable to develop in this fashion and most applications expect to function entirely with PF_PACKET, BPF or DLPI. | For PF_INET/PF_INET6, IP network interfaces are used for name lookups. If | no hardware address is available with the associated IP network interface | then then an error is returned. | For PF_PACKET, datalinks are used and the primary unicast MAC address is | returned. | The classificationand stability for both of these ioctls on PF_INET and | PF_INET6 sockets are the same as SIOCGIFHWADDR in PSARC/2009/232. [1] - nmap-dev mailing list http://seclists.org/nmap-dev/2010/q2/49 From peter.memishian@oracle.com Fri May 7 14:26:58 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47LQw2A006089 for ; Fri, 7 May 2010 14:26:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o47LQtM9057932; Fri, 7 May 2010 15:26:56 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2200K0ZJKWXA00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 May 2010 14:26:56 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L22007WSJKTHN20@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 May 2010 14:26:53 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o47LQq6S886459; Fri, 07 May 2010 14:26:52 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o47LQq1t886447; Fri, 07 May 2010 14:26:52 -0700 (PDT) Date: Fri, 07 May 2010 14:26:52 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE48174.9070405@Sun.COM> To: Darren Reed Cc: peter.memishian@oracle.com, PSARC-ext@sun.com Reply-to: peter.memishian@oracle.com Message-id: <19428.34204.160453.111653@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> <4BE396AA.4090404@Sun.COM> <19427.46181.476578.148719@gargle.gargle.HOWL> <4BE48174.9070405@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 798 > > One final consideration: in the PF_INET / PF_INET6 case, if the interface > > is e.g. only plumbed for PF_INET and one performs a PF_INET6 > > SIOCGIFHWADDR, will ENXIO be returned? For consistency with with other > > SIOC* ioctls I'd expect so, but it is not explicitly stated above. > > Yes, it will. OK, thanks for the clarifications. I think these semantics are all correct, though it means that using PF_PACKET / SIOCGIFHWADDR will really be what most applications want since most applications want a datalink's hardware address regardless of whether an IP interface has been plumbed on top of it. In any case, the subtle semantic distinctions between the three (PF_PACKET / PF_INET / PF_INET6) variants of SIOCGIFHWADDR would be valuable to capture in our manpages. -- meem From peter.memishian@Oracle.COM Mon May 10 12:45:55 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o470uiv3022768 for ; Thu, 6 May 2010 17:56:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o470ugYg006878; Thu, 6 May 2010 17:56:42 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000409YMI0X00@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 17:56:42 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20002BSYMI5P20@nwk-avmta-2.sfbay.sun.com>; Thu, 06 May 2010 17:56:42 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o470ueva773070; Thu, 06 May 2010 17:56:40 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o470uexh773058; Thu, 06 May 2010 17:56:40 -0700 (PDT) Date: Thu, 06 May 2010 17:56:40 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE35F48.3010902@Sun.COM> To: Darren Reed Cc: peter.memishian@Oracle.COM, psarc-ext@sun.com Reply-to: peter.memishian@Oracle.COM Message-id: <19427.25928.510001.563613@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 812 > > I looked at the documentation for 2009/232 but didn't see the answer to a > > couple of semantic issues: > > > > * Does the SIOCGIFHWADDR fail if the given interface is not plumbed > > for the requested address family? > > > > For PF_PACKET, the interface must be known to GLD, so it doesn't need to > be plumbed, as such. For PF_INET and PF_INET6, yes, the interface must > at least be plumb'd. That sounds like a datalink, not an interface. Given that the protocol family is PF_INET/PF_INET6, it seems like the namespace should be objects in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note that it is possible (though certainly not recommended) to have a datalink named foo0 and an interface named foo0 that have no relationship to one another.) -- meem From peter.memishian@Oracle.COM Mon May 10 12:47:44 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47LQw2A006089 for ; Fri, 7 May 2010 14:26:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o47LQtM9057932; Fri, 7 May 2010 15:26:56 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2200K0ZJKWXA00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 May 2010 14:26:56 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L22007WSJKTHN20@nwk-avmta-1.sfbay.Sun.COM>; Fri, 07 May 2010 14:26:53 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o47LQq6S886459; Fri, 07 May 2010 14:26:52 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o47LQq1t886447; Fri, 07 May 2010 14:26:52 -0700 (PDT) Date: Fri, 07 May 2010 14:26:52 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE48174.9070405@Sun.COM> To: Darren Reed Cc: peter.memishian@Oracle.COM, PSARC-ext@sun.com Reply-to: peter.memishian@Oracle.COM Message-id: <19428.34204.160453.111653@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> <4BE396AA.4090404@Sun.COM> <19427.46181.476578.148719@gargle.gargle.HOWL> <4BE48174.9070405@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 798 > > One final consideration: in the PF_INET / PF_INET6 case, if the interface > > is e.g. only plumbed for PF_INET and one performs a PF_INET6 > > SIOCGIFHWADDR, will ENXIO be returned? For consistency with with other > > SIOC* ioctls I'd expect so, but it is not explicitly stated above. > > Yes, it will. OK, thanks for the clarifications. I think these semantics are all correct, though it means that using PF_PACKET / SIOCGIFHWADDR will really be what most applications want since most applications want a datalink's hardware address regardless of whether an IP interface has been plumbed on top of it. In any case, the subtle semantic distinctions between the three (PF_PACKET / PF_INET / PF_INET6) variants of SIOCGIFHWADDR would be valuable to capture in our manpages. -- meem From erik.nordmark@oracle.com Mon May 10 12:51:22 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4682O1l007300 for ; Thu, 6 May 2010 01:02:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4682OGg010796 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 01:02:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L1Z00607NO02S00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 02:02:24 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Z004JHNNZNF70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 02:02:24 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4682IhJ015970; Thu, 06 May 2010 08:02:18 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4682AVh013328; Thu, 06 May 2010 08:02:10 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 241753221273132845; Thu, 06 May 2010 01:00:45 -0700 Received: from [10.7.251.248] (/10.7.251.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 06 May 2010 01:00:44 -0700 Date: Thu, 06 May 2010 01:00:41 -0700 From: Erik Nordmark Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <201005060029.o460TCqR011298@sac.sfbay.sun.com> To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <4BE27729.8090209@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE27789.018F:SCFMA4539814,ss=1,fgs=0 References: <201005060029.o460TCqR011298@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 647 On 05/ 5/10 05:29 PM, Darren Reed wrote: > At present, only the "struct ifreq" version of SIOCGIFHWADDR is planned > as the primary focus of this effort is compatibility and a "struct lifreq" > version of this ioctl is not present in other implementations. The work > in this case does not preclude such an extension at a later time. If struct ifreq sufficiently large to return the hardware address (GUID) used for InfiniBand? Or do we need the larger struct lifreq for that? A sockaddr is only 16 bytes, which doesn't have room for a (20 byte?) GUID AFAICT. Thus I think it makes sense defining these ioctls using struct lifreq. Erik From Darren.Reed@sun.com Mon May 10 12:53:14 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o470V3PZ022222 for ; Thu, 6 May 2010 17:31:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o470V1Ka007440 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 May 2010 19:31:02 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000H15XFQGM00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 17:31:02 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20006XVXFPQ640@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 17:31:01 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o470V0ji009287 for ; Fri, 07 May 2010 00:31:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2000J00XE90Q00@fe-emea-13.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 01:30:49 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2000B4EXFBVED0@fe-emea-13.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 01:30:49 +0100 (BST) Date: Thu, 06 May 2010 17:31:04 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19426.28231.837156.505510@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: peter.memishian@oracle.com Cc: psarc-ext@sun.com Message-id: <4BE35F48.3010902@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 803 On 6/05/10 12:22 AM, Peter Memishian wrote: > I looked at the documentation for 2009/232 but didn't see the answer to a > couple of semantic issues: > > * Does the SIOCGIFHWADDR fail if the given interface is not plumbed > for the requested address family? > For PF_PACKET, the interface must be known to GLD, so it doesn't need to be plumbed, as such. For PF_INET and PF_INET6, yes, the interface must at least be plumb'd. > * Does the SIOCGIFHWADDR fail if the given interface does not have > a hardware address (e.g., IFF_LOOPBACK/IFF_IPMP interfaces)? > It will fail but for different reasons. For PF_PACKET, loopback and IPMP interface names are unknown to GLD, whereas at IP, the interface is not a hardware interface so there is no information to return. Darren From Darren.Reed@sun.com Mon May 10 12:56:42 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o46NQxMt020915 for ; Thu, 6 May 2010 16:26:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o46NQwpF003522 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 6 May 2010 17:26:59 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2000M05UGYFD00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 16:26:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L20006A5UGXQ820@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 06 May 2010 16:26:58 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o46NQvrR006333 for ; Thu, 06 May 2010 23:26:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2000C00U98AH00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 00:26:50 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2000C0JUGOP200@fe-emea-09.sun.com>; Fri, 07 May 2010 00:26:49 +0100 (BST) Date: Thu, 06 May 2010 16:27:04 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE27729.8090209@oracle.com> Sender: Darren.Reed@sun.com To: Erik Nordmark Cc: Darren Reed , PSARC-ext@sun.com Message-id: <4BE35048.80706@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201005060029.o460TCqR011298@sac.sfbay.sun.com> <4BE27729.8090209@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 841 On 6/05/10 01:00 AM, Erik Nordmark wrote: > On 05/ 5/10 05:29 PM, Darren Reed wrote: > >> At present, only the "struct ifreq" version of SIOCGIFHWADDR is planned >> as the primary focus of this effort is compatibility and a "struct >> lifreq" >> version of this ioctl is not present in other implementations. The work >> in this case does not preclude such an extension at a later time. > > If struct ifreq sufficiently large to return the hardware address > (GUID) used for InfiniBand? Or do we need the larger struct lifreq for > that? > > A sockaddr is only 16 bytes, which doesn't have room for a (20 byte?) > GUID AFAICT. > > Thus I think it makes sense defining these ioctls using struct lifreq. I will add SIOCGLIFHWADDR to the case (a "struct lifreq" version of the ioctl) and update PF_PACKET to support it as well. Darren From peter.memishian@oracle.com Mon May 10 12:58:34 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o473HZxv024397 for ; Thu, 6 May 2010 20:17:35 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o473HWsq049527; Thu, 6 May 2010 21:17:33 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2100H0D559GU00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 20:17:33 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L21006N8558Q8B0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 20:17:32 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o473HU1p412312; Thu, 06 May 2010 20:17:30 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o473HUnq412299; Thu, 06 May 2010 20:17:30 -0700 (PDT) Date: Thu, 06 May 2010 20:17:30 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE36DF6.1090106@Sun.COM> To: Darren Reed Cc: peter.memishian@oracle.com, psarc-ext@sun.com Reply-to: peter.memishian@oracle.com Message-id: <19427.34378.624185.251688@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 1469 > > That sounds like a datalink, not an interface. Given that the protocol > > family is PF_INET/PF_INET6, it seems like the namespace should be objects > > in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note > > that it is possible (though certainly not recommended) to have a datalink > > named foo0 and an interface named foo0 that have no relationship to one > > another.) > > I'm not sure that I understand what you're trying to say. I presume you're asking about the disjoint namespaces. Since IP interfaces are not necessarily instantiated from datalinks (e.g., vni(7D), loopback, and IPMP interfaces all exist only at the IP layer), there may be dormant datalinks with the same name. For instance, someone might create an IPMP interface named foo0 and may also have an unplumbed datalink named foo0 that has nothing do with that IPMP interface. If the admin has no need to use the datalink named foo0 for IP traffic, the two foo0's peacefully coexist. However, a PF_INET SIOCGIFHWADDR for foo0 unambiguously refers to the only IP object with that name (the IPMP interface), not the foo0 datalink that's unused. It seems like what you've proposed will erroneously return the hardware address for foo0 in this case. Note that this issue is particular to PF_INET/PF_INET6 -- other protocol families (e.g., PF_PACKET) are free to define the namespace associated wieth their objects -- which may well be datalinks. -- meem From Darren.Reed@sun.com Mon May 10 13:00:22 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o471Xxm9023128 for ; Thu, 6 May 2010 18:33:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o471XxnX020321 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 May 2010 18:33:59 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L21004050CNQP00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 19:33:59 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L21009IG0CMYE60@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Thu, 06 May 2010 19:33:58 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o471XuCj012913 for ; Fri, 07 May 2010 01:33:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2100000049HW00@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 02:33:35 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2100AQE0BP3000@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 02:33:27 +0100 (BST) Date: Thu, 06 May 2010 18:33:42 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19427.25928.510001.563613@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: peter.memishian@oracle.com Cc: psarc-ext@sun.com Message-id: <4BE36DF6.1090106@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1004 On 6/05/10 05:56 PM, Peter Memishian wrote: > > > I looked at the documentation for 2009/232 but didn't see the answer to a > > > couple of semantic issues: > > > > > > * Does the SIOCGIFHWADDR fail if the given interface is not plumbed > > > for the requested address family? > > > > > > > For PF_PACKET, the interface must be known to GLD, so it doesn't need to > > be plumbed, as such. For PF_INET and PF_INET6, yes, the interface must > > at least be plumb'd. > > That sounds like a datalink, not an interface. Given that the protocol > family is PF_INET/PF_INET6, it seems like the namespace should be objects > in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note > that it is possible (though certainly not recommended) to have a datalink > named foo0 and an interface named foo0 that have no relationship to one > another.) I'm not sure that I understand what you're trying to say. Please expand and include an example. Darren From peter.memishian@oracle.com Mon May 10 13:06:22 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o476YJaY026493 for ; Thu, 6 May 2010 23:34:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o476YGk9013281; Fri, 7 May 2010 00:34:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L210010FE94BO00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 23:34:16 -0700 (PDT) Received: from triplex.local ([129.146.108.208]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2100IWKE93G250@nwk-avmta-1.sfbay.Sun.COM>; Thu, 06 May 2010 23:34:15 -0700 (PDT) Received: from triplex.local (triplex [127.0.0.1]) by triplex.local (8.14.3+Sun/8.14.3) with ESMTP id o476YD2C635709; Thu, 06 May 2010 23:34:13 -0700 (PDT) Received: (from meem@localhost) by triplex.local (8.14.3+Sun/8.14.3/Submit) id o476YDHo635698; Thu, 06 May 2010 23:34:13 -0700 (PDT) Date: Thu, 06 May 2010 23:34:13 -0700 From: Peter Memishian Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <4BE396AA.4090404@Sun.COM> To: Darren Reed Cc: peter.memishian@oracle.com, psarc-ext@sun.com Reply-to: peter.memishian@oracle.com Message-id: <19427.46181.476578.148719@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.19 under 21.4 (patch 21) "Educational Television" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> <4BE396AA.4090404@Sun.COM> X-Authentication-warning: triplex.local: meem set sender to peter.memishian@oracle.com using -f Status: RO Content-Length: 1585 > In this case, a SIOCGIFHWADDR on foo0 for PF_INET will return > details for the IPMP interface (i.e. an error because there is > no such thing as a hardware address for an IPMP interface). > > A SIOCGIFHWADDR on foo0 for PF_PACKET would return the > hardware address associated with the physical interface > that was rename to foo0. Yes -- though established Solaris terminology considers the object a "datalink" instead of "physical interface" in the PF_PACKET case. > If an IP network interface could exist, without it having a > datalink behind it, and have a physical address associated > with it, then that would be returned. Whether or not that > makes sense, is another matter and is not the subject of > this case. Yes. > I think the correct summary is: > > For PF_INET/PF_INET6, IP network interfaces are used. If no > hardware address is available with the IP network interface > then an error is returned. (This is what I meant by "it must > be at least plumb'd", although perhaps that implied a datalink > was involved when that isn't necessarily the case.) > > For PF_PACKET, datalinks are used and the primary unicast MAC > address is returned. (There is no scope within this ioctl, as > it is currently defined, for anything else to be returned.) Yes. One final consideration: in the PF_INET / PF_INET6 case, if the interface is e.g. only plumbed for PF_INET and one performs a PF_INET6 SIOCGIFHWADDR, will ENXIO be returned? For consistency with with other SIOC* ioctls I'd expect so, but it is not explicitly stated above. -- meem From Darren.Reed@sun.com Mon May 10 13:21:22 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47LDGHA005973 for ; Fri, 7 May 2010 14:13:16 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o47LDFkl051109 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 7 May 2010 15:13:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2200H0XIY34O00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 14:13:15 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2200745IY2HC20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 14:13:14 -0700 (PDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o47LDDbx018633 for ; Fri, 07 May 2010 21:13:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2200600ILLUH00@fe-emea-13.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 07 May 2010 22:13:01 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L22002O1IXO6Y70@fe-emea-13.sun.com>; Fri, 07 May 2010 22:13:01 +0100 (BST) Date: Fri, 07 May 2010 14:13:17 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <201005060029.o460TCqR011298@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: Darren Reed Cc: PSARC-ext@sun.com Message-id: <4BE4826D.5050207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201005060029.o460TCqR011298@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1947 I've updated the spec as follows below. Darren This case seeks to introduce a new ioctl for PF_INET and PF_INET6 sockets, | SIOCGIFHWADDR. In addition, SIOCGLIFHWADDR will be introduced as a mate to | SIOCIGHWADDR. SIOCIFHWADDR ioctl is already supported for PF_PACKET sockets | and is being brought into IP for better compatibility with open source | projects. This case seeks minor binding. As this case is rather obvious | and straight forward, I'm filing it as automatic approval. Details ======= For better or worse, various open source applications configure themselves at build time by looking for various symbols in header files. The presence of this particular symbol, SIOCGIFHWADDR, is taken to indicate that the kernel supports it on all of the relevant networking sockets. This becomes a problem when an attempt is made to compile open source applications such | as nmap[1]. SIOCGLIFHWADDR is required to support Infiniband interfaces | where the hardware address will not fit inside the structure used by | SIOCGIFHWADDR. Without supporting these ioctls for PF_INET/PF_INET6, it would be necessary for an application wanting to use PF_PACKET (or BPF) to link against the DLPI library in order to lookup the MAC address of a network interface. Whilst functional, it is hardly desirable to develop in this fashion and most applications expect to function entirely with PF_PACKET, BPF or DLPI. | For PF_INET/PF_INET6, IP network interfaces are used for name lookups. If | no hardware address is available with the associated IP network interface | then then an error is returned. | For PF_PACKET, datalinks are used and the primary unicast MAC address is | returned. | The classificationand stability for both of these ioctls on PF_INET and | PF_INET6 sockets are the same as SIOCGIFHWADDR in PSARC/2009/232. [1] - nmap-dev mailing list http://seclists.org/nmap-dev/2010/q2/49 From Darren.Reed@sun.com Mon May 10 13:28:38 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o47L9Tu0005857 for ; Fri, 7 May 2010 14:09:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o47L9TrK012875 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 7 May 2010 14:09:29 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2200H01IRT7D00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 15:09:29 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2200AMZIRSD550@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 15:09:28 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o47L9RL0018447 for ; Fri, 07 May 2010 21:09:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2200L00IISJ800@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 22:08:52 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L22006AWIQQGY90@fe-emea-10.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Fri, 07 May 2010 22:08:52 +0100 (BST) Date: Fri, 07 May 2010 14:09:08 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19427.46181.476578.148719@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: peter.memishian@oracle.com Cc: psarc-ext@sun.com Message-id: <4BE48174.9070405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> <4BE396AA.4090404@Sun.COM> <19427.46181.476578.148719@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 1758 On 6/05/10 11:34 PM, Peter Memishian wrote: > > In this case, a SIOCGIFHWADDR on foo0 for PF_INET will return > > details for the IPMP interface (i.e. an error because there is > > no such thing as a hardware address for an IPMP interface). > > > > A SIOCGIFHWADDR on foo0 for PF_PACKET would return the > > hardware address associated with the physical interface > > that was rename to foo0. > > Yes -- though established Solaris terminology considers the object a > "datalink" instead of "physical interface" in the PF_PACKET case. > > > If an IP network interface could exist, without it having a > > datalink behind it, and have a physical address associated > > with it, then that would be returned. Whether or not that > > makes sense, is another matter and is not the subject of > > this case. > > Yes. > > > I think the correct summary is: > > > > For PF_INET/PF_INET6, IP network interfaces are used. If no > > hardware address is available with the IP network interface > > then an error is returned. (This is what I meant by "it must > > be at least plumb'd", although perhaps that implied a datalink > > was involved when that isn't necessarily the case.) > > > > For PF_PACKET, datalinks are used and the primary unicast MAC > > address is returned. (There is no scope within this ioctl, as > > it is currently defined, for anything else to be returned.) > > Yes. > > One final consideration: in the PF_INET / PF_INET6 case, if the interface > is e.g. only plumbed for PF_INET and one performs a PF_INET6 > SIOCGIFHWADDR, will ENXIO be returned? For consistency with with other > SIOC* ioctls I'd expect so, but it is not explicitly stated above. > Yes, it will. Darren From Darren.Reed@sun.com Mon May 10 13:36:22 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o474ROXI025208 for ; Thu, 6 May 2010 21:27:25 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o474ROBX010702 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Thu, 6 May 2010 21:27:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2100L1B8DO3H00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 May 2010 22:27:24 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L21009WX8DMXSD0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Thu, 06 May 2010 22:27:22 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o474RL4t024148 for ; Fri, 07 May 2010 04:27:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2100E008ACFG00@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 May 2010 05:27:08 +0100 (BST) Received: from mintslice.sfbay.sun.com ([unknown] [129.146.106.55]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2100CTL8D7P220@fe-emea-09.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 07 May 2010 05:27:08 +0100 (BST) Date: Thu, 06 May 2010 21:27:22 -0700 From: Darren Reed Subject: Re: SIOCGIFHWADDR for PF_INET and PF_INET6 [PSARC/2010/159 Self Review] In-reply-to: <19427.34378.624185.251688@gargle.gargle.HOWL> Sender: Darren.Reed@sun.com To: peter.memishian@oracle.com Cc: psarc-ext@sun.com Message-id: <4BE396AA.4090404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <19426.28231.837156.505510@gargle.gargle.HOWL> <4BE35F48.3010902@Sun.COM> <19427.25928.510001.563613@gargle.gargle.HOWL> <4BE36DF6.1090106@Sun.COM> <19427.34378.624185.251688@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-GB; rv:1.9.1.5) Gecko/20091206 Thunderbird/3.0 Status: RO Content-Length: 2664 On 6/05/10 08:17 PM, Peter Memishian wrote: > > > > That sounds like a datalink, not an interface. Given that the protocol > > > family is PF_INET/PF_INET6, it seems like the namespace should be objects > > > in that namespace -- i.e., IPv4 and IPv6 interfaces, not datalinks. (Note > > > that it is possible (though certainly not recommended) to have a datalink > > > named foo0 and an interface named foo0 that have no relationship to one > > > another.) > > > > I'm not sure that I understand what you're trying to say. > > I presume you're asking about the disjoint namespaces. > > Since IP interfaces are not necessarily instantiated from datalinks (e.g., > vni(7D), loopback, and IPMP interfaces all exist only at the IP layer), > there may be dormant datalinks with the same name. For instance, someone > might create an IPMP interface named foo0 and may also have an unplumbed > datalink named foo0 that has nothing do with that IPMP interface. If the > admin has no need to use the datalink named foo0 for IP traffic, the two > foo0's peacefully coexist. However, a PF_INET SIOCGIFHWADDR for foo0 > unambiguously refers to the only IP object with that name (the IPMP > interface), not the foo0 datalink that's unused. It seems like what > you've proposed will erroneously return the hardware address for foo0 in > this case. Note that this issue is particular to PF_INET/PF_INET6 -- > other protocol families (e.g., PF_PACKET) are free to define the namespace > associated wieth their objects -- which may well be datalinks. In this case, a SIOCGIFHWADDR on foo0 for PF_INET will return details for the IPMP interface (i.e. an error because there is no such thing as a hardware address for an IPMP interface). A SIOCGIFHWADDR on foo0 for PF_PACKET would return the hardware address associated with the physical interface that was rename to foo0. If an IP network interface could exist, without it having a datalink behind it, and have a physical address associated with it, then that would be returned. Whether or not that makes sense, is another matter and is not the subject of this case. I think the correct summary is: For PF_INET/PF_INET6, IP network interfaces are used. If no hardware address is available with the IP network interface then an error is returned. (This is what I meant by "it must be at least plumb'd", although perhaps that implied a datalink was involved when that isn't necessarily the case.) For PF_PACKET, datalinks are used and the primary unicast MAC address is returned. (There is no scope within this ioctl, as it is currently defined, for anything else to be returned.) Darren