[PATCH] Re: tap interface and locally generated packets

[Julian Elischer]

Maksim Yevmenkin wrote:
> Pyun,
> 
>> I can't sure but bridge(4) seems to have checksum related issues.
>> Here is my theory.
>>
>> Interface A : H/W checksum offloading supported, Have IP address
>> Interface B : no H/W checksum offloading, No IP address assigned
>> Gateway : 192.168.10.1
>>
>>
>>                             | Bridge
>>                +---------------------------+
>>                |                           |
>>            Interface A               Interface B
>>          IP address 192.168.10.5           |
>>                |                           |
>>                |                           |
>>                | Gateway                   | 192.168.10.0/24
>>
>>
>> If one of client in 192.168.10.0/24 connects to bridged host 
>> IP(192.168.10.5)
>> it would get corrupted checksummed packet. Since the interface selected
>> in ip_ouput(), interface A, will indicate HWCSUM offloading ip_output
>> just pass the packet down to the ethernet layer. But in brdige it would
>> be rerouted to interface B. 
> 
> 
> well, i sort of said the same thing in my previous email to Patrick.
> 
>> As you noted I think it's not fault of tap(4). It seems that the correct
>> solution would do S/W checksumming for all bridged interfaces in
>> ip_output. However it's not easy to know the interface selected in
>> ip_output is one of bridged interfaces(lack of if_bridge member
>> in struct ifnet). So I think this is another reason FreeBSD should
>> import OpenBSD/NetBSD bridge driver.
> 
> 
> i think we all agree that there is a problem. the problem is: bridge(4) 
> assumes that _all_ interfaces in a cluster have _the_same_ hardware 
> capabilities (checksum offloading). if at least one interface in a 
> cluster has different capabilities then you are going to have a problem.
> 
> now i'm not sure this assumption if flawed. it is certainly not obvious 
> from the bridge(4) man page and i do not recall seeing this documented 
> anywhere. it is not that hard to use the same type of ethernet cards in 
> one machine. especially  when all modern server motherboards ships with 
> two (or more) on-board ethernet cards.
> 
> Patrick observed one corner case of the problem where one of the 
> interfaces in the bridge happens to be tap(4). in his case other 
> (physical) interface is loaded and turning hardware checksumming off 
> will increase cpu load. my tap(4) patch is a hack, and it only works for 
> ip checksumming. note that some cards can do udp/tcp checksums as well. 
> imo, implementing similar hacks for all ethernet drivers (that do not 
> support hardware checksumming) is wrong. like you said it has to be done 
> at bridge level.
> 
> if you think that porting OpenBSD/NetBSD bridge driver is a good idea 
> you are welcome to submit the patches. imo, it should be possible to fix 
> this in our current bridge(4) implementation. bridge(4) knows where 
> packet is coming from and going to. it could check hardware capabilities 
> of the destination interface and calculate checksums if needed.
> 
> thanks,
> max

the negraph bridge could also be modified to do this..

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