From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 10:42:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1634016A49E for ; Tue, 26 Sep 2006 10:42:38 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04FC543D55 for ; Tue, 26 Sep 2006 10:42:30 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Sep 2006 03:42:31 -0700 X-IronPort-AV: i="4.09,219,1157353200"; d="scan'208"; a="325332757:sNHT33578988" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8QAgURp006474; Tue, 26 Sep 2006 03:42:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8QAgTML019904; Tue, 26 Sep 2006 03:42:30 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 03:42:29 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 03:42:28 -0700 Message-ID: <451903F5.20001@cisco.com> Date: Tue, 26 Sep 2006 06:41:57 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2006 10:42:29.0065 (UTC) FILETIME=[76A6C390:01C6E158] DKIM-Signature: a=rsa-sha1; q=dns; l=2429; t=1159267350; x=1160131350; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Anyone=20play=20with=20divert=20sockets=20lately?; X=v=3Dcisco.com=3B=20h=3D501uzIGYshBKoQ9c94cTaL/zwjI=3D; b=fQjeYe36Xw/PLmvtwGWBGFIcHsiU+Yg45R6DyHY1e0ZG0CQ1vsN83MTnsw/JMMElZ45zW5Pw DgyMqumQNpln0irhsBYUSAJjrLladWlGWpa5DMJ6UzaiiHV5EmehLwww; Authentication-Results: sj-dkim-6.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-current@freebsd.org Subject: Re: Anyone play with divert sockets lately? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 10:42:38 -0000 Ian FREISLICH wrote: > Randall Stewart wrote: > >>Ian FREISLICH wrote: >> >> >>> >>>I'm using divert sockets extensively for some tunnel/vpn software >>>I wrote _way_ back. It's running fine on -CURRENT (Tue Sep 19 >>>08:33:01 SAST 2006), 4.11-STABLE, and just about everything in >>>between. I've not had to change the code substantially to make it >>>work on newer BSDs. All our VoIP goes through this piece of code: >>> >>> memset(&from, '\0', sizeof from); >>> from.sin_addr.s_addr = INADDR_ANY; >>> from.sin_port = config.tuns[config.tun].fw_rule; >>> while (tot + ntohs(hdr->length) <= (p - buf + in)) { >>> out = sendto(config.tuns[config.tun].div_fd, buf + > > tot, > >>> ntohs(hdr->length), 0, (struct sockaddr *)&from, >>> sizeof(addr)); >>> ... >>> >>> >> >>Well, its interesting ... 6.1 appears to work.. but 7.0 does not.. >> >>Now I don't think the code we have does anything with setting the >>sin_port like you do (to config.tuns[]...) > > > All that does is tell the divert socket which (ipfw) rule to inject > the packet after. If you read from the divert socket, do stuff(tm) > and write back to the divert socket, preserve the struct sockaddr > *from from the recvfrom() call and use that same data in the sendto() > call unless you want processing in the stack to start afresh for > the packet. (I'm sure others will correct that statement, but > that's my poor-man's understanding) Well.. looking at the code, I think we leave this untouched from the recv... that way it re-injects (in theory) at the same place it came out.. (which is what we want).. > > I've found that not zeroing these network structures before use > confounds things, because you might not initialise all the elements. > If my memory serves correctly, I think that these structures have > changed size between 6 and 7, but take my saying so with a pinch > of salt because I haven't checked recently. I will go poke around some more when I have time.. I was able to finish my needed UnitTest without the second tunnel up... so I am ok for now.. but I do want to circle back and see if its truely an app bug.. or a problem with the divert code... Very interesting in any case :-) R > > Ian > > -- > Ian Freislich > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell)