Version: M-55/ 8800.0.0 


System logs and screenshots are uploaded at : https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cr/647370/

No issue with wifi network. Its reprod only with Ethernet. 

Is this true for all devices? I'm curious if this is an OOBE issue or a particular WiFi module.

I checked the device on Shravan's desk. Network is working fine. It has default route and can ping web address, looks like a OOBE UI issue to me. Will check, if this is reproducible on other platforms, while testing R55. 

M-55 OOBE initial screens are different than in M-54 and olders. This issue seems to be on across the boards (tested on samus,chell, parrot-IVB) 

+stevenjb@ could this be an issue with the new network selector?

I saw this recently with the old UI so I think it is unrelated but I'm not certain of that. However we shouldn't be relying on the new network select menu for the "internet is connected" state.

To add more info for comment # 0:

==========================================
Please use labels and text to provide additional information.
a) User can go to VT2.
b) DUT has ip address and ping is working successfully on all tested DUT (samus, chell, parot-IVB). Tested in VT2 mode.

 Issue 648694  has been merged into this issue.

Do we know if this was also happening in the existing 8798 build live on dev channel?

Given this only happens on Ethernet (not common in most of the fleet, outside boxes) and only on recovery I am tempted to push this to release block beta, thoughts?

This does not appear to happen on 8798 (on minnie at least), so we have a bisection range.

This appears to be the root cause preventing real-gaia Autotests to log in.  login_GaiaLogin (and other tests like it) hasn't been running due to lab errors, but it fails at my desk, starting in build 8810.0.0.

 issue 649477 

 Issue 649477  has been merged into this issue.

That's all very strange.
I was testing new OOBE with Ethernet connection, and everything was working fine.
Is it specific to some device? What is the device you're using?

Could someone attach login_GaiaLogin error log?

see the merged bug ( issue 649477 ) - there are logs there

Sorry, I missed the key point about recovery.

How can I reproduce this on a dev device without exiting dev mode?

recovery and dev mode are orthogonal - you can recover a device from a recovery USB stick (press ctrl+u at boot).  If you're still having trouble, swing by 40 and borrow a device from the Test Team

Transition to( or between Normal and) Dev mode. This will destroy stateful partition, and DUT will boot to Welcome screen. After Welcome widget, you'll land on the Connect to Network screen. Then just connect to Eth cable.(Do not connect to WiFi)

OK, I'l look at it on Monday. I am OOO and I don't have device to test right now.

I downloaded ChromeOS-recovery-R55-8838.0.0-lumpy and checked that I my first click on "Ethernet" network leads to EULA screen.

But login_GaiaLogin goes into endless loop. I'm looking into it.

I think the main issue here is, when connected to Ethernet/WiFi on the OOBE screen, it should not show "connect to network" page. It should automatically move "Terms page" without the click. 
Note: I also see this when connected to Wireless network. I think more appropriate title would be  
"OOBE  no longer proceeds automatically when Network (Ethernet/Wifi) is connected."

Re #29:

What if this is not the network user was about to use during initial setup?

Also, this doesn't seem to explain the problem with telemetry. There is likely a race somewhere.

This is something strange. During login_GaiaLogin test WebKit aborts page load with "connection aborted" before even sending initial packet. I.e. tcpdump doesn't report any packets. But I didn't find any obvious reason for that.

