netdudeuk
Posts: 10
Joined: Sun Jul 03, 2016 4:30 pm

Same MAC addresses

Fri Dec 02, 2016 7:57 pm

Hi

I have a couple of these with another one coming -

http://www.ebay.co.uk/itm/381475334140? ... EBIDX%3AIT

Everything has been fine using a Pi Zero with the default driver from the May 27th Raspbian build.

However, I plugged another Pi Zero with another of those adapters into the LAN and had issues.

It turns out that the MAC addresses are the same.

I've confirmed this with ifconfig and arp-a from a PC.

So, any easy way around it ? Maybe the GNU Mac Changer listed in the Add / Remove Software utility ?

Thanks

User avatar
pi-anazazi
Posts: 789
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Same MAC addresses

Fri Dec 02, 2016 8:08 pm

Hi!

The MAC is associated to the RJ45 hardware, i.e. in your case to the USB-hub with RJ45. Why they all have the same MAC? Ask the vendor of the USB-hub, has nothing to do with your zero(s). ;-)
Kind regards

anazazi

netdudeuk
Posts: 10
Joined: Sun Jul 03, 2016 4:30 pm

Re: Same MAC addresses

Fri Dec 02, 2016 10:44 pm

I was wondering if anyone else had used this device and seen similar issues. Maybe there's a way to update the MAC address from the Pi ?

Anyone know what the Ethernet device is inside these or is there a way to find out from within the OS ?

Thanks

User avatar
DougieLawson
Posts: 39613
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Same MAC addresses

Fri Dec 02, 2016 10:50 pm

Usually those very cheapo, very awful things have DM9601 chips in them. If they're super cheapo, exceedingly awful Chinese fakes then you got what you paid for. There's lots of the Chinese junk (sold on eBay) where they clone a chip but don't bother with the burned in serial number stuff.

Send them back to where you got them, stick your hand in your pocket and buy something better that will work with your RPi Zero (and as a power supply for it). https://store.google.com/product/ethern ... chromecast
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

netdudeuk
Posts: 10
Joined: Sun Jul 03, 2016 4:30 pm

Re: Same MAC addresses

Fri Dec 02, 2016 11:24 pm

Thanks Dougie.

This article supports your view -

http://gfdsa.gfdsa.org/2013/05/14/usb-e ... nt-to-buy/

Mine have the same MAC address.

Rather annoying as they actually work very well for me except for the MAC issue.

Thanks for the suggestion but I have five Pi Zeros so it would work out pretty expensive. I also have official and unofficial wifi dongles and the ENC28J60 boards. I could look at the latter again but they have been less reliable.

I wonder if I could find some genuine DM9601 chips ...


User avatar
DougieLawson
Posts: 39613
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Same MAC addresses

Sat Dec 03, 2016 12:19 am

Try it. Don't be surprised when the hardware rejects the request to set a new MAC addr.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

User avatar
pi-anazazi
Posts: 789
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Same MAC addresses

Sat Dec 03, 2016 9:37 am

eeehm, if you need raspis with rj45 why don't you buy raspi 2, OK, more expensive, but the networking will have no issues (at least from cloned MAC addresses....)
Kind regards

anazazi

Martin Frezman
Posts: 1009
Joined: Mon Oct 31, 2016 10:05 am

Re: Same MAC addresses

Sat Dec 03, 2016 9:48 am

I get a kick out of posters in this thread referring to the ethernet adapter as "the RJ45".

Do you refer to your telephones as "The RJ11" ?
If this post appears in the wrong forums category, my apologies.

User avatar
pi-anazazi
Posts: 789
Joined: Fri Feb 13, 2015 9:22 pm
Location: EU

Re: Same MAC addresses

Sat Dec 03, 2016 9:55 am

Jepp
Kind regards

anazazi

netdudeuk
Posts: 10
Joined: Sun Jul 03, 2016 4:30 pm

Re: Same MAC addresses

Sat Dec 03, 2016 8:17 pm

pi-anazazi wrote:eeehm, if you need raspis with rj45 why don't you buy raspi 2, OK, more expensive, but the networking will have no issues (at least from cloned MAC addresses....)
I have a Pi 2 and five Pi Zeros.
I don't need sledgehammers to crack nuts.
Not every project will need a LAN connection.

netdudeuk
Posts: 10
Joined: Sun Jul 03, 2016 4:30 pm

Re: Same MAC addresses

Sat Dec 03, 2016 8:24 pm

DougieLawson wrote:Try it. Don't be surprised when the hardware rejects the request to set a new MAC addr.
Here's how I got on.

The commands -

ifconfig eth0 down
ifconfig eth0 hw ether 00:80:48:BA:d1:30
ifconfig eth0 up

The results -

eth0 Link encap:Ethernet HWaddr 00:80:48:ba:d1:30
inet addr:192.168.1.183 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::18e9:b5d1:45ac:4d76/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2467 errors:8 dropped:2 overruns:5 frame:12
TX packets:3106 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:744159 (726.7 KiB) TX bytes:883974 (863.2 KiB)

This stayed the same after several reboots but was not saved after an extended power off.

netdudeuk
Posts: 10
Joined: Sun Jul 03, 2016 4:30 pm

Re: Same MAC addresses

Sat Dec 03, 2016 8:25 pm

Martin Frezman wrote:I get a kick out of posters in this thread referring to the ethernet adapter as "the RJ45".

Do you refer to your telephones as "The RJ11" ?
Not me ;)

Martin Frezman
Posts: 1009
Joined: Mon Oct 31, 2016 10:05 am

Re: Same MAC addresses

Sat Dec 03, 2016 10:08 pm

netdudeuk wrote:
Martin Frezman wrote:I get a kick out of posters in this thread referring to the ethernet adapter as "the RJ45".

Do you refer to your telephones as "The RJ11" ?
Not me ;)
Good to hear!
If this post appears in the wrong forums category, my apologies.

User avatar
Shoka
Posts: 147
Joined: Sat Jul 12, 2014 8:35 pm
Location: Manchester, UK

Re: Same MAC addresses

Sun May 03, 2020 7:52 pm

Sorry to be grave digging, but this thread came up on a search for this issue, and not much else did on Raspberry Pi and devices that have fixed, uniform MAC addresses.

I found my way here via a search for ways to set MAC addresses on cheap USB-Ethernet dongles.

Dougie's dismissal of their fixability disheartened me somewhat.

I've found a workable solution for me that seems robust, so I'll describe it here, along with some background.

It's based on using systemd-networkd which I use for all my "server" setups, so its probably not for everyone.

You could probably use the same techniques with other network management options.

The problem:

I have a number of devices in my local network, VOIP devices mainly, that think they should be the router in their own network.

I'm not using them that way, they are in a very protected environment, but the devices think that to protect themselves they should be configurable/manageable only from their "inside" interfaces. They expect a management client to appear there, and to accept a DHCP address from them.

I've been using interfaces on one of my "real" routers to provide those "back door" interfaces, configuring ports on the router as DHCP clients, and masquerading connections to those ports so that management devices (ie my laptop) connected elsewhere in my local network can connect to the management/config ports on those devices.

The ports carry only trivial management/configuration traffic, and need only be 10/100 connections and I now need the ports on the router for more important and high bandwidth operations.

Ergo I can meet that need with a raspberry pi based router with the Pi's native Ethernet as the upstream port connected to my network, and the backdoor ports connected via USB 10/100 Ethernet dongles. I need four backdoor ports.

Pi I'm using is:

Code: Select all

Hardware	: BCM2835
Revision	: a02082
Serial		: 00000000c2834f7c
Model		: Raspberry Pi 3 Model B Rev 1.2


Issues:

I need USB/Ethernet dongles that use up a small area on the Pi's USB port field so that four can be plugged in at once.
That eliminates the nice tidy "one piece" units that have a USB interface on one end and an RJ45 on the other, so we are down to the types that have a free USB port on a cable with the RJ45 in a separate box on the other end of the cable. I've a few of these already, but on some the USB interface is too big and blocks the other interfaces, and the gigabit ones I have are also power greedy and running four of them off a pi is asking for trouble, long term.

The cheap little 10/100 interfaces are relatively low power consumption, and the connectors are small, so I ordered four new units like that for this task.

Further Considerations:

For the present, since all the interfaces will act as DHCP clients, ensuring that each USB (physical) interface remains attached to the same Ethernet interface is not critical, but I'd like the solution to offer that stability.

Original plan:

I expected to use the interfaces MAC address to steer the Ethernet interface to the correct USB port.

I was less than impressed to discover when they arrived that all four of the devices reported the same MAC address.
00:e0:4c:53:44:58

Which led me here among many other places.

I've come up with a solution...

Revised plan:

On a cold boot (from power off) the four interfaces enumerate in the same order, and seem to do this reliably. I think this is because the USB hub code enumerates the ports in the internal hub in order. That means that the USB interfaces get assigned Ethernet interfaces in that same order.

This solution relies on that property.

Digging about with udevadm, specifically "udevadm info /sys/class/net/<device file>" locates that each interface is associated with a DEVPATH=="platform-3f980000.usb-usb-0:1.X:1.0" for X=2 to 5. That is in effect I believe, its USB address

That lets me construct a udevd rule like this:

Code: Select all

ACTION=="add", SUBSYSTEM=="net", DEVPATH=="platform-3f980000.usb-usb-0:1.3:1.0", ATTR{address}=="00:e0:4c:53:44:58", RUN+="/usr/bin/ip link set dev eth2 address 00:e0:4c:53:44:52"
That rule, if and only if, the MAC address on that DEVPATH is at the default, resets the MAC address to a arbitrary different, but standard MAC address in a closely associated range.

Four separate rule files are required (because timing and order matter, and one rule needs to complete before we mess with the next) to set the MAC address on each of the USB interfaces to a planned, but non default (burnt in) MAC address.

I'm not sure if you physically unplug and re-plug the USB interface, (rather than the Ethernet cable) if that rule will work, since the action part of that rule depends on the interface name it acquires on re-plugging matches the Ethernet interface name it would get from a cold boot. I suspect that this would not necessarily be the case, and I cannot find a way of patching the MAC address in the udev rule without using an interface name.

Unplugging and plugging the USB interfaces on a very stuffed Raspberry Pi is sufficiently difficult that I'm not motivated to try it and find out. I'm treating the USB/Ethernet interfaces as part of the Pi, so don't care.

For warm boot, all is well since the modified MAC address's are preserved (since the USB/Ethernet interfaces are not powered down), and the udev rules will not fire since the MAC address will not match.

Then the second part of the cunning plan...

Configure a .link file in the /etc/systemd/network/ directory

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 11-eth1.link 
[Match]
MACAddress=00:e0:4c:53:44:51

[Link]
Description="Network backdoor link to XXXX"
Name=eth1

netadmin@backdoorpi
This acts as in the original plan, and uses the (modified at the first cold boot, before systemd-networkd starts) MAC address to ensure that the Ethernet interface name is assigned in line with the MAC address and hence in line with the physical interface.

Then configure a .network file in the same directory

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 11-dhcp.network 
[Match]
Name=eth1

[Link]
MACAddress=00:e0:4c:53:44:51

[Network]
Description="private network backdoor"
DHCP=ipv4
LLDP=true
EmitLLDP=true
LinkLocalAddressing=no
IPv6AcceptRA=no

[DHCP]
ClientIdentifier=mac

netadmin@backdoorpi:
You need:

