It should be possible to use nmcli to edit these settings from a ssh connection. The following command:
DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket nmcli connection edit <connectionName> would allow one to edit the connection properties.
nmcli needs to be installed inside the container as well.
Please test this beforehand on a non production device.
Hi @Michael,
the latest production release for the raspberry pi3 should fix this,
@imrehg would you mind pointing Michael to remotely updating his host OS in order to address this issue?
We are experiencing the same issue, dropping WiFi connections and no retries are executed. After hard-rebooting the device it searches for WiFi again. Running 2.7.5+rev1
Is this fixed in v2.7.8+rev1? If not, any tips how to debug this issue?
Hi, 2.7.5+rev1 should have this fixed.
Can you provision a .dev 2.7.5 OS and then when this happens try to login using the serial debug connection and get back to us then to try and see what is it about?
Are you using resin.io or the unmanaged OS from resinos.io ?
Also, how often does this happen on that particular machine? It may be worth to try “iw dev wlan0 set power_save off”
Thank you for your reply 
The PI is running on the resinio platform. As this unit is running on a external location for a client, we are unable to run the .dev setup. We were unable to replicate the same scenario internally.
We were having the same issue without resinio before, where the ‘power_save’ option was off. Was the reason we moved (and fleet management) to resinio.
Think the WiFi connection drops on that location sometimes, but the PI won’t reconnect.
Ran fine for about 10 days, but dropped out every few days now.
I’m pretty sure we’ve got some work on the way to release that will mean devices don’t ever stop trying to reconnect. I think there’s an upper limit on their reconnection attempts at the moment. Will confirm with the wider team on Monday.
Cool, thanks. Did you got a update yesterday from the team? Our client still has issues unfortunately.
Perhaps it’s possible due to a DHCP lease that expired? Just throwing ideas here
Hi,
are you able to have an eth cable plugged in at the customer site?
Ideally, we would want to get the board in a state with wifi running again and as soon as wifi drops out have eth connected and then ping us again and direct us to the device in question so we can take a look at what exactly is failing.
Hi,
We are facing the same issue with one of our client too. (version Resin OS 2.7.5+rev1) …
The Device goes offline and never come online after that.
I assume it’s the same case as above, a flaky connection? (weak signal I mean)
Also, this is a fresh install of resinOS?
Will look into the eth cable. Just plugging the the network cable and settings WiFi up as normal would be enough to replicate this? WiFi and cable can both be connected? Any tips on how to monitor the WiFi drop-out?
Thanks so far
Yes it’s due to a weak signal. It’s an update from an older version.
Update from our side: the client had about 8 access points from which one had an incorrect DHCP configuration. That is fixed now and testing if the signal keeps stable. Just FYI
Okay, keep us posted.
About your previous question, yes, just plugging an eth cable when the pi3 is not connected to the resin.io dashboard when using wifi would be enough. Nothing else needed
Anyone have a method for reading / logging wifi signal strength?