bash sockets: printf \x0a does TCP fragmentation

[dirk+bash]

Hello there,

we discovered a strange phenomenon in the project testssl.sh:

After opening a TCP socket with a fd (here: 5), when writing to it,
it seems that

printf -- "$data" >&5 2>/dev/null

does not do what it is intended. "$data" is  a ClientHello like

'\x16\x03\x01\x2\x00\x01\x00\x1\xfc\x03\x03\x54\x51\x1e\x7a\xde\xad\xbe\xef\x31\x33\x07\x00\x00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0a\...'

Each \x0a like the last one causes a new TCP fragment to begin which can be 
easily
spotted when using wireshark while running e.g.

testssl.sh --assume-http -p testssl.sh

Starting from the SSLv3 ClientHello the first reassembled packet
ends with 0a.

See also discussion @ https://github.com/drwetter/testssl.sh/pull/1113.

One would assume that a bash socket connection cannot influence the TCP
fragmentation but obviously it does.

This behavior has a performance penalty and other strange effects, e.g.
if the first segment is really small, some devices reject the ClientHello.


If there's a workaround, please let me know. (tried to add "%b" with no
effect). Otherwise I believe it's a bug.

Cheers, Dirk


PS: Would ulimit -b <parameter> help?