Related
I changed my VPN provider(UnblockUS) because it wasnt working on some sections of GooglePlay (cant buy and watch movies(region lock)) but everything other was okay.
Now im using TunnelBear everything is fine but,when i set VPN On it connects to TunnelBear servers. Then my Chromecast dissapears from list of devices(in Chrome browser PC only). When i turn off VPN Chromecast device is back in list.
On other devices like my Find 5 or iPad 3 while connected to Tunnelbear VPN shows my Chromecast device fine.
I tryed to bridge soft adapter(TBear thing) to my LAN adapter but i lose VPN and cant use GooglePlay.
Any help to resolve this issue?
i'm having the exact same issue. moved from unblock.us to a different vpn this week and now i can't see my chromecast
Karlo666 said:
I changed my VPN provider(UnblockUS) because it wasnt working on some sections of GooglePlay (cant buy and watch movies(region lock)) but everything other was okay.
Now im using TunnelBear everything is fine but,when i set VPN On it connects to TunnelBear servers. Then my Chromecast dissapears from list of devices(in Chrome browser PC only). When i turn off VPN Chromecast device is back in list.
On other devices like my Find 5 or iPad 3 while connected to Tunnelbear VPN shows my Chromecast device fine.
I tryed to bridge soft adapter(TBear thing) to my LAN adapter but i lose VPN and cant use GooglePlay.
Any help to resolve this issue?
Click to expand...
Click to collapse
I am outside US. For me, I enable VPN (not using tunnelbear though), buy a movie, then disable the VPN, then cast. Does that work for you?
ykphuah said:
I am outside US. For me, I enable VPN (not using tunnelbear though), buy a movie, then disable the VPN, then cast. Does that work for you?
Click to expand...
Click to collapse
I did tryed that and it doesnt work.
If i buy a movie and turn off VPN i cant cast it because it cant retrieve licence for playing.
Tryed that on phone/tablet and PC
Karlo666 said:
I did tryed that and it doesnt work.
If i buy a movie and turn off VPN i cant cast it because it cant retrieve licence for playing.
Tryed that on phone/tablet and PC
Click to expand...
Click to collapse
Did you change your credit card to US?
Just remove your current credit card, then add it back again, with a real zip code and phone number. Then wait 1-2 hours (at this time mine always show payment denied).
Now I am able to buy music without VPN even. For Movies I still need VPN though. But once its bought, I don't need VPN anymore for either.
Ninjas edited this.. Misinformation
ykphuah said:
Did you change your credit card to US?
Just remove your current credit card, then add it back again, with a real zip code and phone number. Then wait 1-2 hours (at this time mine always show payment denied).
Now I am able to buy music without VPN even. For Movies I still need VPN though. But once its bought, I don't need VPN anymore for either.
Click to expand...
Click to collapse
I can do all of that stuff whitout VPN but i cant Cast Movies/TV to my Chromecast device whitout VPN active.
Well...
Grammar...
yeah i kinda have the same problem, if i turn off tunnelbear, my chromecast can be detected from my phone, but once i turn on tunnelbear to access netflix, chromecast stops working..... =/
any workaround for this? its kinda the only reason i got a chromecast in the first place.....
Technically you shouldn't expect this to work because the Chromecast has to be on the same LAN as the casting device, and when you use a VPN on the casting device you are putting it on a different LAN.
Not to mention that if you are using the VPN on the casting device to bypass geoblocking, then it probably wouldn't work even if you could see the Chromecast because the Chromecast also has to use the VPN to bypass geoblocking. You would have to set up the VPN in your router so that it affects both the casting device and the Chromecast. You can do that with advanced router firmware like DD-WRT, but not with most consumer routers using stock firmware.
Suggestion
I have read through your issue of concern and I guess you should go for CyberGhost. It was established in Romania in the year 2011, by uniting a strong belief in confidentiality with German engineering to make a VPN that gives an anonymous, sage, and dependable service. It’s really simple to utilize, rapid connections, and variety of servers are just some of the numerous perks underlined in hundreds of positive user reviews. Go for https://vpn.review/set-up-chromecast-vpn/ today to learn a lot more. CyberGhost provides a 7-day free trial on Android and iOS, a Windows free trial, and a 45-day money-back assurance on all platforms. Just go for it as I don’t think so you will find anything else better than this one.
I was playing with it only for one few hours...
and I am concerned with current level of security of rooted Chromecast.
If you
reboot wireless router(wireless access point)
OR
wireless router is down/malfunction
OR
communication between Chromecast and wireless router is jammed
OR
someone used Aircrack-ng suite to disconnect Chromecast from wireless router
your Chromecast just created open wireless network for configuration purposes...
and Team-Eureka http panel is accessible at most likely default IP address 192.168.255.253,
also provides you with an IP adress via internal dhcp.
look a bit at config:
http://192.168.255.249/?page=status
and than
http://192.168.255.249/?page=settings
be sure that telnet, ssh, adb are running.
Just connect with telnet or SSH, privledged user is root, there is no password
cat /data/wifi/wpa_supplicant.conf
Code:
ctrl_interface=/data/wifi
update_config=1
country=US
network={
ssid="my wifi essid"
scan_ssid=1
psk=my password on a silver plate in WPA PSK HEX(64 characters)
proto=RSN
key_mgmt=WPA-PSK
}
You just owned someone's Chromecast and can abuse his wireless network.
Still got time tinker with Chromecast? Maybe plant some android type of backdoor... NSA style...
How to fix this?
1. be sure that internal web server is not vurnelable.
2. https
3. Http panel accessible only after providing password that is by default for instance sha-1 hash of serial number.
(user may take a picture of his own chromecast and use tool/service to generate hash), it should be changed at first login
4. adb, telnet, ssh disabled by default
5. root password
Basic stuff...
First off, if you are worried about our panels security it is open source, so feel free to audit it for any vulnerabilities.
Also, we are working on a new revision of the panel which not only includes password support, but also the ability to set a SSH password. The reason none is set ATM is because by default the root acc on the chromecast has none, so we have a modified dropbear binary that will allow any password to work.
As for HTTPS over the web panel, that will be available, but it will not be "enforced". (at least that is the current plan). We may add a panel option that enforces https though, for users who are concerned about security on their local wireless network.
Now telnets another story, because its generated with busybox its hard to have a password enforced, but you can just disable it. same goes with ADB.
We know right now our services are not the most locked-down, but trust me most of it has already been fixed on our end and these changes will be out with the next OTA
ddggttff3 said:
First off, if you are worried about our panels security it is open source, so feel free to audit it for any vulnerabilities.
Also, we are working on a new revision of the panel which not only includes password support, but also the ability to set a SSH password. The reason none is set ATM is because by default the root acc on the chromecast has none, so we have a modified dropbear binary that will allow any password to work.
As for HTTPS over the web panel, that will be available, but it will not be "enforced". (at least that is the current plan). We may add a panel option that enforces https though, for users who are concerned about security on their local wireless network.
Now telnets another story, because its generated with busybox its hard to have a password enforced, but you can just disable it. same goes with ADB.
We know right now our services are not the most locked-down, but trust me most of it has already been fixed on our end and these changes will be out with the next OTA
Click to expand...
Click to collapse
Thank you for fast and exhaustive answer.
Any "ETA" of build with features you mentioned ?
Is there any roadmap for Eureka-ROM?
Any chance for something dedicated to LAN streaming?
(Chrome full screen is buggy, Plex is $ app, Fling is written in JAVA and no longer in developement.)
If there will be any beta or rc I am willing to participate.(not so many things to test there)
mathorv said:
Thank you for fast and exhaustive answer.
Any "ETA" of build with features you mentioned ?
Is there any roadmap for Eureka-ROM?
Any chance for something dedicated to LAN streaming?
(Chrome full screen is buggy, Plex is $ app, Fling is written in JAVA and no longer in developement.)
If there will be any beta or rc I am willing to participate.(not so many things to test there)
Click to expand...
Click to collapse
We don't really do ETA's but we try to have updates out right after google OTA's, or when there is a severe bug. As for a roadmap, we currently don't have one public due to it constantly changing.
LAN streaming still works with Fling (as we have fling added back to our roms through our whitelist service), but that is all I know of. If other users want to create apps that can utilize fling, that would be awesome.
And last for testing, currently I have more then enough testers for when beta updates roll out. keep your eyes open in the future as I may do open signups again at a later date.
Well the scenarios you set would apply to non rooted CCasts as well...
If they hacked your wireless with Aircrack to set a disconnect, then you were exposed long before they reconfigured the CCast and they can do a lot more damage with that access without you ever noticing than they could through the CCast.
Your would notice the CCast changing but you wouldn't notice someone hacked your Wireless without looking at the Router Logs or noticing a degraded Network performance.
If these things are a concern for you then I suggest you turn on MAC Filtering on our Router, Set Allows for the CCast and all the devices you own and deny all others.
But the concerns you have exist regardless of a rooted CCast. Leaving a CCast unconnected might expose the CCast to be taken over since it will be an open AP anyone can connect to....And they can Airtcrack you router even with a stock CCast.
But if you see that just look out the window because they would probably have to be sitting on your Porch or parked in your Driveway to do it!
I don't know many Hackers who are THAT Brazen! LOL
Asphyx said:
Well the scenarios you set would apply to non rooted CCasts as well...
If they hacked your wireless with Aircrack to set a disconnect, then you were exposed long before they reconfigured the CCast and they can do a lot more damage with that access without you ever noticing than they could through the CCast.
Your would notice the CCast changing but you wouldn't notice someone hacked your Wireless without looking at the Router Logs or noticing a degraded Network performance.
If these things are a concern for you then I suggest you turn on MAC Filtering on our Router, Set Allows for the CCast and all the devices you own and deny all others.
But the concerns you have exist regardless of a rooted CCast. Leaving a CCast unconnected might expose the CCast to be taken over since it will be an open AP anyone can connect to....And they can Airtcrack you router even with a stock CCast.
But if you see that just look out the window because they would probably have to be sitting on your Porch or parked in your Driveway to do it!
I don't know many Hackers who are THAT Brazen! LOL
Click to expand...
Click to collapse
Reconfiguring stock Chromecast is one thing and that's not so much a problem. Attacker don't get password, just info about name of connected network. In that scenario attacker gets essid and handshakes or reconfigure Chromecast wireless settings(essid/password).
Problem is that with rooted attacker has access to adb/telnet/ssh. In that scenario attacker has easy access to essid/password in plain text and may do this unnoticed.
About ranges:
What if someone lives in center of a city? Skyscrapers area?
About suburban area, I am not convinced that people in US live in houses with brick/concrete block walls, this is not EU.
Have you ever used Aircrack-ng suite and some gnu/linux wireless pentesting distro?
You can attach high gain directional antenna to 2000mW wireless card(Alfa brand for instance) and use software tweaks.
Ranges are much higher than you would anticipate.
About Chromecast setting security - yes it is ridiculous.
It asks if you see XYZ9 on a screen. (always click yes - right?)
It should at least ask for some automatically generated password that is visible on the screen...
So for now we may create additional wireless network/VLAN with max one client and connection restrictions...
mathorv said:
Have you ever used Aircrack-ng suite and some gnu/linux wireless pentesting distro?
You can attach high gain directional antenna to 2000mW wireless card(Alfa brand for instance) and use software tweaks.
Click to expand...
Click to collapse
Yes many times and the loopholes you suggest in your scenario are not limited to the Rooted version at all...
Sure there are extra tools in the rooted version that do not exist in the non-rooted....
But the scenario suggested gives you about 30 seconds to get what you want before the router is back up, CCast re-connects and shuts down your session!
And they still have the problem of how to shut down your router or know when it will happen to start working the hack.
Sure someone could probably get what they want in that timeframe..
But someone that good really is not going to be interested in hacking YOU!
Not Unless your some Cartel leader or Bank Executive.
People who have no business rooting anything if they want security....LOL
Asphyx said:
Yes many times and the loopholes you suggest in your scenario are not limited to the Rooted version at all...
Sure there are extra tools in the rooted version that do not exist in the non-rooted....
But the scenario suggested gives you about 30 seconds to get what you want before the router is back up, CCast re-connects and shuts down your session!
And they still have the problem of how to shut down your router or know when it will happen to start working the hack.
Sure someone could probably get what they want in that timeframe..
But someone that good really is not going to be interested in hacking YOU!
Not Unless your some Cartel leader or Bank Executive.
People who have no business rooting anything if they want security....LOL
Click to expand...
Click to collapse
@but someone that good really is not going to be interested in hacking YOU!
World is full of sick people, besides, over the years it has become easy, primary school kid can do it, every hacking soft has a GUI now
@ features - it would be nice to override wifi from panel - sometimes chromecast indicates connecting status. at the same time is connected to secure wifi and has open configuration wifi.
@ alpha builds, I would be glad to flash anything newer that does not totally brake chromecast and is safer for now
Is web panel risky?
Sorry it's even worse:
1. connect to device if its in open network AP state
2. http://192.168.255.249/?page=debug
3. cat /data/wifi/wpa_supplicant.conf
4. SEND
Gone in less than 30 seconds.
mathorv said:
Sorry it's even worse:
1. connect to device if its in open network AP state
2. http://192.168.255.249/?page=debug
3. cat /data/wifi/wpa_supplicant.conf
4. SEND
Gone in less than 30 seconds.
Click to expand...
Click to collapse
Good thing devices only are in AP mode for setup. Besides, once the new web panel is released, this will be a non issue.
"Rickroll Innocent Televisions With This Google Chromecast Hack"
http://www.wired.com/2014/07/rickroll-innocent-televisions-with-this-google-chromecast-hack/
In short the video shows:
- remote device forces disconnect of Chromecast by sending deauth command over WiFi
- Chromecast reverts to Reconnect Me mode with its own WiFi
- remote device connects and takes over Chromecast
But if I'm not mistaken, this won't work without being able to see the access code displayed by the Chromecast on the TV screen, right?
The article also mentions another possible buffer-overrun vulnerability in the DIAL protocol, but I don't see any evidence that this is any more than speculation.
DJames1 said:
"Rickroll Innocent Televisions With This Google Chromecast Hack"
In short the video shows:
- remote device forces disconnect of Chromecast by sending deauth command over WiFi
- Chromecast reverts to Reconnect Me mode with its own WiFi
- remote device connects and takes over Chromecast
But if I'm not mistaken, this won't work without being able to see the access code displayed by the Chromecast on the TV screen, right?
The article also mentions another possible buffer-overrun vulnerability in the DIAL protocol, but I don't see any evidence that this is any more than speculation.
Click to expand...
Click to collapse
Hey! This is Dan, the researcher behind the story. To answer some of your questions:
The "access code" that the Chromecast shows is never actually used to authenticate people on the Wi-Fi. its only purpose is to make sure users don't accidentally connect to their neighbor's chromecast on accident. You can verufy this yourself: If you go into the Chromecast Android app and reconfigure your own Chromecast, you'll see that the app pops up with a message that says "Do you see the code 'X1B8'" (or whatever). You can just say "yes" and ignore it. The user never has to enter and verify the code itself.
As for the buffer overflow, it's true that there's no good evidence of it yet. I just haven't finished exploiting the vulnerability. Until I actually have a working exploit, there's no way to be sure that it really exists. The buffer overflow for sure exists, and it's in a remotely accessible location. But who knows, maybe there's some other wrinkle that keeps it from being exploitable. Exect to see more on that soon.
Hope that helps!
yep that PIN system they have is a pretty useless one considering it is more of a CHECK than a security feature....
If it was like a BT PIN where you had to enter the pin you see on the screen before you could connect it would be a real security system.
I wonder why Google hasn't thought of that,
Yup, any Chromecast is vulnerable to "takeover" whenever it gets disconnected from its configured WiFi AP.
Why? Because its setup mode is completely open and requires no challenge, just a response. It's like if you call a credit card company, put in a number that isn't yours, then the agent comes on the line and asks
"Are you Joe Smith?" [Yes]
"Is your password 'ChocolateMilkGivesMeGas'?" [Yes]
Because a simple reconfiguration does not seem to delete the existing WiFi supplicant data (Google could easily fix this by erasing the stored WiFi credentials once a device connects for setup), if the noted buffer overrun bug or another exploit could gain root, user's WiFi credentials are easily accessed.
Factory reset does delete the stored WiFi credentials, but nobody's going to factory-reset their Chromecast until it's already too late.
This particular issue is an issue for those running rooted Chromecasts, as all the attacker needs is a way in (which includes the Team Eureka Web Panel for those running Eureka-ROM, as the current web panel is not secured).
IMO, Google needs to make the setup more secure - ease of use should never data trump security.
Ah, so it's not an access code, it's just an ID to help you match up the Chromecast the app sees on WiFi with the one you see on the TV screen. That certainly seems insecure, especially since there are so many other devices and apps that link up securely via a very similar-appearing access code.
Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.
DJames1 said:
Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.
Click to expand...
Click to collapse
Yeah, Google seems to think being on the WiFi network is "secure" enough and anything else public/school/hotel is not the place for Chromecast... that logic may work in a single-family living situation, but it definitely does not work in a shared environment, and the fact that it automatically goes into Setup mode when it loses its configured AP is where the risk lies, since someone can reconfigure it to connect to their WiFi network and it still has the original user's AP credentials stored.
Google can lock things down by changing the behavior so either
Clear the stored WiFi credentials when the setup process begins, before Chromecast connects to another network
This wouldn't stop some kind of remote-access exploit that can break in during setup mode, but it does stop any normal-mode exploits.
Require a factory reset to enter Setup mode when Chromecast is configured to connect to a WiFi network.
IMO the second one is more of the expected user behavior - when it arrives it has no credentials stored so it automatically proceeds to setup mode, but once configured it stays configured and requires reset to start configuration again.
Right now it says configured but can be reconfigured - by anyone any time the configured AP goes unavailable.
DJames1 said:
Ah, so it's not an access code, it's just an ID to help you match up the Chromecast the app sees on WiFi with the one you see on the TV screen. That certainly seems insecure, especially since there are so many other devices and apps that link up securely via a very similar-appearing access code.
Maybe Google figures that the vulnerability is not significant if it can only be used for a harmless prank to display a different media stream, and the user could just do a reset to take back control.
Click to expand...
Click to collapse
Yeah if the made the Pin System an integral part of allowing connection then it would be MUCH more secure even if it was in open AP mode because you would still need to be in front of the TV it is plugged into to see the pin!
Odd isn't it how Google seems to have spent so much effort and time into securing what can RUN on the damn device yet took little to no interest in who could connect to it!
The fact that the worst thing possible is a bad Video Picture being displayed I guess they thought it wasn't worth the effort and was maybe too difficult for an idiot to use if it was secure!
Hello everyone, I'm new on here. I have been an Android user since 2010. I recently purchased a Chromecast to use with my Nexus 5 however I was struggling to get it to work with some apps, including Netflix.
It occurred to me that every time I connect a new device to my home, I am redirected to a page which let's me set up the new device on the network. I realised that Chromecast would lack the ability to navigate through this set up process and the process was preventing the device from working correctly...
Sure enough, I went into my router admin settings and disabled the 'Smart Setup' and my Chromecast immediately allowed me to cast Netflix. So check your router settings! Hope this helps!
Chromecast, stock build 22062. Was working fine a couple of days ago. Then all of the sudden one night from my phone (rooted Galaxy S3, Likewise S5 ROM) I could see the cast button in RealPlayer Cloud, but when I pushed it it would act like it was connecting for a while, and then the cast button would disappear and reappear. However, there was no change on the TV screen - it stayed on the Chromecast background. Doing some more investigation I found that none of the Chromecast apps would connect to it (Netflix, Youtube, etc.). If I go into the actual Chromecast app it would see my Chromecast, and I can see all of the info about it, but if I click on "Backdrop" it scans the network and then says "No Chromecasts found."
I could go onto my Nexus 7, and everything worked fine - I could cast from everything perfectly. However, after I rebooted the Nexus, it started having the same problem as well. I can not cast from anything. It sees the Chromecast, but cannot connect. Now none of my Android devices work with it.
I tried factory resetting the Chromecast. I could connect to the Chromecast and set it up, but it did not solve my problem. The only thing that does work is casting a tab from my laptop.
My thought is this has something to do with my router setup. I have a Watchguard XTM-25, and I am outside the US blocking Google DNS requests. About a week ago I made some configuration changes on my router (bridged two interfaces together) but this should not have affected the Chromecast - it and all the devices go through one access point on the same side of the bridge). Indeed, everything worked after I made the change. I have, however, reverted to the previous setup just in case and still nothing works. It worked for more than a year with this setup.
Any ideas on where I should start looking to fix this? It almost seems that the Chromecast is only able to communicate in one direction - it can't receive anything from any Android device (although it does from my laptop), but it is sending out the signal saying it is there. It is basically useless as it is.
Thanks in advance!
Update: If I connect to a different subnet which goes through a VPN everything works fine, so I am sure it is in router settings. However, I still don't know what to look for.
Matthew Carson said:
Chromecast, stock build 22062. Was working fine a couple of days ago. Then all of the sudden one night from my phone (rooted Galaxy S3, Likewise S5 ROM) I could see the cast button in RealPlayer Cloud, but when I pushed it it would act like it was connecting for a while, and then the cast button would disappear and reappear. However, there was no change on the TV screen - it stayed on the Chromecast background. Doing some more investigation I found that none of the Chromecast apps would connect to it (Netflix, Youtube, etc.). If I go into the actual Chromecast app it would see my Chromecast, and I can see all of the info about it, but if I click on "Backdrop" it scans the network and then says "No Chromecasts found."
I could go onto my Nexus 7, and everything worked fine - I could cast from everything perfectly. However, after I rebooted the Nexus, it started having the same problem as well. I can not cast from anything. It sees the Chromecast, but cannot connect. Now none of my Android devices work with it.
I tried factory resetting the Chromecast. I could connect to the Chromecast and set it up, but it did not solve my problem. The only thing that does work is casting a tab from my laptop.
My thought is this has something to do with my router setup. I have a Watchguard XTM-25, and I am outside the US blocking Google DNS requests. About a week ago I made some configuration changes on my router (bridged two interfaces together) but this should not have affected the Chromecast - it and all the devices go through one access point on the same side of the bridge). Indeed, everything worked after I made the change. I have, however, reverted to the previous setup just in case and still nothing works. It worked for more than a year with this setup.
Any ideas on where I should start looking to fix this? It almost seems that the Chromecast is only able to communicate in one direction - it can't receive anything from any Android device (although it does from my laptop), but it is sending out the signal saying it is there. It is basically useless as it is.
Thanks in advance!
Update: If I connect to a different subnet which goes through a VPN everything works fine, so I am sure it is in router settings. However, I still don't know what to look for.
Click to expand...
Click to collapse
I've had exactly the same issues with my HTC One Max and HTC EVO LTE. Daughters GS4 works with the 6.5.87 version on my WIFI and my HTC does not work on her home WIFI. After doing everything you've described with no help, I noticed this occured with a recent update of Google Play Services to 6.5.87. I uninstalled it and sideloaded an older version from apkmirror.com (6.1.88) and my Chromecast world was right again. Unfortunatley Google would do a "stealth" upgrade within 24hr back to 6.5.87. So I tried sideloading the newest version (6.5.88). Now You Tube and Google Play Music work fine but the cast button doesn't even show up on the 3rd party apps (TuneIn, Pocket Casts, NetFlix etc.). Don't know what it means, maybe an API incomptability? Hoping for some updates to Services or the apps that will fix this.
retired129 said:
I've had exactly the same issues with my HTC One Max and HTC EVO LTE. Daughters GS4 works with the 6.5.87 version on my WIFI and my HTC does not work on her home WIFI. After doing everything you've described with no help, I noticed this occured with a recent update of Google Play Services to 6.5.87. I uninstalled it and sideloaded an older version from apkmirror.com (6.1.88) and my Chromecast world was right again. Unfortunatley Google would do a "stealth" upgrade within 24hr back to 6.5.87. So I tried sideloading the newest version (6.5.88). Now You Tube and Google Play Music work fine but the cast button doesn't even show up on the 3rd party apps (TuneIn, Pocket Casts, NetFlix etc.). Don't know what it means, maybe an API incomptability? Hoping for some updates to Services or the apps that will fix this.
Click to expand...
Click to collapse
Thanks. I tried going back to 6.5.86 but unfortunately it didn't fix it in my case.
Matthew Carson said:
Thanks. I tried going back to 6.5.86 but unfortunately it didn't fix it in my case.
Click to expand...
Click to collapse
I think if you try 6.1.88 you'll find it will work. My question is why and how to fix it.
Same happened to me this week, my SG3 works fine as always with the Chromecast but my SGN 10.1 suddenly stopped working. Cast button is on and Chromecast app can see it but it never connects.
Sent from my GT-N8013 using XDA Free mobile app