Re: MAC address issue

On 1/17/08, christos <christosastron.com> wrote:
> The problem was that the ifconf ioctls did not have
space to store the lladdr.
> This has changed now, and we can fix it so that for the
cards that support
> changing the mac address we can do it directly.

Will it be changed? Is someone working under this?

Cheers...

On Jan 17,  7:45pm, comfoocgmail.com (comfooc) wrote:
-- Subject: Re: MAC address issue

| On 1/17/08, christos <christosastron.com> wrote:
| > The problem was that the ifconf ioctls did not have
space to store the lladdr.
| > This has changed now, and we can fix it so that for
the cards that support
| > changing the mac address we can do it directly.
| 
| Will it be changed? Is someone working under this?

Not to my knowledge but the fix is very simple. What
hardware are you
interested?

christos

On Jan 17, 2008 8:26 PM, Christos Zoulas <christoszoulas.com> wrote:
> Not to my knowledge but the fix is very simple. What
hardware are you
> interested?

i386 pcmcia ne* and ep* ethernet cards

On Thu, Jan 17, 2008 at 02:26:10PM -0500, christoszoulas.com wrote:
> On Jan 17,  7:45pm, comfoocgmail.com (comfooc) wrote:
> -- Subject: Re: MAC address issue
> 
> | On 1/17/08, christos <christosastron.com> wrote:
> | > The problem was that the ifconf ioctls did not
have space to store the lladdr.
> | > This has changed now, and we can fix it so that
for the cards that support
> | > changing the mac address we can do it directly.
> | 
> | Will it be changed? Is someone working under this?
> 
> Not to my knowledge but the fix is very simple. What
hardware are you
> interested?
> 
> christos

Is this PR 30665?  The patch therein seems sufficient?

-seanb

On Thu, Jan 17, 2008 at 07:45:34PM +0100, comfooc wrote:
> On 1/17/08, christos <christosastron.com> wrote:
> > The problem was that the ifconf ioctls did not
have space to store the lladdr.
> > This has changed now, and we can fix it so that
for the cards that support
> > changing the mac address we can do it directly.
> 
> Will it be changed? Is someone working under this?

I will work on it this weekend.  I think that add/delete
semantics are
desirable for link-layer addresses (lladdrs), however, we
need to apply
several restrictions in the short term:

        1. The kernel must flag each lladdr with its
properties and role:

                property        meaning
                --------        -------
                factory         lladdr was read from EEPROM
                synthetic       lladdr was produced by the
kernel

                role            meaning
                ----            -------
                active          lladdr is used for both tx
and rx
                                only one lladdr may be
active
                inactive        lladdr is used for neither
tx nor rx
                                inactive = !active

        2. For now, each lladdr must be assigned a unique
preference
           number, and the most preferred lladdr is the only
active
           lladdr.

Let me show some examples of how I think that this will work
from the
operator's perspective.

Here is a sip(4) with one lladdr assigned.  I leave the
'address:' line
for compatibility with old scripts.  Note that the lladdr is
listed a
second time.  The 'link' keyword tells us that it belongs to
the AF_LINK
address family.

# ifconfig sip0
sip0:
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu
1500
        address: 00:00:24:c6:a5:24
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        link 00:00:24:c6:a5:24 factory active
        inet 10.165.36.254 netmask 0xffffff00 broadcast
10.165.36.255
        inet6 fe80::200:24ff:fec6:a524%sip0 prefixlen 64
scopeid 0x1

Let us try to delete the lladdr:

# ifconfig sip0 link 00:00:24:c6:a5:24 delete
ifconfig: SIOCDIFADDR: Can't assign requested address

Let us add some lladdrs and display the new interface
configuration.

# ifconfig sip0 link 02:00:00:00:00:01 preference -1
# ifconfig sip0 link 02:00:00:00:00:02 preference -2
# ifconfig sip0 link 02:00:00:00:00:03 preference -3
# ifconfig sip0
sip0:
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu
1500
        address: 00:00:24:c6:a5:24
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.165.36.254 netmask 0xffffff00 broadcast
10.165.36.255
        inet6 fe80::200:24ff:fec6:a524%sip0 prefixlen 64
scopeid 0x1
        link 00:00:24:c6:a5:24 preference 0 factory active
        link 02:00:00:00:00:01 preference -1 inactive
        link 02:00:00:00:00:02 preference -2 inactive
        link 02:00:00:00:00:03 preference -3 inactive

Let us try to add a fifth lladdr with preference equal to
an
existing address:

# ifconfig sip0 link 02:00:00:00:00:04 preference -3
ifconfig: SIOCAIFADDR: Operation not supported by device

Let us activate the address 02:00:00:00:00:01.  Note that
the link-local
IPv6 address should probably change as it does in this
example:

# ifconfig sip0 link 02:00:00:00:00:01 preference 1
# ifconfig sip0
sip0:
flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu
1500
        address: 02:00:00:00:00:01
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.165.36.254 netmask 0xffffff00 broadcast
10.165.36.255
        inet6 fe80::000:00ff:fe00:0001%sip0 prefixlen 64
scopeid 0x1
        link 02:00:00:00:00:01 preference 1 active
        link 00:00:24:c6:a5:24 preference 0 factory
inactive
        link 02:00:00:00:00:02 preference -2 inactive
        link 02:00:00:00:00:03 preference -3 inactive

Dave

-- 
David Young             OJC Technologies
dyoungojctech.com      Urbana, IL * (217) 278-3933 ext 24

On Thu, Jan 17, 2008 at 02:39:02PM +0000, Sean Boudreau
wrote:
> Is this PR 30665?  The patch therein seems sufficient?

IMO, there is no need for Yet Another Ioctl.  I have some
more
complaints about that patch:

        1 the patch is not applicable to -current, where we
do not any
          longer assume that the first ifaddr is the
link-layer
          address
        2 the patch does not produce any routing messages to
indicate
          a change of lladdr
        3 there is no way to restore the h/w default lladdr
        4 the patch only treats the case where the lladdr
length
          is 6 octets
        5 the patch resets every interface, always (IFF_UP
-> !IFF_UP
          -> IFF_UP)
        6 the patch puts some address-family specific
knowledge into
          net/if.c, the arp_ifinit() calls

Dave

-- 
David Young             OJC Technologies
dyoungojctech.com      Urbana, IL * (217) 278-3933 ext 24

On Thu, Jan 17, 2008 at 02:39:07PM -0600, David Young
wrote:
> I will work on it this weekend.  I think that
add/delete semantics are
> desirable for link-layer addresses (lladdrs), however,
we need to apply
> several restrictions in the short term:

I don't think all this complexity buys any real advantage.
If the only
real improvement is the ability to restore the factory
default, a copy
of it would be more than enough. None of your examples shows
what it is
useful for.

Joerg

On Thu, Jan 17, 2008 at 03:50:27PM -0500, Joerg Sonnenberger
wrote:
> On Thu, Jan 17, 2008 at 02:39:07PM -0600, David Young
wrote:
> > I will work on it this weekend.  I think that
add/delete semantics are
> > desirable for link-layer addresses (lladdrs),
however, we need to apply
> > several restrictions in the short term:
> 
> I don't think all this complexity buys any real
advantage. If the only
> real improvement is the ability to restore the factory
default, a copy
> of it would be more than enough. None of your examples
shows what it is
> useful for.
> 
> Joerg

I don't see what 'preference' is useful for.  It seems
reasonable to have a 'factory' flag which can't be deleted,
others can be added / removed, only one can be active?

-seanb