From owner-freebsd-questions@freebsd.org Tue Dec 22 11:40:16 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA58AA4E363 for ; Tue, 22 Dec 2015 11:40:16 +0000 (UTC) (envelope-from ml@netfence.it) Received: from smtp207.alice.it (smtp207.alice.it [82.57.200.103]) by mx1.freebsd.org (Postfix) with ESMTP id 547501B67 for ; Tue, 22 Dec 2015 11:40:15 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu (87.17.57.17) by smtp207.alice.it (8.6.060.28) (authenticated as acanedi@alice.it) id 562CAA690BDE125C for freebsd-questions@freebsd.org; Tue, 22 Dec 2015 12:40:05 +0100 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.15.2/8.14.9) with ESMTP id tBMBe6rI002865 for ; Tue, 22 Dec 2015 12:40:06 +0100 (CET) (envelope-from ml@netfence.it) To: freebsd-questions@freebsd.org From: Andrea Venturoli Subject: inetd + sysutil/socket VS net/tcpproxy Message-ID: <56793696.5020406@netfence.it> Date: Tue, 22 Dec 2015 12:40:06 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 11:40:16 -0000 Hello. I know this question will be vague and possibly a little OT, but I'm in search of some suggestion. I've always used sysutil/socket to allow access to an internal server through a firewall, with an inetd.conf line like > myport stream tcp4 nowait nobody /usr/local/bin/socket socket internalip myport This has always worked (and still is in several cases), but now I found a custom program which would give a protocol error. I tried replacing inetd+socket with net/tcpproxy and everything started working properly. I might declare all is well and solved, but I'm very curious... So I recorded the conversation with "tcpdump -s 65000 -w myfile port myport" and processed it with "tcpflow -o MyConv -r myfile"; I did this for both the "good" traffic (the working one, thanks to tcpproxy) and the "bad" traffic (the problematic one, with inetd+socket). To my surprise they are identical!!! So I'm left wondering why one works and the other doesn't. Of course the size, timestamps, fragmentation of the data stream is not the same across the two packet sets, but I don't think that should matter. Any suggestion? bye & Thanks av.