Database Develop

Reverse-Tethering on a Vogue with Android (Share Windows PC's Internet with phone)

I have done the NAND install method on my Vogue with Myn's Warm Donut RLS3 from 2010-02-20. Since I do not have a data plan, and have the XV6900, which comes without WiFi, I cannot just connect to a local network to get internet access, so how do I get access over the USB cable or via Bluetooth? This would basically be like "Reverse-tethering", that you can do in Windows via ActiveSync (when you are hooked up you can use the desktop PC's internet connection)
So, how do we do this now on Android?
Thanks,
-C

Short version: we don't. Do you want details?

Well, without looking very hard... I know this is possible, since you can do almost anything on Linux. Here's a brief description of how this is done, although it may need some modification for our builds:
http://www.htc-android.com/viewtopic.php?f=5&t=154
OR
http://forums.androidandme.com/topic/internet-over-usb
Search for android ifconfig usb and see what you can find.

polyrhythmic said:
Well, without looking very hard... I know this is possible, since you can do almost anything on Linux. Here's a brief description of how this is done, although it may need some modification for our builds:
http://www.htc-android.com/viewtopic.php?f=5&t=154
OR
http://forums.androidandme.com/topic/internet-over-usb
Search for android ifconfig usb and see what you can find.
Click to expand...
Click to collapse
We certainly could if it was supported in our kernel, but our only USB drivers are adb and mass storage. I believe dzo and mssmison are working on some other. cdc, ethernet, rndis, etc. aren't currently supported.

mrkite38 said:
Short version: we don't. Do you want details?
Click to expand...
Click to collapse
Hmm bummer. Most people with cell service are STILL not paying for data plans, and only about 50% of people with smartphones have data plans yet. Heck...I got a data plan and then got rid of it after 6 months...that alone was $180 worth that was totally wasted for what...the convenience of checking email on my lunch break....yeah that's worth it. At least ATT is only $10 a month now if you are on a shared plan with your family for unlimited data. To bad I an on VZW, lol...
So anyway, it seems like this would almost be a must. I would gladly pay a developer here $50 if he came up with a widget to do it. He'd make a lot more than that on the market too if he developed that.

crobs808 said:
So anyway, it seems like this would almost be a must. I would gladly pay a developer here $50 if he came up with a widget to do it. He'd make a lot more than that on the market too if he developed that.
Click to expand...
Click to collapse
'Real' android phones can do it, our kernel can't. Plus, you can't download from market or use youtube, etc, over bluetooth tethering (I've tried) or via usb from what I've read. Only the cellular data connection and wifi are considered 'valid' by Android. So the dev would have to fix that, too, to make it worthwhile.

mrkite38 said:
'Real' android phones can do it, our kernel can't. Plus, you can't download from market or use youtube, etc, over bluetooth tethering (I've tried) or via usb from what I've read. Only the cellular data connection and wifi are considered 'valid' by Android. So the dev would have to fix that, too, to make it worthwhile.
Click to expand...
Click to collapse
I would be happy just to have WiFi, but the XV6900 (Verizon Touch) doesnt even have WiFi at all. I am considering getting the Nexus when it comes to Verizon in a few months.

crobs808 said:
I would be happy just to have WiFi, but the XV6900 (Verizon Touch) doesnt even have WiFi at all. I am considering getting the Nexus when it comes to Verizon in a few months.
Click to expand...
Click to collapse
Yeah, and the mogul might be a good solve but it only has a 64 MB ROM... I know, been through it all in my head before, too.

Thanks
Thanks. It can sure take some time searching to find some of this info, but even with the NO it won't work I'll still be searching
I want the Bluetooth PAN on Android!
It does not make any sense that Google would know I'm connecting via Bluetooth PAN vs. WiFi to my PC since this occurs behind my Router??? The IP is set at the Router level, my phone should not be visible.
edit... misread post above.
I guess Android itself would know, but that seems odd. But Odd rules sometimes.

Any updates on possibilities yet ??? or there is still no way to use internet on Vogue Andriod without having data plan ?

gogodj said:
Any updates on possibilities yet ??? or there is still no way to use internet on Vogue Andriod without having data plan ?
Click to expand...
Click to collapse
Not yet... the reasons posted above are still true.

Are there any plans to add this feature to future ROMS? The only reason I haven't switched to android from windows mobile is because of this.

damaph said:
Are there any plans to add this feature to future ROMS? The only reason I haven't switched to android from windows mobile is because of this.
Click to expand...
Click to collapse
I don't think so. It's a kernel thing, not a rom thing, and it requires a lot of driver work. But even if it did work, android wouldn't recognize it as a valid connection.

rfcomm + pppd to tether both ways?
I am new to android, but I have networking experience with Linux. I am running Myn's latest Warm Donut on my Sprint Touch. And it seems that hciconfig/hcitool are working to associate the phone with another bluetooth interface. Also, rfcomm seems to be working. And lastly, pppd is installed and (indeed) necessary for the 3g/edge connection as evidenced by the ppp0 in ifconfig. Also, reviewing dmesg, I see L2CAP and BNEP are compiled into the kernel. And pand is also compiled and running. I am not familiar with these, but it seems to offer another route for maybe getting a bluetooth IP link established.
So, my question is simply this. Can we not use the hci commands to associate the phone to another bluetooth adapter on, say, a networked Linux system? Then use rfcomm to build a bluetooth serial connection between the two systems, and finally establish a ppp interface on each end of that serial link? Once that is done, the two systems will share a point-to-point IP link over BT over which they can communicate. Then it is simply a matter of establishing gateways, proxies, iptables NAT, DNS, and routes to make either forwarded or reversed tethered connections. I am reasonably confident I can do that. With a Class 1 bluetooth interface on the Linux server side, the range could be extended for reverse tethering...perhaps making it useful as a moderate range wifi replacement. Other webpages discuss similar approaches using bluetooth rfcomm/pppd. It might require experimentation to find reasonable baud rates for the serial link, etc., but nothing seems obviously impossible. And bluetooth can provide a 1 Mbps+ speeds...again, not great, but better than Edge or dodgy EVDO.
Likewise, we may be able to build a proper PAN connection. I am not familiar with pand and bnep interfaces, but I could probably figure it out.
As I said, I am new to Android, and I am just starting to test this on my phone. Is there something that I am missing with regard to existing hci/rfcomm/pand functionality? Dmesg reports all of these compiled in and hcitool scan seems to do something...it blinks the blue light and find my laptop. I guess I am just asking if someone can shoot holes in my idea before I waste too much time pursuing it.
Thanks.

mprinkey said:
I am new to android, but I have networking experience with Linux. I am running Myn's latest Warm Donut on my Sprint Touch. And it seems that hciconfig/hcitool are working to associate the phone with another bluetooth interface. Also, rfcomm seems to be working. And lastly, pppd is installed and (indeed) necessary for the 3g/edge connection as evidenced by the ppp0 in ifconfig. Also, reviewing dmesg, I see L2CAP and BNEP are compiled into the kernel. And pand is also compiled and running. I am not familiar with these, but it seems to offer another route for maybe getting a bluetooth IP link established.
So, my question is simply this. Can we not use the hci commands to associate the phone to another bluetooth adapter on, say, a networked Linux system? Then use rfcomm to build a bluetooth serial connection between the two systems, and finally establish a ppp interface on each end of that serial link? Once that is done, the two systems will share a point-to-point IP link over BT over which they can communicate. Then it is simply a matter of establishing gateways, proxies, iptables NAT, DNS, and routes to make either forwarded or reversed tethered connections. I am reasonably confident I can do that. With a Class 1 bluetooth interface on the Linux server side, the range could be extended for reverse tethering...perhaps making it useful as a moderate range wifi replacement. Other webpages discuss similar approaches using bluetooth rfcomm/pppd. It might require experimentation to find reasonable baud rates for the serial link, etc., but nothing seems obviously impossible. And bluetooth can provide a 1 Mbps+ speeds...again, not great, but better than Edge or dodgy EVDO.
Likewise, we may be able to build a proper PAN connection. I am not familiar with pand and bnep interfaces, but I could probably figure it out.
As I said, I am new to Android, and I am just starting to test this on my phone. Is there something that I am missing with regard to existing hci/rfcomm/pand functionality? Dmesg reports all of these compiled in and hcitool scan seems to do something...it blinks the blue light and find my laptop. I guess I am just asking if someone can shoot holes in my idea before I waste too much time pursuing it.
Thanks.
Click to expand...
Click to collapse
That's all correct, and I've done it before. But the issue is that Android only acknowledges TWO kinds of data connections: cellular and wifi. When I setup a pan and iptable'd my way to the internet, I was able to get google maps, but not market. I haven't tried Opera but the android browser didn't work. Etc., etc. So I think the usefulness of pan is limited. The real challenge here is for someone to dig through the source and find out how to ADD bt and USB as 'valid' data interfaces. I've never looked into that.

Cellular connection is ppp0. Have you tried running pppd over rfcomm? Or assign an identical IP address to the pan/pppd interface and set it's metric a notch lower so it is preferred over the ppp0 one? Also, will Android route over a VPN? Setup pan and VPN over it. VPN seems to "own" Internet traffic when it is configured according to this: http://code.google.com/p/android/issues/detail?id=4205
Also, I've seen posts indicating that the default browser can be configured to use a proxy.
Just ideas and I'd like to know what you've tried so I don't waste my time. Thanks for your input.

mprinkey said:
Cellular connection is ppp0. Have you tried running pppd over rfcomm? Or assign an identical IP address to the pan/pppd interface and set it's metric a notch lower so it is preferred over the ppp0 one? Also, will Android route over a VPN? Setup pan and VPN over it. Also, I've seen posts indicating that the default browser can be configured to use a proxy.
Just ideas and I'd like to know what you've tried so I don't waste my time. Thanks for your input.
Click to expand...
Click to collapse
Nope, didn't try any fancy-pants stuff. When I did all this, I was a total n00b to linux (only a partial n00b now) and it didn't take too long, so I say - give it a try! That's the spirit around here.

mrkite38 said:
Nope, didn't try any fancy-pants stuff. When I did all this, I was a total n00b to linux (only a partial n00b now) and it didn't take too long, so I say - give it a try! That's the spirit around here.
Click to expand...
Click to collapse
Great. That is encouraging. The link that I edited into my previous post seems to indicate that ALL traffic gets routed over the VPN when it is established. That would fix any security concerns I'd have about using a high-powered BT adapter. I think I will give it a spin.

USB Ethernet
In my kernel hacking trying to get Debian to run, I managed to enable USB Ethernet (the function driver; USB gadget crashes the phone) working, and I've been using it to SSH into my phone. I've used it to apt-get update without any problems. I believe it's just a kernel config option (although I might have done some code modifications), so the problem isn't the driver, it's with Android's userspace.

gTan64 said:
In my kernel hacking trying to get Debian to run, I managed to enable USB Ethernet (the function driver; USB gadget crashes the phone) working, and I've been using it to SSH into my phone. I've used it to apt-get update without any problems. I believe it's just a kernel config option (although I might have done some code modifications), so the problem isn't the driver, it's with Android's userspace.
Click to expand...
Click to collapse
So you enabled USB ether in the kernel config and it's working for you? Against a linux host or Windows? that would be nice, I haven't tried that in ages.
Edit: yes, the 'valid' connection check is definitely in Android userspace. But I either forgot or didn't know that our usb ether func driver worked when enabled.

wifi problem in overcome 7 series v4.1.0

hi there i am having a problem with my sgt p1000 wifi just upgrade to 7 series 4.1.0 i noticed that my wifi connection is not stable...

Think is an hardware problem.because i have installed this rom and i have any problem with the wifi.
Galaxy Tab P1000-OVERCOME 7 SERIES 4.1.0

icy25 said:
hi there i am having a problem with my sgt p1000 wifi just upgrade to 7 series 4.1.0 i noticed that my wifi connection is not stable...
Click to expand...
Click to collapse
Get yourself over to the Overcome thread and READ through it. Your answer lies within...

No offense phlooke, but you've told a few people that, and I've already become a bit lost in the over 100 pages of posts in that overcome 4.1 thread. Unless you're gonna post a link to the page in that thread where the solution begins, how is your above post helpful?
I'm going back into that thread now, but I swear, it's full of a lot of duplicate commentary, side discussions, and very little of the content is useful. A mod should clean up that thread.

maybe this one?
http://forum.xda-developers.com/showpost.php?p=21180574&postcount=770
Overcome 4.1 wifi fix attached there by Alterbridge himself.

Well the reason the thread is so congested is because of the same questions being asked over and over again.
People are too damn lazy to do there own investigation.
If you can't be bothered to read the whole thread there's a search function.
Check the forum rules.
Lastly the post I made is helpful in pointing the op to the place containing the answer? Duh.
Sent from my GT-P1000 using XDA App

Overcome Series ROM's are awesome but I always have a screen problems on my TMO Tab. I get these little brownie prickles on my screen like a twinkling stars at night. I am not sure why, maybe it's because the LCD and RAM are under voltage. Normally, every time I flash a new ROM, I always flash back my modem.bin just to make sure that I get all the benefits of my carrier's. Right now, I use Chromed JQ8 Stock ROM with Dip7 Kernel. It's pretty much stable and fast. Chromed JQ8 and Dip7 Kernel combo works furiously fast and stable. No bugs and everything works wonderfully.

Actually not really, because if you read through the conversations on the Overcome 4.1.0 thread, that wifi fix doesn't work for many people. And now, as a new Overcome user (as of four hours ago), it doesn't work for me, either. I flashed the fix file from CWM and I still get an up, down, up, down and so on with the wifi connection. There needs to continue to be people asking some of the same questions about this, so that people like yourself don't give the mistaken impression that this problem is somehow "solved". I'm not putting you down, because I can tell from your posts on XDA that you really want to help when and where you can (as do most people on XDA including myself), but the fact remains that this wifi problem is NOT fixed, and at least for the time being, the more people who squawk about it on here or in the official Overcome thread, the more likely a true solution will present itself.
Because right now, there isn't one. The flash fix doesn't work for a lot of us, and I shouldn't have to tweak my router. That's a ridiculous notion. That, and I find myself moving from location to location, relying in a variety of wireless networks to connect to, and I certainly can't go and tweak every single router I come into contact with. It's unrealistic, and it's a *software* issue on the ROM. So a fix is possible. But isn't available just yet.
So this thread, and any other new ones... at least for the short term, they have the latent function of keeping the issue current and visible to the developer or others who might have the tech savvy to truly fix the issue.

personally, if I don't feel like helping, I will just move on.
I just don't understand why some people feel like policing the threads while not offering valuable info.
Take a deep breath and ignore the post.
As for the wifi problem, I wonder if it is modem related? It has to be either that or hardware related (batch issue with chipset?)
There is a small number of users with unstable wifi issue.

Small number of reported people with this issue. Who knows how many it actually affects, but more than three is too many. I can't see why it would be hardware related, since the devices in question work fine prior to flashing Overcome 4.1.0. Some people have switched to Overcome 4.0 and seen the problem go away (as have those who switched to other Chefs' ROMs). Of those who install 4.1.0 and see no problems, it suggests that whatever change happened between 4.0 and 4.1.0 affects only certain routers. Maybe some kind of optimization done has rendered a number of router models affected. ???

Suleeto said:
Of those who install 4.1.0 and see no problems, it suggests that whatever change happened between 4.0 and 4.1.0 affects only certain routers. Maybe some kind of optimization done has rendered a number of router models affected. ???
Click to expand...
Click to collapse
It has nothing to do with what router you have. Any router set to have no lease expiration will cause the bug. MOST routers don't even allow you to do such an asinine things. I couldn't force my router to have no lease expiration if I wanted to (which I wouldn't, because it would be stupid).
Search google for "Netgear No Lease Expiration". This is a GENERAL problem. It is not confined to Gingerbread Overcome ROM 4.1.
The bug is a combination of some routers' fault for shoddy programming and a gingerbread wifi config fault for not handling a fringe (and borderline retarded) but technically acceptable setting.
Change (FIX) your router's setting.
---
See for details: http://www.ietf.org/rfc/rfc2131.txt
According to the RFC SPEC:
The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the client has been retired.
Nowhere in the spec does it say the server should give out Infinite Leases to clients that do not ask for them. If your router gives infinite leases to clients that can not or do not handle them, THE ROUTER IS THE BROKEN PART.

So you're saying that Froyo, WinMo, and other more powerful computing devices have additional functionality to deal with "fringe" features on select routers?
I am considering your explanation but you can understand how the explanation itself also might sound asinine to a layperson. I understand what DHCP servers do and how IP leases work.
My router is a newer Belkin model only a couple years old.
Edit: Because I am curious, I'll be looking into the router settings to see just what it is actually set at.
Edit 2: Yep, it's set to forever. Then again, I still can't understand why that is in your assessment considered a "bad" thing. And in my experience, it has never, NEVER been a problem with previous tech, over the years and years of wifi router use.
None of this explains or justifies why Gingerbread-based ROMs should suddenly lose this functionality. It is not like Android clients are going to change the face of what is a very common DHCP configuration among routers past and present (despite your sentiments). To me, moving from Froyo builds that can handle this to Gingerbread builds that cannot seems counterproductive for Google, as most consumers WILL NOT want to tweak their three to five year old routers that otherwise connect fine to every other computing device they can bother to try to connect with.
And like I said previously in this very thread... you can't exactly go into the back room of a Starbucks, the town library, or of local businesses, and demand they make a change to their DHCP lease configurations that for everyone else (oh! oh! oh! Including the well loved iPhone!) works without any issues whatsoever.
So I'm sorry, I'm not being a **** here, but what you're suggesting is an extremely large pill you are asking me to swallow, and it just seems like a prescription for a disease I do not possess.

LOL, checked the router and found the problem.
Was that not covered in the thread as one of the issues/fixes?
Jeez.

you can't exactly go into the back room of a Starbucks, the town library, or of local businesses, and demand they make a change to their DHCP lease configurations
Click to expand...
Click to collapse
And you'll almost never have to, because 99.5% of routers are made to the spec I linked and won't give the type of lease that your router does. Surprising that there isn't a firmware upgrade available that changes the default on the router to not be infinite - may just be because you can do it yourself in the router setup, so they didn't bother.
The "infinite-lease" by router without client request situation is not specifically defined in the spec, which means it is not necessarily defined in all clients. What makes other devices work with this router is either
a) the other clients can/do request infinite-leases
b) the other clients happen to have a lease handler that accepts an infinite lease
But nothing in the spec says the client should handle an infinite lease if it did not request one. In the case of this particular gingerbread ROM, that handler is left out, which is a case of not coding defensively enough. -Great- code would handle that in a different way than re-scanning constantly. However, there is a difference between "great code" and "meeting specs". By specification technicality it is the router that is on the wrong side of this argument.
All it means is that both sides kind-of suck. And in this situation the sucky part you have control over is the router, unless Alterbridge releases a modified wifi config that can handle this case gracefully that it shouldn't have had to handle in the first place (but honestly should have anyway, because that's what great code does).

