ClearFoundation Tracker - ClearOS
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0006681ClearOSapp-registration - System Registrationpublic2015-12-07 16:192016-02-17 10:18
Reporterbchambers 
Assigned Tobchambers 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
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.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-12-07 16:19bchambersNew Issue
2015-12-07 16:19bchambersStatusnew => assigned
2015-12-07 16:19bchambersAssigned To => bchambers
2015-12-07 17:15bchambersStatusassigned => acknowledged
2015-12-07 17:15bchambersStatusacknowledged => confirmed
2015-12-07 17:52user2Note Added: 0002371
2015-12-07 18:08bchambersNote Added: 0002381
2015-12-07 18:57bchambersStatusconfirmed => acknowledged
2015-12-07 18:57bchambersStatusacknowledged => confirmed
2015-12-07 18:57bchambersStatusconfirmed => resolved
2015-12-07 18:57bchambersFixed in Version => 7.2.0
2015-12-07 18:57bchambersResolutionopen => fixed
2016-02-17 10:18user2Statusresolved => closed

Notes
(0002371)
user2   
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.
(0002381)
bchambers   
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 strings...it 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).