Argon intermittently failing to bind DHCP offer?

HI all, I’m seeing some intermittent issues with an Argon that seems to sometimes fails to accept the DHCP settings (can see it pop up on the router, be offered an address, but times out ) over Ethernet.

DeviceOS is 3.2.0

I don’t have a minimal code for reproducing at this time (nor can even reliably instiagate it), but have noticed that it seems to have some form of incorrect address resolution.
When it accepts the DHCP settings:

2022-03-21T13:41:47Z : 9760986 : *********** NETWORK SETTINGS ***************
2022-03-21T13:41:47Z : 9760987 : * LocalIP: 192.168.88.250 SubnetMask: 255.255.255.0 GatewayIP: 192.168.88.1 DNSServer: 0.0.0.0 DHCPServer: 0.0.0.0 *

When it fails to bind the settings:

2000-01-01T00:02:07Z : 127882 : *********** NETWORK SETTINGS ***************
2000-01-01T00:02:07Z : 127883 : * LocalIP: 0.0.0.253 SubnetMask: 255.255.255.0 GatewayIP: 0.0.0.1 DNSServer: 0.0.0.0 DHCPServer: 0.0.0.0 *

(These are results from calling Ethernet.localIP /subnetMask etc)

A soft reset (via reset button) doesn’t seem to resolve the issue, but a hard reset (pull power for a duration) does resolve it.

Has anyone else had particular issues with something similar?

Also, is there any particular way to force clearing the existing network settings and re-requesting new ones?

Have you tried setting a slower keepalive for the Argon? The default is 30/25 seconds.

For Ethernet, you will probably want to set a keepAlive of 2 to 5 minutes.For the Argon, the keep-alive is not generally needed. However, in unusual networking situations if the network router/firewall removes the port forwarded back-channels unusually aggressively, you may need to use a keep-alive.

1 Like

Not as of yet: I’ve not changed the keepalive from the default. So far as of yet, I’ve (anecdotally) only observed it occuring after flashing via USB - that being said, I haven’t observed it frequently enough for me to dive into it much further as of yet, and wanted to see if anyone else had similar observations.

I wouldn’t expect the keepalive to be an issue with recognizing/binding the DHCP message, however?

I don’t either, but that’s all that I can think of - the device ignoring the DHCP messages and sending it’s keepalive.

The best tool to debug this would be the cloud debug firmware: Cloud Debug | Tools | Particle (You can run it directly from Chrome)