This site is now in read-only archive mode. Please move all discussion, and create a new account at the new Victron Community site.
My firewall is blocking the cerbo because "arp cache poisoning attack".
Result everything blocked & the only way to get it back alive is hard reset (power disconnection). Then it works for a while I can't define when it really happens but I suppose during api demands to VRM.
How can I solve this issue?
Hi @Stefan DB
Those IPs doesn't seem right... Looks like APIPA addresses.
Are you sure your network and Cerbo is configured properly? Or the Eset?
Do you have a range extender or AP on your Wi-Fi?
Or did you checked to not have any duplicated IP addresses?
Or did you assigned any static IP to a DHCP reserved range?
Alex
The IP adress 169.254.x.x (the x are changing). When I click on it I arrive at the cerbo but the cerbo has indeed another fix IP.
In fact everything was working fine till some time ago so I assume everything was correct configured. Maybe update or from Victron or from Eset causes this. No idea not a an expert in these things that is why I ask it.
I can say eset don't have to look at 169.254.000.000 to 169.254.999.999 but need to be sure this is safe.
See here: https://community.victronenergy.com/questions/49662/ccgx-ethernet-mac-address-changing-link-local.html?childToView=268605#comment-268605
The Cerbo looked for and failed to get an IP address from a network DHCP server. It then assigned its own using apipa. It might clear if you restart the Cerbo and/or the whole system.
But may be a technical/software thing for tech network people.
Hey @kevgermany and all,
actually its a bit different:
its normal for the GX to have both a normal ip address (manually configured or DHCP), and at the same time a link local address as well (169.254.x.x). Its by design, and has certain advantages.
On some routers this apparently seems to raise a warning. Perhaps you can disable that warning feature @Stefan DB in your router.
Ok but how do I solve the problems ?
Made some changes in the node red code (less api calls) and this problem didn't come back.
BUT I still have the problem that Node Red get complete blocked serveral times a day. I can't acces any more via VRM (or local) to the Node Red page. Then I gave to disconnect the power off the servo to get restarted. Flows also stop complete.
How can I find the reason for this behavior and solve it?
@mvader (Victron Energy) it is a communication problem caused by something that is blocked inside the GX. Yesterday a debugged the flows and they worked perfect without issues. This morning still fine. Right now after some changing something in a function I could not deploy again. When I want to reload node-red via VRM I get no respons from the server. Browser stays trying to open the page but nothing happens. Now I will have to do a hard reset (power off/onn) on the GX before I get back in. Do you have any idea what is causing this issue since a while (before everything worked fine)?
I is getting worser no I am blocked again & can't even connect to the remote console.
I'd start with basics: check free disk space, on rootfs + data partition, and check CPU usage.
Or Disable the node-red flows and see what happens then.
And check if the firewall is still blocking things, and if yes, unblock it, or disable that rule entirely for a while and see what happens then.
Node-red flows have i put in disable already but I don't think the problem is there as it was working without troubles yesterday.
How do I acces to "check free disk space, on rootfs + data partition, and check CPU usage." ?
I have found a conditional endless loop in my code.
I think this will be de reason why the node red was blocked. I was suspecting something like this but clearly overlooked.
@Stefan DB I'd uninstall/disable the eset security software for two days and see if that helps. As @mvader (Victron Energy) described, using Link Local IP address from private address space like 169.x is perfectly valid as long as they advertise their own MAC address different from the MAC address that the DHCP ethernet interface is using.
The cache poisoning error would mean that 169.x is actually advertised with the same MAC address as the DHCP interface... meaning the 169.x is trying to steal the packets destined to DHCP interface...
So I'd disable eset to see if it helps... and if it helps, then I'd tcpdump ARP to see what real MAC/IP mappings is the Cerbo actually advertising on your network...
But given the fact that it works for all the Cerbo devices out there, it may as well be eset being buggy?
