P
<p>See Conformance Test Policy Version 2.0
<p>Chapter 9.1.3
<pre>
9.1.3. Improper Message Length
9.1.3.1. A request is sent via TCP on port 502 with an improper message length, in the format
specified by [2] and [3] from the Laboratory PC.
9.1.3.2. The Modbus request will be of the form
00 00 00 00 00 FF XX 03 00 00 00 01
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 FF
Unit Identifier: XX
Function Code: 03
Register Offset: 00 00
Number of Registers: 00 01
9.1.3.3. The response must be of the form:
00 00 00 00 00 03 XX 83 03
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 03
Unit Identifier: XX
Function Code: 83
Exception Code: 03
</pre>
<p>Not agree with that :<br>
- according to "MODBUS Application Protocol Specification V1.1"
<pre>
"The size of the Modbus PDU is limited by the size constraint
inherited from the first Modbus implementation on Serial Line network
(max. RS485 ADU = 256 bytes).
Therefore, MODBUS PDU for serial line communication
= 256 - Server adress (1 byte) - CRC (2 bytes) = 253 bytes.
Consequently :
RS232 / RS485 ADU = 253 bytes + Server adress (1 byte) + CRC (2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes."
</pre>
<p>so the maximum for "Message Length" is 254 bytes (Message length include Unit Identifier)
<p>- We can say in this case that the header is corrupt (not conform with Modbus spec.)
<p>- In this case we have to UNILATERALLY CLOSE THE CONNECTION according to Open MODBUS/TCP Specification
page 20 (I think we have to replace 256 with 254)
<p>"Analyze the header. If it appears corrupt, for example
the protocol field is non-zero or the length of message
is larger than 256, then UNILATERALLY CLOSE THE CONNECTION.
This is the correct response as a server to a situation
implying the TCP encoding is incorrect."
<pre>
Chapter 9.1.4
9.1.4. Illegal Number of Registers
9.1.4.1. A request is sent via TCP on port 502 with an illegal number of registers, in the
format specified by [2] and [3] from the Laboratory PC.
9.1.4.2. The Modbus request will be of the form
00 00 00 00 00 06 XX 03 00 00 FF FF
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 06
Unit Identifier: XX
Function Code: 03
Register Offset: 00 00
Number of Registers: FF FF
9.1.4.3. The response must be of the form:
00 00 00 00 00 03 XX 83 02
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 03
Unit Identifier: XX
Function Code: 83
Exception Code: 02
</pre>
<p>Not agree with that :
<p>- It is not possible in modbus to ask for #FFFF registers, I think that in this
case an Exception Code : 03 is better than 02
<pre>
03 Illegal Data Value
A value contained in the query data field is not an allowable value
for the slave. This indicates a fault in the structure of the remainder
of a complex request, such as that the implied length is incorrect. It
specifically does NOT mean that a data item submitted for storage in a
register has a value outside the expectation of the application program,
since the MODBUS protocol is unaware of the significance of any
particular value of any particular register.
02 Illegal Data Address
The data address received in the query is not an allowable address for the
slave. More specifically, the combination of reference number and transfer
length is invalid. For a controller with 100 registers, a request with offset
96 and length 4 would succeed, a request with offset 96 and length 5 will generate
exception 02.
</pre>
<p>Another problem with the request 00 00 00 00 00 FF XX 03 00 00 00 01 (see chapter 9.1.3.2),
We have seen that the maximum is FE so if we just change the request in :
00 00 00 00 00 FE XX 03 00 00 00 01<br>
I think we have to reject this request too, and UNILATERALLY CLOSE THE CONNECTION, because
the real length of the request we received is not the same of "Message Length". So we have to
consider that the MBAP is corrupt..
<p>Philippe Boudot<br>
Electronic Research & Development<br>
CP Industrial Business Unit
<p>Email: [email protected]<br>
http://www.chicagopneumatic.com
<p>Chapter 9.1.3
<pre>
9.1.3. Improper Message Length
9.1.3.1. A request is sent via TCP on port 502 with an improper message length, in the format
specified by [2] and [3] from the Laboratory PC.
9.1.3.2. The Modbus request will be of the form
00 00 00 00 00 FF XX 03 00 00 00 01
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 FF
Unit Identifier: XX
Function Code: 03
Register Offset: 00 00
Number of Registers: 00 01
9.1.3.3. The response must be of the form:
00 00 00 00 00 03 XX 83 03
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 03
Unit Identifier: XX
Function Code: 83
Exception Code: 03
</pre>
<p>Not agree with that :<br>
- according to "MODBUS Application Protocol Specification V1.1"
<pre>
"The size of the Modbus PDU is limited by the size constraint
inherited from the first Modbus implementation on Serial Line network
(max. RS485 ADU = 256 bytes).
Therefore, MODBUS PDU for serial line communication
= 256 - Server adress (1 byte) - CRC (2 bytes) = 253 bytes.
Consequently :
RS232 / RS485 ADU = 253 bytes + Server adress (1 byte) + CRC (2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes."
</pre>
<p>so the maximum for "Message Length" is 254 bytes (Message length include Unit Identifier)
<p>- We can say in this case that the header is corrupt (not conform with Modbus spec.)
<p>- In this case we have to UNILATERALLY CLOSE THE CONNECTION according to Open MODBUS/TCP Specification
page 20 (I think we have to replace 256 with 254)
<p>"Analyze the header. If it appears corrupt, for example
the protocol field is non-zero or the length of message
is larger than 256, then UNILATERALLY CLOSE THE CONNECTION.
This is the correct response as a server to a situation
implying the TCP encoding is incorrect."
<pre>
Chapter 9.1.4
9.1.4. Illegal Number of Registers
9.1.4.1. A request is sent via TCP on port 502 with an illegal number of registers, in the
format specified by [2] and [3] from the Laboratory PC.
9.1.4.2. The Modbus request will be of the form
00 00 00 00 00 06 XX 03 00 00 FF FF
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 06
Unit Identifier: XX
Function Code: 03
Register Offset: 00 00
Number of Registers: FF FF
9.1.4.3. The response must be of the form:
00 00 00 00 00 03 XX 83 02
Corresponding to:
Transaction Identifier: 00 00
Protocol Identifier: 00 00
Message Length: 00 03
Unit Identifier: XX
Function Code: 83
Exception Code: 02
</pre>
<p>Not agree with that :
<p>- It is not possible in modbus to ask for #FFFF registers, I think that in this
case an Exception Code : 03 is better than 02
<pre>
03 Illegal Data Value
A value contained in the query data field is not an allowable value
for the slave. This indicates a fault in the structure of the remainder
of a complex request, such as that the implied length is incorrect. It
specifically does NOT mean that a data item submitted for storage in a
register has a value outside the expectation of the application program,
since the MODBUS protocol is unaware of the significance of any
particular value of any particular register.
02 Illegal Data Address
The data address received in the query is not an allowable address for the
slave. More specifically, the combination of reference number and transfer
length is invalid. For a controller with 100 registers, a request with offset
96 and length 4 would succeed, a request with offset 96 and length 5 will generate
exception 02.
</pre>
<p>Another problem with the request 00 00 00 00 00 FF XX 03 00 00 00 01 (see chapter 9.1.3.2),
We have seen that the maximum is FE so if we just change the request in :
00 00 00 00 00 FE XX 03 00 00 00 01<br>
I think we have to reject this request too, and UNILATERALLY CLOSE THE CONNECTION, because
the real length of the request we received is not the same of "Message Length". So we have to
consider that the MBAP is corrupt..
<p>Philippe Boudot<br>
Electronic Research & Development<br>
CP Industrial Business Unit
<p>Email: [email protected]<br>
http://www.chicagopneumatic.com