How to change MAC address on RPI-B?

[diffusae]

Hello!

Does anyboy know how to change the MAC address on a Raspberry Pi with
FreeBSD 11.0-STABLE?

I've tried it this way in /etc/start_if.ue0:

ifconfig ue0 down delete
ifconfig ue0 promisc
ifconfig ue0 ether 00:FF:CC:00:11:11

But it's only possible to do it in promicous mode of the device.
Without there is no more network connection after applying these settings.

It could be properly a bug due to the USB network driver.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168268

Maybe there is another way, how with the Linux kernel command line or an
config option, like this: smsc95xx.macaddr=00:FF:CC:00:11:11.

Regards,

[Hans Petter Selasky]

Post by diffusae
Hello!
Does anyboy know how to change the MAC address on a Raspberry Pi with
FreeBSD 11.0-STABLE?
ifconfig ue0 down delete
ifconfig ue0 promisc
ifconfig ue0 ether 00:FF:CC:00:11:11
But it's only possible to do it in promicous mode of the device.
Without there is no more network connection after applying these settings.
It could be properly a bug due to the USB network driver.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168268
Maybe there is another way, how with the Linux kernel command line or an
config option, like this: smsc95xx.macaddr=00:FF:CC:00:11:11.

Hi,

The sys/dev/usb/net/if_smsc.c driver needs a patch to set the mac
address runtime. I think you can change the mac address in the RPI FDT
file and it will pick it up.

--HPS

[diffusae]

Hi,

thanks a lot for your reply.

I'm not sure, if it's possible to change it in RPI FDT file,
but I will give a try:

https://www.raspberrypi.org/forums/viewtopic.php?f=72&t=143011

The MAC address isn't stored anywhere. It is generated from a
combination of the MAC range (b8:27:eb) and the last three bytes of the
serial number.

Best regards,

Post by Hans Petter Selasky

Post by diffusae
Hello!
Does anyboy know how to change the MAC address on a Raspberry Pi with
FreeBSD 11.0-STABLE?
ifconfig ue0 down delete
ifconfig ue0 promisc
ifconfig ue0 ether 00:FF:CC:00:11:11
But it's only possible to do it in promicous mode of the device.
Without there is no more network connection after applying these settings.
It could be properly a bug due to the USB network driver.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168268
Maybe there is another way, how with the Linux kernel command line or an
config option, like this: smsc95xx.macaddr=00:FF:CC:00:11:11.

Hi,
The sys/dev/usb/net/if_smsc.c driver needs a patch to set the mac
address runtime. I think you can change the mac address in the RPI FDT
file and it will pick it up.
--HPS

[John W. Kitz]

Hi,

I saw a couple of emails whizz by, which discussed how to override the
burned in MAC address (BIA) on an RPI-B.

First off I'm not familiar with the use or configuration of either a Pi or
FreeBSD, but to me it looked like in the emails a dependency between two
techniques, i.e. overriding the BIA of a NIC and configuring a NIC into
promiscuous mode, was made while such a dependency does not or at least, to
the best of my knowledge, should not exist.

I used, what in IBM lingo is referred to as a locally administered MAC
addresses, numerous times predominantly in the nineties of the previous
century in datacenter environments using equipment from big blue or its plug
compatible competitors, while such equipment exclusively used IBM's Systems
Network Architecture (SNA), i.e. non TCP/IP, protocols.

To the best of my recollection at the time there was no need whatsoever to
configure these NICs into promiscuous mode, which in itself is needed to
have a NIC consider frames that aren't destined for the NIC's BIA address as
if they were, so I doubt that such a need exists today.

I hope this helps, regards, Jk.

[Erich Dollansky]

Hi,

On Wed, 9 Nov 2016 12:35:56 +0100

Post by John W. Kitz
To the best of my recollection at the time there was no need
whatsoever to configure these NICs into promiscuous mode, which in

you need this for fault-tolerant computing. A machine or a device with
a known goes down, the failure will be detected and another device or
machine is configured to take over the other's task by also taking over
the other's MAC address. The communication partners will only a delay
but not a failure.

Erich

[John W. Kitz]

Erich,

Post by John W. Kitz
To the best of my recollection at the time there was no need
whatsoever to configure these NICs into promiscuous mode, which in

you need this for fault-tolerant computing. A machine or a device with a
known goes down, the failure will be detected and another device or machine
is configured to take over the other's task by also taking over the other's
MAC address. The communication partners will only a delay but not a failure.

JKi: I'm curious, would, in your experience, the impact of any delay
incurred by tinkering with addresses at both layer-3 AND layer-2 in a
failover situation be less in comparison to any delay incurred when
tinkering with the addresses at layer-3 ONLY and leave the recovery of
addressing issues at layer-2 to the relevant protocols?

Jk.

[Erich Dollansky]

Hi John,

On Thu, 10 Nov 2016 11:11:02 +0100

Post by Erich Dollansky

Post by John W. Kitz
To the best of my recollection at the time there was no need
whatsoever to configure these NICs into promiscuous mode, which in

you need this for fault-tolerant computing. A machine or a device
with a known goes down, the failure will be detected and another
device or machine is configured to take over the other's task by also
taking over the other's MAC address. The communication partners will
only a delay but not a failure.
JKi: I'm curious, would, in your experience, the impact of any delay
incurred by tinkering with addresses at both layer-3 AND layer-2 in a
failover situation be less in comparison to any delay incurred when
tinkering with the addresses at layer-3 ONLY and leave the recovery of
addressing issues at layer-2 to the relevant protocols?

it depends of what you want. When the machine connecting to the
fault-tolerant machine is not fault-tolerant, it will not be able to
change any addresses. All it will do is repeating requests. A watch-dog
should have realised by then that either the interface or the machine
with the interface is down and should have activated either a different
interface or a different machine.

It is just one of many option you have. And it is a cheap option as you
can make even FreeBSD fault-tolerant with this as the operating system
does not play any part in this kind of fault-tolerance.

Erich

[John W. Kitz]

Erich,

Post by Erich Dollansky

Post by John W. Kitz
To the best of my recollection at the time there was no need
whatsoever to configure these NICs into promiscuous mode, which in

you need this for fault-tolerant computing. A machine or a device with
a known goes down, the failure will be detected and another device or
machine is configured to take over the other's task by also taking
over the other's MAC address. The communication partners will only a
delay but not a failure.
JKi: I'm curious, would, in your experience, the impact of any delay
incurred by tinkering with addresses at both layer-3 AND layer-2 in a
failover situation be less in comparison to any delay incurred when
tinkering with the addresses at layer-3 ONLY and leave the recovery of
addressing issues at layer-2 to the relevant protocols?

it depends of what you want. When the machine connecting to the
fault-tolerant machine is not fault-tolerant, it will not be able to change
any addresses. All it will do is repeating requests. A watch-dog should have
realised by then that either the interface or the machine with the interface
is down and should have activated either a different interface or a
different machine.

It is just one of many option you have. And it is a cheap option as you can
make even FreeBSD fault-tolerant with this as the operating system does not
play any part in this kind of fault-tolerance.

JKi: The point I was trying to make is that locally administered MAC
addresses serve a purpose in the recovery of hardware failures, e.g. in its
basic form when one needs to replace a broken NIC thereby ending up with a
system with a different MAC address, in those situations where the higher
layer protocol (addressing or rather lack thereof, such as can be the case
in SNA / VTAM installations) doesn't.

The other point, which you're not answering, is assuming that one would rely
on the use of both lower and higher layer addressing in the recovery from
hardware failures is there, in your experience, a noticeable gain in
recovery time to be made by applying both techniques.

Regards, Jk.

[Hans Petter Selasky]

Hi,

Does the attached patch solve the problem?

--HPS

[diffusae]

Hi!

Thanks a lot for this patch.

Post by Hans Petter Selasky
Hi,
Does the attached patch solve the problem?
--HPS

I've applied the patch and complied a new kernel with all modules.
After that, i copied the kernel and modules to the boot partition of the
RPi. I also copied the debug symbols to /usr/lib/debug/boot/kernel.
Don't know if it's necessary.

After rebooting I only get this error message from ifconfig:

ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
smsc0: chip 0xec00, rev. 0002
ue0: link state changed to DOWN
ue0: link state changed to UP

No network connection without promiscuous mode.

So, unfortunately it doesn't solve the problem. Or maybe I did something
wrong?

Best regards,

[Hans Petter Selasky]

Post by diffusae
So, unfortunately it doesn't solve the problem. Or maybe I did something
wrong?

I patched the wrong IOCTL, sorry. I have a RPI2 myself, and will fix
this issue later today. Stay tuned. Meanwhile, can you test the new
attached patch and revert the previous one?

--HPS

[diffusae]

Hi!

Thanks again for your patch.

Sorry for the delay. You don't have to hurry. I've started a "buildword"
on RPI-B and it tooks 3.5 days until it was finished. :-)

I've revert the previous patch and applied the new one. Build the the
new kernel and modules and copied the kernel and the relevant driver to
/boot/kernel.

It works on the fly. Now you can change the MAC address at boot.

So settings in /etc/rc.conf:

ifconfig_ue0="ether 00:11:22:33:44:55"

or in /etc/start_if.ue0:

/sbin/ifconfig $1 lladdr 00:11:22:33:44:55

works for me. With IPv6 you better have to use /etc/start_if.name.

I am not sure, but do you like to commit the patch to head, so it will
be available in FreeBSD 12? That would be great.

Best regards,

Post by Hans Petter Selasky

Post by diffusae
So, unfortunately it doesn't solve the problem. Or maybe I did something
wrong?

I patched the wrong IOCTL, sorry. I have a RPI2 myself, and will fix
this issue later today. Stay tuned. Meanwhile, can you test the new
attached patch and revert the previous one?
--HPS

[Hans Petter Selasky]

Post by diffusae
I am not sure, but do you like to commit the patch to head, so it will
be available in FreeBSD 12? That would be great.

Yes, I'll put it in later today. Thank you for testing!

--HPS

[Hans Petter Selasky]

Post by diffusae
Hi!
Thanks again for your patch.

...

Post by diffusae
I am not sure, but do you like to commit the patch to head, so it will
be available in FreeBSD 12? That would be great.

Here you go:

https://svnweb.freebsd.org/changeset/base/308730

--HPS

[diffusae]

Hi!

Post by Hans Petter Selasky
https://svnweb.freebsd.org/changeset/base/308730

Cool, that's it. I will post a link into the FreeBSd Forum, where
somebody was looking for a solution.

Many thanks,
Reiner

[Erich Dollansky]

Hi John,

On Fri, 11 Nov 2016 13:12:19 +0100

Post by John W. Kitz
JKi: The point I was trying to make is that locally administered MAC
addresses serve a purpose in the recovery of hardware failures, e.g.
in its basic form when one needs to replace a broken NIC thereby
ending up with a system with a different MAC address, in those
situations where the higher layer protocol (addressing or rather lack
thereof, such as can be the case in SNA / VTAM installations) doesn't.
The other point, which you're not answering, is assuming that one
would rely on the use of both lower and higher layer addressing in
the recovery from hardware failures is there, in your experience, a
noticeable gain in recovery time to be made by applying both
techniques.

we have at the moment only the situation in which non-fault-tolerant
systems address our fault-tolerant system. Our emphasis is currently
only to detect a fault, switch MAC and IP address, report the fault and
let the outside world believe all is fine. We have then 1 to 4 days
time to fix the faulty system. Yes, I know, this is not a very common
situation. We use this only as users of the system have to have no IT
skills. They even wonder that there is some IT used in our system.

I can imagine where you come from. Your system is very, very different
from our system. Just have a look at our website. The words IT,
computer, fault-tolerant etc are not even used a single time.

Erich

Post by John W. Kitz
Regards, Jk.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arm

[diffusae]

Hi,

thanks a lot for your help.

Post by John W. Kitz
I saw a couple of emails whizz by, which discussed how to override the
burned in MAC address (BIA) on an RPI-B.

Do you saw them at this mailing list? Maybe I should have a look into
the archive?

Post by John W. Kitz
techniques, i.e. overriding the BIA of a NIC and configuring a NIC into
promiscuous mode, was made while such a dependency does not or at least, to
the best of my knowledge, should not exist.

That's true, if you try this in Linux, you could use one of both
techniques. You can override the MAC on boot or set the MAC on runtime.
And this works on the fly.

Post by John W. Kitz
have a NIC consider frames that aren't destined for the NIC's BIA address as
if they were, so I doubt that such a need exists today.

