New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 334620 link

Starred by 8 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Mar 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Verify XAUTH authentication to a SonicWall

Project Member Reported by pstew@chromium.org, Jan 15 2014

Issue description

Over the last iteration, code was added to shill / vpn-manager to perform XAUTH authentication.  Verify this works with a SonicWall VPN.
 

Comment 1 Deleted

What version of chrome does one need to test this out on a SonicWall VPN

thanks

Comment 3 by chron@chromium.org, Feb 18 2014

Please try the latest dev channel.
Here is the first update

Model:	NSA 240

Product Code:	6931

Serial Number:	0017C565FF4A

Authentication Code:	94H9-RFQC

Firmware Version:	SonicOS Enhanced 5.9.0.3-117o

Safemode Version:	SafeMode 5.0.1.13

ROM Version:	SonicROM 5.0.2.12


Chrome version 33.0.1750.152
Platform 5116.115.5.
Frimware google snow.2695.1167.0


Here is the Sonicwall log
Time	Group	Event	Src. IP	Src. Port	Dst. IP	Dst. Port	IP Protocol	FW Action	Notes	Message
3/17/2014 12:31	General	Clear Log								Log Cleared
3/17/2014 12:31	VPN IKE	IPsec Dead Peer Detection	66.60.153.130	500	76.126.64.71	500				RECEIVED<<< ISAKMP OAK MM (InitCookie:0x0bfc50d0030146d5 RespCookie:0x0000000000000000, MsgID: 0x0)  (SA, VID, VID, VID, VID)
3/17/2014 12:31	VPN IKE	Responder Main Mode Request Received	66.60.153.130	500	76.126.64.71	500	udp			IKE Responder: Received Main Mode Request (Phase 1)
3/17/2014 12:31	VPN IKE	VPN Peer Behind NAT Device								NAT Discovery : Peer IPsec Security Gateway behind a NAT/NAPT Device
3/17/2014 12:31	VPN IKE	Responder Main Mode Completed	66.60.153.130	28182	76.126.64.71	4500			VPN Policy: WAN GroupVPN;3DES; SHA1; DH Group 2; lifetime=10800 secs	IKE Responder: Main Mode complete (Phase 1)
3/17/2014 12:31	VPN IKE	Duplicate Packet Dropped	66.60.153.130	28182	76.126.64.71	4500	udp	Drop	VPN Policy: WAN GroupVPN	Received packet retransmission. Drop duplicate packet


L2pt wan side of the sonicwall I think see a packet more then 2 times, then drops it

I read this has been a issue with other OS type.

What is the MTU setting on a chromebook,  it may be set to high

josh




Update Two

Model:	NSA 240

Product Code:	6931

Serial Number:	0017C565FF4A

Authentication Code:	94H9-RFQC

Firmware Version:	SonicOS Enhanced 5.9.0.3-117o

Safemode Version:	SafeMode 5.0.1.13

ROM Version:	SonicROM 5.0.2.12

Chrome version 35.0.1883.2 dev
Platform 5619.0.0 dev-channel daisy
Frimware google snow.2695.1167.0

I have added three files

One is the log file from a succesfull lpt2 to my sonicwall from the sonicwall client
One is the log file from a the sonicwall about the succesfull sonicwall client connecting

The last one is the failure log report from the sonicwall device, using the dev channel

I sent this pass on that the sonicwall will take a lpt2 connection.  I did export the setup file from the soniswall 240 and then imported into the sonicwall client software


josh






Logsonicwallchromebook.txt
5.4 KB View Download
Sonicwallvpnreports.txt
14.9 KB View Download
log_65FF4A_3-18.wri
29.7 KB Download

Comment 6 by pstew@chromium.org, Mar 23 2014

When I attempted to connect to a SonicWall endpoint with XAUTH credentials I ended up with the following error:

