This site is now in read-only archive mode. Please move all discussion, and create a new account at the new Victron Community site.
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
Hi @Kenrick
Did you check if it does this also when using a 'normal' router that does DHCP?
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)
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
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 .
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.
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.
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
22 People are following this question.