Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Successful connection on the Model S internal Ethernet network

This site may earn commission on affiliate links.
@chris that would require replacing the application currently running on the touchscreen/cluster with a custom designed one, which would be a challenge if the filesystem is static/readonly like I've been led to believe.

As for warranties, isn't their a clause in most of them which only voids the particular warranty, in this case, on the touchscreen/cluster, if you FUBAR them. Rather than the whole car, that is.

Haha I would not want to remove any warranty, so I am glad we have a test dummy to do this for us!
 
@nlc
If you're taking requests, I'm most curious about these:
VehiclePowerStatus
VehicleVolatile2
Vehicle
VehicleStateBasics
VehicleIndicators
ParrotInfo
EVRecentWHPM
EVTripData
PowerState
PowerRequests
ParrotPowerState

- - - Updated - - -

Total shot in the dark but by any chance does this number correspond to the hex value of your vehicle_id entry of the "vehicles" REST method for your car?
 
@nlc
If you're taking requests, I'm most curious about these:

The VehiclePowerStatus frame looks like this (I replaced an hexa code maybe personal by 1/2/3/4/5/6/7/8) :

PHP:
17:40:57.938423 IP 192.168.90.100.35008 > 192.168.90.255.4031: UDP, length 204
    0x0000:  4500 00e8 0000 4000 4011 0351 c0a8 5a64  E.....@[email protected]
    0x0010:  c0a8 5aff 88c0 0fbf 00d4 4c12 0000 0000  ..Z.......L.....
    0x0020:  0000 000c 0000 000a 0000 0000 2400 5600  ............$.V.
    0x0030:  6500 6800 6900 6300 6c00 6500 5000 6f00  e.h.i.c.l.e.P.o.
    0x0040:  7700 6500 7200 5300 7400 6100 7400 7500  w.e.r.S.t.a.t.u.
    0x0050:  7300 0000 0a00 0000 0010 0031 0032 0033  s..........1.2.3
    0x0060:  0034 0035 0036 0037 0038 0000 0006 0040  .4.5.6.7.8.....@
    0x0070:  6786 7380 0000 0000 0000 0001 ffff ffff  g.s.............
    0x0080:  0000 0006 0000 0000 0000 0000 0000 0000  ................
    0x0090:  0600 0000 0000 0000 0000 0000 0006 0000  ................
    0x00a0:  0000 0000 0000 0000 0000 0600 0000 0000  ................
    0x00b0:  0000 0000 0000 0006 0040 2e00 0000 0000  .........@......
    0x00c0:  0000 0000 0600 0000 0000 0000 0000 0000  ................
    0x00d0:  0006 0000 0000 0000 0000 0000 0000 0600  ................
    0x00e0:  4036 0000 0000 0000

I wrote my UDP capture software, this evening I will try to see if some value are changing when changing the power consumption of the car.
Don't understand why there are 0x00 in string, maybe string are unicode encoded ?

Total shot in the dark but by any chance does this number correspond to the hex value of your vehicle_id entry of the "vehicles" REST method for your car?

No it's not this ID. This value seems to be the same for all frame group (on the same UDP port).
 
Just an FYI, but you might have already figured it out. The second word seems to be the length of the message with the last bit being zero.

For Vehicle Power Status, the second word is 0x00e8, shift one bit to the right and you get 0x0074 which is 116 (the length of the message).

For the Vehicle Indicators, the second word is 0x04ce, which becomes 615.
 
I expect they're using UTF-16, but no idea why. Is that the standard? I thought UTF-8 was a lot more common. I know Microsoft use UTF-16 frequently. I guess one advantage (maybe from a performance or message layout perspective) is messages are a consistent size.

Byte before VehiclePowerStatus is definitely length of that string (UTF-16 size, 36 bytes or 0x24.)
 
Last edited:
So, I don't have the time yet, but I'll see if I can get into the Linux systems running there, I wonder if there is a NFS mount open or maybe can brute-force myself into the SSH server running there.

P.S.: I'm wondering how many Tesla people are reading this thread... :)
 
Just an FYI, but you might have already figured it out. The second word seems to be the length of the message with the last bit being zero.

For Vehicle Power Status, the second word is 0x00e8, shift one bit to the right and you get 0x0074 which is 116 (the length of the message).

