From owner-freebsd-net@FreeBSD.ORG Tue May 10 00:52:00 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 17F9D16A4F6 for ; Tue, 10 May 2005 00:52:00 +0000 (GMT) Received: from mss1.myactv.net (mss1.myactv.net [24.89.0.26]) by mx1.FreeBSD.org (Postfix) with SMTP id 7BDCC43D4C for ; Tue, 10 May 2005 00:51:59 +0000 (GMT) (envelope-from patrickdk@patrickdk.com) Received: (qmail 20787 invoked from network); 10 May 2005 00:51:58 -0000 Received: from dyn-19-218.myactv.net (24.89.19.218) by new.mss1.myactv.net with SMTP; 10 May 2005 00:51:58 -0000 Date: Tue, 10 May 2005 00:51:58 +0000 (UTC) From: Patrick Domack X-X-Sender: dswett@server.dswett.patrickdk.com To: Maksim Yevmenkin In-Reply-To: <427FB9ED.6010607@savvis.net> Message-ID: References: <427FA14C.30805@savvis.net> <427FB9ED.6010607@savvis.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org cc: patrickdk@patrickdk.com Subject: Re: [PATCH] Re: tap interface and locally generated packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: patrickdk@patrickdk.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2005 00:52:00 -0000 Yes, this works, atleast on my development system. Thanks. On Mon, 9 May 2005, Maksim Yevmenkin wrote: > Dear Hackers, > > could someone please take/try a look at the attached patch? since i do not > have a card that is capable of hardware checksumming i can not test it here. > > thanks, > max > > Maksim Yevmenkin wrote: >> 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 >>>> >>>> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >