ClearOS Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006681ClearOSapp-registration - System Registrationpublic2015-12-07 16:192016-02-17 10:18
Assigned Tobchambers 
PrioritynormalSeverityminorReproducibilityhave not tried
PlatformOSOS Version
Product Version7.1.0 
Target Version7.2.0Fixed in Version7.2.0 
Summary0006681: Registration can indicate no Internet conection
DescriptionAfter configuring network, it can take less than a minute for a user to get to the registration page. In this time, syswatch may not have populated the /var/lib/syswatch/state settings, which gives users a false 'not connected to the Internet' message.

Leave error messages up to the native calls and don't implement checks based on "Network_Status" library.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
2015-12-07 17:52

I see the issue. The Ajax call is using the Network_Status->get_connection_status() method, but then comparing against return codes from the Network_Status->get_live_connection_status() method. In controllers/ajax.php, it looks like the get_live_connection_status() method was the intended method call (and there's no syswatch involved on that one).

BTW, syswatch only sets the status to "down" when consecutive failures to multiple IPs occur. During startup, the status is immediately set to "up" until ping failures re-occur. In other words, when you start syswatch (or make a network configuration change), you will see the state file populated right away. There's no 1-minute delay to show an "up" status, but there can be a 1-minute delay to show a "down" status.
bchambers (administrator)
2015-12-07 18:08

My testing showed that when someone changes the network role from LAN to External (or vice versa), /var/lib/syswatch/state resets the two WAN parameters to empty can definitely take up to 60 seconds to see the actual network device to show up.

Do you really think we need this check in the registration app? Software updates will fail before the user hits this, and an informative error message should be displayed via CURL (perhaps a bit cryptic).

- Issue History
Date Modified Username Field Change
2015-12-07 16:19 bchambers New Issue
2015-12-07 16:19 bchambers Status new => assigned
2015-12-07 16:19 bchambers Assigned To => bchambers
2015-12-07 17:15 bchambers Status assigned => acknowledged
2015-12-07 17:15 bchambers Status acknowledged => confirmed
2015-12-07 17:52 user2 Note Added: 0002371
2015-12-07 18:08 bchambers Note Added: 0002381
2015-12-07 18:57 bchambers Status confirmed => acknowledged
2015-12-07 18:57 bchambers Status acknowledged => confirmed
2015-12-07 18:57 bchambers Status confirmed => resolved
2015-12-07 18:57 bchambers Fixed in Version => 7.2.0
2015-12-07 18:57 bchambers Resolution open => fixed
2016-02-17 10:18 user2 Status resolved => closed