Disconnecting every 5 minutes
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.Disconnecting every 5 minutes
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Team,
I have a device connected to a ER7206 router. And according to the log on the controller, it is disconnecting every 5 minutes.
The device then reconnects a few minutes later.
This behavior is not shown in the OS log of that device..
Is anyone able to explain what could be happening here?
With warm regards - Will
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Hank21 wrote
Hi @ITV,
Let's clarify your issue, the frequently Disconnected-Connected logs generated only occur on the Vigilant device, right?
How did you link the JVM crash dumps in the Omada log to your Vigilant device issue?
Did this issue start to happen after a firmware upgrade or any settings change?
The JVM crash is "resolved" - it seems to be related to the auto-refresh-IP in the system settings under access config.
The auto-refresh is now disabled and the hostname in the fields controller, portal and device-management is now fixed.
Meaning it is set to the hostname as applicable for the default management vlan (i.e. vlan-1).
With auto-refresh-IP enabled it is using the hostname as defined by one of the other vlans.
The 30-minutes disconnect-connect cycle is indeed only seen on the vigilant device - not on any other device in the network.
Since the message is saying "5m connected, traffic: 0Bytes" it is probably more of a cosmetic thing.
This is because vigilant holds pihole, the Omada controller and Observium.
Observium is a device monitoring application. And has a 5 minute polling interval to all application servers in the network.
Meaning with these three applications, there is always some network traffic going in and out of the device called vigilant.
The Omada controller runs in a Docker container against the host network.
Here the word host means a LXC container called morpheus.
And this LXC container is running on the Proxmox server called vigilant.
I'm not aware of a config change or firmware update that triggered this.
Simply because I didn't notice this "cyle" until 2 days ago.
- Copy Link
- Report Inappropriate Content
Hi @ITV
Thanks for posting in our business forum.
Do you have time to shoot a short video when you are idle? Like a 15-minute video with time stamps?
Quite strange when I read your description. Device status switched from Connected > Disconnected > Connected? Be specific.
- Copy Link
- Report Inappropriate Content
See attached messages: this is from the Omada log viewer.
Vigilant is a Proxmox server running PVE 8.1.3.
The controller is running as a Docker container within a LXC container.
Cheers - Will
=====
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:5m connected, traffic: 0Bytes).
|
Jan 03, 2024 09:07:24
|
|
|
|
vigilant is connected to dozer on Tech (factory default) network.
|
Jan 03, 2024 08:53:37
|
|
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:4m connected, traffic: 0Bytes).
|
Jan 03, 2024 08:32:54
|
|
|
|
vigilant is connected to dozer on Tech (factory default) network.
|
Jan 03, 2024 08:18:28
|
|
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:5m connected, traffic: 0Bytes).
|
Jan 03, 2024 07:59:24
|
|
|
|
vigilant is connected to dozer on Tech (factory default) network.
|
Jan 03, 2024 07:45:40
|
|
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:5m connected, traffic: 0Bytes).
|
Jan 03, 2024 07:24:54
|
|
|
|
vigilant is connected to dozer on Tech (factory default) network.
|
Jan 03, 2024 07:10:21
|
|
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:5m connected, traffic: 0Bytes).
|
Jan 03, 2024 06:50:54
|
|
|
|
vigilant is connected to dozer on Tech (factory default) network.
|
Jan 03, 2024 06:37:14
|
|
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:5m connected, traffic: 180Bytes).
|
Jan 03, 2024 06:16:54
|
|
|
|
vigilant is connected to dozer on Tech (factory default) network.
|
Jan 03, 2024 06:01:35
|
|
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:5m connected, traffic: 180Bytes).
|
Jan 03, 2024 05:42:24
|
|
|
|
vigilant is connected to dozer on Tech (factory default) network.
|
Jan 03, 2024 05:27:28
|
|
|
|
vigilant was disconnected from network "Tech (factory default)" on dozer(connected time:5m connected, traffic: 0Bytes).
|
Jan 03, 2024 05:07:54
|
|
|
|
- Copy Link
- Report Inappropriate Content
Hi @ITV
Thanks for posting in our business forum.
ITV wrote
See attached messages: this is from the Omada log viewer.
Vigilant is a Proxmox server running PVE 8.1.3.
The controller is running as a Docker container within a LXC container.
Cheers - Will
=====
This happens to all wired/wireless devices. And it is not a problem with the router.
This is the log on the controller to detect/monitor the connection(session) time between every device.
Your device sleeps or green energy mode can also cause this log. Looks like your device keeps connect for 5 minutes and disconnects (enter sleep or low consumption mode).
- Copy Link
- Report Inappropriate Content
Thank you for the update.
But I also found (literally!) hundreds of JVM crash dumps in the Omada log (see below).
Not sure if this has anything to do with it?
Cheers - Will
=====
01-03-2024 09:46:38.725 ERROR [https-jsse-nio-8043-exec-4] [] c.t.s.o.c.u.b.b(): Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
- Copy Link
- Report Inappropriate Content
Hi @ITV
Thanks for posting in our business forum.
ITV wrote
Thank you for the update.
But I also found (literally!) hundreds of JVM crash dumps in the Omada log (see below).
Not sure if this has anything to do with it?
Cheers - Will
=====
01-03-2024 09:46:38.725 ERROR [https-jsse-nio-8043-exec-4] [] c.t.s.o.c.u.b.b(): Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
This might be a controller issue. @Hank21 Can you take a look at this?
- Copy Link
- Report Inappropriate Content
Please note that:
(1) - the crash dump happens a few dozen times per second!
Meaning about every 30-45 minutes a new server.log is created because the previous one was filled with these crash dumps.
(2) - the controller picks up the IP address from a different vlan when using auto update.
Cheers - Will
- Copy Link
- Report Inappropriate Content
Hi @ITV,
Let's clarify your issue, the frequently Disconnected-Connected logs generated only occur on the Vigilant device, right?
How did you link the JVM crash dumps in the Omada log to your Vigilant device issue?
Did this issue start to happen after a firmware upgrade or any settings change?
- Copy Link
- Report Inappropriate Content
Hank21 wrote
Hi @ITV,
Let's clarify your issue, the frequently Disconnected-Connected logs generated only occur on the Vigilant device, right?
How did you link the JVM crash dumps in the Omada log to your Vigilant device issue?
Did this issue start to happen after a firmware upgrade or any settings change?
The JVM crash is "resolved" - it seems to be related to the auto-refresh-IP in the system settings under access config.
The auto-refresh is now disabled and the hostname in the fields controller, portal and device-management is now fixed.
Meaning it is set to the hostname as applicable for the default management vlan (i.e. vlan-1).
With auto-refresh-IP enabled it is using the hostname as defined by one of the other vlans.
The 30-minutes disconnect-connect cycle is indeed only seen on the vigilant device - not on any other device in the network.
Since the message is saying "5m connected, traffic: 0Bytes" it is probably more of a cosmetic thing.
This is because vigilant holds pihole, the Omada controller and Observium.
Observium is a device monitoring application. And has a 5 minute polling interval to all application servers in the network.
Meaning with these three applications, there is always some network traffic going in and out of the device called vigilant.
The Omada controller runs in a Docker container against the host network.
Here the word host means a LXC container called morpheus.
And this LXC container is running on the Proxmox server called vigilant.
I'm not aware of a config change or firmware update that triggered this.
Simply because I didn't notice this "cyle" until 2 days ago.
- Copy Link
- Report Inappropriate Content
Hi @ITV,
Thanks so much for your sharing, you may keep monitoring and if you have any questions or concerns, we are always here to help.
- Copy Link
- Report Inappropriate Content
Hank21 wrote
Hi @ITV,
Thanks so much for your sharing, you may keep monitoring and if you have any questions or concerns, we are always here to help.
These events seem to be related to the client idle time.
Which part of the remote logging option.
If I lower this value to 5 or 3 minutes, more devices are showing the same behavior.
And the vigilante-device pops up more often
Is there a way to disable this idle time detection feature?
Without turning off remote logging?
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 1318
Replies: 13
Voters 0
No one has voted for it yet.