Re: "hme" tcp4csum-rx breaks 'pf' redirection to 'ftp-proxy'

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

On Mon, 14 Sep 2015, Eduardo Horvath wrote:

> On Mon, 14 Sep 2015, Greg Troxel wrote:
> 
> > (I used to have a sparc64 with qfe, but it broke.)
> > 
> > Have you convinced yourself that the interface works ok with rx checksum
> > offloading when pf is not involved?
> > 
> > Over the years there have been multiple cases of "card X firmware Y is
> > buggy with checksum offloading Z".  So this is not shocking.
> 
> HME is a really primitive MAC and doesn't have any firmware.  The rx 
> checksum is simply the checksum of all the bytes in the ethernet packet.  
> The driver needs to take that value and adjust it by whatever bytes in the 
> packet should not be part of the checksum.
> 
> Having said that, I wouldn't be surprised if the h/w accellerated 
> checksumming code in the driver was suffering from code rot.  You should 
> test it without pf and make sure it's working properly.

In the past I have run NetBSD-{4,5,6} with a pair of single hme/nsphy
(RJ45+MII on back panel) as NAT/Firewall with 'pf' and 'ftp-proxy' with
full tcp4csum offload without any problems.

I also ran another system under NetBSD-{3,4} with a single hme/nsphy
card without 'pf' with full tcp4csum offload without problems (my first
experiments with a file server using RAIDframe).

I also regularly run a SWIFT (fast-wide SCSI + hme/nsphy) without 'pf'
with full tcp4csum offload without any problems--both with local-disk
OS and as the root device for diskless operation.

When I was checking out the SUNW,qfe cards, they ran without 'pf' with
tcp4csum offload without problems, including being the root device during
diskless operation ("ifconfig.hme0" just enables "tcp4csum" and "udp4csum"
and nothing else, since the address was already configured by the in-kernel
dhcp client).

Since installing the SUNW,qfe card in my NAT/firewall system, I didn't
notice any problem until updating my package distfiles due to the much
more frequent use of FTP (and the failures that ensued).  So far as I can
see, that's the only aspect of their operation that is affected.

Perhaps I should look deeper (need to dig those SS20s out and poke at
them anyway)?

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645