[PATCH] Re: tap interface and locally generated packets

[Maksim Yevmenkin]

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