Normally you shouldn't use the promiscuous mode for this. You only need
it, if you use some kind of sniffing software for the whole network
traffic, etc.

Best regards,

[John W. Kitz]

Post by John W. Kitz
I saw a couple of emails whizz by, which discussed how to override the
burned in MAC address (BIA) on an RPI-B.

Do you saw them at this mailing list? Maybe I should have a look into the
archive?

JKi: I meant your emails and they whizzed by because I had already deleted
the first couple of ones in this thread from my email box by the time I
decided that I was going to respond to them. So, as it happens, yes, I had
to go to the archives to look them up. Actually I've been following this
email distribution since late 2015 because I'm hoping to, at some point in
time, use FreeBSD on an ARM platform for HAM radio purposes. Consequently I
think it's quite nice to see that with 11.0 the developers released the
first FreeBSD images specifically aimed at various ARM architectures.

Post by John W. Kitz
techniques, i.e. overriding the BIA of a NIC and configuring a NIC
into promiscuous mode, was made while such a dependency does not or at
least, to the best of my knowledge, should not exist.

That's true, if you try this in Linux, you could use one of both techniques.
You can override the MAC on boot or set the MAC on runtime.
And this works on the fly.

Post by John W. Kitz
have a NIC consider frames that aren't destined for the NIC's BIA
address as if they were, so I doubt that such a need exists today.

Normally you shouldn't use the promiscuous mode for this. You only need it,
if you use some kind of sniffing software for the whole network traffic,
etc.

Best regards,
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-***@freebsd.org"

[John W. Kitz]

Hi,

Further to my earlier email on this topic and assuming you haven't already
done so, you may need to have a look at
https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/FreeBSD as well as
at, a more UNIX flavor independent, discussion of the topic at
https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/Linux, which also
specifically addresses how to make overriding the burned-in MAC address
persistent.

In addition I noticed that the MAC address, which you are trying to use
instead of the burned-in one, contains 'FF', which, given its use in
functional MAC addresses used for broadcast type purposes, might not be such
a good idea.

I hope this helps, regards, Jk.

[diffusae]

Hi!

Thanks for you reply.

Post by John W. Kitz
https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/FreeBSD as well as
at, a more UNIX flavor independent, discussion of the topic at

That's the way it works. You could do this on the RPi, but after that
you haven't no more network connection.

It's like Hans Petter said: The sys/dev/usb/net/if_smsc.c driver needs a
patch to set the mac address runtime. I don't know, how to write it,
because I am not really familiar with C source code.

Post by John W. Kitz
https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/Linux, which also
specifically addresses how to make
persistent.

In all flavour of Linux that should work, without problems on the RPi.
You could set the MAC address from the kernel command line.

Post by John W. Kitz
In addition I noticed that the MAC address, which you are trying to use
instead of the burned-in one, contains 'FF', which, given its use in
functional MAC addresses used for broadcast type purposes, might not be such
a good idea.

Really, that I don't know. I only use it, as an example, instead of
00:11:22:33:44:55. Overriding the burned-in MAC address persistent on a
RPi wouldn't work, because it is generated from a combination of the MAC
range (b8:27:eb) and the last three bytes of the serial number.

But it should be possible to change this in this RPi FTD file, then it
might work.

Best regards,

[John W. Kitz]

Post by John W. Kitz
https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/FreeBSD as
well as at, a more UNIX flavor independent, discussion of the topic at

That's the way it works. You could do this on the RPi, but after that you
haven't no more network connection.

JKi: Could the information on the two sites that I sent you be an indication
that it may work as you intend it to if you configure a locally administered
MAC address to override the burned-in one OR promiscuous mode and not both
at the same time? At least that is what I interpret the information in the
initial emails of this thread to mean.

It's like Hans Petter said: The sys/dev/usb/net/if_smsc.c driver needs a
patch to set the mac address runtime. I don't know, how to write it, because
I am not really familiar with C source code.

Post by John W. Kitz
https://en.wikibooks.org/wiki/Changing_Your_MAC_Address/Linux, which
also specifically addresses how to make persistent.

In all flavour of Linux that should work, without problems on the RPi.
You could set the MAC address from the kernel command line.

