Desperately Requesting Assistance: Honeywell Redlink Internet Gateway [Happening Again]

[agilis]

Absolutely, no issues the entire day. I am not sure what was the fix but I believe it is fixed. I really hope this time it works out and stays working for the foreseeable future.

Thank you very much @ColinTaylor and everyone else that was taking the time to read through this lengthy ordeal. This is such a terrific community and I hope to help one of you in the near future.

Cheers!

 

[mfish]

@ColinTaylor @agilis

I literally have the exact same setup and the exact same problem. I also have an Asus AC-86U router and the a Honeywell Redlink Gateway that is exhitbing the same behavior. I went through this whole thread to do my best to re-create the same router settings and even downgraded my Merlin firmware from the most recent to the one the op was using during his ordeal. I also brough my RIG to my brother in laws house and plugged it into his router. It connected fine just like it does here. I didn't have enough time there to see if it would "hold" the connection which is the issue.

I issued all the same SSH commands. When I do I only have the 2 expected running dnsmasq whereas before, like the op, I had 4 running before issuing the SSH commands. Unfortunately even with just the 2 running - see code below, I still have the same issue where the RIG drops the connection within usually 15 minutes or less and the internet light turns amber

CODE:

27119 nobody 5040 S dnsmasq --log-async --dhcp-broadcast
27120 mfish 4908 S dnsmasq --log-async --dhcp-broadcast

If I power cycle the RIG it will re-establish a connection but doesn't hold it. Also, I've found that if I issue this SSH command: killall dnsmasq that does kill all the dnsmasq and that will cause the router to generate new PID's and that makes the RIG re-establish the connection (just like if I power cycle it) But unfortunatley it doesn't hold the connection.

My RIG is successful registered on Honeywell's portal

I haven't done a factory data reset on the router and would really prefer not to if I can avoid it but I will if all else fails. Does anyone have any other ideas of things I can try? Thanks!

Here is a server log right after power cycling the RIG through when it drops the connection