2014-03-22T21:22:20.217366-07:00 localhost charon: 13[ENC] payload type ID_V1 was not encrypted
2014-03-22T21:22:20.217457-07:00 localhost charon: 13[ENC] could not decrypt payloads
2014-03-22T21:22:20.217496-07:00 localhost charon: 13[IKE] integrity check failed
2014-03-22T21:22:20.217529-07:00 localhost charon: 13[ENC] generating INFORMATIONAL_V1 request 1104961070 [ HASH N(INVAL_HASH) ]

This stalled the communication and the connection failed.  Here's what the incoming packet in question looked like from the standpoint of the client:

Frame 10: 106 bytes on wire (848 bits), 106 bytes captured (848 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Mar 22, 2014 21:22:20.215818000 PDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1395548540.215818000 seconds
    [Time delta from previous captured frame: 0.000617000 seconds]
    [Time delta from previous displayed frame: 0.000617000 seconds]
    [Time since reference or first frame: 4.048395000 seconds]
    Frame Number: 10
    Frame Length: 106 bytes (848 bits)
    Capture Length: 106 bytes (848 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:isakmp]
Ethernet II, Src: xxx, Dst: yyy
    Destination: yyy
        Address: yyy
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: xxx
        Address: xxx
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.1.202 (192.168.1.202), Dst: 192.168.1.2 (192.168.1.2)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 92
    Identification: 0x0233 (563)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 255
    Protocol: UDP (17)
    Header checksum: 0x3541 [correct]
        [Good: True]
        [Bad: False]
    Source: 192.168.1.202 (192.168.1.202)
    Destination: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: isakmp (500), Dst Port: isakmp (500)
    Source port: isakmp (500)
    Destination port: isakmp (500)
    Length: 72
    Checksum: 0x73cc [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Internet Security Association and Key Management Protocol
    Initiator cookie: f40cb6a7d782baa6
    Responder cookie: c3abb61d0aafcf8f
    Next payload: Identification (5)
    Version: 1.0
    Exchange type: Identity Protection (Main Mode) (2)
    Flags: 0x00
        .... ...0 = Encryption: Not encrypted
        .... ..0. = Commit: No commit
        .... .0.. = Authentication: No authentication
    Message ID: 0x00000000
    Length: 28

Although the Encryption flag isn't set, the information involved isn't of particularly high value.  Furthermore by rejecting the connection there's little to gain (the un-encrypted packet has already sent, so a potential snooper has already seen it) and a lot to lose (the user doesn't get their connection).  I have a CL:

  https://chromium-review.googlesource.com/#/c/191108/

which when used allows successful XAUTH authentication to such endpoints.  The XAUTH credentials need to be supplied, however there's no UI for that currently, although it's possible to configure those parameters using ONC.
I read over the 191108 issue  

Is there a new version release with the code change to test?


Comment 8 by pstew@chromium.org, Mar 26 2014

Not yet.  The code change is still in review as you should be able tell from 191108.
Project Member

Comment 9 by bugdroid1@chromium.org, Mar 27 2014

Project: chromiumos/overlays/chromiumos-overlay
Branch : master
Author : Paul Stewart <pstew@chromium.org>
Commit : 5b37629b21c342b3f6d79927d6876ff8249047c4

Code-Review  0 : Paul Stewart, chrome-internal-fetch
Code-Review  +2: Mike Frysinger
Commit-Queue 0 : Mike Frysinger, chrome-internal-fetch
Commit-Queue +1: Paul Stewart
Verified     0 : Mike Frysinger, chrome-internal-fetch
Verified     +1: Paul Stewart
Change-Id      : I80c755fd5c9adb156ae09838ef816bc1b2f37daf
Reviewed-at    : https://chromium-review.googlesource.com/191096

Change strongswan-5.0.2-r7.ebuild to a symlink

Follow the pattern used by other ebuilds of this type, where
the non "-r*" ebuild tracks the changes to the ebuild and the
"-r*" file is a symlink.  There is no functional change in
what is actually built, but there is a switch to EAPI=4 to
satisfy pre-submit tests.  Therefore, revbump to -r8.

BUG= chromium:334620 
TEST=emerge strongswan, ensure strongswan-5.0.2-r8 is built.

net-misc/strongswan/strongswan-5.0.2-r7.ebuild
net-misc/strongswan/strongswan-5.0.2-r8.ebuild
net-misc/strongswan/strongswan-5.0.2.ebuild

Comment 10 by pstew@chromium.org, Mar 28 2014

Cc: keescook@chromium.org
Status: Started
I've sent a change to the CQ that works around some behavior on the SonicWall that previously aborted the authentication.  I'll leave this issue open until this change is also accepted upstream.  When the change lands, I'll move this from Started -> ExternalDependency.
Project Member

Comment 11 by bugdroid1@chromium.org, Mar 31 2014

Project: chromiumos/overlays/chromiumos-overlay
Branch : master
Author : Paul Stewart <pstew@chromium.org>
Commit : 1606e9472300eb429f63fe17af377c61636042f3

Code-Review  0 : Ben Chan, Paul Stewart, Will Drewry, chrome-internal-fetch
Code-Review  +2: Kees Cook
Commit-Queue 0 : Ben Chan, Kees Cook, Will Drewry, chrome-internal-fetch
Commit-Queue +1: Paul Stewart
Verified     0 : Ben Chan, Kees Cook, Will Drewry, chrome-internal-fetch
Verified     +1: Paul Stewart
Change-Id      : Ie06ea3ca90dca96abf8451160c08736af17f0c41
Reviewed-at    : https://chromium-review.googlesource.com/191108

strongSwan: Be lenient about downstream encryption

strongSwan has an "encryption" flag for each payload type.
It uses this flag both to signal whether it should encrypt
these payloads and whether to accept such payloads in an
unencrypted form.  Some VPN endpoints do not encrypt their
ID_V1 and HASH_V1 during ID_PROT during an XAUTH
authentication flow.  This doesn't expose a lot of
information and does not induce the client to expose
anything either.  This CL whitelists these specific payloads
from being rejected if they are not encrypted, but preserves
the client behavior of encrypting these payloads when they
are sent.

BUG= chromium:334620 , chromium:267647 
TEST=Perform XAUTH based L2TP/IPSec with a SonicWall
network_VPNConnect.l2tpipsec_cert
network_VPNConnect.l2tpipsec_psk
network_VPNConnect.l2tpipsec_xauth

net-misc/strongswan/files/strongswan-5.0.2-lenient-encryption.patch
net-misc/strongswan/strongswan-5.0.2-r10.ebuild
net-misc/strongswan/strongswan-5.0.2.ebuild

Comment 12 by pstew@chromium.org, Mar 31 2014

Status: Fixed
I've verified this works with a SonicWall if XAUTH credentials are specified.  To verify:

  - Acquire and configure a SonicWall with L2TP/IPSec VPN (I have one extra)
  - Make sure to enable XAUTH credentials.
  - Create a VPN configuration.  You can do so using one of two methods:
    + Create it using ONC, providing the Xauth username and password tehre
    + Create it using the UI, which will fail, but you can later use "set-service-property" from the command-line to set L2TPIPsec.XauthPassword and L2TPIPsec.XauthUser on the created service.
  - Connect
Would you detail more the code needed to use the set-service-property

assume user name surfer
assume password  surfer1000
Try to connect (and fail since the XAUTH properties aren't set)

From a shell prompt (running the "shell" command at a crosh prompt)

/usr/local/lib/flimflam/test/list-services

(Find the VPN service in the list.  Let's assume the service is "/service/123")

/usr/local/lib/flimflam/test/set-service-property /service/123 L2TPIPsec.XauthUser surfer 
/usr/local/lib/flimflam/test/set-service-property /service/123 L2TPIPsec.XauthPassword surfer1000



I have a Samsung

got into crosh

then I type shell
I get.  unknow command:   'shell'

I am in developer mode.

running

35.0.1.1905.3 dev
If you get that, then you're not in developer mode, and you won't be able to use the "set-service-property" command.  It's likely you do not want to go into developer mode just for this.  If you're keen on trying this right now before there's any UI, might I suggest you try importing an ONC file instead?  A reasonable template of what this file should look like is in:

https://chromium.googlesource.com/experimental/chromium/src/+/refs/heads/master/chromeos/test/data/network/valid_l2tpipsec.onc
I can confirm this is working against a Sonicwall NSA 240 using CrOS dev channel, not in developer mode. I used the ONC import method described by pstew

Being uninitiated, the example ONC file posted tripped me up. It apparently needs to be wrapped in an outer layer and is not valid standalone; attempts to import it without the wrapper result in a parsing error. A template of the ONC file which worked for me is attached (be sure to replace the property values in brackets).

Also note that if your VPN uses groups you'll need to exactly match this value in your ONC file.

Thank you Chromium devs for all your work on this, it's much appreciated!


onc
654 bytes View Download
From, here what is the normal time frame for the UI to be update?

Thank for the all great work.

Thanks for the ONC file

josh
Cc: krisr@chromium.org
Labels: Merge-Requested
Status: Verified
Used the ONC with XAuth credentials to connect to a local SonicWall setup and verified that it is able to connect on ToT. 5725.0.0, R36. Requesting merge to R35.
How can we tell when it will be Merged?
What version of Chrome were you running.  Have not been able to make it
work yet

Thanks for the help on "wrapped in an order" issue

josh
I was able to connect, then I am getting dropped on Phase two

Called Sonicwall

See notes
Created By: Tathagata Roy (4/8/2014 2:34 PM)
Inbound Call 
- Custome not able to connect through L2TP from chrome book 
- Tested. from windows its working fine 
- Asked customer to check security parameters for phase 2 as in phase 2 its not negotiating & remote end sending delete SA request 
- Customer will check. Xauth authentication passing through 

I am on Dev Channel 35.0.1916.17 DEV
Although you're on dev-channel, your dev-channel is too old to have this change.  If you note comment #19, you'll see that there was a _request_ to have this change merged to R35 (35.x.xxxx.xx) like you're on, but that hasn't been approved yet.  So this change is on R36 only so far.  Dev channel is currently still on R35, but should cut over to R36 before too long, hopefully.
I'm not sure why, but this is definitely working for me on the Stable channel (34.0.1847.118) using the ONC method described above and the ONC template file I posted on 4/2/2014.

I also tried connecting using ONC files with the XAUTH section removed and with an invalid XAUTH password, both of which failed. This seems to suggest that XAUTH is in fact being used.

It's definitely possible that I don't know what I'm talking about or am somehow not using XAUTH, but the SonicWall VPN is configured to require it and VPN connections from the Chromebook fail without a proper XAUTH section in the ONC.

Re: Comment #24: Lucky you. :-)  It's quite possible there are SonicWall firmwares around that don't have that issue.  In fact, if you could report your model and firmware version, that'd be interesting.  I know that with both the units I had available to me, the authentication failed without the fix in comment #11.
Also, what are setting for phase one and phase two of the VPN setup
 des3,,,,, and so on
Here is copy of log from Sonicwall..   I will slow down tell R36  thanks
  I am using IKEVersion": 2 at this time in the onc
 13:19:10 Apr 09 263 Users User logged out - jtyler 66.60.153.130
69.62.216.133 0 tcp jtyler  13:18:55 Apr 09 413 VPN Received IKE SA delete
request 66.60.153.130 500 69.62.216.133 500  VPN Policy: W-
AN GroupVPN  13:18:55 Apr 09 412 VPN Received IPsec SA delete
request66.60.153.13050069.62.216.133500  VPN
Policy: W-
AN GroupVPN...  13:18:44 Apr 09 89 VPN IKE negotiation complete. Adding
IPsec SA. (Phase 2) 66.60.153.130 500 69.62.216.133 500 udp VPN Policy: W-
AN GroupVPN...  13:18:44 Apr 09 87 VPN IKE Responder: Accepting IPsec
proposal (Phase 2) 66.60.153.130 500 69.62.216.133 500 udp VPN Policy: W-
AN GroupVPN...  13:18:44 Apr 09 352 VPN IKE Responder: Received Quick Mode
Request (Phase 2) 66.60.153.130 500 69.62.216.133 500 udp VPN Policy: W-
AN GroupVPN  13:18:44 Apr 09 139 VPN XAUTH Succeeded with VPN
client66.60.153.13050069.62.216.133500
jtyler  13:18:44 Apr 09 237 Users VPN zone remote user login
allowed66.60.153.130
69.62.216.133 0 tcp jtyler jtyler  13:18:44 Apr 09 373 VPN IKE Responder:
Aggressive Mode complete (Phase 1) 66.60.153.130 500 69.62.216.133 500  VPN
Policy: W-
AN GroupVPN...  13:18:44 Apr 09 356 VPN IKE Responder: Received Aggressive
Mode Request (Phase 1) 66.60.153.130 500 69.62.216.133 500 udp   13:18:44
Apr 09 171 VPN RECEIVED<<< ISAKMP OAK AG (InitCookie:0xdf34dbeb3036d646
RespCookie:0x0000000000000000, MsgID: 0x0) (SA, KE, NON, ID, VID, V-
ID, VID, VID) 66.60.153.130 500 69.62.216.133 500   13:18:38 Apr 09
998UsersGUI administration session ended66.60.153.130
69.62.216.133 443 tcp admin admin  13:18:38 Apr 09 995 Users Configuration
mode administration session ended 66.60.153.130 69.62.216.133 443 tcp admin
at GUI
from 66.60....  13:18:38 Apr 09 261 Users Administrator logged out66.60.153.130
69.62.216.133 443 tcp admin User logged o-
ut  13:18:34 Apr 09 5 Log Log Cleared

is part of the sonicwall log
Hah, yes, I'm not complaining! Here's my specs:

SonicWall Model: NSA 240
Firmware: SonicOS Enhanced 5.8.1.9-58o

VPN Authentication Method: IKE using Preshared Secret
IKE Phase 1 Proposal:
  - DH Group: Group 2
  - Encryption: 3DES
  - Authentication: SHA1
  - Life Time (seconds): 28800

Ipsec (Phase 2) Proposal:
  - Protocol: ESP
  - Encryption: 3DES
  - Authentication: SHA1
  - Enable Perfect Forward Secrecy: false
  - Life Time (seconds): 28800

Require authentication of VPN clients by XAUTH: true
Client Connections - Allow Connections to: Split Tunnels

SonicWall L2TP server is also configured and enabled.
Updated to

Version 36.0.1941.2 dev
Platform 5764.0.0 (Official Build) dev-channel daisy
Firmware Google_Snow.2695.117.0


I am now able to connect to sonicwall and get IP address

thanks for the all the help and work.

Used the ONC file provided

Same Sonicwall setting from the above email

Comment 30 by kareng@google.com, Apr 21 2014

Labels: M-35
you need a mstone on this bug.
pstew: Is this needed for M35?

Comment 32 by pstew@chromium.org, Apr 22 2014

I don't think a merge is strictly required for this one.  This does fix a regression WRT M33, though.
Labels: -Merge-Requested -M-35 Merge-Rejected M-36
OK. let's not merge it. thanks!
Project Member

Comment 34 by bugdroid1@chromium.org, Apr 24 2014

Project: chromiumos/platform/vpn-manager
Branch : master
Author : Paul Stewart <pstew@chromium.org>
Commit : a190ef1968f6069f0b4fab97c289ddd6817bb78f

Code-Review  0 : Paul Stewart, chrome-internal-fetch
Code-Review  +2: Ben Chan
Commit-Queue 0 : Ben Chan, chrome-internal-fetch
Commit-Queue +1: Paul Stewart
Verified     0 : Ben Chan, chrome-internal-fetch
Verified     +1: Paul Stewart
Change-Id      : I19d277f66cd105e1e5aaaaaef35db24aabfaa6a5
Reviewed-at    : https://chromium-review.googlesource.com/195408

ipsec_manager: Enable SonicWall compatibility

Use the new upstream flag to accept frames from SonicWall.

BUG= chromium:334620 
TEST=Authenticate to SonicWall

ipsec_manager.cc
ipsec_manager_test.cc
Project Member

Comment 35 by bugdroid1@chromium.org, Apr 25 2014

Project: chromiumos/overlays/chromiumos-overlay
Branch : master
Author : Paul Stewart <pstew@chromium.org>
Commit : 90e387b5fbf98ee94ee6a331e7a0f3c075142c95

Code-Review  0 : Ben Chan, chrome-internal-fetch
Code-Review  +2: Paul Stewart
Commit-Queue 0 : Ben Chan, chrome-internal-fetch
Commit-Queue +1: Paul Stewart
Verified     0 : Ben Chan, chrome-internal-fetch
Verified     +1: Paul Stewart
Change-Id      : I28e18ddfa1e8e932f4dc459b0df895dd306af5f9
Reviewed-at    : https://chromium-review.googlesource.com/196731

Update strongSwan lenient encryption to upstream

Use the upstream version of the lenient-encryption patch, which
puts this functionality behind a flag.

CQ-DEPEND=CL:195408
BUG= chromium:334620 
TEST=authenticate to SonicWall VPN with XAUTH.

net-misc/strongswan/files/strongswan-5.0.2-lenient-encryption.patch
net-misc/strongswan/strongswan-5.0.2-r12.ebuild

Comment 36 by pstew@chromium.org, Apr 25 2014

Status: Fixed
Bindu, would it be possible for you to re-verify with the next R36 build?   I've changed this fix slightly.
We still have the SonicWall setup, i can test it.
Status: Verified
Successfully authenticated to a SonicWall running l2tp/ipsec with XAuth using onc.

Verified with 5795.0.0, R36 dev channel leon-test.

Comment 39 by Deleted ...@, Apr 28 2014

When do I expect the bug will be fixed for Settings->Internet connection->Add connection->Add private network... for normal ChromeOS release? I prefer to connect through SonicWALL VPN in this way instead of using ONC.
I am using the following:

Updated to

Version 36.0.1941.2 dev
Platform 5764.0.0 (Official Build) dev-channel daisy
Firmware Google_Snow.2695.117.0


I am now able to connect to sonicwall and get IP address

thanks for the all the help and work.

Used the ONC file provided

All work great

VPN is dropped each time at 5 mins....

Has any one else had this issue?  Please along a work around if you have one

Comment 41 by pstew@chromium.org, Apr 28 2014

Comment #39: Please track  issue 267647  for resolution to the UI portion you requested

Comment #40: Please create a feedback log (Alt-Shift-i) so I can see what happened in your logs when the connection exits.  This particular issue (establishing the connection) is closed, so I'll create a new issue for your problem once you have logs for it.

Comment 42 by Deleted ...@, Apr 29 2014

Thanks for providing a link to  issue 267647 . The linked page doesn't provide a place to post a comment so that I have to ask the same question again: since I can't tell if the bug on GUI has been fixed, I would like to know when do we expect the bug to be fixed. Also if we don't know it, is the ONC method available for normal ChromeOS? 

Comment 43 by pstew@chromium.org, Apr 29 2014

I don't maintain the schedule for UI fixes.  The bug will be updated with a release number and iteration when someone from that team picks up the issue.  It depends on what you mean by "normal ChromeOS".  The ONC method is available on dev-channel, which will become beta, and later stable, at which point it will be on all current versions of ChromeOS.  http://www.chromium.org/developers/calendar shows the approximate branch points for each release from dev -> beta.  This would mean from my reading that some time around late June when this change (and M-36 in general) will reach stable.
Peter, I have up loaded the sonicwall logs per your request  Showing chromebook and iphone 5S session details  Chromebook stop at about 5 mins,  Iphone i went for about 15 mins, then gave up  josh  How due I find when/if you open a new issue up? thanks    
Labels: Restrict-AddIssueComment-EditIssue
I've created  issue 371563 .  Could you create another feedback log?  It appears that the network logs were not uploaded with your last one.  Please comment on  issue 371563  when you have done so.

Sign in to add a comment