Post by John W. Kitz
In addition I noticed that the MAC address, which you are trying to
use instead of the burned-in one, contains 'FF', which, given its use
in functional MAC addresses used for broadcast type purposes, might
not be such a good idea.

Really, that I don't know.

JKi: Neither do I, but as mentioned I imagined that it wouldn't.

I only use it, as an example, instead of 00:11:22:33:44:55. Overriding the
burned-in MAC address persistent on a RPi wouldn't work, because it is
generated from a combination of the MAC range (b8:27:eb) and the last three
bytes of the serial number.

JKi: Doesn't that depend on the sequence of events at boot time?

In addition, not being familiar with the specifics of this generating of a
MAC address that you mention, I'm curious how does this process guarantee a
globally unique MAC address as its result, bearing in mind that a MAC
address in principle is supposed to be either functional (such as for the
purpose of broadcasting), locally administered or globally unique?

But it should be possible to change this in this RPi FTD file, then it might
work.

JKi: I'm curious, are you just in the process of confirming that it can be
done or do you actually have some purpose for this and if yes, what is it?

Best regards,
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-***@freebsd.org"

[diffusae]

Hi,

I've tried both, but not at the same time. To override the burned-in MAC
at bootime doesn't work on FreeBSD. It works on Linux, but only the
promiscuous mode works as aspected with the FreeBSD RPi build.

Post by John W. Kitz
JKi: Doesn't that depend on the sequence of events at boot time?

I don't think so. The serial number is hard-coded on the RPi. As I know,
you could change it, but with a parameter in CONFIG.TXT it doesn't
work. That's also the reason, why I like to change it. I have used a RPI
with a faulty power connector and suddenly the MAC address was changing
after reboot (this happens only once).

Post by John W. Kitz
JKi: I'm curious, are you just in the process of confirming that it can be
done or do you actually have some purpose for this and if yes, what is it?

I've look into the FDT file with dtc and found the following string:

mac-address = [00 00 00 00 00 00];

So, I guess it should be possible to change it. I tried it and the the
auto configuration of the MAC remains. Maybe I've done something wrong.

https://wiki.freebsd.org/FlattenedDeviceTree#How_to_convert_a_platform_to_FDT

Regards,

[John W. Kitz]

Reiner,

I've tried both, but not at the same time. To override the burned-in MAC at
bootime doesn't work on FreeBSD. It works on Linux, but only the promiscuous
mode works as aspected with the FreeBSD RPi build.

Post by John W. Kitz
JKi: Doesn't that depend on the sequence of events at boot time?

I don't think so. The serial number is hard-coded on the RPi. As I know, you
could change it, but with a parameter in CONFIG.TXT it doesn't work. That's
also the reason, why I like to change it. I have used a RPI with a faulty
power connector and suddenly the MAC address was changing after reboot (this
happens only once).

JKi: Again since I don't have a Pi at my disposal and since I don't have any
prior experience with one, I'm not in a position to argue this. But are you
implying that if one has two or more Pi's attached to one network(segment)
there is a, albeit slim, chance that a situation would occur in which two or
more of these Pi's would end up having the same MAC address resulting in
duplicate MAC addresses on the same LAN?

Obviously Pi's are a cheap platform, not designed for professional use, but
this would seem very awkward and unlikely to me.

In addition you mentioned in one of your emails that the Organizationally
Unique Identifier (OUI) or in short vendor portion of the MAC address used
by a Pi is b8:27:eb providing for MAC addresses ranging from
b8-27-eb-00-00-00 up to and including b8-27-eb-FF-FF-FF. Yet you mention, or
at least that is my understanding of what you wrote, that Pi's use some
algorithm to determine the last portion of the MAC address based on the Pi's
serial number, which doesn't always yield the same result on one and the
same Pi?

Post by John W. Kitz
JKi: I'm curious, are you just in the process of confirming that it
can be done or do you actually have some purpose for this and if yes, what

is it?

I've look into the FDT file with dtc and found the following string:

mac-address = [00 00 00 00 00 00];

So, I guess it should be possible to change it. I tried it and the the auto
configuration of the MAC remains. Maybe I've done something wrong.

https://wiki.freebsd.org/FlattenedDeviceTree#How_to_convert_a_platform_to_FD
T

JKi: As mentioned before I don't have a Pi at my disposal and I don't have
any prior experience with one, so I have nothing to add to this last portion
of your post.

