Support
Quality
Security
License
Reuse
kandi has reviewed scapy and discovered the below as its top functions. This is intended to give you an instant insight into scapy implemented functionality, and help decide if they suit your requirements.
Get all kandi verified functions for this library.
Get all kandi verified functions for this library.
Scapy: the Python-based interactive packet manipulation program & library. Supports Python 2 & Python 3.
QUESTION
Renault Zoe doesn't send SDP Request After SLAC Matching Process
Asked 2022-Feb-25 at 12:01We are trying to communicate with Renault Zoe according to DIN SPEC 70121.
We are successfully communciating with the Hyundai Kona and BMW i3 but fail to receive the SPD Request with Renault Zoe. We are passing the SLAC process with Renault Zoe but we don't recieve any UDP messages afterwards. We are sending the CM_SLAC_MATCH_CNF message as an ethernet unicast message according to DIN SPEC 70121:2014-12, 8.3.3.3.2, Table 2 (noted in Design Guide Combined Charging System V5 - Failures during SLAC - Interruption at SLAC match sequence).
Why can it be that we receive the SDP Request with Kona and i3 but fail to do so with Zoe? Has anyone experienced this behaviour before?
Sniffed SLAC messages with scapy:
(= '' means the field is filled with zeroes)
Received from Zoe:
###[ CM_SLAC_MATCH_REQ ]###
ApplicationType= 0
SecurityType= 0
MatchVariableFieldLen= 15872
\VariableField\
|###[ SLAC_varfield ]###
| EVID = ''
| EVMAC = 7c:bc:84:41:03:3b
| EVSEID = ''
| EVSEMAC = 3e:7e:f1:10:ab:3e
| RunID = '\xd3\xac;\x0f\x17-\xb7+'
| RSVD = ''
Send to Zoe:
###[ CM_SLAC_MATCH_CNF ]###
ApplicationType= 0
SecurityType= 0
MatchVariableFieldLen= 86
\VariableField\
|###[ SLAC_varfield ]###
| EVID = ''
| EVMAC = 7c:bc:84:41:03:3b
| EVSEID = ''
| EVSEMAC = 3e:7e:f1:10:ab:3e
| RunID = '\xd3\xac;\x0f\x17-\xb7+'
| RSVD = ''
| NetworkID = '$\x94\xc1\x0c\xbcO\xb5'
| Reserved = 0
| NMK = ''
ANSWER
Answered 2022-Feb-25 at 12:01The solution was to send the 2 byte field MatchVariableFieldLen
in the CM_SLAC_MATCH_CNF
message in little-endian byte order.
From the message that was send by the Renault Zoe, we can see that Zoe sends the CM_SLAC_MATCH_REQ
with the MatchVariableFieldLen
as 0x3e 0x00
(15872 == 0x3e00
). Since this field should be 0x3e
according to DIN SPEC 2014-12, we can see the byte order of this field is little-endian. So a reasonable guess was that it expects this field in little-endian in the response message.
Result: We received the SDP request and the messages after that.
The HomePlug GP Specification does not specify the endianness of this field in clause 11.5.58. But looking at the example in Table 11-316, one would say its big-endian.
It's clear that Zoe interpret this field as little-endian and doesn't accept 0x00 0x56
but accepts 0x56 0x00
.
Kona and i3 either don't complain about this field and accept the message or Zoe's intepreting is false. Either way the cause of the problem has been identified.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
No vulnerabilities reported
Save this library and start creating your kit
Save this library and start creating your kit
Open Weaver – Develop Applications Faster with Open Source