Mar 28 11:14:42 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Mar 28 11:14:42 kernel: br0: port 3(eth3) entered disabled state
Mar 28 11:14:57 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps full duplex
Mar 28 11:14:57 kernel: br0: port 3(eth3) entered listening state
Mar 28 11:14:57 kernel: br0: port 3(eth3) entered listening state
Mar 28 11:14:59 kernel: br0: port 3(eth3) entered learning state
Mar 28 11:15:01 kernel: br0: topology change detected, propagating
Mar 28 11:15:01 kernel: br0: port 3(eth3) entered forwarding state
Mar 28 11:15:04 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:15:04 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:15:04 dnsmasq-dhcp[27119]: DHCPREQUEST(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:15:04 dnsmasq-dhcp[27119]: DHCPACK(br0) 192.168.50.211 48:a2:e6:1b:9f:c6 Gateway1B9FC6
Mar 28 11:25:17 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth6: Auth 02:0F:B5:54:8A:9E, status: Successful (0)
Mar 28 11:25:17 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth6: Assoc 02:0F:B5:54:8A:9E, status: Successful (0)
Mar 28 11:26:49 dnsmasq-dhcp[27119]: DHCPRELEASE(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:26:53 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:26:53 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:26:53 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:26:53 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:26:56 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:26:56 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:01 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:01 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:10 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:10 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:24 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:24 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:32 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:32 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:47 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:47 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:50 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:50 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:55 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:55 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:27:56 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:27:56 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:28:02 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:28:02 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:28:11 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:28:11 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 28 11:28:22 dnsmasq-dhcp[27119]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 28 11:28:22 dnsmasq-dhcp[27119]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6


Server log from when I issued the SSH commands in the attached picture:

EDIT - Maybe there is a character limit on posts? I can't post this log in this post

 

[ColinTaylor]

Yes there is a character limit on posts.

The --dhcp-broadcast experiment didn't seem to make a difference so I don't know what solved the OP's issue.

 

[mfish]

Yes there is a character limit on posts.

The --dhcp-broadcast experiment didn't seem to make a difference so I don't know what solved the OP's issue

@ ColinTaylor Thanks for chiming. Hopefully the op @agilis see's this and can offer some insight. I'll try to update this thread. Next step is to take the RIG back to my brother in laws and let it sit connected to his router for a longer stretch of time to see if it disconnects. If it does i'm suspecting a bad RIG and I'll get a replacement. If it holds the connection then I'll likely bite the bullet and do a factory reset of my router. And ultimately if no amount of troubleshooting helps then I'll probably just suck it up and buy a different router. Already have sunk costs into thermostats, outdoor sensor and wireless adapter for zone module. I'm pretty deep into Honeywell's eco system. Figured since my zone module is already Honeywell this would be the logical route.

For whatever its worth, here is the unhelpful email Honeywell tech support sent me. I followed their directions. Not sure how wifi authentication has anything to do with a hard wired LAN device but I did implement their recommendations and they didn't help:

Here are the instructions to go over with your Internet Service Provider or router manufacturer:

• Make sure the network is using one of the following security protocols: OPEN, WEP_PSK, WPA_TKIP_PSK, WPA2_AES_PSK, or WPA2_MIXED_PSK.
• WPA2_AES_PSK or WPA2_MIXED_PSK are the recommended security types.
• On Netgear Geni routers constantly receiving a 169.254.x.x IP address ensure WPA2 both AES and TKIP is selected.
• While connection has been possible in some cases, WPA_AES, and WPA2_TKIP have a high failure rate, and are not recommended
• Make sure the network is a standard home network and does not require logging in from a webpage, like a guest or enterprise network might.

Check the device for an IP Address if possible

• Valid: 192.168.x.x OR 172.16.x.x to 172.31.x.x OR 10.x.x.x
  • The issue is NOT with the connection to the Wi-Fi
  • This indicates it is properly connected to the Wi-Fi.
  • Checks on the Device Cloud telemetry service (Greyhound, TCC Admin) should be made from here.
• Invalid: 169.254.x.x (DHCP connection error)
  • This error does indicate the device did connect to the Wi-Fi radio.
  • A router reset, followed by a power-cycle may resolve the problem.
  • Some ISPs do limit the number of active IP connections. Check if there are any connection limits with the ISP service.
• NO IP address:
  • Check to ensure Wi-Fi is enabled on the device.

Also, please ask the router manufacturer or Internet Service Provider to PIN the MAC ID of the gateway to the router to prevent any future disconnections.

Thank you,

Resideo Customer Care

 

[ColinTaylor]

Also, I've found that if I issue this SSH command: killall dnsmasq that does kill all the dnsmasq and that will cause the router to generate new PID's and that makes the RIG re-establish the connection (just like if I power cycle it) But unfortunatley it doesn't hold the connection.

This is an interesting observation and one I don't think has been mentioned before.

So when you have the DHCPDISCOVER/DHCPOFFER messages repeating in the log can you SSH into the router and issue a service restart_dnsmasq command. Then wait until the RIG connects. Can you post the complete log from the beginning to the end of this process.

 

[mfish]

Thanks! @ColinTaylor

Mar 30 17:06:37 dnsmasq-dhcp[1268]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Mar 30 17:06:37 dnsmasq-dhcp[1268]: DHCPOFFER(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 30 17:06:39 dnsmasq-dhcp[1268]: DHCPREQUEST(br0) 192.168.50.211 48:a2:e6:1b:9f:c6
Mar 30 17:06:39 dnsmasq-dhcp[1268]: DHCPACK(br0) 192.168.50.211 48:a2:e6:1b:9f:c6 Gateway1B9FC6
Mar 30 17:07:46 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth6: Auth 02:0F:B5:54:8A:9E, status: Successful (0)
Mar 30 17:07:46 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth6: Assoc 02:0F:B5:54:8A:9E, status: Successful (0)
Mar 30 17:07:46 rc_service: service 7756:notify_rc restart_dnsmasq
Mar 30 17:07:46 dnsmasq[1268]: exiting on receipt of SIGTERM
Mar 30 17:07:46 dnsmasq[7759]: started, version 2.82-34-gb309cca cachesize 1500
Mar 30 17:07:46 dnsmasq[7759]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset no-auth DNSSEC no-ID loop-detect no-

 

[ColinTaylor]

Thanks @mfish but it looks like the RIG was already successfully connected when you restarted dnsmasq. I'm interested in the log file from when the problem is occurring until after you resolve it.

 

[mfish]

Thanks @mfish but it looks like the RIG was already successfully connected when you restarted dnsmasq. I'm interested in the log file from when the problem is occurring until after you resolve it.

@ColinTaylor got it - sorry having some forum issues where it wouldn't let me post. Not sure if it was the character limit or not.

Here is a screenshot. it let me post this way.

 

[ColinTaylor]

Yes the forum won't allow you to post any text that contains "/etc" followed by "/hosts" (without the space). It's a malware filter.

I'm still not seeing the log file behaviour you described before. The RIG releases its lease at 17:22:14. From 17:22:19 onward it's in the DISCOVER/OFFER loop. It's now that I want you to restart dnsmasq to make the RIG reconnect, and show me the log file from 17:22:45 up until you see the DHCPACK for Gateway1B9FC6.

 

[mfish]

Yes the forum won't allow you to post any text that contains "/etc" followed by "/hosts" (without the space). It's a malware filter.

I'm still not seeing the log file behaviour you described before. The RIG releases its lease at 17:22:14. From 17:22:19 onward it's in the DISCOVER/OFFER loop. It's now that I want you to restart dnsmasq to make the RIG reconnect, and show me the log file from 17:22:45 up until you see the DHCPACK for Gateway1B9FC6.

@ColinTaylor I actually had to step away earlier Here are fresh logs starting from the pre-existing discover/offer loop, logging in SSH, issuing the SSH command, getting dhcpack and then it re-entering the discover/offer loop. I hope this is what you're looking for. It started the loop almost immediately after dhcpack if I'm understanding these logs correctly

 

[ColinTaylor]

I don't see anything in the log that shows the RIG reconnecting. The only device that connects after you restart dnsmasq is your laptop. The RIG is unaffected and just carries on with the DISCOVER/OFFER messages.

 

[mfish]

I don't see anything in the log that shows the RIG reconnecting. The only device that connects after you restart dnsmasq is your laptop. The RIG is unaffected and just carries on with the DISCOVER/OFFER messages.

@ColinTaylor Does the fact that this command doesn't cause the RIG to re-connect tell us anything? If I pull the power cable and then plug it back in that does cause it to reconnect with a DHCPACK.

Does it matter if I manually assign an ip or let DHCP auto assign one? Earlier I had DHCP auto assigning and I had the RIG plugged into my TP Link switch which is connected to the Router.

I just switched to manual assign and plugged it directly into the router. Previously I had it plugged directly into the router and was still getting this same behavior.

I just tried issuing the command again with the RIG connected directly to the router and the behavior is still the same

Also, please see these screen shots? Any smoking guns here? It says 2 devices are connecting to the RIG. And it identifies it as a Canon Photo Printer.

 

[ColinTaylor]

Unless you can create a scenario where the RIG reconnects without having to power cycle it I don't think this tells us anything new.

The "2 devices" are because the RIG's MAC address has been given two different IP addresses at various times. Initially it was given 192.168.50.211 and after the restart it was given 192.168.50.214. I don't know why it thinks it's a Canon printer.

 

[mfish]

@ColinTaylor Thanks again.

I issued all the various SSH commands you suggested in this thread and unfortunately none of them get the RIG to connect. Please see attached - not sure if this tells you anything.

The reason for the different ip addresses yesterday is due to me installing some smart switches in the house and there now being more devices. the router no longer shows there being 2 devices connected through the rig

 

[ColinTaylor]

As I said before the --dhcp-broadcast option doesn't seem to change anything. The only thing different in the logs are the errors created from your router running out of space in /var. I don't know what you were doing that caused that but it doesn't seem to be related to the RIG issue.

All the experimentation seems to reinforce the suspicion that the problem lies with the RIG not accepting the lease that the router is giving it. Quite why that is is still a mystery. You have the problem even when the RIG is plugged directly into the router so that eliminates issues with WiFi or intermediate switches.

Without getting some sort of visibility of what is happening on the RIG we're just left guessing and trying random things. Do you have a smart switch with port mirroring capability? If so you could try capturing the packets being received by the RIG and looking at them in Wireshark. But it depends on how far down that rabbit hole you're prepared to go. Or you could setup another DHCP server on the network and disable the one on the router, then see if that exhibits the same behaviour.

 

[mfish]

As I said before the --dhcp-broadcast option doesn't seem to change anything. The only thing different in the logs are the errors created from your router running out of space in /var. I don't know what you were doing that caused that but it doesn't seem to be related to the RIG issue.

All the experimentation seems to reinforce the suspicion that the problem lies with the RIG not accepting the lease that the router is giving it. Quite why that is is still a mystery. You have the problem even when the RIG is plugged directly into the router so that eliminates issues with WiFi or intermediate switches.

Without getting some sort of visibility of what is happening on the RIG we're just left guessing and trying random things. Do you have a smart switch with port mirroring capability? If so you could try capturing the packets being received by the RIG and looking at them in Wireshark. But it depends on how far down that rabbit hole you're prepared to go. Or you could setup another DHCP server on the network and disable the one on the router, then see if that exhibits the same behaviour.

Thanks for sticking with me. I think I already took the red pill! LOL

Given enough time I can usually learn how to do these things but I'm not in the IT profession. Just somewhat tech saavy. Yes, I have TP link switch that has port mirroring. I'll look into wireshark and if I think I can get it to capture packets without taking up too much time to figure that out, I'll do that and report back here.

I'll also look into setting up a DHCP server on Windows 10 and see how involved that is. Same deal - if i do that, I'll report back here.

I may just look into getting a replacement RIG from the vendor first before going too much further down this rabbit hole.

 

[mfish]

As I said before the --dhcp-broadcast option doesn't seem to change anything. The only thing different in the logs are the errors created from your router running out of space in /var. I don't know what you were doing that caused that but it doesn't seem to be related to the RIG issue.

All the experimentation seems to reinforce the suspicion that the problem lies with the RIG not accepting the lease that the router is giving it. Quite why that is is still a mystery. You have the problem even when the RIG is plugged directly into the router so that eliminates issues with WiFi or intermediate switches.

Without getting some sort of visibility of what is happening on the RIG we're just left guessing and trying random things. Do you have a smart switch with port mirroring capability? If so you could try capturing the packets being received by the RIG and looking at them in Wireshark. But it depends on how far down that rabbit hole you're prepared to go. Or you could setup another DHCP server on the network and disable the one on the router, then see if that exhibits the same behaviour.

Hi again @ColinTaylor and below is a log.

I've just had the RIG plugged in over the last couple of days. It actually does periodically re-connect by itself.

The pattern is - it will re-connect by itself (DHCPack) when the below events happen, stay connected for approx 16 minutes, then enter the offer/release loop for about 27 minutes, re-connect, rinse, repeat.

Apr 2 04:27:02 dnsmasq-dhcp[1263]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Apr 2 04:27:02 dnsmasq-dhcp[1263]: DHCPOFFER(br0) 192.168.50.220 48:a2:e6:1b:9f:c6
Apr 2 04:27:12 dnsmasq-dhcp[1263]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Apr 2 04:27:12 dnsmasq-dhcp[1263]: DHCPOFFER(br0) 192.168.50.220 48:a2:e6:1b:9f:c6
Apr 2 04:27:31 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Apr 2 04:27:31 kernel: br0: port 3(eth3) entered disabled state
Apr 2 04:27:39 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps full duplex
Apr 2 04:27:39 kernel: br0: port 3(eth3) entered listening state
Apr 2 04:27:39 kernel: br0: port 3(eth3) entered listening state
Apr 2 04:27:41 kernel: br0: port 3(eth3) entered learning state
Apr 2 04:27:43 kernel: br0: topology change detected, propagating
Apr 2 04:27:43 kernel: br0: port 3(eth3) entered forwarding state
Apr 2 04:27:48 dnsmasq-dhcp[1263]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Apr 2 04:27:48 dnsmasq-dhcp[1263]: DHCPOFFER(br0) 192.168.50.220 48:a2:e6:1b:9f:c6
Apr 2 04:27:49 dnsmasq-dhcp[1263]: DHCPREQUEST(br0) 192.168.50.220 48:a2:e6:1b:9f:c6
Apr 2 04:27:49 dnsmasq-dhcp[1263]: DHCPACK(br0) 192.168.50.220 48:a2:e6:1b:9f:c6 Gateway1B9FC6
Apr 2 04:29:18 wlceventd: WLCEVENTD wlceventd_proc_event(500): eth6: Auth 02:0F:B5:54:8A:9E, status: Successful (0)
Apr 2 04:29:18 wlceventd: WLCEVENTD wlceventd_proc_event(529): eth6: Assoc 02:0F:B5:54:8A:9E, status: Successful (0)
Apr 2 04:34:21 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth6: Deauth_ind 02:0F:B5:54:8A:9E, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Apr 2 04:34:21 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth6: Disassoc 02:0F:B5:54:8A:9E, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Apr 2 04:43:20 dnsmasq-dhcp[1263]: DHCPRELEASE(br0) 192.168.50.220 48:a2:e6:1b:9f:c6
Apr 2 04:43:24 dnsmasq-dhcp[1263]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Apr 2 04:43:24 dnsmasq-dhcp[1263]: DHCPOFFER(br0) 192.168.50.220 48:a2:e6:1b:9f:c6

I do also see the following typically shows up at some point during the offer/release loop roughly 9 minutes before it re-connects and think it may be relevant too - its recurring

EDIT - ADD: The weird thing about the below is that i don't see any devices that have this mac id: 02:0F:B5:54:8A:9E And that is not the LAN or wireless mac id of the router either so maybe that tells us something?

pr 2 04:19:00 dnsmasq-dhcp[1263]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Apr 2 04:19:00 dnsmasq-dhcp[1263]: DHCPOFFER(br0) 192.168.50.220 48:a2:e6:1b:9f:c6
Apr 2 04:19:06 wlceventd: WLCEVENTD wlceventd_proc_event(466): eth6: Deauth_ind 02:0F:B5:54:8A:9E, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Apr 2 04:19:06 wlceventd: WLCEVENTD wlceventd_proc_event(481): eth6: Disassoc 02:0F:B5:54:8A:9E, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Apr 2 04:19:07 dnsmasq-dhcp[1263]: DHCPDISCOVER(br0) 48:a2:e6:1b:9f:c6
Apr 2 04:19:07 dnsmasq-dhcp[1263]: DHCPOFFER(br0) 192.168.50.220 48:a2:e6:1b:9f:c6

 

[ColinTaylor]

The WLCEVENTD messages are caused by a WiFi device. It looks like the typical behaviour of a mobile phone that's in standby. The MAC address is probably because phones now default to using private MAC addresses.

I don't see from your log where the RIG reconnects after 27 minutes because the log file doesn't cover enough time. The only reconnect I see is at 04:27:48 which is presumably because the RIG was disconnected/reconnected or power cycled at 04:27:31?

 

[mfish]

The WLCEVENTD messages are caused by a WiFi device. It looks like the typical behaviour of a mobile phone that's in standby. The MAC address is probably because phones now default to using private MAC addresses.

I don't see from your log where the RIG reconnects after 27 minutes because the log file doesn't cover enough time. The only reconnect I see is at 04:27:48 which is presumably because the RIG was disconnected/reconnected or power cycled at 04:27:31?

@ColinTaylor Thanks for the feedback. So here is logs from a full "cycle". I actually didn't power cycle the RIG. It just does this endless cycle on its own while its plugged in the whole time

 

[ColinTaylor]

OK, so that's sort of interesting. As you say, it looks like the RIG releases the lease after about 15 minutes 30 seconds, although it did do it after only 12 minutes one time. After the release it then goes into the loop for 30 minutes 13 seconds and then reboots itself. I can only suggest that you give this information to the manufacturer and see what they make of it.

I don't see what more you can do on your side apart from running a different DHCP server.