0005517: UACTT client refuses more chunks than defined in ACK from server whereas HEL defines no limit (MaxChunkCount == 0) - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0005517	Compliance Test Tool (CTT) Unified Architecture	2 - CTT Binary	public	2020-03-10 17:13	2020-04-17 15:12

Reporter	V. Monfort	Assigned To	Alexander Allmendinger
Priority	normal	Severity	minor	Reproducibility	always
Status	closed	Resolution	no change required
Product Version	1.03.341.390

Summary	0005517: UACTT client refuses more chunks than defined in ACK from server whereas HEL defines no limit (MaxChunkCount == 0)
Description	Hello, In tests View Basic 005/015/016/020 if the server defines <N> chunks maximum in ACK message, when it returns more than <N> chunks for a response message UACTT client close the connection and indicates BadTcpMessageTooLarge in UACTT logs whereas UACTT client indicated 0 chunks maximum in HEL message. Since UACTT client indicated unlimited number of chunks (0), it should be able to receive more than <N> chunks without any issue. Note: the MaxMessageSize of UACTT client is not reached.
Steps To Reproduce	Limit the number of chunks on server side between 1 to 11 and run the View Basic test 005/015/016/020. Attached a run of test View Basic 005.js configured on server side with MaxChunkCount to 5 (FAIL) and with MaxChunkCount to 12 (OK). For both tests UACTT client provides MaxChunkCount to 0 which means it should accept unlimited number of chunks whatever the server indicated for itself. 005_fails_after_5_chunks: see packet number 265 leading to response and disconnection after 5 chunks (whereas illimited number should be accepted) 005_ok_after_12_chunks: see packet number 259 which is the same as in previous capture, same test run with MaxChunkCount = 12 in ACK message (server side) succeeds.
Tags	No tags attached.
Attached Files	005_fails_after_5_chunks.pcapng (1,050,332 bytes) 005_ok_after_12_chunks.pcapng (2,061,960 bytes)

Files Affected

Alexander Allmendinger 2020-03-20 18:36 developer ~0011794	When the client is sending in a "0" for the MaxChunkCount in its Hello, it means unlimited. As a result the server can set the MaxChunkCount in its Acknowledge to whatever his limit is. But once this is set, neither the client nor the server is allowed to exceed the number. See Part 6 of the specification which states for the Acknowledge: The maximum number of chunks in any request Message. The Client shall abort the Message with a Bad_RequestTooLarge StatusCode if a request Message exceeds this value. The mechanism for aborting Messages is described fully in 6.7.3. A value of zero indicates that the Server has no limit.

V. Monfort 2020-03-21 08:39 reporter ~0011804	Hi again, I confirm my first analysis of the specification. If I quote your comment regarding the MaxChunkCount in ACK message: "The maximum number of chunks in any request Message." It is indicated "request Message" which clearly means it does not concern the response messages the server will send to the client for which maximum parameters have been provided in HELLO message. If the intend was to negotiate the values for both request and response, I guess the specification shall be modified to indicate it.

Alexander Allmendinger 2020-03-31 22:18 developer ~0011857	For a change request of the specification please create a Mantis Issue in the UA Specification project with a recommended specification change.

Paul Hunkar 2020-04-17 15:12 administrator ~0011930	reviewed in CMP meeting

Date Modified	Username	Field	Change
2020-03-10 17:13	V. Monfort	New Issue
2020-03-10 17:13	V. Monfort	File Added: 005_fails_after_5_chunks.pcapng
2020-03-10 17:14	V. Monfort	File Added: 005_ok_after_12_chunks.pcapng
2020-03-20 17:08	Paul Hunkar	Assigned To	=> Alexander Allmendinger
2020-03-20 17:08	Paul Hunkar	Status	new => assigned
2020-03-20 18:36	Alexander Allmendinger	Status	assigned => resolved
2020-03-20 18:36	Alexander Allmendinger	Resolution	open => no change required
2020-03-20 18:36	Alexander Allmendinger	Note Added: 0011794
2020-03-21 08:39	V. Monfort	Status	resolved => feedback
2020-03-21 08:39	V. Monfort	Resolution	no change required => reopened
2020-03-21 08:39	V. Monfort	Note Added: 0011804
2020-03-31 22:18	Alexander Allmendinger	Status	feedback => resolved
2020-03-31 22:18	Alexander Allmendinger	Resolution	reopened => no change required
2020-03-31 22:18	Alexander Allmendinger	Note Added: 0011857
2020-04-17 15:12	Paul Hunkar	Status	resolved => closed
2020-04-17 15:12	Paul Hunkar	Note Added: 0011930