tap interface and locally generated packets

[Patrick Domack]

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.

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.

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
>
>