Date: Tue, 10 May 2005 00:51:58 +0000 (UTC) From: Patrick Domack <patrickdk@patrickdk.com> To: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> Cc: patrickdk@patrickdk.com Subject: Re: [PATCH] Re: tap interface and locally generated packets Message-ID: <Pine.LNX.4.62.0505100051320.2324@server.dswett.patrickdk.com> In-Reply-To: <427FB9ED.6010607@savvis.net> References: <Pine.LNX.4.62.0505081401540.31842@server.dswett.patrickdk.com> <Pine.LNX.4.62.0505090230001.19060@server.dswett.patrickdk.com> <427FA14C.30805@savvis.net> <427FB9ED.6010607@savvis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.62.0505100051320.2324>