For the Vehicle Indicators, the second word is 0x04ce, which becomes 615.

14 first Word (28 first byte), are IP header (20 byte) + UDP header (8 bytes). In fact useful data begin at offset 0x001C :smile:

- - - Updated - - -

do you see any traffic when you press the sterring wheel buttons

For now difficult to see, there is a lot of trafic even when doing nothing (frames received at >1000Hz rate). Need to filter on some specific UDP port to see if something happen when doing something special in the car.

- - - Updated - - -

I expect they're using UTF-16, but no idea why. Is that the standard? I thought UTF-8 was a lot more common. I know Microsoft use UTF-16 frequently. I guess one advantage (maybe from a performance or message layout perspective) is messages are a consistent size.
Maybe to be 16 bits multiple, yes

Byte before VehiclePowerStatus is definitely length of that string (UTF-16 size, 36 bytes or 0x24.)

You are right, it works for all other frame :smile:

- - - Updated - - -

it also work for the hexadecimal string, the word just before give the size of that string
 
Now the real trick is once your in, unlock all 40kWh models to 60.

Haha, yeah, that's the funny story we were having an argument over morals/ethics about this on another forum.

Basically a thermal imaging company, Flir, released a set of cameras - Flir E4 through Flir E8. Flir E4 costs around $1,000 USD, Flir E8 costs close to $6,000. Main difference is resolution: E4 is a poxy 80x60 limiting its application, but E8 is a full 320x240 which is good for electronic engineering.

Do you know what the difference between the E4 and E8 is? turns out... a configuration file, on the camera. Physically for 5000 dollars you're paying for some different characters. Some clever guys basically figured out how to convert E4 into E8, making it a lot more useful.

Are you stealing $5k from FLIR by applying this modification?

Moral dilemma - since technically it's software you're modifying and it's licenced, you've broken the EULA... but it's not REALLY that much software, it's basically telling the imaging processor (an FPGA) whether to cut image at 80x60 or 320x240... so it's kinda stretching what you'd call a software licence.

...

So, by unlocking 40kWh capacity into 60kWh, aren't you stealing $10k from Tesla?

Well, in the same case like Flir, you're already paying for all that capacity. All the battery hardware is there. So you're just unlocking what was already sold to you.

So there's no problem right?

Well, you're also not paying for the R&D behind the 60kWh pack which was "licenced" to you at 40kWh with the understanding should you wish to use this, that you would pay for it.

So there's a moral/ethical dilemma here.

Same thing goes for tuning cars; people figured out how to unlock ECUs and gain extra horses, are they stealing the next model up? No, not really, but the car manufacturer would argue they are.

In my opinion you should be free to do whatever you like with what has been sold to you. It is yours to play with however you wish.
 
Haha, yeah, that's the funny story we were having an argument over morals/ethics about this on another forum.

Basically a thermal imaging company, Flir, released a set of cameras - Flir E4 through Flir E8. Flir E4 costs around $1,000 USD, Flir E8 costs close to $6,000. Main difference is resolution: E4 is a poxy 80x60 limiting its application, but E8 is a full 320x240 which is good for electronic engineering.

Do you know what the difference between the E4 and E8 is? turns out... a configuration file, on the camera. Physically for 5000 dollars you're paying for some different characters. Some clever guys basically figured out how to convert E4 into E8, making it a lot more useful.

Are you stealing $5k from FLIR by applying this modification?

Moral dilemma - since technically it's software you're modifying and it's licenced, you've broken the EULA... but it's not REALLY that much software, it's basically telling the imaging processor (an FPGA) whether to cut image at 80x60 or 320x240... so it's kinda stretching what you'd call a software licence.

...

So, by unlocking 40kWh capacity into 60kWh, aren't you stealing $10k from Tesla?

Well, in the same case like Flir, you're already paying for all that capacity. All the battery hardware is there. So you're just unlocking what was already sold to you.

So there's no problem right?

Well, you're also not paying for the R&D behind the 60kWh pack which was "licenced" to you at 40kWh with the understanding should you wish to use this, that you would pay for it.

So there's a moral/ethical dilemma here.

Same thing goes for tuning cars; people figured out how to unlock ECUs and gain extra horses, are they stealing the next model up? No, not really, but the car manufacturer would argue they are.

In my opinion you should be free to do whatever you like with what has been sold to you. It is yours to play with however you wish.

Ha. Yeah. Tell that to Apple. Nowadays the hardware might be yours but the firmware is "licensed".

If it's anything like Apple/iOS/iPhone: "In the US, jailbreaking is not currently illegal. Unlocking, however, is. Jailbreaking will void any warranty, forfeit any right to support, and could end up bricking your phone." Dunno if those statements are accurate.

But seriously though. This reminds me of unlocking Intel CPU multipliers. Is it illegal? Not to my knowledge. It does void your warranty though.
 
@nlc, which pins on the connector do you have wired to pins 1,2,3,6? If I look at the connector, one side has a clip and the opposite side has a red plastic piece on it. If I number the pins like this:

Clip side

A B

C D

Red side


Are "A and B" a pair and "C and D" a pair? Or are the pairs "A and C" and "B and D"? I'm sure I could figure this out through process of elimination, but since you've already figured it out, easier to ask. Which pair is tx and which is rx?
 
The pinout seems to be explained in post #33. It appears the Green/Green-white pair are on your pins C/D and the Orange/Orange-white on pins A/B (clip side). Standard pins to a straight thought RJ-45 (568A) are Green-White(1), Green(2), Orange-White(3) & Orange(6). Ethernet cables can be wired either as 568A or 568B - it doesn't matter what is used as long as the same standard is used on both ends for straight through cables. In this case one end is cut off and we don't know what the RJ45 end is. But the pairing seems to be A/B & C/D
cat5_tia_568ab.jpg
 
tom66
Having done a bit of reverse work in the automotive ECU field, I have to disagree about changing calibration data being stealing.
Courts have ruled that calibration data is not "code" and thus not protected by software licenses or other similar type protections.
There are two things, however, that I did find more than worrying. First, people would routinely change calibration data to consume some of the manufacturer provided protections (that let the car reach the end of the warranty period), do damage to the engine or dive line then return to stock calibrations to bring the car in for warranty work. Dealers make money on warranty so they look the other direction. This, to me, is stealing.

Second, pulling an ECU's calibration space leaves you with a bunch of ones and zeros. Some compilers/operating systems provide table headers at the front of table data (thinking Mazda here) where they list the size of each axis along with some other useful data at the top of map data. Most do not. While it is possible to hack around and find useful changes, most all "tuning" is done using factory calibration space definition files call A2Ls or DAMOS files. Manufacturers do not let these out the door so, if you have access to one or more, you are by definition using stolen material to make money at the manufacturer's expense.

In short, although I do not agree on your specific point when it comes to tuners, I do agree that the whole industry is based on theft which is why I moved on. It is no way to live.

WRT MS, Tesla should provide full diagnostic software similar to PWIS, MB Star Diagnositcs, etc. I believe other large OEMs are compelled to do so by law. Heck, even Ferrari provide documentation for their cars and you can purchase an SD tool if you are so inclined. These OEMs also belong to a profession association where they publish their proprietary interface specifications such that third parties can build diagnostic tools. Bavarian Technic and AutoLogic come to mind.

I understand Tesla's desire to protect their technology but owners do have a right to understand and work on the car they have purchased if they choose. So far Tesla's service has been so far above the rest that Tesla can delay the availability of such tools. They understand that there is only one source for service and any screw up in overall management will play havoc with customers writing to local and state legislatures. I think this is a good bit of the reason behind Tesla's over the top approach to service (in addition to it being a good business decision).

Lastly, will some use information in this thread for theft? Maybe but most will only use it to satisfy curiosity and the desire to learn which, for me, more than offsets any risk of theft.
 
Don't understand why there are 0x00 in string, maybe string are unicode encoded ?
I was assuming UTF-16, yes.

- - - Updated - - -

The second word seems to be the length of the message with the last bit being zero.

For Vehicle Power Status, the second word is 0x00e8, shift one bit to the right and you get 0x0074 which is 116 (the length of the message).
Looking at post 43, the 0x00e8 in the 2nd word is exactly the length of the message he quoted. No shifting required.
 
And 0x4500 is some kind of consistent magicnum.

space of 8 bytes between message name and hidden hex ID? All zeros, except at 4th byte, it is 0xa0, for both messages. Maybe some kind of message flags, for example 0xa0 = not compressed(?) just a guess.
 
Last edited: