Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14628
| From | dirk+bash@testssl.sh |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | bash sockets: printf \x0a does TCP fragmentation |
| Date | 2018-09-21 22:13 +0200 |
| Message-ID | <mailman.1111.1537562978.1284.bug-bash@gnu.org> (permalink) |
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?
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
bash sockets: printf \x0a does TCP fragmentation dirk+bash@testssl.sh - 2018-09-21 22:13 +0200
csiph-web