RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/reg-tests/converter/fix.vtc

236 lines
14 KiB
Plaintext
Raw Normal View History

REGTEST: converter: Add a regtest for fix converters This new script tests fix_is_valid() and fix_tag_value() converters used to validate and extract information from a FIX (Financial Information eXchange) message.
2020-10-29 15:34:22 +00:00
varnishtest "fix converters Test"
REGTESTS: Fix required versions for several scripts The following scripts require HAProxy 2.4 : * cache/caching_rules.vtc * cache/post_on_entry.vtc * cache/vary.vtc * checks/1be_40srv_odd_health_checks.vtc * checks/40be_2srv_odd_health_checks.vtc * checks/4be_1srv_health_checks.vtc * converter/fix.vtc * converter/mqtt.vtc * http-messaging/protocol_upgrade.vtc * http-messaging/websocket.vtc * http-set-timeout/set_timeout.vtc * log/log_uri.vtc However it may change is features are backported.
2020-12-15 16:13:39 +00:00
#REQUIRE_VERSION=2.4
REGTEST: converter: Add a regtest for fix converters This new script tests fix_is_valid() and fix_tag_value() converters used to validate and extract information from a FIX (Financial Information eXchange) message.
2020-10-29 15:34:22 +00:00
feature ignore_unknown_macro
server s1 {
# Valid FIX-4.0 logon
recv 92
# 8=FIX|4.0|9=66|35=A|34=1|49=EXECUTOR|52=20201029-10:54:19|56=CLIENT1|98=0|108=30|10=147|
sendhex "383d4649582e342e3001393d36360133353d410133343d310134393d4558454355544f520135323d32303230313032392d31303a35343a31390135363d434c49454e54310139383d30013130383d33300131303d31343701"
close
# Valid FIX-4.1 logon
accept
recv 98
# 8=FIX.4.1|9=72|35=A|34=1|49=EXECUTOR|52=20201029-12:43:07|56=CLIENT1|98=0|108=30|141=Y|10=187|
sendhex "383d4649582e342e3101393d37320133353d410133343d310134393d4558454355544f520135323d32303230313032392d31323a34333a30370135363d434c49454e54310139383d30013130383d3330013134313d590131303d31383701"
close
# Valid FIX-4.2 logon
accept
recv 98
# 8=FIX.4.2|9=79|35=A|34=1|49=EXECUTOR|52=20201029-12:55:12.101414|56=CLIENT1|98=0|108=30|141=Y|10=027|
sendhex "383d4649582e342e3201393d37390133353d410133343d310134393d4558454355544f520135323d32303230313032392d31323a35353a31322e3130313431340135363d434c49454e54310139383d30013130383d3330013134313d590131303d30323701"
close
# Valid FIX-4.3 logon
accept
recv 125
# 8=FIX.4.3|9=79|35=A|34=1|49=EXECUTOR|52=20201029-12:58:50.891371|56=CLIENT1|98=0|108=30|141=Y|10=051|
sendhex "383d4649582e342e3301393d37390133353d410133343d310134393d4558454355544f520135323d32303230313032392d31323a35383a35302e3839313337310135363d434c49454e54310139383d30013130383d3330013134313d590131303d30353101"
close
# Valid FIX-4.4 logon
accept
recv 125
# 8=FIX.4.4|9=79|35=A|34=1|49=EXECUTOR|52=20201029-13:02:44.535360|56=CLIENT1|98=0|108=30|141=Y|10=038|
sendhex "383d4649582e342e3401393d37390133353d410133343d310134393d4558454355544f520135323d32303230313032392d31333a30323a34342e3533353336300135363d434c49454e54310139383d30013130383d3330013134313d590131303d30333801"
close
# Valid FIX-5.0 logon
accept
recv 140
# 8=FIXT.1.1|9=86|35=A|34=1|49=EXECUTOR|52=20201029-13:13:22.626384|56=CLIENT1|98=0|108=30|141=Y|1137=7|10=184|
sendhex "383d464958542e312e3101393d38360133353d410133343d310134393d4558454355544f520135323d32303230313032392d31333a31333a32322e3632363338340135363d434c49454e54310139383d30013130383d3330013134313d5901313133373d370131303d31383401"
} -start
server s2 {
# Valid FIX-4.4 logon
recv 125
# 8=FIX.4.4|9=79|35=A|34=1|49=EXECUTOR|52=20201029-13:02:44.535360|56=CLIENT1|98=0|108=30|141=Y|10=038|
sendhex "383d4649582e342e3401393d37390133353d410133343d310134393d4558454355544f520135323d32303230313032392d31333a30323a34342e3533353336300135363d434c49454e54310139383d30013130383d3330013134313d590131303d30333801"
} -start
haproxy h1 -conf {
defaults
mode tcp
REGTESTS: extend the default I/O timeouts and make them overridable With the CI occasionally slowing down, we're starting to see again some spurious failures despite the long 1-second timeouts. This reports false positives that are disturbing and doesn't provide as much value as this could. However at this delay it already becomes a pain for developers to wait for the tests to complete. This commit adds support for the new environment variable HAPROXY_TEST_TIMEOUT that will allow anyone to modify the connect, client and server timeouts. It was set to 5 seconds by default, which should be plenty for quite some time in the CI. All relevant values that were 200ms or above were replaced by this one. A few larger values were left as they are special. One test for the set-timeout action that used to rely on a fixed 1-sec value was extended to a fixed 5-sec, as the timeout is normally not reached, but it needs to be known to compare the old and new values.
2021-11-18 16:46:22 +00:00
timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
timeout client "${HAPROXY_TEST_TIMEOUT-5s}"
timeout server "${HAPROXY_TEST_TIMEOUT-5s}"
REGTEST: converter: Add a regtest for fix converters This new script tests fix_is_valid() and fix_tag_value() converters used to validate and extract information from a FIX (Financial Information eXchange) message.
2020-10-29 15:34:22 +00:00
frontend fe1
bind "fd@${fe1}"
tcp-request inspect-delay 1s
tcp-request content reject unless { req.payload(0,0),fix_is_valid }
default_backend be1
frontend fe2
bind "fd@${fe2}"
tcp-request inspect-delay 1s
tcp-request content reject unless { req.payload(0,0),fix_is_valid }
tcp-request content set-var(req.fix_vsn) req.payload(0,0),fix_tag_value(BeginString)
tcp-request content set-var(req.fix_len) req.payload(0,0),fix_tag_value(BodyLength)
tcp-request content set-var(req.fix_type) req.payload(0,0),fix_tag_value(MsgType)
BUG/MINOR: sample: Rename SenderComID/TargetComID to SenderCompID/TargetCompID The recently introduced Financial Information eXchange (FIX) converters have some hard coded tags based on the specification that were misspelled. Specifically, SenderComID and TargetComID should be SenderCompID and TargetCompID according to the specification [1][2]. This patch updates all references, which includes the converters themselves, the regression test, and the documentation. [1] https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP264/tag49.html [2] https://fiximate.fixtrading.org/en/FIX.5.0SP2_EP264/tag56.html
2021-03-10 04:00:34 +00:00
tcp-request content set-var(req.fix_sender) req.payload(0,0),fix_tag_value(SenderCompID)
tcp-request content set-var(req.fix_target) req.payload(0,0),fix_tag_value(TargetCompID)
REGTEST: converter: Add a regtest for fix converters This new script tests fix_is_valid() and fix_tag_value() converters used to validate and extract information from a FIX (Financial Information eXchange) message.
2020-10-29 15:34:22 +00:00
tcp-request content set-var(req.fix_chksum) req.payload(0,0),fix_tag_value(CheckSum)
MEDIUM: vars: make the var() sample fetch function really return type ANY A long-standing issue was reported in issue #1215. In short, var() was initially internally declared as returning a string because it was not possible by then to return "any type". As such, users regularly get trapped thinking that when they're storing an integer there, then the integer matching method automatically applies. Except that this is not possible since this is related to the config parser and is decided at boot time where the variable's type is not known yet. As such, what is done is that the output being declared as type string, the string match will automatically apply, and any value will first be converted to a string. This results in several issues like: http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) lt 0 } not working. This is because the string match on the second line will in fact compare the string representation of the variable against strings "lt" and "0", none of which matches. The doc says that the matching method is mandatory, though that's not the case in the code due to that default string type being permissive. There's not even a warning when no explicit match is placed, because this happens very deep in the expression evaluator and making a special case just for "var" can reveal very complicated. The set-var() converter already mandates a matching method, as the following will be rejected: ... if { int(12),set-var(txn.truc) 12 } while this one will work: ... if { int(12),set-var(txn.truc) -m int 12 } As such, this patch this modifies var() to match the doc, returning the type "any", and mandating the matching method, implying that this bogus config which does not work: http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) lt 0 } will need to be written like this: http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) -m int lt 0 } This *will* break some configs (and even 3 of our regtests relied on this), but except those which already match string exclusively, all other ones are already broken and silently fail (and one of the 3 regtests, the one on FIX, was bogus regarding this). In order to fix existing configs, one can simply append "-m str" after a "var()" in an ACL or "if" expression: http-request deny unless { var(txn.jwt_alg) "ES" } must become: http-request deny unless { var(txn.jwt_alg) -m str "ES" } Most commonly, patterns such as "le", "lt", "ge", "gt", "eq", "ne" in front of a number indicate that the intent was to match an integer, and in this case "-m int" would be desired: tcp-response content reject if ! { var(res.size) gt 3800 } ought to become: tcp-response content reject if ! { var(res.size) -m int gt 3800 } This must not be backported, but if a solution is found to at least detect this exact condition in the generic expression parser and emit a warning, this could probably help spot configuration bugs. Link: https://www.mail-archive.com/haproxy@formilux.org/msg41341.html Cc: Christopher Faulet <cfaulet@haproxy.com> Cc: Tim Dsterhus <tim@bastelstu.be>
2021-11-02 16:08:15 +00:00
tcp-request content reject if ! { var(req.fix_vsn) -m str "FIX.4.4" } || ! { var(req.fix_len) -m str "102" }
tcp-request content reject if ! { var(req.fix_type) -m str "A" } || ! { var(req.fix_sender) -m str "CLIENT1" }
tcp-request content reject if ! { var(req.fix_target) -m str "EXECUTOR" } || ! { var(req.fix_chksum) -m str "252" }
REGTEST: converter: Add a regtest for fix converters This new script tests fix_is_valid() and fix_tag_value() converters used to validate and extract information from a FIX (Financial Information eXchange) message.
2020-10-29 15:34:22 +00:00
default_backend be2
backend be1
server s1 ${s1_addr}:${s1_port}
tcp-response inspect-delay 1s
tcp-response content reject unless { res.payload(0,0),fix_is_valid }
backend be2
server s2 ${s2_addr}:${s2_port}
tcp-response inspect-delay 1s
tcp-response content reject unless { res.payload(0,0),fix_is_valid }
tcp-response content set-var(res.fix_vsn) res.payload(0,0),fix_tag_value(8)
tcp-response content set-var(res.fix_len) res.payload(0,0),fix_tag_value(9)
tcp-response content set-var(res.fix_type) res.payload(0,0),fix_tag_value(35)
tcp-response content set-var(res.fix_sender) res.payload(0,0),fix_tag_value(49)
tcp-response content set-var(res.fix_target) res.payload(0,0),fix_tag_value(56)
tcp-response content set-var(res.fix_chksum) res.payload(0,0),fix_tag_value(10)
MEDIUM: vars: make the var() sample fetch function really return type ANY A long-standing issue was reported in issue #1215. In short, var() was initially internally declared as returning a string because it was not possible by then to return "any type". As such, users regularly get trapped thinking that when they're storing an integer there, then the integer matching method automatically applies. Except that this is not possible since this is related to the config parser and is decided at boot time where the variable's type is not known yet. As such, what is done is that the output being declared as type string, the string match will automatically apply, and any value will first be converted to a string. This results in several issues like: http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) lt 0 } not working. This is because the string match on the second line will in fact compare the string representation of the variable against strings "lt" and "0", none of which matches. The doc says that the matching method is mandatory, though that's not the case in the code due to that default string type being permissive. There's not even a warning when no explicit match is placed, because this happens very deep in the expression evaluator and making a special case just for "var" can reveal very complicated. The set-var() converter already mandates a matching method, as the following will be rejected: ... if { int(12),set-var(txn.truc) 12 } while this one will work: ... if { int(12),set-var(txn.truc) -m int 12 } As such, this patch this modifies var() to match the doc, returning the type "any", and mandating the matching method, implying that this bogus config which does not work: http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) lt 0 } will need to be written like this: http-request set-var(txn.foo) int(-1) http-request deny if { var(txn.foo) -m int lt 0 } This *will* break some configs (and even 3 of our regtests relied on this), but except those which already match string exclusively, all other ones are already broken and silently fail (and one of the 3 regtests, the one on FIX, was bogus regarding this). In order to fix existing configs, one can simply append "-m str" after a "var()" in an ACL or "if" expression: http-request deny unless { var(txn.jwt_alg) "ES" } must become: http-request deny unless { var(txn.jwt_alg) -m str "ES" } Most commonly, patterns such as "le", "lt", "ge", "gt", "eq", "ne" in front of a number indicate that the intent was to match an integer, and in this case "-m int" would be desired: tcp-response content reject if ! { var(res.size) gt 3800 } ought to become: tcp-response content reject if ! { var(res.size) -m int gt 3800 } This must not be backported, but if a solution is found to at least detect this exact condition in the generic expression parser and emit a warning, this could probably help spot configuration bugs. Link: https://www.mail-archive.com/haproxy@formilux.org/msg41341.html Cc: Christopher Faulet <cfaulet@haproxy.com> Cc: Tim Dsterhus <tim@bastelstu.be>
2021-11-02 16:08:15 +00:00
tcp-response content reject if ! { var(res.fix_vsn) -m str "FIX.4.4" } || ! { var(res.fix_len) -m str "79" }
tcp-response content reject if ! { var(res.fix_type) -m str "A" } || ! { var(res.fix_sender) -m str "EXECUTOR" }
tcp-response content reject if ! { var(res.fix_target) -m str "CLIENT1" } || ! { var(res.fix_chksum) -m str "038" }
REGTEST: converter: Add a regtest for fix converters This new script tests fix_is_valid() and fix_tag_value() converters used to validate and extract information from a FIX (Financial Information eXchange) message.
2020-10-29 15:34:22 +00:00
} -start
client c1_4_0 -connect ${h1_fe1_sock} {
# Valid FIX-4.0 logon
# 8=FIX|4.0|9=70|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-10:54:19.617|98=0|108=30|10=090|
sendhex "383d4649582e342e3001393d37300133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31303a35343a31392e3631370139383d30013130383d33300131303d30393001"
recv 88
expect_close
} -run
client c1_4_1 -connect ${h1_fe1_sock} {
# Valid FIX-4.1 logon
# 8=FIX.4.1|9=76|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-12:43:07.940|98=0|108=30|141=Y|10=138|
sendhex "383d4649582e342e3101393d37360133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31323a34333a30372e3934300139383d30013130383d3330013134313d590131303d31333801"
recv 94
expect_close
} -run
client c1_4_2 -connect ${h1_fe1_sock} {
# Valid FIX-4.2 logon
# 8=FIX.4.2|9=76|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-12:55:12.100|98=0|108=30|141=Y|10=126|
sendhex "383d4649582e342e3201393d37360133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31323a35353a31322e3130300139383d30013130383d3330013134313d590131303d31323601"
recv 101
expect_close
} -run
client c1_4_3 -connect ${h1_fe1_sock} {
# Valid FIX-4.3 logon
# 8=FIX.4.3|9=102|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-12:58:50.889|98=0|108=30|141=Y|553=Username|554=Password|10=012|
sendhex "383d4649582e342e3301393d3130320133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31323a35383a35302e3838390139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d30313201"
recv 101
expect_close
} -run
client c1_4_4 -connect ${h1_fe1_sock} {
# Valid FIX-4.4 logon
# 8=FIX.4.4|9=102|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e3401393d3130320133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
recv 101
expect_close
} -run
client c1_5_0 -connect ${h1_fe1_sock} {
# Valid FIX-5.0 logon
# 8=FIXT.1.1|9=116|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:13:22.624|1128=7|98=0|108=30|141=Y|553=Username|554=Password|1137=7|10=204|
sendhex "383d464958542e312e3101393d3131360133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a31333a32322e36323401313132383d370139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f726401313133373d370131303d32303401"
recv 109
expect_close
} -run
client c2_1 -connect ${h1_fe1_sock} {
# InValid FIX-4.4: Empty TagName (missing EncryptMethod <98> tag name)
# 8=FIX.4.4|9=100|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|=0|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e3401393d3130300133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e353238013d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
expect_close
} -run
client c2_2 -connect ${h1_fe1_sock} {
# InValid FIX-4.4: Empty TagValue (missing EncryptMethod <98> tag value)
# 8=FIX.4.4|9=101|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e3401393d3130310133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
expect_close
} -run
client c2_3 -connect ${h1_fe1_sock} {
# InValid FIX-4.4: Empty Tag no delimiter (missing delimiter for EncryptMethod <98> tag)
# 8=FIX.4.4|9=101|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e3401393d3130300133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e353238013938013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
expect_close
} -run
client c2_4 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: First tag != BeginString
# 9=102|8=FIX.4.4|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "393d31303201383d4649582e342e340133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
expect_close
} -run
client c2_5 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: Second tag != BodyLength
# 8=FIX.4.4|35=A|9=102|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e340133353d4101393d3130320134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
expect_close
} -run
client c2_6 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: Third tag != MsgType
# 8=FIX.4.4|9=102|49=CLIENT1|35=A|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e3401393d3130320134393d434c49454e54310133353d410135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
expect_close
} -run
client c2_7 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: Bad body length (too short 100 != 102)
# 8=FIX.4.4|9=100|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e3401393d3130300133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
expect_close
} -run
client c2_8 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: Bad body length (too long 105 != 102)
# 8=FIX.4.4|9=105|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=252|XXX
sendhex "383d4649582e342e3401393d3130350133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201585858"
expect_close
} -run
client c2_9 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: Too short checksum value (< 3 digit)
# 8=FIX.4.4|9=102|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=25|
sendhex "383d4649582e342e3401393d3130320133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d323501"
expect_close
} -run
client c2_10 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: Too long checksum value (> 3 digit)
# 8=FIX.4.4|9=102|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=2520|
sendhex "383d4649582e342e3401393d3130320133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d3235323001"
expect_close
} -run
client c2_11 -connect ${h1_fe1_sock} {
# Invalid FIX-4.4: invalid checksum value (253 != 252)
# 8=FIX.4.4|9=102|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=253|
sendhex "383d4649582e342e3401393d3130320133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353301"
expect_close
} -run
client c3_1 -connect ${h1_fe2_sock} {
# 8=FIX.4.4|9=102|35=A|49=CLIENT1|56=EXECUTOR|34=1|52=20201029-13:02:44.528|98=0|108=30|141=Y|553=Username|554=Password|10=252|
sendhex "383d4649582e342e3401393d3130320133353d410134393d434c49454e54310135363d4558454355544f520133343d310135323d32303230313032392d31333a30323a34342e3532380139383d30013130383d3330013134313d59013535333d557365726e616d65013535343d50617373776f72640131303d32353201"
recv 101
expect_close
} -run