Modbus function 2B "Encapsulated Interface Transport" has encapsulated MEI type 0E "Read Device Identification". Server responce for this request has "Number Of Objects" field that is described as "Number of identification Object returned in the response (for an individual access, Number Of Objects = 1)".
If the response packet has no enough space to place all identification objects, transaction may be splitted to separate packets. In this case the field "More Follows" must be equal to FF, the field "Next Object Id" must be equal to number of first object that weren't placed into this packet. But what the field "Number of objects" must be equal to?
Modbus Application Protocol Specification has an example:
First transaction:
Request
Response
Field Name
Value
Field Name
Value
Function
2B
Function
2B
MEI Type
0E
MEI type
0E
Read Dev Id Code
01
Read Dev Id Code
01
Object Id
00
Conformity Level
01
More Follows
FF
Next Object Id
02
Number Of Objects
03
Object Id
00
Object Length
16
Object Value
"Company identification"
Object Id
01
Object Length
1C
Object Value
"Product code XXXXXX"
Second transaction:
Request
Response
Field Name
Value
Field Name
Value
Function
2B
Function
2B
MEI Type
0E
MEI type
0E
Read Dev Id Code
01
Read Dev Id Code
01
Object Id
02
Conformity Level
01
More Follows
00
Next Object Id
00
Number Of Objects
03
Object Id
02
Object Length
05
Object Value
"V2.11"
In this example both responses have "Number of object" = 3, so this field must be equal to entire number of objects for selected Read Dev Id Code. There the very bad Modbus feature goes to scene: Modbus ADU doesn't contains full packet length. When identification packet has "Number of objects" = 3, calculating of actual packet size is impossible. Specification doesn't contains any explanation of what Number of objects must be equal when MoreFollows==FF. Is it error in Modbus Application Protocol Specification?
I examined several Modbus libraries for this subject. Most libraries have not implemented Modbus Encapsulated Interface, so I found only two convient libraries.
pymodbus
https://github.com/riptideio/pymodbus/blob/dev/pymodbus/mei_message.py
Constructing responce:
Line 181
When this lib constructs device identification response it places number of objects that is actually presented in packet.
Parsing response:
Line 194
When this lib parses device identification response it reads number of object from corresponding packet field, after that reads each object until packet ended.
Qt
https://github.com/qt/qtserialbus/blob/dev/src/serialbus/qmodbusdeviceidentification.cpp
Parsing response:
Line 213
When this lib parses device identification response it reads number of objects from corresponding packet field, after that reads Number Of Object objects.
Qt has no identification response constructor.
So, we have at least two libraries that implements identification response putting actually presented number of objects.
Your opinions, what Number of objects must be equal to when More Follows == FF?
The document I referenced:
https://modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf
Related
I have an ELM327 connected to a (non-CAN) bus on an older GM vehicle. I realize I can send an OBD command (mode 09 and PID 02) by just sending the payload like "0902".
However, is it possible to send a complete frame (assuming the final checksum byte is added by the ELM327)? So if I wanted to send header 00 11 22 and then the payload 09 02, how would I do that?
Something similar was asked in this question but not really answered.
I am having trouble reading ICC data from an card. I have an AID from an issuer which is A0000007790000. So I am sending an APDU of 00A4040007A0000007790000 to select the application by its AID but I keep getting response of SWA: 62 SWB: 83. What am I missing, and how can I proceed from there.
I can only do a select PSE using 00A404000E315041592E5359532E444446303100 which is successful and I am getting a response of 6F1A840E315041592E5359532E4444463031A5088801015F2D02656E..
The Other commands like 00B2010C00 are returning that SWA SWB 6283 (Selected file invalidated) response. Any pointers will be greatly appreciated.
The AID Select Command should have additional Le byte.
APDU Command: 00A4040007 A000000779 0000 00
The problem that I had was on the device permissions, I had not realized that the device I was using to read the emv cards had no permissions to read external files, so that did not allow me to read any data from the application files in the chip card
in RFC5389 MESSAGE-INTEGRITY calculation includes itself but with dummy content
dummy content is not defined
how can MESSAGE-INTEGRITY be verified without knowing dummy content value?
why would MESSAGE-INTEGRITY calculation include itself?
is't it faster to calculate MESSAGE-INTEGRITY and equally secure if it didn't include itself?
Since the MESSAGE-INTEGRITY attribute itself is not part of the hash, you can append whatever you want for the last 20 bytes. Just replace it with the hash of all the bytes leading up to the attribute itself.
The algorithm is basically this:
Let L be the original size of the STUN message byte stream. Should be the same as the value for MESSAGE LENGTH in the STUN message header.
Append a 4 byte header onto the STUN message followed by 20 null bytes
Adjust the LENGTH field of the STUN message to account for these 24 new bytes.
Compute the HMAC/SHA1 of the first L bytes of the message (all but the 24 bytes you just appended).
replace the 20 null bytes with the 20 bytes of the computed hash
And as discussed in comments, the bytes don't have to be null bytes, they can be anything - since they aren't included in the hash computation.
There's an implementation of MESSAGE-INTEGRITY for both short-term and long-term credentials on my Github: here and here
I need to parse and decode the data field from a CAN Message.
I sent the transmitted the request and i got back the data field :
02 01 20 00 00 00 00 00
Now I have to decode it in a SWITCH, the first byte is the length(02) but how I split the whole data field in separate bytes and then take them 1 by 1 to decode?
I do not know the SWITCH protocol, but I can help you with accessing byte by byte the payload of the message you are interested in.
Lets say your message ID is 0x100 (or you have its name by database dbc, your call to define the message).
If you are working in a test environment (test node like CAPL/XML test node), you can define a testcase/function, and in it the following sequence:
message 0x100 MessageContainer;
then you wait for your message in the point where you expect the payload to be to your liking:
..
.
.
.
.
testwaitformessage(0x100,cycletimeofMessage); /*Cycletime the message has, or maximum time you expect your message to arrive*/
testGetWaitEventMsgData(MessageContainer); /*the message object MessageContainer will be filled with the content of the message catched early in testwaitformessage()*/
write("%X",MessageContainer.byte(0)); /*you access the bytes through the .byte selector field of the message object and do whatever you wish with it.*/
If you want to do the decoding in a Simulation Node, you can do it only through on events, and it is much simpler:
on message 0x100
{
write("The first byte of the captured message 0x100 is 0x%X",this.byte(0));
}
Of course, this on event procedure is working in test environments also.
While testing SIP Video call, I am getting the below the media line information in an answer for an Offered media. Is this valid media line ??
where media format number is different from the rtpmap number:
m=video 49218 RTP/AVP 109
b=TIAS:322000
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42801f; max-mbps=216000; max-fs=3600; sar=13
a=sendonly
It's not a valid session description, but for a more subtle reason than Ralf's answer. A PT (payload type) of 109 falls in the dynamic range of the RTP/AVP profile defined in RFC 3551 which applies because of the RTP/AVP in the m line. "Dynamic" means what it says: RTP/AVP defines a whole bunch of standard codecs - PCM mu-law, G.729, and so on - and also allows for you to define your own PTs.
Here, the description says "we're going to use a custom PT of 109, and define another at 96, and forget to define what 109 means".
It's perfectly valid to define a bunch of rtpmap attributes and not use them; it's not valid to use a PT and then not define it!
I would say that it's an implementation bug since the rtpmap attribute is not referencing a payload format that has been specified in the media line, which effectively renders the attribute useless.
From Rfc4566:
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
This attribute maps from an RTP payload type number (as used in
an "m=" line) to an encoding name denoting the payload format
to be used.