Question for an owner, when you browse the web using the model s webbrowser, does it connect through the tesla VPN service, then to the website (car->3g->tesla mothership->website), or does it connect directly from car->3g->website? (browsing here Display My Hostname - Find your current public hostname would tell us)
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Successful connection on the Model S internal Ethernet network
- Thread starter nlc
- Start date
-
- Tags
- Model S User Interface
HankLloydRight
No Roads
I wonder if it has hardcoded DNS servers...
I think I'll sniff the WiFi traffic and see if I see any port 53 queries to my internal DNS boxen, or see if it appears that the VPN connection back to the Tesla mothership appears to be the path for the queries....
HankLloydRight
No Roads
Why do people keep bringing up a VPN? Is there *any* evidence that tesla uses a VPN for telemetry, web browsing, DNS, or any other traffic?
Given the instability of the 3G connection, I just don't see it a feasible option to having a VPN service startup up and connect every-time the car gains or looses cell or wifi service.
They don't need a VPN to do anything they are currently doing, they can still have encrypted conversations over the internet without a VPN adding to the complexity.
Given the instability of the 3G connection, I just don't see it a feasible option to having a VPN service startup up and connect every-time the car gains or looses cell or wifi service.
They don't need a VPN to do anything they are currently doing, they can still have encrypted conversations over the internet without a VPN adding to the complexity.
The VPN isn't actually in question. We know the VPN exists. Just sniff wifi traffic and you'll see the openvpn connection. OpenVPN can actually be pretty stable over any connection since it doesn't require much state and works over UDP.
Also, while sniffing the wifi traffic I spotted leaked DNS requests to internal IPs, presumably on the VPN, when that connection must have broken or whatever and caused the packets to leak towards the default gateway.
Code:
23:03:29.059668 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 69
23:03:34.230698 IP 192.168.5.73.51238 > 209.11.133.22.1194: UDP, length 69
23:03:34.320183 IP 209.11.133.22.1194 > 192.168.5.73.51238: UDP, length 69
23:03:34.801182 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 117
23:03:34.805278 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 117
23:03:34.807899 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 117
23:03:34.899864 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 197
23:03:34.904669 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 197
23:03:34.904687 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 197
23:03:34.909249 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 117
23:03:34.913770 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 197
23:03:34.916917 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 197
23:03:35.051622 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 117
23:03:35.061224 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 101
23:03:35.065975 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 725
23:03:35.216846 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 1253
23:03:35.217046 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 917
23:03:35.217069 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 181
23:03:35.217078 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 101
23:03:35.225030 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 101
23:03:35.227849 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 101
23:03:35.233614 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 101
23:03:35.236368 IP 192.168.5.59.56919 > 209.11.133.22.1194: UDP, length 101
23:03:35.334841 IP 209.11.133.22.1194 > 192.168.5.59.56919: UDP, length 101What if you put a NAT layer between the car IP range and another private network? Could you fool the browser into navigating there directly?
Now that you mention it, I seem to recall that someone else who had sniffed the traffic previously had noticed similar while also seeing traffic passing over the already-established VPN tunnel... so it may not be just if/when the VPN connection flaps. Interesting.
And HankLloydRight - Not only has the VPN been known about, as wk057 demonstrates, but the endpoint that it's established with actually has a hostname of "mothership.teslamotors.com". :biggrin:
I can only hope that host is sitting in a datacenter with as cool a name as the one SpaceX operates ("Cyberdyne Systems", of course)
I think the issue is that the hostname would have to resolve via external public DNS, which is assumedly what the mothership ultimately allows resolution for, in addition to the private car management hosts they run.
You used to be able to browse internal websites via IP address I believe, as I did that once to display a page on my home intranet on the console. It no longer seems to work...
Wow, maybe they masked out all the private IP address ranges (ie. 192.168.x.y, 10.x.y.z, etc). I suppose you could use a public IP in a NAT layer just for fun... but then, I'm not actually sure what we're trying to accomplish anymore.
They are using some kind of authentication scheme that requires a wireless connection back to Tesla to confirm that access is permitted.
chickensevil
Active Member
everyone interested in getting to know more about the internals of the Model S, see Disharmony | Unix stuff
dirkhh
Middle-aged Member
Sadly that is pretty much exactly how most companies respond to security concerns brought to them. Somehow I hoped that Tesla would do better, guess I was wrong.
What's the date you are going to pick? Now with the v7 rollout in full swing publishing things about v6 might not be as scary to Tesla - but then again, I can't wait to see if this still works on v7.
Maybe we can develop a better UI for it
So I just connected to my Model S and I can see the same as nlc found. The connection is 100Mbit and I used the B schematic for my own cable.
NFS
I ran a 'showmount -e' against 192.168.90.100 and there is one NFS mount: /opt/navigon
Mounting it was no problem. I chose 192.168.90.254 as my IP-address.
A simple "ls -al" in the NFS mount:
The VERSION file contained some information which might be interesting:
So Yzadik build this navigation ext3 filesystem for the EU about 1 year ago
It's probably a loopback device on the center screen, but I can't be sure.
SSH
Afterwards I tried to SSH in, but all the combinations I could think of this time didn't work, so I gave up the SSH for now.
But I did do a quick telnet to get some version information:
So it seems to be Ubuntu which is running on there? Well, at least a modified version of Ubuntu.
192.168.90.100 and 192.168.90.101 are both running the same version of OpenSSH.
DNS
On 192.168.90.100 there is also a DNS server running on port 53. It's a recursive nameserver which is open for me:
I also queried to find out which DNS server it's running:
So that seems to be dnsmasq 2.58
That's weird. Since Ubuntu 10.04 (previous LTS) has dnsmasq 2.52 and the current one, 12.04 has 2.59. So this has to be a homebrew version of Ubuntu OR a non-LTS version of Ubuntu.
HTTP
So 192.168.90.100 is running a webserver which serves one file only: nowplaying.png:
We can assume that 192.168.90.101 (the dashboard) downloads this file to display the same image on the dashboard. I tried a couple of HTTP urls, but they all failed.
mini_httpd 1.19 seems pretty old though! 19 dec 2003? But the website says it's the latest version: mini_httpd
I still would have gone for something like nginx or lighttpd, but hey, it's up to them. It's also available as a package on Ubuntu: Ubuntu – Details of package mini-httpd in precise
X11 / XDMCP
Using remmina in Ubuntu I was able to set up a X11 connection on port 6000, but it only showed me a blank screen, nothing else.
This was on both .100 and .101. Could be that I did something wrong.
IPv6
I tried to connect to the internal IP's using IPv6, but all three hosts didn't respond on the link-local address I calculated based on their mac address.
Broadcast UDP traffic
I also see all this UDP traffic. I ran tcpdump for about 2 minutes and I'll try to see what it actually contains.
I connect the ethernet cable with tesla(blow cid screen interface),sniffer the cable ,just see some boardcast info。but “ssh” "http" not found .why？ i use nmap to scan the 192.168.90.100.but not found open tcp port......please
Similar threads
