[Bug 284625] pf NAT with SMSC9512/9514 drops packets when RXCSUM is enabled (default setting)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284625

            Bug ID: 284625
           Summary: pf NAT with SMSC9512/9514 drops packets when RXCSUM is
                    enabled (default setting)
           Product: Base System
           Version: 14.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: jd@eyb.com.br

The system under test is a Raspberry Pi 3B+, using the internal ethernet port,
which is connected to the USB bus. Here's the dmesg for the kernel module:

smsc0 on uhub1
smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus1
smsc0: chip 0xec00, rev. 0002
miibus0: <MII bus> on smsc0
smscphy0: <SMC LAN8700 10/100 interface> PHY 1 on miibus0
smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <USB Ethernet> on smsc0
smsc0: chip 0xec00, rev. 0002

and the usbconfig for the device:

ugen1.3: <SMSC9512/9514 Fast Ethernet Adapter Microchip Technology, Inc.
(formerly SMSC)> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA)

Networking works fine on the host. When I set up some jails using Bastille,
with localhost networking (bastille0), I can send packets just fine (like
trying to "host mit.edu") and get a reply on the interface, but the jail does
not see the reply packet. This happens for both TCP and UDP. I get the logs
using this in pf.conf:

nat log(all) on $ext_if from <jails> to any -> ($ext_if:0)

and then

tcpdump -i pflog0

I then did the exact same setup but connecting via a wifi interface (wlan0,
with ue0 disconnected) and it worked as expected (proper network access from
inside the jails, NAT working fine). I tried it with another external USB
ethernet adapter, and it also worked fine. So while debugging this, I tried
disabling RXCSUM on the ue0 interface, and the NATed reply packets instantly
started going through to the jails. So AFAICT there is some conflict between
the expected checksum and the computed one, and the packets are dropped during
the NAT reply processing.

Please let me know if you need any testing.

cheers,
jd

-- 
You are receiving this mail because:
You are the assignee for the bug.