I’m observing that after a few hours/days the wifi gets into a really weird state. The device is unreachable over IP and it’s not renewing its DHCP lease, but I can still see the MAC address being registered to my access points and on the device under the wifi connections it shows “connecting” next to the network but never connects. if I disable the “Allow using Wifi for internet access” option than I can’t reenable it and it says, “No Wi-Fi adapter connected”. Once I reboot the device, we’re back in business and everything works great for a while.
On the network side nothing has changed - same access points. Van is parked in the same spot, and it does connect post reboot so it’s unlikely a channel issue (maybe channel steering or something similar is doing something weird with the software/hardware - I can’t really root cause that). All of this worked great for over a year and it’s just been over the last ~month that I’m seeing this strange behavior.
Pictures:
Shows the device in the “broken” state. The mac of the Netgear adapter is showing up on my wireless network, no ARP is showing up on the router/dhcp server, the IP address it had is expired and unreachable.
I did enable the reboot on VRM connectivity loss setting to see if that helps. However, I’m not sure this will be a good long-term solution as when we’re traveling WiFi is spotty (if at all) and it seems less than ideal to have the device rebooting every couple hours.
Details below and everything is on the latest versions. My access points offer both 2.4ghz and 5ghz networks. The Cerbo is connected to the 2.4ghz network using WPA2 security.
Client/Device Side:
Cerbo Gx - firmware version 3.75
Netgear AC1200
Network side:
Access points - Eero Mesh (the van connects to an Eero 6 extender) running 7.15.1 (latest)
Extenders are some of the most problematic network devices, the cause of many issues.
Mesh networks can make it easier to deploy a wireless network without all the cabling, but they can also introduce problems. The amazon and google offerings have not been without faults.
I would try eliminating any extensions and get a decent signal to a wired AP/router and see if your issue disappears.
There are no known issues that would cause this, so it is localised.
If the network is auto banding that will be most of the issue.
At 40% signal there will always be connectivity issues. Especially if another device close by is also connecting to said network it sort of pulls it down for lack of a simple way of explaining
I’ve also been seeing Wi-Fi connectivity issues with GX devices, particularly on Mesh networks, starting with firmware versions 3.72–3.73 onwards. This happens even on SMB-class Cisco and Linksys equipment, which is generally considered the industry standard for networking and fully compliant with the relevant RFCs. That’s why I always try to connect GX devices via Ethernet wherever possible. Of course, there are situations where a wired connection simply isn’t feasible, and that’s where the Wi-Fi connectivity issues become apparent. Why Victron equipment behaves this way is difficult for me to assess, as I don’t have full visibility of the changes introduced in the firmware releases, the underlying OS kernel, or the specifications of the Wi-Fi module itself.
That is debatable, long since not market leaders in the segment but certainly big names.
The fundamental issue is that relying on a mesh, ie wireless inter-AP comms, to build out a network, is subject to everything from interference to signal issues to software flaws. The average Joe does not necessarily have access to the tools or know-how to check if any of these factors are in play. These mass consumer plug and pray devices can be problematic to troubleshoot.
I have run venus’s, and Cerbo on the very edge of signal without any issues as the connection is stable and consistent and channels have been mapped to avoid the most congested ones.
Another fault is poor config and configuring unneccesarily wide bands. I prefer creating a dedicated network, tuned down to the specific band and basics that suit a device like a cerbo. Band-steering is then completely unnecessary.
For an IOT device you do not need speed, you need good signal and reliability. Tuning an AP’s radios (if it permits) can go a long way to helping.
As for Cisco’s supposedly questionable position in the networking industry, that’s a debatable claim in itself. They’re the ones sitting around the small RFC table, effectively deciding what’s considered good practice and what isn’t, as well as what technologies will live on and evolve, and which ones won’t.
As for the network configuration, believe me, both my home network and the networks I deploy at client sites are set up properly. At this point I can confidently confirm this issue based even on my own home installation. It runs flawlessly - I simply rolled back to version 3.55, and everything has been stable and working perfectly ever since. Every gadget I own is connected to my mesh network, from the water heater, fridge and oven to the washing machine and dishwasher, and not a single one has any connectivity issues apart from the Victron equipment. On top of that, the entire network has excellent Wi-Fi coverage, with signal strength no worse than -41 dBm anywhere in my flat. So I’m not making baseless claims, but the evidence doesn’t reflect well on Victron.
Never said questionable. There are many sitting around that table now. Newer kids on the block, and when it comes to pure wifi, cisco has not been the defacto go-to for some time. Lots of nippers eating their lunch.
Unfortunately wifi experience can vary. Too many factors. We have seen far fewer complaints recently than before; and its not an issue for most I talk to. Doesn’t mean it doesn’t exist but also why the official line is to use wired.
Yes, exactly. That is why I always try to connect all installations via a direct wired connection, as I consider the power system a critically important node, the heart of the whole setup, so to speak.
Pity wifi “sniffers” are so expensive, would be an interesting exercise to map the area around a troublesome gx connection. It just so difficult to conclusively point a finger at either side.
I have an enterprise grade system covering my property and my monitoring catches my isp’s issues but they refuse to log a ticket without a photo of a wired device, which is exciting on devices that no longer have one
I should have been more accurate - it’s not connected to an 802.11 repeater (aka extender) it’s connected to a mesh AP that’s using a wireless backhaul (how Eero works…). Similar to @Diessel I have over 100 devices on this L2 network (segmented at L3) and this is the only device that is excepting any issues add to that that it was working flawlessly until somewhat recently.
I can’t rule out that some other update is at fault, but I’ve worked in OS development for a long time, and this certainty feels like an OS / driver bug. Before I did more poking around, I at least wanted to see if this was a known issue or something other folks had seen.
Stock… and not a lot going on. MPPT, Lynx, Orion, Multi-Plus II (which is typically off). I haven’t even moved to the large firmware yet, the device already feels so slow that I’m reluctant to add more complexity to it.
@Diessel - are you using the stock WiFi adapter or a USB one? I had a theory that maybe there was some race condition or the like in the connection/reconnection logic that I was stressing at the lower range of signal strength. But Diessel’s seeing a similar issue at an excellent signal strength so that seems less likely now.
It doesn’t seem like this is an overly common issue or the forums would be full of complaints so there has to be some combination of hardware/configuration/luck.
I don’t use a USB adapter, only the onboard built-in GX Wi-Fi module.
@nickdb At home, I also have a business-grade Mesh system, with each access point connected to the main router via a network cable, which coordinates the operation of the entire network. The migration between them is seamless, with a single SSID and key for all networks, using fixed channels for the three bands: 2.4 GHz, 5 GHz and 6 GHz. The devices choose what to connect to themselves based on signal strength, and while moving around they smoothly migrate between access points without any interruptions. At the same time, the main node can also manage the connections depending on the load on each segment. However, I don’t have any overload on any of the access points.
I’ll dare to make a bold assumption - this is only a guess - but the issue is probably related to the drivers of the built-in Wi-Fi module used by the newer Venus OS firmware, unlike the previous version 3.55.
I created separate networks for 2.4ghz (pretty much only IOT on this band nowadays) and another for 5/6ghz.
Some networks and devices just seemed to have an issue with band-steering, which the separation managed to address.
For edge cases I have also restricted a network to a specific radio on an AP, I found there were times the device could roam to an AP that was further away which created issues.
There was a a change to the network manager on the GX but quite a way back now. We used to see a fair number of complaints, broadly, about wifi and those, from a community perspective anyway, are now few and far between. It tends to be more connection orientated now, such as having issues with Starlink.
From our side there is little we can do to escalate as there isn’t anything concrete to pass on.
Honestly, I’ve got absolutely no desire to start experimenting with my rock-solid home network, which works flawlessly in every respect. It’s so stable that it can run for years without a reboot. I simply adapted and rolled the GX firmware back. A network topology diagram is attached.
UPD: If you take a look at the channel allocation across the entire coverage area and the channel widths, you’ll notice they don’t even overlap anywhere. That creates a stable coverage area with different operating frequencies assigned to each node in the network.
I also follow the Venus beta testing channel closely and reading through all the change logs, so that’s why I took the liberty of suggesting that the issue might be related to the kernel and module driver combination.
We’ll see how things develop. So far I’m perfectly happy with how things are on 3.55, and even on 3.73 everything’s been stable.
with my rock-solid home network, which works flawlessly in every respect. It’s so stable that it can run for years without a reboot. I simply adapted and rolled the GX firmware back. A network topology diagram is attached.