Yup, we're in a loop where these messages are printed:
[15044:15044:0928/170132:VERBOSE1:gaia_screen_handler.cc(536)] Gaia is loaded
[15044:15044:0928/170132:WARNING:error_screen.cc(104)] Network error screen message is hidden
[15044:15044:0928/170132:VERBOSE1:gaia_screen_handler.cc(306)] Reloading Gaia.
[15044:15044:0928/170132:VERBOSE1:gaia_screen_handler.cc(799)] LoadAuthExtension, force: 0, offline: 0
[15044:15044:0928/170132:VERBOSE1:signin_screen_handler.cc(1248)] Login WebUI >> loginVisible, src: gaia-signin, webui_visible_: 1
[15044:15044:0928/170132:INFO:signin_screen_handler.cc(1293)] Login WebUI >> active: 1, source: gaia-signin
[15044:15044:0928/170132:VERBOSE1:gaia_screen_handler.cc(414)] Auth extension finished loading
[15044:15044:0928/170132:VERBOSE1:signin_screen_handler.cc(1248)] Login WebUI >> loginVisible, src: gaia-loading, webui_visible_: 1
[15044:15066:0928/170132:ERROR:ssl_client_socket_impl.cc(1149)] handshake failed; returned -1, SSL error code 1, net_error -100
[15044:15066:0928/170132:ERROR:ssl_client_socket_impl.cc(1149)] handshake failed; returned -1, SSL error code 1, net_error -100
[15044:15044:0928/170132:ERROR:gaia_screen_handler.cc(445)] Gaia webview error: ERR_CONNECTION_CLOSED
[15044:15044:0928/170132:WARNING:signin_screen_handler.cc(771)] Retry frame load due to reason: frame error
[15044:15044:0928/170132:WARNING:error_screen.cc(94)] Network error screen message is shown
[15044:15044:0928/170132:VERBOSE1:gaia_screen_handler.cc(306)] Reloading Gaia.
[15044:15044:0928/170132:VERBOSE1:gaia_screen_handler.cc(799)] LoadAuthExtension, force: 1, offline: 0
[15044:15044:0928/170132:WARNING:CONSOLE(237)] "<webview>: The load has aborted with error -100: ERR_CONNECTION_CLOSED.", source: extensions::webViewEvents (237)
[15044:15044:0928/170132:INFO:signin_screen_handler.cc(1293)] Login WebUI >> active: 0, source: gaia-signin
[15044:15044:0928/170132:VERBOSE1:gaia_screen_handler.cc(414)] Auth extension finished loading
[15044:15066:0928/170132:ERROR:ssl_client_socket_impl.cc(1149)] handshake failed; returned -1, SSL error code 1, net_error -100
[15044:15066:0928/170132:ERROR:ssl_client_socket_impl.cc(1149)] handshake failed; returned -1, SSL error code 1, net_error -100
[15044:15044:0928/170132:ERROR:gaia_screen_handler.cc(445)] Gaia webview error: ERR_CONNECTION_CLOSED
[15044:15044:0928/170132:WARNING:CONSOLE(237)] "<webview>: The load has aborted with error -100: ERR_CONNECTION_CLOSED.", source: extensions::webViewEvents (237)

Issue 650936 has been merged into this issue.

Even if I disable the network error screen, I'm seeing frame errors in the gaia frame. It's possible that this is due to a low level SSL change. Certainly a lot of CLs have landed in ssl_client_socket_impl.cc:
https://chromium.googlesource.com/chromium/src/+log/master/net/socket/ssl_client_socket_impl.cc

Ryan, what are these errors:
[15044:15066:0928/170132:ERROR:ssl_client_socket_impl.cc(1149)] handshake failed; returned -1, SSL error code 1, net_error -100

Tagging Internals>Network>SSL for triage, as I'm not available for that. It's unlikely to be caused by a low-level SSL change, however.

-100 is https://cs.chromium.org/chromium/src/net/base/net_error_list.h?rcl=0&l=115 aka ERR_CONNECTION_CLOSED. Unless you have a middlebox, that's likely indicative of a low-level network error causing the connection to be closed (after the TCP connect has been reported as successful, the moment we try to write data to it). This seems highly suggestive of driver, hardware, switch, or other fundamental aspect of networking failing unreliably, and it's just manifest as an "SSL" error because the requests are/should be SSL.

Another episode that seems similar. This one suggests that disabling QUIC solves the problem:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/vdaat8Em8P0

achuith: An ERR_CONNECTION_CLOSED on SSL would not be fixed by disabling QUIC. Those are very unlikely to be related.

8798 and 8800.0.0 do not look like Chromium version numbers. What are the corresponding Chromium revisions?

ARC++ enterprise end to end tests is red for 2 weeks now (started Sep 20):https://wmatrix.googleplex.com/unfiltered?hide_missing=True&tests=cheets_EnterpriseLogin&days_back=14

Nikita, I think the problem you're looking for is actually http://crbug.com/650936. There's a fix that should land today: https://chromium-review.googlesource.com/#/c/391123/

Is this issue still open? The Cl in comment 42 landed before the 55 branch so we should have this in R55 already.

We are looking to promote R55 to beta with the build on Monday evening, so if we need anything else we need it soon.

Removing release block, since it appears the CL is in.

Merging into 650936 as it seems to be fixed.