phlooke said:
LOL, checked the router and found the problem.
Was that not covered in the thread as one of the issues/fixes?
Jeez.
Click to expand...
Click to collapse
Um I only mentioned that out of rhetoric, I am not questioning what I can do to resolve the tablet connection process AT MY HOME, I'm questioning the logic of defining the router as a "problem", which the other gentleman (darkmatter) is discussing with me. Or did you miss the point I was actually making? Jeez
darkmattar said:
And you'll almost never have to, because 99.5% of routers are made to the spec I linked and won't give the type of lease that your router does. Surprising that there isn't a firmware upgrade available that changes the default on the router to not be infinite - may just be because you can do it yourself in the router setup, so they didn't bother.
The "infinite-lease" by router without client request situation is not specifically defined in the spec, which means it is not necessarily defined in all clients. What makes other devices work with this router is either
a) the other clients can/do request infinite-leases
b) the other clients happen to have a lease handler that accepts an infinite lease
But nothing in the spec says the client should handle an infinite lease if it did not request one. In the case of this particular gingerbread ROM, that handler is left out, which is a case of not coding defensively enough. -Great- code would handle that in a different way than re-scanning constantly. However, there is a difference between "great code" and "meeting specs". By specification technicality it is the router that is on the wrong side of this argument.
All it means is that both sides kind-of suck. And in this situation the sucky part you have control over is the router, unless Alterbridge releases a modified wifi config that can handle this case gracefully that it shouldn't have had to handle in the first place (but honestly should have anyway, because that's what great code does).
Click to expand...
Click to collapse
I am not really concerned with "great code" vs. "poor code" here, I'm concerned with consumer use. I am more and more convinced this was a decision of the ROM chef and less that it's "Gingerbread" design. I can't imagine Google taking a risk of alienating even a small percentage of consumers who find themselves trying to connect to routers with default infinite leases. You claim that most new routers don't even allow that. This would mean that "infinite lease" is a legacy configuration, but again, every other device seems to have no trouble with that, because companies making these devices and their ROMs understand that the average consumer DOES NOT always know how (or have the option to) go in and change the config of a given router.
And btw... using the term "code" to criticize router design is a bit sloppy. How cleanly it's "coded" isn't at all what you're describing. It's "design philosophy" that is at work here. Not "code". Sometimes amateur programmers haven't spent enough time in the corporate development world and do not understand that the deciding factor in features and function is the COMSUMER end. Code is the guts, not the result. The result is designed based on need.
Also, you have some devices (recent ones, like my HP wireless printer for instance) that do not have an easy way to be assigned a fixed IP, and do not like frequent DHCP reassignment because the driver end on the client PC retains the IP as the pointer for the print queue. An infinite lease allows the initial assignment process to happen, and allows the client PC driver assigned IP to keep consistent with the IP assignment of the printer. This is not the only device that has this issue, but it is an increasingly common problem among a few wireless printer manufacturers in the way they set up client software connections to wireless printers.
So are you saying I should change my router config and cause printing problems in order to satisfy my apparently gutted, less-than-full featured network functionality of my custom flashed Android device?
Does that sound reasonable? Does that even address the concern that I have no control over public and other private wireless networks that I might try to connect to (and have infinite lease enabled)?
Tell you what: I will be going to not one, but three different wireless networks today. One at my local college, one at Starbucks, and believe it or not, the Denny's down the street has a brand new wifi setup installed (only about six months old). I will tell you what happens.
Even still, if I have this situation at home, then inevitably it exists elsewhere. And I would wager it's not a 1% experience, either.
I'm all for streamlining custom ROM's and trimming the fat, but not at the expense of such particularly important functionality. You call it "fringe", but from a product development point of view, we would consider it "comprehensive".
I like my "comprehensive" term a lot better than your "fringe" one. Maybe dropping this kind of functionality will happen eventually in devices, but I feel that doing so now is premature.
And I'm hoping that the chef reads this and at least offers the code in a subsequent version.
---------- Post added at 10:06 AM ---------- Previous post was at 09:50 AM ----------
From the Overcome 4.1.0 thread:
absolutab said:
Not every GB ROM. Only on 2.3.6 JQ8. Had no issues with wi-fi on previous GB versions.
OTOH, on previous versions I had market issues (even at 240 dpi and with the 60Mb cache hack) and everything's working great on 2.3.6. Go figure... If I could have overcome 7 4.0 with overcome 7 4.1 market behavior I'd be more than happy.
I've tried ICS CM9 and wi-fi seemed stable.
Click to expand...
Click to collapse
So Google may have indeed been the one to F' things up... Still, my sentiments stay the same, and it means that I might be switching to Overcome 4.0 until the situation is resolved. At least if this is the case, it's not the Chef's fault.

It has been a good discussion - I feel it is definitely clearing up the details, and I've learned a few things myself while researching to make sure my dhcp knowledge is up-to-date and at least mostly factually correct.
Also, you have some devices (recent ones, like my HP wireless printer for instance) that do not have an easy way to be assigned a fixed IP, and do not like frequent DHCP reassignment because the driver end on the client PC retains the IP as the pointer for the print queue. An infinite lease allows the initial assignment process to happen, and allows the client PC driver assigned IP to keep consistent with the IP assignment of the printer.
Click to expand...
Click to collapse
The infinite lease merely stops the Lease Handshake from occurring. The lease handshake is a different communication altogether from DHCP [re]assignment. About the only time a DHCP assignment will happen is if DHCP settings change on the router between leases, and on the rare occasion it could happen that the Lease Handshake fails (like if one of the devices is unplugged or loses power momentarily) and a different device is connected and takes the IP, requiring a new one to be given to the other device. However, on your mostly stable/unchanging home network, this should happen pretty much never. The only case worth worrying about is if a power outage lasts long enough to span the lease expiring on multiple devices, they could reconnect and get different IPs each
less-than-full featured
Click to expand...
Click to collapse
I have been quoting from the RFC on DHCP. What your router is doing is not "full featured", it's "extra featured", which means not every device is going to support it, nor does it have to support it to be approved. If you look up "infinite lease" on google, you will see that essentially all documentation recommends against it. Another humorous link is to microsoft DHCP server software, which allows setting infinite leases (it is nowhere close to the default) but then begs you not to in the documentation!
However, since the spec does not explicitly state that a device should fail and retry the connection when an infinite lease is given, there really is no wrong method.
There is certainly a "more-appealing-to-users-desiring-full-compatibility" method. But again, when one device does something not explicitly defined in the specifications for ALL DHCP devices, it is just asking for other devices to be unable to connect to it.
Does that sound reasonable? Does that even address the concern that I have no control over public and other private wireless networks that I might try to connect to (and have infinite lease enabled)?
Click to expand...
Click to collapse
As for this concern, I may be wrong, but I believe any public wifi with infinite leases will be broken 1/2 the time due to the allocated IP space being used up by devices that aren't even connected anymore. They'll be rebooting their router every few hours/days depending on how heavy their traffic is.
Almost all documentation warns against even setting your client to request infinite leases, or allowing your router to grant them
See: http://technet.microsoft.com/en-us/library/dd183602(WS.10).aspx
or: http://www.tcpipguide.com/free/t_DHCPLeasesLeaseLengthPoliciesandManagement-4.htm
or: http://blogs.technet.com/b/teamdhcp/archive/2007/02/07/configuring-lease-time.aspx
Important Excerpts from above links:
Although it is possible to configure a client with infinite lease duration, use infinite lease durations with caution. Even relatively stable environments have a certain amount of client turnover. At a minimum, computers might be added and removed, moved from one office to another, or network adapters might be replaced. If a client with an infinite lease is removed from the network without releasing its lease, the DHCP server is not notified, and the IP address is not automatically reused. Also, when using an infinite lease, options set on the DHCP server are not automatically updated on the DHCP client, because the client is never required to renew its lease and obtain the new options. We recommend that you use reservations, rather than infinite lease durations.
Click to expand...
Click to collapse
Perhaps the most relevant one of all is here:
Should I have INFINITE lease time?
It’s technically possible and most of the devices support it but the recommendation is never to have infinite lease time. The main reason is that any change in network configuration on dhcp server will not be updated on the client as the client will not trigger renew. Also it’s reported on some site that few devices don’t behave properly with INFINITE lease time and result in service crash and other issues. So if you are dhcp admin and want to avoid unnecessary issues it’s recommended not to have INFINITE lease time
Neelmani
Windows Enterprise Networking
Click to expand...
Click to collapse
See quotes above. It is way more of a router problem than a client problem.
But, in the end, I do agree that a well-designed wifi driver -should- be capable of handling an infinite lease without failing and reconnecting endlessly.

After reading all that the morning you posted it, I agree with you even before the edit. I see your point.
And I'm glad you also seem to agree with me that it could have been more comprehensive.
I've since turned my lease to two weeks (the maximum increment other than infinite). Hopefully my printer will continue to sync up to the client software later on. I will admit that I partly blame HP and other printer manufacturers for using such a LAZY workaround for their wifi printing solutions.
I suppose in a few years from now it won't matter. I still haven't visited those three other networks I wanted to try Overcome's Gingerbread on. Not yet. Been extremely busy. In a few minutes I'll be heading to a Starbucks in another town, so it might happen.

Connection problems either WiFi or physical cable have all the same similarity, Manufacturer's problem and not the OS. If I remember it correctly, way back in the 90's, Modem manufacturer's would just produce hardware and doesn't even think about the end user that will use it. We used to trash WinMo for having so many hardware problem's without realizing that some of the hardware manufacturer's doesn't go by the standards when designing and writing device drivers.They'll just re-use the same design hardware and hoping that they could just re-write the device coding to make it work whatever OS the end user would be using.A well designed hardware makes a coder job fairly easy and would work easily with the end user without a hitch. Sadly, I have to admit that until to these days some manufacturers still have problems catching up every time we have a new OS and merging two OS on a router to make a connection is still a ***** for them.I hate to say it, but "Belkin" should join the club properly .

Sometimes happens only !
I flashed overcome 4.1 over 20 times (while trying other roms and CM9 releases) and return back to it.
on 50% of the cases wifi caused problems. So wonder was about cache - wiping issue.
P.S. Yes i do use same file everytime and re-stock.

Try it.. Simple
i can smile use this because wifi easy connect... use this
1. Install Wifi Static (download from Android Market)
2. Make sure your wifi is connect.
3. Open Wifi Static, and click all box.
4. Click (add configuration) and press button option at your tablet.
5. Now u can see Generate click it.
6. Now click at IP Address change it. example:
192.168.2.1 to 192.168.2.100
7. Restart wifi.
it simple because can save configure and know
ip address/gateway/netmask/dns1/dns2
just changed ip address because you should use ip address no people take already.
easy to use at McD... or any Wifi

Setup question - technical query

I have my Chromecast already set up, and am forging ahead with learning and reading tricks on here, but I was curious about the set up process itself.
Think about it - I have an encrypted WiFi, and there's no open WiFi around me... But somehow when I was setting up the device, the program on my laptop knew the code that the device was broadcasting. The device clearly communicated out to the internet BEFORE I set up my WiFi password in the setup program. I'm wondering what the trickery was that managed that, or am I missing something critical in the process here?

