From owner-freebsd-net@FreeBSD.ORG Sun Jun 11 12:29:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D5716A418 for ; Sun, 11 Jun 2006 12:29:10 +0000 (UTC) (envelope-from shaun@rsc.cx) Received: from mail.rsc.cx (mail.rsc.cx [64.235.233.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4354943D58 for ; Sun, 11 Jun 2006 12:29:08 +0000 (GMT) (envelope-from shaun@rsc.cx) Received: from [::1] (helo=webmail.rsc.cx) by mail.rsc.cx with esmtp (Exim 4.52 (FreeBSD)) id 1FpP3t-0005xC-J4; Sun, 11 Jun 2006 05:29:02 -0700 Received: from 81.107.58.115 (SquirrelMail authenticated user shaun@rsc.cx) by webmail.rsc.cx with HTTP; Sun, 11 Jun 2006 05:29:01 -0700 (PDT) Message-ID: <52332.81.107.58.115.1150028941.squirrel@webmail.rsc.cx> In-Reply-To: <200606111308.28468.max@love2party.net> References: <52706.81.107.58.115.1149986191.squirrel@webmail.rsc.cx> <200606111308.28468.max@love2party.net> Date: Sun, 11 Jun 2006 05:29:01 -0700 (PDT) From: "Shaun Colley" To: "Max Laier" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: -2.8 (--) X-Spam-Report: Spam detection software, running on the system "mail.rsc.cx", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi Max & group, > As you can see in netinet/in_proto.c, tcp does not use pr_output, but > calls > tcp_output() directly where needed. Depending on what you want to achive > it > might be enough to hack up tcp_usr_send() and replace tcp_usrreqs.pru_send > instead. Replaceing tcp_output() is not easily possible. You could start > with telling us what you *really* want to do so we can point you to a > workable option. [...] Content analysis details: (-2.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -2.8 ALL_TRUSTED Did not pass through any untrusted hosts Cc: freebsd-net@freebsd.org, Shaun Colley Subject: Re: Unexpected behavior after altering inetsw[] switch table X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2006 12:29:10 -0000 Hi Max & group, > As you can see in netinet/in_proto.c, tcp does not use pr_output, but > calls > tcp_output() directly where needed. Depending on what you want to achive > it > might be enough to hack up tcp_usr_send() and replace tcp_usrreqs.pru_send > instead. Replaceing tcp_output() is not easily possible. You could start > with telling us what you *really* want to do so we can point you to a > workable option. Right, I'll start by telling you what I'm actually trying to achieve. Everytime an IP datagram with a TCP header is sent, I want to mangle (i.e. modify) part of the TCP packet and it's payload with 'random' data. Although this may sound a bit pointless, I want to do this to implement a form of dumb fuzzing, which is a form of stress testing used a lot in computer security. Does that make a bit of sense? So I was attempting to modify the pr_output hook for TCP (which I now know isn't possible) and replace it with a ptr to my own hacked tcp_output routine. Can you see a way to do what I'm trying to achieve? Cheers, shaun