[BUG] Session with disabled pause on centralized PostgreSQL Server.

[kcaBmask]

This occurs during power interruptions when all servers shut down. Once the power is restored, some users sessions with disabled pause cannot connect to the internet, even though their sessions are still running. I have to manually pause and resume their sessions on the admin panel before they can regain internet connection.

NOTE:

All session settings in Online Status Checking are all enabled All with the same centralized server token.

If you removed the centralized server token, it works without having to manually pause and resume devices with disabled paused option. This doesn't affect all users. Some are affected, some are not.

Setup: 3 Servers running on proxmox 1 Server orange pi one. Cloud hosted database postgreSQL 12 server hosted in the Philippines Latency from AdoPIsoft servers to database server average 5 ms.

[xynapxone]

experienced this issue as well. and my only fix is to manually pause their time. or allow them to have infinite pause.

[kcaBmask]

experienced this issue as well. and my only fix is to manually pause their time. or allow them to have infinite pause.

are you using centralized database server as well?

I offer special rate plans that include 1-day and 3-day unlimited access with no pause time, as well as various Internet of Things (IoT) devices like CCTV cameras, smart bulbs, and plugs, all of which have auto-pause disabled when inactive or offline. I believe the session settings, particularly the online status checking options, should be enhanced on the centralized database server.

I managed to take a look inside the database to have an idea on what is happening, i might be wrong but I think there is a problem with the value of true or false in one of the table of mobile_devices inactive_auto_paused disable_autopause.

[kcaBmask]

I notice I don't have a problem on a server who boot up first.

Servers settings

Allow session to be pause? = TRUE, Disable Auto-pause on Inactive/Offline = TRUE

[xynapxone]

I assume what triggers the issue is when the 1st machine to boot activates the session of other machines when the option "Automatically continue sessions after reboot?" Option is enabled. The users of other machines cannot enable their sessions on their respective machine since it is already activated on the 1st machine to boot up.

enabling pause time fixes their issue if you wish to enable auto continue sessions after reboot. I had mine configured with unlimited pause and disabled auto continue sessions after reboot. It is a good workaround but not a fix.

i still have problems with centralized database like time doesn't reflect in realtime after inserting coins. even thiugh the latency of the database server is at <1ms.

I am hoping that these centralized bugs will be fixed in their new system and i am willing to do live beta testing in a live environment.

[xynapxone]

Also, when having centralized machines, always use different ip pools as i have observed overlapping ip pools with other centralized machines results in session activation errors.

[kcaBmask]

Downgrading from Ubuntu Server 22.04 to 18.04 didn’t resolve my issues, but it seems to have reduced the RTNETLINK problems during power interruptions.

I've also tried using different IP pools on each machine, thinking this might be the cause of the issue. I'm hopeful that this bug will be fixed in the next release.

The centralized server option has been available since version 4.0.10. Have there been no reports of bugs? Or perhaps it's just that only a few users are utilizing this option.

[xynapxone]

Theres only a few utilizing centralized option due to the fact that there are only few who had public ip and/or only few who had low latency pg database on the cloud.

I am not having RTNETLINK Issues. I am using ubuntu 22.04 on proxmox.

[kcaBmask]

Perhaps the hardware behaves differently. On my main server, where I host my web server, Nextcloud, and other services, the bonus plugin works fine even during power interruptions. However, on another server (a Dell mini PC), whenever it shuts down improperly, the bonus plugin gets disabled, and I can't re-enable it from the panel. Restarting the server resolves the issue.

I don't have a public IP; I use ZeroTier instead. But due to these power interruption problems, I had to move my database server to the cloud.

[kcaBmask]

I assume what triggers the issue is when the 1st machine to boot activates the session of other machines when the option "Automatically continue sessions after reboot?" Option is enabled. The users of other machines cannot enable their sessions on their respective machine since it is already activated on the 1st machine to boot up.

enabling pause time fixes their issue if you wish to enable auto continue sessions after reboot. I had mine configured with unlimited pause and disabled auto continue sessions after reboot. It is a good workaround but not a fix.

Thank you for this! It seems to resolve my issue. I'll need to disable the "Automatically continue sessions after reboot" option on each server. But, for the IOT devices this is an issues. I have to resume all of them one by one.

[xynapxone]

SLR, It's good that the workaround is feasible for your case also.

The reason it's a workaround and not a fix is because of that thing also. IOT devices cannot be automatically resumed. in the device information page of each user, you can see disable auto pause no automatically resume option (where u can set this up on each machine where the IOT is connected, nice additional to features if they can see this).

I had resolved mine by using another VLAN and not use captive portal in it. then have my APs multicast SSIDs of different VLAN (in my case 2 SSID with 2 different VLAN, 1 with captive portal, 1 without captive portal) and have those IOTs to connect to the SSID-VLAN with captive portal off. just make sure that there would be no Leakage of wifi keys. the only down side is, multiple VLANs is a pain in the ass when it comes to boot time.

Things are just complicated for the lazy ones like me. HAHAHA.

Additional info share: I had 1 machine set up with 28 VLANs each with captive portal (/23 subnet). That is the maximum limit for me since the machine cannot boot if i had more VLANs. wish the new version is out for testing. It would be lovely to see having a limit of 200 or so.