Regards, Jk.

[John W. Kitz]

diffusae (if that's your name),

I'm not contradicting the possibility that the sys/dev/usb/net/if_smsc.c
driver needs a patch to set the mac address runtime, as you quoted a Hans
Petter in one of the emails in this thread. But in general if I were you I
would have a good look at the relevant documentation at
"https://www.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=0&manp
ath=FreeBSD+11.0-stable&arch=default&format=html" and compare that to:

ifconfig ue0 down delete
ifconfig ue0 promisc
ifconfig ue0 ether 00:FF:CC:00:11:11

as you state you've tried and came to conclude that it doesn't do what you
intend or expect it to.

Success and regards, Jk.

[diffusae]

Hello John,

Post by John W. Kitz
"https://www.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=0&manp

Yes, you're right. I've also tried some other options (-RXCSUM).

https://forums.freebsd.org/threads/49518/

Extra console error logging (debug) should be interesting, too

Post by John W. Kitz
as you state you've tried and came to conclude that it doesn't do what you
intend or expect it to.

With promisc it works, like expected. But as you mentioned before, that
is not the intended use. Don't need to log every packet on the network.

https://forums.freebsd.org/threads/57525/

Thanks a lot

Best regards,
Reiner

[John W. Kitz]

Reiner,

Post by John W. Kitz
"https://www.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=
0&manp ath=FreeBSD+11.0-stable&arch=default&format=html" and compare

Yes, you're right. I've also tried some other options (-RXCSUM).

https://forums.freebsd.org/threads/49518/

Extra console error logging (debug) should be interesting, too

JKi: I had a look at both the posts in the forum you're referring to and at
your first emails in this thread in which you wrote that you tried (I
quote):

ifconfig ue0 down delete
ifconfig ue0 promisc
ifconfig ue0 ether 00:FF:CC:00:11:11

And it's not quite clear to me what you're trying to achieve. Why would one
override the MAC address of an interface for the sole purpose of initiating
a request for a new IP address from the DHCP server (in a home environment
typically the ADSL or cable modem supplied by the ISP) that one is using.
Surely FreeBSD provides more elegant ways to achieve the same thing. If
these don't get you the desired result, based on the information supplied, I
think it would be more appropriate to look at reducing the DHCP lease time
on the server side and stick with the options available to you to initiate a
request for a new IP address from the DHCP server rather than at configuring
a locally administered MAC addresses to achieve the same thing.

As for the commands in the various post, if I compare these to
"https://www.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=0&manp
ath=FreeBSD+11.0-stable&arch=default&format=html" I wonder what, in your
opinion, the purpose is of sticking "delete" (per the documentation I
referred to (I quote) "Another name for the -alias parameter") at the end of
the first one.

In addition given that operating system commands, particularly the most
basic ones, tend to be similar across platforms (in this case I'm referring
to similar Cisco commands) and considering the possibility that you may not
have supplied all commands you used in the various posts, I would have
expected a command like "ifconfig ue0 up" to have been the last one in the
sequence.

Post by John W. Kitz
as you state you've tried and came to conclude that it doesn't do what
you intend or expect it to.

With promisc it works, like expected. But as you mentioned before, that is
not the intended use. Don't need to log every packet on the network.

https://forums.freebsd.org/threads/57525/

Thanks a lot

Best regards,
Reiner
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-***@freebsd.org"

[John W. Kitz]

Reiner,

I was again looking at one of the first posts in the thread in which you
wrote:

"I've tried it this way in /etc/start_if.ue0:

ifconfig ue0 down delete
ifconfig ue0 promisc
ifconfig ue0 ether 00:FF:CC:00:11:11

But it's only possible to do it in promicous mode of the device."

In the man pages for ifconfig the parameter 'down' is explained as follows:

"Mark an interface ``down''. When an interface is marked ``down'', the
system will not attempt to transmit messages through that interface. If
possible, the interface will be reset to disable reception as well. This
action does not automatically disable routes using the interface."

So based on the information supplied it would seem logical that "there is no
more network connection after applying these settings." as you mentioned.

Looking further down the man pages you'll notice the parameter "up" to "Mark
an interface ``up''. This may be used to enable an interface after an
``ifconfig down''. It happens automatically when setting the first address
on an interface. If the interface was reset when previously marked down, the
hardware will be re-initialized."

Hence my question shouldn't you also use "ifconfig ue0 up" at the end in the
example you supplied (see above).

Also you are referring to the bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=168268

The method stated in this bug report to reproduce the issue is:

"How-To-Repeat: /etc/rc.conf

ifconfig_re0="inet 192.168.0.2/24"

ifconfig_re0="inet 192.168.0.2/24"
ifconfig_re0_alias0="ether 00:02:1a:2b:3c:4d"

I don't know if the operating system interprets "alias" in
"ifconfig_re0_alias0" as per the man pages of ifconfig or if it just
considers it to be a label, but if it is being interpreted as per the man
pages I'd imagine the operating system to expect the parameter to contain an
IP address intended to serve as secondary IP address for the interface,
rather than a MAC address.

Did you try this command-by-command through the CLI and have the output of
that?

Jk.

[diffusae]

Hi John,

thanks a lot for you reply
/etc/start_if.ue0 will be launched before the interface is up,
so ifconfig up is done by the boot process.

The only message I get at boot in this stage is:

ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
smsc0: chip 0xec00, rev. 0002
ue0: link state changed to DOWN
ue0: link state changed to UP

I also cannot change the MAC at runtime without loosing network connection.

Post by John W. Kitz
Hence my question shouldn't you also use "ifconfig ue0 up" at the end in the
example you supplied (see above).

There is no network connection, also if I supplied the ifconfig command
on the CLI.

Post by John W. Kitz
"How-To-Repeat: /etc/rc.conf
ifconfig_re0="inet 192.168.0.2/24"
ifconfig_re0_alias0="ether 00:02:1a:2b:3c:4d"

That's another way you can set the MAC in /etc/rc.conf

Post by John W. Kitz
Did you try this command-by-command through the CLI and have the output of
that?

Yes, but I can't use alias or add parameter with the ether, lladdr or
link options. Than it says: ifconfig: ether: bad value.

But I've also tried this settings in /etc/rc.conf and it doesn't work.

Regards,
Reiner

[John W. Kitz]

Reiner,

Post by John W. Kitz
"How-To-Repeat: /etc/rc.conf
ifconfig_re0="inet 192.168.0.2/24"
ifconfig_re0_alias0="ether 00:02:1a:2b:3c:4d"

That's another way you can set the MAC in /etc/rc.conf

Post by John W. Kitz
Did you try this command-by-command through the CLI and have the
output of that?

Yes, but I can't use alias or add parameter with the ether, lladdr or link
options.

JKi: As per the man-pages of ifconfig ether, lladdr and link may be used
interchangeably and are all interpreted to mean one and the same thing.

Than it says: ifconfig: ether: bad value.

JKi: That was exactly what I tried to convey in my previous email. As per
the man pages of ifconfig 'alias' and '-alias' are intended to respectively
add and remove a, what in Cisco terminology is referred to as a, secondary
IP address to or from an interface. Since both 'ether' and the notation of
the address in "ifconfig_re0_alias0="ether 00:02:1a:2b:3c:4d" pertain to a
MAC address this is behavior that one IMHO would expect as per the
man-pages, assuming 'alias' in 'ifconfig_re0_alias0' is interpreted as a
command parameter rather than as a mere label.

My hands-on experience in the area of UNIX is limited and dated, so these
were my 5 cents worth of suggestions.

Sorry I can't help you any further at this time.

Regards, Jk.

[diffusae]

Hello Jonh,

Post by John W. Kitz
Sorry I can't help you any further at this time.

That doesn't matter. I glad, that you try to find a solution.

Best regards.
Reiner

[John W. Kitz]

Reiner,

I found a couple of examples in the FreeBSd documentation that may be useful
to you.

"The ether line will contain the MAC address of the specified interface.
Now, change the MAC address of the underlying wireless interface:

# ifconfig iwn0 ether 00:21:70:da:ae:37

Bring the wireless interface up, but do not set an IP address:

# ifconfig wlan0 create wlandev iwn0 ssid my_router up"

To retain this configuration across reboots, add the following entries to
/etc/rc.conf:

ifconfig_iwn0="ether 00:21:70:da:ae:37"

Source: https://www.freebsd.org/doc/handbook/network-aggregation.html

Are you sure the NIC you are using itself (i.e. aside from the driver) is
capable of supporting locally administered MAC addresses?

Jk.

[John W. Kitz]

Reiner,

Referring to: "(...) Universally administered and locally administered
addresses are distinguished by setting the second-least-significant bit of
the first octet of the address. This bit is also referred to as the U/L bit,
short for Universal/Local, which identifies how the address is administered.
If the bit is 0, the address is universally administered. If it is 1, the
address is locally administered. In the example address 06-00-00-00-00-00
the first octet is 06 (hex), the binary form of which is 00000110, where the
second-least-significant bit is 1. Therefore, it is a locally administered
address. Consequently, this bit is 0 in all OUIs. (...)"

Source: https://en.wikipedia.org/wiki/MAC_address#Universal_vs._local

and my earlier remarks about functional MAC addresses, it could also matter
which address you are using as your locally administered address.

Jk.

[John W. Kitz]

Reiner,

thanks a lot.

I'm not sure, but I think, that it is this one: LAN9512-JZX

I am using an RPI-B plus. The LAN chip on all boards seems to be identical.

http://elinux.org/RaspberryPi_Boards

So the data sheet should be here:

http://ww1.microchip.com/downloads/en/devicedoc/9512.pdf

JKi: The information on those sites seems quite conclusive and authoritative, so I'm quite sure you are right on that.

For sure, this NIC support locally administered MAC addresses.
I can set the MAC address on the same RPi in Linux without problems.

JKi: I don't know if you mentioned that it does work using Linux in any of the previous posts, if you did I must have overlooked it.

Setting the second-least-significant bit of the first octet of the address sounds really interesting to me. Do you think its a problem with the driver and FreeBSD kernel, if this bit is set to 0. I was using 00:1f:ca, which is the Vendor ID of Cisco. Maybe this could be relevant.
I will try to set something different, who the significant bit is one.

But I don't think, that's because of the hardware, because everything works fine in Linux. But I guess, if I try to set the same MAC address, which is "burned in", than I will lose network connection, too. Never tried it, only a variation of the last octet. This only work in promiscuous mode.

JKi: I don't know if strict adherence to the specification with regards to the U/L bit when choosing the locally administered MAC address you're going to use is going to make any difference in it working or not. You would have to test that on your Pi or you'd have to give it a try on a Linux installation.

JKi: That having been mentioned; from experience I wouldn't be surprised if it doesn't matter. If my memory serves me right my colleagues and I used to adhere to it when choosing locally administered MAC addresses, but this was mostly in IEEE 802.5 networks which by design tended to be less forgiving (hence my remarks about functional MAC addresses), especially in the early years.

JKi: Over the years I have noticed many times that not all products adhere to relevant specifications and standards as strictly as others do, which accounts for numerous interoperability incidents and problems in many an IT department around the world.

JKi: The only thing I can say is that the Wikipedia article appears to be correct with respect to this; I verified it with against the content on this topic of a number of different books I have.

BTW: The RPi isn't professional, but a nice thing to play around with and learn.

JKi: I didn't intend to imply anything by mentioning that the Pi probably wasn't designed with the professional market in mind other than just that. There are numerous examples to be found on the Internet of articles which discuss (clusters of) cheap hardware like the Pi, which do an excellent job in (research) projects at various universities around the globe.

It isn't really fast, especially the first one, but most of simple services work on it.

JKi: This is exactly why I'm pleased to see that with 11.0 the first FreeBSD images intended for use on those platforms have been released.

I've heard from some HAM radio amateurs in Berlin, that they are using an RPi as a relay and it works great.

JKi: I recently watched this

video in which a Pi was shown briefly.

Best regards,
Reiner

Post by John W. Kitz
Reiner,
I don't know which chipset provides for the Ethernet interface on the
Pi that you are using, but based on the remark "The
sys/dev/usb/net/if_smsc.c driver needs a patch to set the mac address
runtime." by Hans Petter in one of the emails on the freebsd-arm
distribution list I'm assuming it is most likely the SMSC LAN9514/LAN9514i.
In case you don't have the datasheet of that controller please find
one, in which I have highlighted all references to the MAC address,
attached to this email for your convenience.
Regards, Jk.