FractalSphere said:
I have my Chromecast already set up, and am forging ahead with learning and reading tricks on here, but I was curious about the set up process itself.
Think about it - I have an encrypted WiFi, and there's no open WiFi around me... But somehow when I was setting up the device, the program on my laptop knew the code that the device was broadcasting. The device clearly communicated out to the internet BEFORE I set up my WiFi password in the setup program. I'm wondering what the trickery was that managed that, or am I missing something critical in the process here?
Click to expand...
Click to collapse
Pretty sure the device uses ad-hoc WiFi and/or Bluetooth to perform the initial sync. There is a thread about how your desktop must have a WiFi card in order to set up the chromecast (but Streaming from Chrome over ethernet works after initial setup).

Louer Adun said:
Pretty sure the device uses ad-hoc WiFi and/or Bluetooth to perform the initial sync. There is a thread about how your desktop must have a WiFi card in order to set up the chromecast (but Streaming from Chrome over ethernet works after initial setup).
Click to expand...
Click to collapse
Didn't think about an ad-hoc solution. And the setup program could be set to look for its broadcasts... Nor did I even consider using anything other than my laptop on WiFi to sit RIGHT IN FRONT OF THE TV and play while setting it up.
That sounds plausible, though it felt like wizardry at the time.

FractalSphere said:
Didn't think about an ad-hoc solution. And the setup program could be set to look for its broadcasts... Nor did I even consider using anything other than my laptop on WiFi to sit RIGHT IN FRONT OF THE TV and play while setting it up.
That sounds plausible, though it felt like wizardry at the time.
Click to expand...
Click to collapse
I thought the same thing at first, but after setting up my second Chromecast using the Android application, you can see it messing with your WiFi/Bluetooth settings in the status bar when initially searching for Chromecast devices.

Making Rooted safer than Stock

Dear Team Eureka there is one thing you may do with security of Chromecast that Google did not.
You may add the missing security feature:
"if there is no connection to preset network" - "do not enable unprotected wifi ap mode" unless user will press reset button for short time (something like enable/disable wifi feature with openwrt)
There is plenty of things you ma use button for in future
(you may use different functions within different interval)
press
1-5 seconds
6- 15... and so on

I like this feature!

I agree that the way it is currently working is not as secure as it could be...
But I think the better way to do all of this is the following:
1 - Never have the CCast automatically connect to an Open Wireless unless specifically told to via Setup (not sure if it does this now or not)
2 - (and this would be the alternative to your suggestion) CCast doesn't leave any unprotected network sans AP connection for setup. It's default setup mode is a protected WiFi either WEP or WPA
CCast should instead set a random pin/pass and WPA/WEP connection for use in setup when it can't find an authorized AP.
Since you should have access to the screen it is plugged into and hackers would not, you would make the connection to the CCast in protected mode using the PIN that is displayed on the screen to make the connection to the protected network. Once connected you set up the device normally.
Much better than walking over to the TV and device to press a button and much more secure because the only way to set up or take over the unit requires access to the TV it is plugged into.
As far as the Button is concerned I would really like to see it used to switch modes and add a DLNA device mode to the custom rom. Unless the ROM could add this feature while still in CCast mode.

Asphyx said:
1 - Never have the CCast automatically connect to an Open Wireless unless specifically told to via Setup
2 - (and this would be the alternative to your suggestion) CCast doesn't leave any unprotected network sans AP connection. It's default setup mode is a protected WiFi either WEP or WPA
CCast should instead set a random pin/pass and WPA/WEP connection for use in setup when it can't find an authorized AP.
Since you should have access to the screen it is plugged into and hackers would not, you would make the connection to the CCast in protected mode using the PIN that is displayed on the screen to make the connection to the protected network. Once connected you set up the device normally.
Click to expand...
Click to collapse
AFAIK Chromecast never does #1 - it won't auto-connect to any AP unless it's already set up.
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Since the serial number is easily accessible on the unit itself and its box, that could be an easy-to-get password, and the 4-character alphanumeric ID shown on the TV could be a secondary confirmation for Setup, not just a convenient way to make sure you're connected to the correct Chromecast (does Google really think/hope there will be that many Chromecasts out there being set up at the same time?).

Also if http will be protected with https also passwords it may be better to config Chromecast wireless options via https/ssh.
Is there any way to implement power save for example trigger via ssh/https?

bhiga said:
AFAIK Chromecast never does #1 - it won't auto-connect to any AP unless it's already set up.
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Since the serial number is easily accessible on the unit itself and its box, that could be an easy-to-get password, and the 4-character alphanumeric ID shown on the TV could be a secondary confirmation for Setup, not just a convenient way to make sure you're connected to the correct Chromecast (does Google really think/hope there will be that many Chromecasts out there being set up at the same time?).
Click to expand...
Click to collapse
Thats why I think whenever it can't find an AP to connect to it shouldn't take anything for it to generate a random password (changes everytime) that can be used until setup is complete...
As for HTTP access i it is not connected to an AP there really is no HTTP available until you have connected to it in some way.
I would be happy if Google allowed us some config tools but I don't think they are all that interested in us having control over the unit for DRM purposes.
The devs at Plex have even said that Google will not allow them to implement sending to CCast as part of their Local PlexWeb (Plex.TV is fine though)
This suggests they really do not want anything they can't approve or any usage that could expose how the device is talked to being left open to the public.
I guess they figure that if we can see how linkage and communication is done we will reverse engineer it to play and do things they don't want us doing or bypassing DRM schemes as they currently work.

bhiga said:
Agree on #2 though. Actually, both yours and mathorv's suggestion could be used in conjunction - Chromecast should use WEP security* on its setup AP and turning on the setup AP could be set to require human interaction.
*mainly for compatibility with clients/routers that don't support WPA or better - yes, they still exist - crackable, yes, but still better than completely open as it is now.
Click to expand...
Click to collapse
WEP is broken for over 10 years now! No sane human being is using it. Cracking WEP is extremely fast and easy. WEP is a false protection, illlusion of security. Using WEP is BLASHEMY.

