Closed brandonros closed 3 years ago
That payload type (0xf010) falls into the "reserved for manufacturer-specific use" section of the specification, so it's not implemented by this client. With that said, I suppose it might be useful for the client to return a generic DoIP message object with at least the body and length extracted. In this case, the length is 56 bytes and apparently has 12 bytes of header followed by 44 bytes of ASCII. Or, more likely given the padding bytes, it's 3 distinct fixed width ASCII fields. Beyond inspection though, you'd need information from Mercedes to know exactly the details of the protocol. The primary purpose of this package is UDS which is (mostly) standard.
Also somewhat interesting that it's not using the standard port for DoIP, but vendors seem to do their own thing in that regard which is why I left it as an option in the client package.
I will post back here with some progress I made.
When I connect the OBD to Ethernet cord to a normal Ethernet adapter on a computer, should I manually assign an IP/gateway or do cars typically support DHCP?
If you're going in through the OBD2 port (SAE J1962), you do need to contend with the line activation signalling. There's two distinct pinouts which you need to differentiate by looking at Pin 8's resistance, and you need to apply voltage to Pin 8 to enable the ethernet transcievers on the DoIP edge gateway. I'm assuming you've already taken care of that though.
As I recall, the UDS spec doesn't explicitly require DHCP - it merely requires that any DoIP entity use the DHCP address if one is offered. Since you're going in through the OBD interface, I would expect an address to be offered. If it's not, just look at Wireshark and hunt around for the mandatory broadcast messages to get the subnet. Then pick an unused IP.
I'm using a BMW E-NET cable which oddly enough works for Mercedes DoIP (despite BMW not actually being ISO13400/DoIP, it's actually called HSFZ I believe)
So... some weird stuff to report. Not quite there, maybe you can help. When I connect the J1962 -> ENET cable (basically RJ45 with the resistor on pin whatever to make it "DoIP"), I do actually get a DHCP lease on Mac but not on Linux (udhcpc with Alpine Linux...). It seems to be 169.254.xx.xx, which is what I'd expect. However, it does not define a gateway which makes things kind of hard?
Wiresharking around helped me figure out that my head unit (HU55) is DoIP and at 169.254.2.48 or 169.254.123.17 (I believe it ARPs as a Panasonic hostname or something?)
On top of the already 0xf010 "reserved for manufacturer-specific use" command listed originally above, I also came across "DoIP ON" (02 fd f0 80 00 00 00 02 03 00
). Is this any more common or still manufacture specific?
What would you recommend I do? I feel this is the hard part (broadcast, activation, announcements, etc.)
I have this DoIP vehicle announcement message from Wireshark on a sniff I did, but it comes in as malformed?
01 fe 00 04 00 00 00 19 30 31 32 33 34 35 36 37
38 39 41 42 43 44 45 46 30 20 01 58 52 8a 9d 73
bf
How can I make all devices in the 169.254.xxx.xxx namespace announce themself? ARP? Some kind of special MB DoIP ON command? What have you seen in your experience?
Mac OS X might automatically be assigning me 169.254.xxx.xxx addresses because DHCP fails just like Linux, which would make more sense... I just didn't know it did that automatically.
I'd recommend updating https://github.com/jacobschaer/python-doipclient/commit/a942390a1fe3908f202a52651d90c287dac1c1f0#diff-5c0ffe9b2dab4548e4f94fef709437cad882767657dec317d7e162c1c4a94701R10 to include something about which one is most popular (like which one is used by Mercedes/VAG/BMW)
Also, once we figure out how to "initialize" Mercedes-Benz/Daimler DoIP settings, we'll document it together and add it here. :)
169.254.xxx.xxx is the IPv4 Link-Local address block https://en.wikipedia.org/wiki/Link-local_address. Windows will for sure do it, OSX doesn't surprise me, and Linux should, though sometimes you need to specifically ask for "link local". Just means there was no DHCP server found.
What I've seen, and what's normally required, is that on powerup all the ECU's will send out ARP announcements and start asking for each other's MAC addresses via ARP as well. If they don't respond to an ARP request (your OS will generate one if you try to connect like with ping), then for all intents and purposes the IP is available. All the ECU's should identify themselves over DoIP by broadcasting on powerup, but you can request them to again by broadcasting a "Vehicle identification request message" with protocol version 0xff. I didn't implement this, but if it proves useful it's not hard to add to the library.
The choice of network is completely arbitrary - sometimes it's some class C network with all hardcoded IP's. Though the specification does suggest Local-Link if there's not going to be a DHCP server.
You probably don't need to worry about a default gateway address. I would probably try using the library to connect to one of those DoIP entities you found and see what you get. Worst case they should just send back a DoIP NACK with a reason included.
The vehicle announcement you got was using the 2010 version (0x01) but the other messages were using the 2012 version (0x02) which is interesting. The activation message you posted is valid DoIP structure (the length and header are fine) - the only strange thing is it claims to be 25 bytes payload, but it should be either 32 or 33 bytes. I don't have the older version of the document, but perhaps we can guess:
The VIN should be: 30 31 32 33 34 35 36 37 38 39 41 42 43 44 45 46 30 The logical address would be 20 01 The EID would be 58 52 8a 9d 73 bf
EID is often the MAC address.
I had sent you an email on Sunday
Supports generic messages properly. Nothing further to do.
but you can request them to again by broadcasting a "Vehicle identification request message" with protocol version 0xff. I didn't implement this, but if it proves useful it's not hard to add to the library.
Could we work together to implement this? It sounds simple to add?
Zero clue with diagnostic message is NACKing with invalid source address when it's the same address from vehicle ID response + routing activation response.
Makes no sense to me...
By the way, MB is DoIP V1 with a non-standard routing activation request size (2 byte client logical address, 2 byte activation type, then 8 bytes of padding/reserved/OEM specific)
Any tips on why the logical address from the vehicle ID response is saying invalid target address?
I got it working. More Mercedes-Benz non-standardness for a 2018 W213 with HU55 (no DoIP at the gateway level, HU55 acts as its own gateway). The ECU responds that it's source address is 0x2001 but you actually need to talk to it on 0x3000.
I think W223 + W206 with newer EZS223/EZS206 gateway will act more proper. EZS213 seems to not properly support DoIP as one would expect (it's a gateway but doesn't support DoIP?) Only HU55.
You're welcome to create a PR that adds your script to like an examples folder or add a page to the docs describing what the correct sequence was to talk to your vehicle. The purpose of this library is to be standards compliant, so if MB isn't compliant perhaps you should fork and update as needed. The ECU being its own gateway doesn't seem unreasonable to me.
I have 223 cars here, who can help me, use enet link to him
This cable works with VCI DOIP
Does this look right to you? I have a DoIP VCI connected and open in DTS.Monaco trying to do an Ethernet activation/Broadcast.
192.168.8.1:54279 sends a UDP packet to 255.255.255.255:6818
Payload is 64 bytes long
Looks like this: