question

kenrick avatar image
kenrick asked

CCGX ethernet MAC address changing (link-local)

I am attempting to use the ethernet MAC address of CCGX to determine it's IP on a DHCP network. The CCGX is running firmware v2.53.


Our device is acting as the DHCP server in this case, and the MAC address we see in the arp table for the CCGX changes back and forth between two addresses. Sometimes the MAC appears correctly, with a prefix of 'c4:f3:12' which matches the value reported on the console display and by ifconfig on the CCGX for the eth0 interface. However, sometimes we are seeing what appears to be a random address (changing on reboot), for example with a prefix of '56:e8:21'.

This second value corresponds with the MAC shown on the link-local (ll-eth0) MAC address shown by ifconfig on the CCGX. Which looks like it was added as part of this issue: https://github.com/victronenergy/venus/issues/361

My guess as to why we're seeing the other MAC is that the CCGX is sending packets out over this link-local interface, even though it has a valid DHCP IP address. Do you have any suggestions? We would ideally like to see only the 'real' eth0 MAC address once it has a DHCP IP so we can easily identify it.
CCGX Color Controlethernet
1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

kenzo avatar image kenzo commented ·

These effects are due to avahi (see here and here for details); you can stop and disable as follows:

/etc/init.d/avahi-autoipd stop
/etc/init.d/avahi-daemon stop
update-rc.d avahi-autoipd disable
update-rc.d avahi-daemon disable
0 Likes 0 ·
5 Answers
mvader (Victron Energy) avatar image
mvader (Victron Energy) answered ·

In 2020 we fixed a bug related to this.

Since then now and then people have questions, for example about why there is a mac address that changes randomly at every boot.

For the answer to that, and more, see my answer of Mar 12 2024 here:

https://community.victronenergy.com/questions/133443/cerbo-gx-announces-two-ip-adresses.html

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Daniël Boekel (Victron Energy Staff) avatar image
Daniël Boekel (Victron Energy Staff) answered ·

Hi @Kenrick

Did you check if it does this also when using a 'normal' router that does DHCP?

1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

kenrick avatar image kenrick commented ·

Hi Daniël,

We have now tested this with a two new devices (CCGX + client computer). Both devices were connected to a 'normal' office LAN which has a physical router acting as the DHCP server. We see similar behaviour. This new CCGX's mac changed between '3e:3e:bf' and '0c:b2:b7', where the first one is unknown and the second is a Texas Instruments MAC (a 'real' address).

Any other suggestions? It seems like something on the CCGX itself is causing this, because we have seen it on multiple CCGX devices but don't see it on most other network devices. If it helps here is some output that we see when we point arping at the CCGX (with the last few characters of the MAC addresses hidden):

~$ arping -I eth0 192.168.15.133
ARPING 192.168.15.133 from 192.168.15.98 eth0
Unicast reply from 192.168.15.133 [0C:B2:B7:XX:XX:XX]  1.113ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  1.406ms
Unicast reply from 192.168.15.133 [0C:B2:B7:XX:XX:XX]  165.599ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  167.127ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  1.007ms
Unicast reply from 192.168.15.133 [0C:B2:B7:XX:XX:XX]  850.505ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  850.952ms
Unicast reply from 192.168.15.133 [0C:B2:B7:XX:XX:XX]  953.276ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  953.696ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  1.140ms
Unicast reply from 192.168.15.133 [0C:B2:B7:XX:XX:XX]  779.928ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  780.454ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  1.677ms
Unicast reply from 192.168.15.133 [0C:B2:B7:XX:XX:XX]  155.854ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  157.078ms
Unicast reply from 192.168.15.133 [3E:3E:BF:XX:XX:XX]  1.609ms
^CSent 5 probes (1 broadcast(s))
Received 16 response(s)


0 Likes 0 ·
mvader (Victron Energy) avatar image
mvader (Victron Energy) answered ·

Hi Kenrick, we found an issue with arp, see here for the fix:


https://github.com/victronenergy/meta-victronenergy/commit/0b0880c8db77aa2ade4e49a501b473c0ad4bf877


(Note that link might disappear once we included in the master-branch of that repo. The commit is called sysctl-conf: set arp_ignore .


its scheduled to be included in v2.60.


all the best & thanks for helping to make a better product!

Matthijs

2 comments
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

mvader (Victron Energy) avatar image mvader (Victron Energy) ♦♦ commented ·

Hi @Kenrick, the fix for your issue is now available in a beta version, details here: https://community.victronenergy.com/questions/51615/venus-os-v26025-available-to-be-tested.html .

0 Likes 0 ·
schneeseefee avatar image schneeseefee mvader (Victron Energy) ♦♦ commented ·

It is possible that the fix was forgotten to be included in the production release?

0 Likes 0 ·
schneeseefee avatar image
schneeseefee answered ·

Thress years later with firmware 3.10 the problem still exists. I was wondering about unknown addresses in my router that appeared over a longer period of time. My Cerbo is connected to the router, which is acting as DHCP server, via an unmanaged switch. Root cause: my Cerbo generates after every reboot a new zombie MAC address that connects via ethernet to my router. This connection is always active additional to the standard Cerbo LAN connection. It is very confusing.

1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

christiangurk avatar image christiangurk commented ·
I have the same "problem" with fw 3.20~10. Would be great, if this behaviour could be disabled in the console.
0 Likes 0 ·
angus-parkinson avatar image
angus-parkinson answered ·

This is an interesting one. I noticed some log messages in my router saying

7a:76:ac:09:44:4a IP conflict Source IP and/or VLAN mismatch Client: 169.254.7.159, MAC: 7A:76:AC:09:44:4A, VLAN: 0, details: sent 11270 unexpected packets


Done a packet capture on my LAN and managed to see some SSDP packets coming from that MAC. The captured packets had the real MAC of the GX in the messages. So I enabled SSH on the GX used "ifconfig -a" command and found this interface in the list.


ll-eth0 Link encap:Ethernet HWaddr 7A:76:AC:09:44:4A

inet addr:169.254.7.159 Bcast:0.0.0.0 Mask:255.255.0.0

inet6 addr: fd79:40c8:1467:914e:7876:acff:fe09:444a/64 Scope:Global

inet6 addr: fe80::7876:acff:fe09:444a/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1

RX packets:449066 errors:0 dropped:95263 overruns:0 frame:0

TX packets:11619 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:51062236 (48.6 MiB) TX bytes:4729516 (4.5 MiB)

Not sure why this interface is always active.







1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Link local address is always active on purpose. See what I typed here for explanation: https://community.victronenergy.com/questions/133443/cerbo-gx-announces-two-ip-adresses.html



what we’ll look into is the changing mac addresses

0 Likes 0 ·

Related Resources

CCGX Product Manual

CCGX Product page

Additional resources still need to be added for this topic