Date: Mon, 09 May 2005 10:43:40 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: patrickdk@patrickdk.com Cc: freebsd-net@freebsd.org Subject: Re: tap interface and locally generated packets Message-ID: <427FA14C.30805@savvis.net> In-Reply-To: <Pine.LNX.4.62.0505090230001.19060@server.dswett.patrickdk.com> References: <Pine.LNX.4.62.0505081401540.31842@server.dswett.patrickdk.com> <427E3336.3040907@savvis.net> <Pine.LNX.4.62.0505090230001.19060@server.dswett.patrickdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?427FA14C.30805>