Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail From: Chet Ramey Newsgroups: gnu.bash.bug Subject: Re: bash sockets: printf \x0a does TCP fragmentation Date: Fri, 21 Sep 2018 19:34:52 -0400 Organization: ITS, Case Western Reserve University Lines: 32 Approved: bug-bash@gnu.org Message-ID: References: Reply-To: chet.ramey@case.edu NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: usenet.stanford.edu 1537572915 25451 208.118.235.17 (21 Sep 2018 23:35:15 GMT) X-Complaints-To: action@cs.stanford.edu Cc: chet.ramey@case.edu To: dirk+bash@testssl.sh, bug-bash@gnu.org Envelope-to: bug-bash@gnu.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:cc:subject:to:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4padntcryVK7dR6vkLX77ekOQ/3BbLCvmfnVIQGsqNk=; b=LkQYS/U6vs0QiD50HLTjIe5KF92ebEQ2SroaFpBIv/0wsNHnCnmMpNjx/sF2i/oSzP a/sfBMAKueH17giiGtFlw7iOANAVRNUaWsqsuFZ2tW6hhck3Q4u0uxm1pRL9JPTmigso YWillBNfHXT/+WNxhkebvfgdGzDfrO5gM1O/U330F2kmXYpsVw84V33/+hnR+03GQsMM GLWRKdr9WbLEtMnsscyGfx/QPuAXIfinTSRjtQlvLNGsgquDT1QVLkEPmrZb56YdhJrs 46/8wegpZ4zgk6OfvRU1/O17YKztA0cd6jNuAX/lIiWI0gL5J88BT02YISJJ6S12UF3V IC0w== X-Gm-Message-State: ABuFfojqG1/jf46HGed/4Vx97Bg59umFjOIRj0do+a3+l9MvcpplOD1u LGIUR3G9Q4sExDkEo+L/TytxT2ew/nJuPzwky1+RjBByDDx0HfOk9aMEc+aQN/nT3ePlHgA0Owz hEp3NskD5Axs= X-Received: by 2002:a6b:9a46:: with SMTP id c67-v6mr33782ioe.24.1537572908154; Fri, 21 Sep 2018 16:35:08 -0700 (PDT) X-Google-Smtp-Source: ACcGV61yK24X1DPiKWEmjoUTXNLACdwbGCDAWhtA1mzMheWrxGsWYKCKYToeUAInzcVn24iYlFDzvg== X-Received: by 2002:a6b:9a46:: with SMTP id c67-v6mr33775ioe.24.1537572907897; Fri, 21 Sep 2018 16:35:07 -0700 (PDT) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 In-Reply-To: Content-Language: en-US X-Junkmail-Status: score=7/90, host=mpv1-2015.case.edu X-Junkmail-PrAS-Raw: score=7/90, refid=2.7.2:2018.9.21.231216:17:7.944, ip=, rules=__YOUTUBE_RCVD, __X_GOOGLE_DKIM_SIGNATURE, __HAS_REPLYTO, __HAS_CC_HDR, __SUBJ_REPLY, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __TO_MALFORMED_2, __TO_NO_NAME, __REFERENCES, __HAS_FROM, FROM_EDU_TLD, __HAS_MSGID, __SANE_MSGID, DATE_TZ_NA, __USER_AGENT, __MOZILLA_USER_AGENT, __MIME_VERSION, __IN_REP_TO, __CT, __CT_TEXT_PLAIN, __CTE, __REPLYTO_SAMEAS_FROM_ADDY, __REPLYTO_SAMEAS_FROM_ACC, __FROM_DOMAIN_IN_ANY_CC1, __FROM_DOMAIN_IN_ANY_CC2, __REPLYTO_SAMEAS_FROM_DOMAIN, __ANY_URI, __URI_WITH_PATH, __URI_NO_WWW, __CP_URI_IN_BODY, __FRAUD_MONEY_CURRENCY_DOLLAR, __SUBJ_ALPHA_NEGATE, __URI_IN_BODY, __URI_NOT_IMG, __FORWARDED_MSG, __NO_HTML_TAG_RAW, BODY_SIZE_1100_1199, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_P1, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, __FRAUD_MONEY_CURRENCY, BODY_SIZE_5000_LESS, IN_REP_TO, MSG_THREAD, __FROM_DOMAIN_IN_RCPT, [TRUNCATED], so=2010-03-03 19:42:08, dmn=2016-08-03-0138 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 129.22.103.226 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14629 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/