request_vehicle_identification
Closed this issue · 8 comments
when we try to connect the vehicle, we should use vehicle_identification_request to get the DoIP Node IP address and then try to bind it
but firstly we init DoIPClient(), we need input the ecu_ip_address, which is unknown param
so I suggest to make this func to be a classmethod, then we can get the euc_ip_address firstly
I think the intention was you would use await_vehicle_announcement to discover ECU's per the algorithm in the standard. How would you use vehicle identification request? Send to a broadcast?
Yes, use broadcast to request vehicle identification, I think vehicle_announcement only will happen when ECU powered on, ECU will send some frames announcement but not always, so when we want to actively connect vehicle, we need send broadcast, and get the response announcement, and get the ecu ip address
I think you could probably copy the majority of the function await_vehicle_announcement and just add the necessary transmit at the top. If you come up with something that fits your workflow, feel free to PR. This has been asked for before, it just falls under one of the areas where there doesn't seem to be universal support.
I just ran into the same problem. But why is there no universal support? It's in the standard (8.DoIP-046 APP – DoIP entity vehicle identification request message), and is a well defined feature, based on UDP broadcasts. It's even in the lib, but I'd expect that function to be a classmethod like await_vehicle_announcement
The vehicle announcements are only sent 3 times after an IP address has been issued, and in my specific usecase the cars are connected to the IP network before the software is. So this would enable iterating available devices without prior knowledge regarding the specific IP.
Awesome work! Unfortunately binding to all interfaces is just meaningful for received messages, not for sending. So when sending the broadcast, the first available interface will be used. I thought it's an easy fix, because _create_udp_socket has a parameter source_interface, but that is only being used for IPv6 and documented accordingly.
So long story short: It's not usable unless you are lucky and the first interface is the correct one.
Do you prefer to reopen this issue, or open a new one?
You can specify the broadcast address. Your OS should use the correct NIC so long as you pick the correct address. The default of 255.255.255.255 is, admittedly, rarely useful but it was in the docs and is at least guaranteed to do something regardless of setup. But I see your point we did accept an interface for the other version for subscribing to the group which was needed for Windows if I recall.
If you have something in mind though fell free to PR and/or add an issue. Seems like it should be easy for @HarshaLaxman maybe? Just one extra parameter?
Did you have any experience with IPv6 to support/test that as well?
Unfortunately my test network is IPv4 only. Do you see problems in using source_interface in IPv4 as well? It'd be easy that way, but I'm not sure if the fact that is ignored for IPv4 is useful in cases I do not see.
Sounds helpful and is an easy addition! Created the issue and threw up a quick PR