Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14629
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: bash sockets: printf \x0a does TCP fragmentation |
| Date | 2018-09-21 19:34 -0400 |
| Organization | ITS, Case Western Reserve University |
| Message-ID | <mailman.1115.1537572915.1284.bug-bash@gnu.org> (permalink) |
| References | <c6de6616-dda0-570d-de56-419e7676be8a@cbii-hh.de> |
On 9/21/18 4:13 PM, dirk+bash@testssl.sh wrote: > > 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. Newline? It's probably that stdout is line-buffered and the newline causes a flush, which results in a write(2). > If there's a workaround, please let me know. (tried to add "%b" with no > effect). Otherwise I believe it's a bug. How? Does the emitted output not correspond to what's passed to printf in some way? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: bash sockets: printf \x0a does TCP fragmentation Chet Ramey <chet.ramey@case.edu> - 2018-09-21 19:34 -0400
csiph-web