[PATCH] Re: tap interface and locally generated packets

[Patrick Domack]

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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
>