MAC address issue

[comfooc]

Hello,
I want to touch once again subject of hardware network address
changes. I've made some research and found that NetBSD is the only one
(from BSD's) with lack of this feature... Why?

Why I need this:
At my University is network with restricted access there are 8 public
MAC's so you need to change your one to the public one to gain access
to the network. So i can't use NetBSD in this case...

Cheers...

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew sporleder]

Post by comfooc
Hello,
I want to touch once again subject of hardware network address
changes. I've made some research and found that NetBSD is the only one
(from BSD's) with lack of this feature... Why?
At my University is network with restricted access there are 8 public
MAC's so you need to change your one to the public one to gain access
to the network. So i can't use NetBSD in this case...

If I recall correctly, you can setup an etherip(4) virtual
interface/tunnel to achieve this. You then set the mac address with a
sysctl(8).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[comfooc]

Post by matthew sporleder
If I recall correctly, you can setup an etherip(4) virtual
interface/tunnel to achieve this. You then set the mac address with a
sysctl(8).

Thanks, that will help...
But still i would like to know why there is nothing in ifconfig like
OpenBSD's lladdr or FreeBSD's link.

Cheers...

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew sporleder]

Post by comfooc

Post by matthew sporleder
If I recall correctly, you can setup an etherip(4) virtual
interface/tunnel to achieve this. You then set the mac address with a
sysctl(8).

Thanks, that will help...
But still i would like to know why there is nothing in ifconfig like
OpenBSD's lladdr or FreeBSD's link.

Well.. I think the discussions came down to points about how netbsd
supported actually changing the mac address of a card in its firmware
sometimes, so "faking it" on cards that didn't support such activities
didn't seem clean. I personally like the idea of using a virtual
interface when I'm doing this sort of thing.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[comfooc]

Post by matthew sporleder
Well.. I think the discussions came down to points about how netbsd
supported actually changing the mac address of a card in its firmware
sometimes, so "faking it" on cards that didn't support such activities
didn't seem clean. I personally like the idea of using a virtual
interface when I'm doing this sort of thing.

Hmm that seems to be reasonable, cleaner and simpler (in coding). I'm
satisfied by Your answer. Thank You.

P.S.
Maybe I missed it but it would be nice to make something like hint (or
tip) in guide pointing to this nice etherip(4) trick...

Cheers...

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Quentin Garnier]

Post by comfooc

Post by matthew sporleder
Well.. I think the discussions came down to points about how netbsd
supported actually changing the mac address of a card in its firmware
sometimes, so "faking it" on cards that didn't support such activities
didn't seem clean. I personally like the idea of using a virtual
interface when I'm doing this sort of thing.

Hmm that seems to be reasonable, cleaner and simpler (in coding). I'm
satisfied by Your answer. Thank You.
P.S.
Maybe I missed it but it would be nice to make something like hint (or
tip) in guide pointing to this nice etherip(4) trick...

It's actually tap+bridge, not etherip.

[Christos Zoulas]

Post by matthew sporleder

Post by comfooc

Post by matthew sporleder
If I recall correctly, you can setup an etherip(4) virtual
interface/tunnel to achieve this. You then set the mac address with a
sysctl(8).

Thanks, that will help...
But still i would like to know why there is nothing in ifconfig like
OpenBSD's lladdr or FreeBSD's link.

Well.. I think the discussions came down to points about how netbsd
supported actually changing the mac address of a card in its firmware
sometimes, so "faking it" on cards that didn't support such activities
didn't seem clean. I personally like the idea of using a virtual
interface when I'm doing this sort of thing.

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.

christos



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by matthew sporleder

Post by comfooc
Hello,
I want to touch once again subject of hardware network address
changes. I've made some research and found that NetBSD is the only one
(from BSD's) with lack of this feature... Why?
At my University is network with restricted access there are 8 public
MAC's so you need to change your one to the public one to gain access
to the network. So i can't use NetBSD in this case...

If I recall correctly, you can setup an etherip(4) virtual
interface/tunnel to achieve this. You then set the mac address with a
sysctl(8).

It's tap(4).

HTH
-is



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[comfooc]

Post by Christos Zoulas
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...

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

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

| On 1/17/08, christos <***@astron.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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[comfooc]

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

i386 pcmcia ne* and ep* ethernet cards

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Sean Boudreau]

Post by Christos Zoulas
-- Subject: Re: MAC address issue
| > 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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by comfooc

Post by Christos Zoulas
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

[Joerg Sonnenberger]

Post by David Young
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

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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Sean Boudreau]

Post by Joerg Sonnenberger

Post by David Young
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

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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Sean Boudreau

Post by Joerg Sonnenberger

Post by David Young
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

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

My thought about the preference was as follows: the preference provides
for a predictable "succession" if the active lladdr is deleted. ifaddrs
already have preference numbers, so we can re-use an existing mechanism.

Now that you mention it, I see some problems with using the preference
number in this way. The first problem is that userland cannot add an
address simultaneously with setting its preference (perhaps we should
allow that, though), so the kernel would have to auto-assign a unique
preference. I don't like the idea of that at all.

Post by Sean Boudreau
reasonable to have a 'factory' flag which can't be deleted,
others can be added / removed, only one can be active?

