From owner-freebsd-net@FreeBSD.ORG Mon May 9 17:43:58 2005 Return-Path: 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 F41F216A4E9 for ; Mon, 9 May 2005 17:43:57 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49A3243D99 for ; Mon, 9 May 2005 17:43:57 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 9277E3BECD; Mon, 9 May 2005 12:43:56 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16245-01-48; Mon, 9 May 2005 12:43:56 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id 5AD143BEB7; Mon, 9 May 2005 12:43:56 -0500 (CDT) Received: from s228130hz1ew171.apptix-01.savvis.net ([10.146.4.29]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 12:43:52 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew171.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 12:43:42 -0500 Message-ID: <427FA14C.30805@savvis.net> Date: Mon, 09 May 2005 10:43:40 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: patrickdk@patrickdk.com References: <427E3336.3040907@savvis.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 May 2005 17:43:42.0163 (UTC) FILETIME=[A3FBBA30:01C554BE] X-Virus-Scanned: amavisd-new at savvis.net cc: freebsd-net@freebsd.org Subject: Re: tap interface and locally generated packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 17:43:58 -0000 Patrick, > Yes, ifconfig -txcsum fixes the problem, so somewhere packets are not > getting marked to be summed if the hardware checksum is turned on, > and packets don't go to the hardware card, but head to the tap > interface instead. i do not know how your network is setup exactly, but i would guess that your ethernet bridge contains both tap and physical ethernet card that is capable of hardware ip checksumming. if the above guess is correct then what probably happens is: 1) packet goes out 2) because physical ethernet card can do ip checksumming, ip checksum is not calculated 3) the packet hits the bridge 4) tap gets a copy of the packet without ip checksum 5) openvpn/whatever reads the packet and sends it over the network 6) remote peer gets the packet without ip checksum and drops it > This will work for a for alittle while, but as these are high usage, > gigabit links, and tend to have alot of traffic on them, where as > the tap interface is low load. It could cause a descent amount of cpu > load. Thanks. again, the problem is not in the tap(4) (imo). because physical ethernet card is capable of hardware ip checksumming, ip checksum is not generated until the packet is about to be transmitted over the wire. ethernet bridge(4) just picks the packet earlier. it is possible (imo) to ensure that packets that go out on the tap interface have proper ip checksum. we could modify tapread() function and check if mbuf packet header has checksum flags. i will look into this and will send you a patch in a few days. in the mean time all ethernet interfaces in the bridge should have the same set of features. thanks, max > > On Sun, 8 May 2005, Maksim Yevmenkin wrote: > >> Patrick, >> >>> I have been working with tap interfaces, bridging and openvpn >>> >>> Bridging works perfectly, and openvpn does too >>> >>> Packet pings from the tap interface works to any ip address, on >>> the local machine or computer on the bridged network >>> >>> Attempting to make a tcp connection works for bridged network, >>> but not the machine the tap interface is on >>> >>> I have found this is due to tcp checksums not being generated, >>> Packets recieved over the tap interface on the client machine >>> have blank (bad) checksums. >>> >>> I have looked at the source and it seems there is no interface to >>> add the checksums to be generated for the tap interface. >> >> >> tap(4) interface should not modify anything inside the packet. the >> whole point is to accept _complete_ ethernet frame from user-space >> (just as it comes from the wire) and pass it up the stack. >> >> my guess would be that something else is not generating proper ip >> checksum. just a crazy thought: are you offloading ip checksum'ing >> to your ethernet card? if so, please try to disable it and see if >> it helps. >> >> thanks, max >> >>