mathorv said:
WEP is broken for over 10 years now! No sane human being is using it. Cracking WEP is extremely fast and easy. WEP is a false protection, illlusion of security. Using WEP is BLASHEMY.
Click to expand...
Click to collapse
Obviously you feel strongly about WEP.
I'm not going to argue that, because you are right that WEP is easily broken. WPA can be broken too, but with more effort.
That said, WEP is an illusion of security only if you expect it to be unbreakable, just like passwords and everything else.
Seat belts won't save you in every accident, but if you don't expect them to, they are still helpful in the event of an accident.
Now if you're driving recklessly because you think seat belts and air bags will save you, then yes it is a false sense of security and you're foolish to take extra risks.
But for the Chromecast setup AP that is temporary by nature, are you suggesting that it is better to not use any security at all, just as it is right now?

You know what I always say.....
"Just because you are Diagnosed Paranoid doesn't mean people aren't out to get you!"
LOL
This is the second conversation regarding CCast vulnerability and so far all we have identified as a REAL security concern is that someone could set up the CCast to connect to some WiFi other than yours which would lead to the grand total tragedy that they could send content to your TV.
The other conversation was in regards to the Rooted ROM having SSH and Telnet installed that could be used to hack your Router Password provided you had already hacked the router password to make the connection to the CCast in the first place to use those tools to get what you already have!
Here is something folks should take into account....NOTHING IS SECURE EVER!
Even the Servers in Iran's Nuke Plant that had no connection to the outside world whatsoever were compromised, Hacked and attacked by Stuxnet!
There is no security ever the only thing you can ever really do is make the hack hard enough and as time consuming as possible that they will move onto someone else's system to pry into their Word Docs and that private folder you keep your IFriends profile pictures in instead. LOL
Yes WEP can be hacked. Imagine how much fun someone will have after they set up your CCast to use their network and try to send content to a TV never knowing if you actually noticed it or not because they can't see your TV.
It's still a damn site better than leaving an Open WiFi AP on the CCast until setup which takes no hacking skill at all to crack.
The way I look at it if the person is smart enough to hack they are also smart enough to know there is no point in hacking a CCast...Not when there is a WiFi router that gets them a hell of a lot more personal info and much more access than just displaying content to your TV.

Asphyx said:
This is the second conversation regarding CCast vulnerability and so far all we have identified as a REAL security concern is that someone could set up the CCast to connect to some WiFi other than yours which would lead to the grand total tragedy that they could send content to your TV.
Click to expand...
Click to collapse
While this would be a great dorm prank, at least with the current functionality of Chromecast, that's all they get to do... turn on the TV and send whatever video to the TV they want, which would be quite scary/annoying. Think of the beginning of Back to the Future Part II where all the screens in the house turn on with Marty's boss telling him he's fired.
Asphyx said:
The other conversation was in regards to the Rooted ROM having SSH and Telnet installed that could be used to hack your Router Password provided you had already hacked the router password to make the connection to the CCast in the first place to use those tools to get what you already have!
Click to expand...
Click to collapse
Actually I think the scenario @mathorv described is a little different and easy to exploit.
Chromecast is in setup mode and broadcasting an open AP
Attacker connects to the open AP
Attacker connects to Web Panel and enables ADB/Telnet/SSH (because web panel currently does not require authentication, Team Eureka said authentication is coming)
Attacker connects to Chromecast via ADB, Telnet, or SSH and gets access to the root filesystem, where they can see the cleartext password and SSID of the AP that Chromecast normally connects to (because password is stored in supplicant config file which is accessible)
So the attacker does not need anything more than to see the Chromecastnnnn AP.
Sadly, the WPA authentication seems to be stored the same way on phones/tablets as well. The only thing that shields phones/tablets from the same type of attack is not all of them have root and they usually aren't accessible from the network. Hence, with root comes extra responsibility, which is why root often is made difficult.
Asphyx said:
Here is something folks should take into account....NOTHING IS SECURE EVER!
Click to expand...
Click to collapse
Yup. What we commonly call "security" is really just a deterrent. It increases the effort and the hope is that the attacker will pick an easier target. It's why we put locks on doors when it's often relatively simple to bypass them.

bhiga said:
Chromecast is in setup mode and broadcasting an open AP
Attacker connects to the open AP
Attacker connects to Web Panel and enables ADB/Telnet/SSH (because web panel currently does not require authentication, Team Eureka said authentication is coming)
Attacker connects to Chromecast via ADB, Telnet, or SSH and gets access to the root filesystem, where they can see the cleartext password and SSID of the AP that Chromecast normally connects to (because password is stored in supplicant config file which is accessible)
So the attacker does not need anything more than to see the Chromecastnnnn AP.
Click to expand...
Click to collapse
Except for the fact that if it is not connected to the router then that means the router is unavailable, and or the Password saved in cleartext isn't working. If it was it would be connected and not in Setup mode.
Thats the point I was trying to get across there....
Sure you could find passwords to APs the CCast was connected to...
But if it isn't connected at the time of the hack then those APs are not available if they were you would not be able to connect to the CCast.
And if they are available then anything saved in the CCast is worthless since the CCast couldn't use it to connect either.
And I told him how to plug that hole far better than via the ROM....
Turn on Mac Filtering so not only do you need the password but need to clone a MAC address as well.
And all of this to get at what?
Your last will and testament and some compromising Pictures?
If you make it difficult enough that the payoff isn't worth the effort they will move on....

Asphyx said:
Except for the fact that if it is not connected to the router then that means the router is unavailable, and or the Password saved in cleartext isn't working. If it was it would be connected and not in Setup mode.
Click to expand...
Click to collapse
Ahh, I see your point now.
At least for me, sometimes Chromecast will "miss" the connection shortly after boot, so the setup AP is available for a few minutes after a reboot. To exploit that, someone would need to be sitting and listening for it to pop up - not a "juicy" target, but still possible. People do strange things "just because they can" - at least that's what YouTube teaches me.
As you say, MAC filtering provides an additional deterrent level. Unfortunately the target customer is probably not sophisticated enough to do that. I'm not sure all ISP-provided devices (I avoid integrated hardware that I can't configure) allows setting MAC restrictions though.

Asphyx said:
But if it isn't connected at the time of the hack then those APs are not available if they were you would not be able to connect to the CCast.
And if they are available then anything saved in the CCast is worthless since the CCast couldn't use it to connect either.
Click to expand...
Click to collapse
Well, in theory, you could connect to the CCast when it is in unprotected AP mode, enable ssh, and write a shell script which gets started every boot and sends out the saved wifi password somewhere to the internet. Then, when the CCast owner sets up is wifi, and sometimes later reboots, the wifi passwords will be sent out.
But... since there are probably only a few thousand rooted Chromecasts, and the time window in which to push the script to the Chromecast is so narrow, I doubt anyone would spend any time to try this.

bhiga said:
Unfortunately the target customer is probably not sophisticated enough to do that. I'm not sure all ISP-provided devices (I avoid integrated hardware that I can't configure) allows setting MAC restrictions though.
Click to expand...
Click to collapse
I'm sure thats true but if your not sophisticated enough to control your own Network or let an ISP do it all for you the least of your issues are what might happen in the odd chance CCast is disconnected or in the 30 seconds before it connects to an AP during Bootup. Locking up the holes in a CCast sure isn't going to help you much LOL
frantisek.nesveda said:
Well, in theory, you could connect to the CCast when it is in unprotected AP mode, enable ssh, and write a shell script which gets started every boot and sends out the saved wifi password somewhere to the internet. Then, when the CCast owner sets up is wifi, and sometimes later reboots, the wifi passwords will be sent out.
Click to expand...
Click to collapse
Well in theory you could have it do location checks with Google and map location, SSID and Password of every AP it ever connects to...
Like I said to what end would someone do that?
What is the PAYOFF in the end?
I could understand it if your living next to Bill Gates and wanted to steal banking info....
The Average Joe doesn't have anything worth seeing that would make someone go through all of that especially when they could get it much easier by just sniffing WiFi packets and finding the same data and decrypting it.
They could sit there all day and hack the Router but they have such a small window to work with on an unconnected CCast either because they have to catch it rebooting or catch it in a location that it isn't setup for and unless you have written a program to do all of that without Human Intervention you still got a snowballs chance in hell of getting any worthwhile information...
Security only happens when there are multiple layers of protection that make it so difficult to breach that they won't bother unless the payoff is worth it.
Someone really has to hate you in order to go through all that so some of the best security practices you can implement is don't be an AZZ and no one will have it out for you enough to want to get something on you via a Hack! LOL
(Not suggesting anyone in this discussion is just saying in General LOL)

Asphyx said:
Like I said to what end would someone do that?
Click to expand...
Click to collapse
Well, would you give me your WiFi password?
I can think of a few things you could do with access to someone's WiFi... Free internet, torrenting on someone else's responsibility, or just messing with someone.
Asphyx said:
I could understand it if your living next to Bill Gates and wanted to steal banking info...
Click to expand...
Click to collapse
The real question here is... Would Bill Gates buy a Google Chromecast? :laugh:

frantisek.nesveda said:
Well, would you give me your WiFi password?
I can think of a few things you could do with access to someone's WiFi... Free internet, torrenting on someone else's responsibility, or just messing with someone.
The real question here is... Would Bill Gates buy a Google Chromecast? :laugh:
Click to expand...
Click to collapse
Sure! I could very easily give you my router password and you would still not be able to do anything you mentioned until you figured out a MAC address one of my networked devices actually uses.
And to my other point...Is Free Internet or messing with someone really worth the risk of going to a Federal Pen for hacking?
As for what Bill Gates has I wonder if he is even running Windows 8 cause I don't know anyone who has it that likes it! LOL

Asphyx said:
Sure! I could very easily give you my router password and you would still not be able to do anything you mentioned until you figured out a MAC address one of my networked devices actually uses.
Click to expand...
Click to collapse
Good point.
I guess that if we really wanted, we could play this cat and mouse game for quite some time, but the outcome would be that if you really care about security, you can make your network secure enough. But that would be just spamming the thread.

frantisek.nesveda said:
but the outcome would be that if you really care about security, you can make your network secure enough. But that would be just spamming the thread.
Click to expand...
Click to collapse
Actually I think what I was trying to say is that no matter how much you care and try to be secure...
If they want you they WILL get you and they don't need nor would they do it through your CCast when there are far better tried and true methods to attack a wireless router directly that doesn't require LUCK of a device not connecting or the timing of catching it while it is booting up in order to catch the weakness.
Any security hole that results from the CCast will likely never amount to anything more than the Prankish "Look what dirtyPorn I put on your screen"
If they want dirt they will go to the router which is always up and doesn't require some act of god or electronics to happen.
You secure your router the best you can and if that isn't enough then you need to keep your wireless off until you need it to be TRULY secure....
And even then there is nothing to stop them from tapping into the pole where your Internet connection comes in and getting you that way!
Security is nothing more than an illusion and a deterrent...Truth is your never secure no matter how much you worry which says to me...Worrying is pointless. Unless you have enemies that really want to get you...and if thats the case all the security in the world won't stop them!

Asphyx said:
Actually I think what I was trying to say is that no matter how much you care and try to be secure...
If they want you they WILL get you and they don't need nor would they do it through your CCast when there are far better tried and true methods to attack a wireless router directly that doesn't require LUCK of a device not connecting or the timing of catching it while it is booting up in order to catch the weakness.
Any security hole that results from the CCast will likely never amount to anything more than the Prankish "Look what dirtyPorn I put on your screen"
If they want dirt they will go to the router which is always up and doesn't require some act of god or electronics to happen.
You secure your router the best you can and if that isn't enough then you need to keep your wireless off until you need it to be TRULY secure....
And even then there is nothing to stop them from tapping into the pole where your Internet connection comes in and getting you that way!
Security is nothing more than an illusion and a deterrent...Truth is your never secure no matter how much you worry which says to me...Worrying is pointless. Unless you have enemies that really want to get you...and if thats the case all the security in the world won't stop them!
Click to expand...
Click to collapse
MAC access list = joke, blacklist is also a illusion changing MAC address(spoofing MAC) is extremely easy on any platform.
In case of whitelist Attacker will look into it just a bit for a longer, to know list of allowed devices.
At home you will have to whitelist every new device...
In corporate environment it will take you more time also WPA2-PSK is not suitable for serous corporate use.
About absolute security.
Security is relative term. Its just like healthy life style, it will not make you immune to diseases, it will make you generally healthier, less likely to get ill.

Wired warns of Chromecast takeover vulnerability

"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!