Let us put aside lladdr preferences, and use only the 'active' flag,
instead. Only one lladdr may be active at a time, deleting an active
lladdr is not allowed (EBUSY), and setting a second lladdr to 'active'
clears the 'active' state on every other lladdr.

Dave

[j***@dsg.stanford.edu]

Post by David Young
Let us put aside lladdr preferences, and use only the 'active' flag,
instead. Only one lladdr may be active at a time, deleting an active
lladdr is not allowed (EBUSY), and setting a second lladdr to 'active'
clears the 'active' state on every other lladdr.

Huh? What about hardware capable of, and IETF protocols which call
for, multiple active link-level addresses on a single interface??

Are you proposing a user/kernel API which makes those ~impossible?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by j***@dsg.stanford.edu

Post by David Young
Let us put aside lladdr preferences, and use only the 'active' flag,
instead. Only one lladdr may be active at a time, deleting an active
lladdr is not allowed (EBUSY), and setting a second lladdr to 'active'
clears the 'active' state on every other lladdr.

Huh? What about hardware capable of, and IETF protocols which call
for, multiple active link-level addresses on a single interface??

Do those exist? I wasn't aware of that. Can you name one, so that
we can consider the exact interface model used? E.g.

Post by j***@dsg.stanford.edu
Are you proposing a user/kernel API which makes those ~impossible?

I'm actually needing this, because the per-Macaddr-limit in German
Telekom's PPPoE routers is set to 1, and I'm using two providers
simultaneously. I'm emulating this using bridge(4) and tap(4). I
guess this is not desirable in the high performance case.

But wouldn't sub-interfaces (similar to what Solaris does) be easier
to use?

Regards,
-is

[Martin Husemann]

Post by Ignatios Souvatzis
I'm actually needing this, because the per-Macaddr-limit in German
Telekom's PPPoE routers is set to 1, and I'm using two providers
simultaneously. I'm emulating this using bridge(4) and tap(4). I
guess this is not desirable in the high performance case.

Me too - but how do the upper parts of the stack select the link addr
to use? I.e. when pppoe calls the if_output function to enqueue a packet
on hme0 instead of tap0 - how does it tell hme0 to use a secondary
link address?

We could create an interface clone (say "hme0:1"), and have that do it's
own ether_ifattach(), while still using the same hardware.

But then we are back to a single, changable lladdr per interface.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Ignatios Souvatzis

Post by j***@dsg.stanford.edu

Post by David Young
Let us put aside lladdr preferences, and use only the 'active' flag,
instead. Only one lladdr may be active at a time, deleting an active
lladdr is not allowed (EBUSY), and setting a second lladdr to 'active'
clears the 'active' state on every other lladdr.

Huh? What about hardware capable of, and IETF protocols which call
for, multiple active link-level addresses on a single interface??

Do those exist? I wasn't aware of that. Can you name one, so that
we can consider the exact interface model used? E.g.

The ethernet built into the Atheros SoC has the capability. Judging by
tlp_filter_setup(), the DEC Tulip does, too. I'm sure there are others.

Post by Ignatios Souvatzis

Post by j***@dsg.stanford.edu
Are you proposing a user/kernel API which makes those ~impossible?

I'm actually needing this, because the per-Macaddr-limit in German
Telekom's PPPoE routers is set to 1, and I'm using two providers
simultaneously. I'm emulating this using bridge(4) and tap(4). I
guess this is not desirable in the high performance case.

When a NIC's address filter has more than one slot for unicast addresses,
we should take advantage when that will improve bridge(4) performance.
We should also take advantage of hardware VLAN support such as the
ADM5120 SoC provides. To get there, we need for bridge(4) and member
interfaces to pass messages indicating when interfaces go up & down, when
they assign new lladdrs, they join & leave multicast groups, they join &
leave the bridge, et cetera.

I really prefer to treat such optimizations in a separate proposal.
They seem orthogonal to the problem at hand.

Post by Ignatios Souvatzis
But wouldn't sub-interfaces (similar to what Solaris does) be easier
to use?

IMO, sub-interfaces are an abomination. :-) Wherever I have dealt
with a system that has "child" interfaces hanging off of a "parent"
interface, it seems either that the parent has become a vestigial or a
second-class interface, or that the parent->child relationship is tenuous:
one interface may as well be a peer/sibling of the other.

Dave

[Sean Boudreau]

Post by David Young

Post by Sean Boudreau

Post by Joerg Sonnenberger

Post by David Young
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

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

My thought about the preference was as follows: the preference provides
for a predictable "succession" if the active lladdr is deleted. ifaddrs
already have preference numbers, so we can re-use an existing mechanism.
Now that you mention it, I see some problems with using the preference
number in this way. The first problem is that userland cannot add an
address simultaneously with setting its preference (perhaps we should
allow that, though), so the kernel would have to auto-assign a unique
preference. I don't like the idea of that at all.

Post by Sean Boudreau
reasonable to have a 'factory' flag which can't be deleted,
others can be added / removed, only one can be active?

Let us put aside lladdr preferences, and use only the 'active' flag,
instead. Only one lladdr may be active at a time, deleting an active
lladdr is not allowed (EBUSY), and setting a second lladdr to 'active'
clears the 'active' state on every other lladdr.

Sounds good to me.

-seanb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Sean Boudreau
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