Four udevd rule files
Four .link files (actually also processed by udevd)
Five .network files processed by systemd-networkd (one for the Pi's integral Ethernet interface)

I'll put the complete listings at the end of this post.

Thus running we see:

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.16.194  netmask 255.255.255.0  broadcast 172.16.16.255
        ether b8:27:eb:83:4f:7c  txqueuelen 1000  (Ethernet)
        RX packets 53563  bytes 3404845 (3.2 MiB)
        RX errors 0  dropped 33634  overruns 0  frame 0
        TX packets 12741  bytes 2098713 (2.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.12  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:e0:4c:53:44:51  txqueuelen 1000  (Ethernet)
        RX packets 1419  bytes 800341 (781.5 KiB)
        RX errors 43  dropped 11  overruns 13  frame 52
        TX packets 3759  bytes 531932 (519.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.103  netmask 255.255.255.0  broadcast 192.168.10.255
        ether 00:e0:4c:53:44:52  txqueuelen 1000  (Ethernet)
        RX packets 867  bytes 198708 (194.0 KiB)
        RX errors 10  dropped 3  overruns 1  frame 8
        TX packets 3117  bytes 288346 (281.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.11.22  netmask 255.255.255.0  broadcast 192.168.11.255
        ether 00:e0:4c:53:44:53  txqueuelen 1000  (Ethernet)
        RX packets 482  bytes 49083 (47.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2726  bytes 260462 (254.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth4: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:e0:4c:53:44:54  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 1  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Thus we have distinct different MAC addresses for each interface, and stable assignments of Ethernet interface names.

QED...


Further Notes:

Since I'm here and explained this set up this far, I may as well provide the rest of the router set up.

I'm using two further pieces of software.

My backbone network is built of MikroTik routers, and uses the OSPF network routing protocol.

To interface this Pi based router to the rest of the routers could be done in multiple ways.

I use the bird internet routing daemon for this. An elderly but workable release of bird ver 1 is available in the Raspbian repository.

It's not installed by default, you need to install it. It runs a few internal protocols, which both detect when the kernel gets new routes, and adds the OSPF routes to the kernel on the Pi.

/etc/bird/bird.conf (bird is paranoid about its config file, need to be root to access it)

Code: Select all

root@backdoorpi:/etc/bird# cat bird.conf 

router id 172.18.200.80;

# The Kernel protocol is not a real routing protocol. Instead of communicating
# with other routers in the network, it performs synchronization of BIRD's
# routing tables with the OS kernel.

protocol kernel {
	learn;			# Learn all alien routes from the kernel
	persist;		# Don't remove routes on bird shutdown
	scan time 10;	# Scan kernel routing table every 10 seconds
	export all;		# Default is export none
}

# The Device protocol is not a real routing protocol. It doesn't generate any
# routes and it only serves as a module for getting information about network
# interfaces from the kernel. 
protocol device {
	scan time 10;		# Scan interfaces every 10 seconds
}

protocol ospf backdoorpi_OSPF {
	tick 2;
	rfc1583compat yes;
	export all;
	area 0.0.0.0 {
		stub no;
		interface "eth0" {
			hello 10;
			retransmit 5;
			cost 10;
			transmit delay 1;
			priority 1;
			dead count 4;
			wait 40;
			type broadcast;
		};
	};
}

root@backdoorpi:/etc/bird# 

That takes care of the routing management.


The masquerade is set up with nftables.
Again not installed by default, you need to install it.

It is configured via /etc/nftables.conf

The following is a minimal config, with little fire-walling.

Code: Select all

netadmin@backdoorpi:/etc $ cat nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
	chain input {
		type filter hook input priority 0;
	}

    chain forward {
      type filter hook forward priority 0;

    # Allow incoming on eth0
       iifname eth0 ct state new accept

    # Allow established & related on all interfaces
       iifname eth* ct state related, established accept

    # Drop invalid on all interfaces
       iifname eth* ct state invalid drop

    # Drop any other incoming traffic on all interfaces
      iifname eth* drop

    # Allow outgoing via all interfaces
      oifname eth* accept

  }

  chain output {
    type filter hook output priority 0;
  }

}

table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }

  chain postrouting {
    type nat hook postrouting priority 0;

    # Masquerade outgoing traffic
      oifname eth1 masquerade
      oifname eth2 masquerade
      oifname eth3 masquerade
      oifname eth4 masquerade
  }
}
netadmin@backdoorpi:/etc $ 
Identify this specific USB/Ethernet adapter:

I purchased them via:
eBay item number:362694259987

UK stock, arrived in a couple of days.
They have no obvious Link LED, but the whole end of the box with the RJ45 connector in it lights up like a glow worm when the link becomes active.

Code: Select all

netadmin@backdoorpi:/etc/udev/rules.d $ udevadm info /sys/class/net/eth1
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/net/eth1
L: 0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/net/eth1
E: INTERFACE=eth1
E: IFINDEX=3
E: SUBSYSTEM=net
E: USEC_INITIALIZED=5561987
E: ID_NET_NAMING_SCHEME=v240
E: ID_NET_NAME_MAC=enx00e04c534458
E: ID_OUI_FROM_DATABASE=REALTEK SEMICONDUCTOR CORP.
E: ID_VENDOR=0fe6
E: ID_VENDOR_ENC=0fe6
E: ID_VENDOR_ID=0fe6
E: ID_MODEL=USB_2.0_10_100M_Ethernet_Adaptor
E: ID_MODEL_ENC=USB\x202.0\x2010\x2f100M\x20Ethernet\x20Adaptor
E: ID_MODEL_ID=9700
E: ID_REVISION=0101
E: ID_SERIAL=0fe6_USB_2.0_10_100M_Ethernet_Adaptor
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:000000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=dm9601
E: ID_VENDOR_FROM_DATABASE=ICS Advent
E: ID_MODEL_FROM_DATABASE=DM9601 Fast Ethernet Adapter
E: ID_PATH=platform-3f980000.usb-usb-0:1.2:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_2_1_0
E: ID_NET_DRIVER=dm9601
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth1
E: TAGS=:systemd:

netadmin@backdoorpi:
USB_Ethernet2.JPG
USB_Ethernet2.JPG (196.81 KiB) Viewed 630 times
netadmin@backdoorpi:/etc/udev/rules.d $

Full file list:

Code: Select all

netadmin@backdoorpi:/etc/udev/rules.d $ cat 75*rules
ACTION=="add", SUBSYSTEM=="net", DEVPATH=="platform-3f980000.usb-usb-0:1.2:1.0", ATTR{address}=="00:e0:4c:53:44:58", RUN+="/usr/bin/ip link set dev eth1 address 00:e0:4c:53:44:51"

netadmin@backdoorpi:/etc/udev/rules.d $

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 11*.link
[Match]
MACAddress=00:e0:4c:53:44:51

[Link]
Description="Network backdoor link to XXXX"
Name=eth1
netadmin@backdoorpi:

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 11*.network
[Match]
Name=eth1

[Link]
MACAddress=00:e0:4c:53:44:51

[Network]
Description="private network backdoor"
DHCP=ipv4
LLDP=true
EmitLLDP=true
LinkLocalAddressing=no
IPv6AcceptRA=no

[DHCP]
ClientIdentifier=mac
netadmin@backdoorpi:

Code: Select all

netadmin@backdoorpi:/etc/udev/rules.d $ cat 76*rules
ACTION=="add", SUBSYSTEM=="net", DEVPATH=="platform-3f980000.usb-usb-0:1.3:1.0", ATTR{address}=="00:e0:4c:53:44:58", RUN+="/usr/bin/ip link set dev eth2 address 00:e0:4c:53:44:52"

netadmin@backdoorpi:/etc/udev/rules.d $ 

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 12*.link
[Match]
MACAddress=00:e0:4c:53:44:52

[Link]
Description="Network backdoor link to XXXX"
Name=eth2
netadmin@backdoorpi:

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 12*.network
[Match]
Name=eth2

[Link]
MACAddress=00:e0:4c:53:44:52

[Network]
Description="backdoor two"
DHCP=ipv4
LLDP=true
EmitLLDP=true
LinkLocalAddressing=no
IPv6AcceptRA=no

[DHCP]
ClientIdentifier=mac
netadmin@backdoorpi:

Code: Select all

netadmin@backdoorpi:/etc/udev/rules.d $ cat 77*rules
ACTION=="add", SUBSYSTEM=="net", DEVPATH=="platform-3f980000.usb-usb-0:1.4:1.0", ATTR{address}=="00:e0:4c:53:44:58", RUN+="/usr/bin/ip link set dev eth3 address 00:e0:4c:53:44:53"

netadmin@backdoorpi:/etc/udev/rules.d $ 

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 13*.link
[Match]
MACAddress=00:e0:4c:53:44:53

[Link]
Description="Network backdoor link to XXXX"
Name=eth3
netadmin@backdoorpi:

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 13*.network
[Match]
Name=eth3

[Link]
MACAddress=00:e0:4c:53:44:53

[Network]
Description="backdoor three"
DHCP=ipv4
LLDP=true
EmitLLDP=true
LinkLocalAddressing=no
IPv6AcceptRA=no

[DHCP]
ClientIdentifier=mac
netadmin@backdoorpi:

Code: Select all

netadmin@backdoorpi:/etc/udev/rules.d $ cat 78*rules
ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:e0:4c:53:44:58", RUN+="/usr/bin/ip link set dev eth4 address 00:e0:4c:53:44:54"

netadmin@backdoorpi:/etc/udev/rules.d $ 

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 14*.link
[Match]
MACAddress=00:e0:4c:53:44:54

[Link]
Description="Network backdoor link to XXXX"
Name=eth4
netadmin@backdoorpi:

Code: Select all

netadmin@backdoorpi:/etc/systemd/network $ cat 14*.network
[Match]
Name=eth4

[Link]
MACAddress=00:e0:4c:53:44:54

[Network]
Description="backdoor four"
DHCP=ipv4
LLDP=true
EmitLLDP=true
LinkLocalAddressing=no
IPv6AcceptRA=no

[DHCP]
ClientIdentifier=mac
netadmin@backdoorpi:
Last edited by Shoka on Sun May 03, 2020 8:24 pm, edited 1 time in total.
Cheers Harry

epoch1970
Posts: 5461
Joined: Thu May 05, 2016 9:33 am
Location: Paris, France

Re: Same MAC addresses

Sun May 03, 2020 8:06 pm

Shoka wrote:
Sun May 03, 2020 7:52 pm
The problem:

I have a number of devices in my local network, VOIP devices mainly, that think they should be the router in their own network.
These things, VOIP devices esp. expect to be alone in their LAN, usually what you'd do is create a VLAN for them rather that add dedicated cables/interfaces.
"S'il n'y a pas de solution, c'est qu'il n'y a pas de problème." Les Shadoks, J. Rouxel

User avatar
Shoka
Posts: 147
Joined: Sat Jul 12, 2014 8:35 pm
Location: Manchester, UK

Re: Same MAC addresses

Sun May 03, 2020 8:34 pm

I don't think I can configure vlans on the upstream interfaces. These are rather limited devices.
My backdoor cable is the only connectivity they have on the downstream interface.
They happily talk to each other over the upstream interface via SIP connections.
Just will not present a management interface there.
All I am using them for is as peripherals for a raspbx Asterisk VOIP exchange and similar tasks.

Harry
Cheers Harry

Return to “Troubleshooting”