On Thu, 16 Feb 2017 22:16:49 +0800 Sepherosa Ziehau <[email protected]> wrote:
> Please test the following patch: > https://leaf.dragonflybsd.org/~sephe/re_193.diff First, I'm sorry to not report this earlier, but until now I haven't time to analyze this more thoroughly. I've experienced two problems with new re(4). In fact, the problems haven't been introduced by recent driver update (from 1.92 to 1.93), but appeared already with previous major driver overhaul (commit e5a5a43+, "re: Leverage Realtek driver's chip/PHY initialization/reset."). First "problem" is trivial typo that prevents txcsum capability to be turned off. See attached diff. Second problem is more tough (or weird, I'd say), and AFAICT is related to txcsum. New re(4) with txcsum turned on (which is default) seems to create, under some circumstances, malformed UDP packets. In particular, I'm hitting this with openvpn client that connects to a server via linux-based router. The client side never gets any response packet from the server because all initial packets are being dropped by the router. After turning txcsum off, vpn connection is initiated successfuly. Also, with re(4) driver from pre-e5a5a43+, there is no problem with vpn connection, even with txcsum turned on. OTOH, other UDP packets do not seem to have these problems on new re(4). For example DNS queries generated with drill(1) are not dropped by the router and are correctly answered. As I've said... weird. -- Dan
diff --git a/sys/dev/netif/re/if_re.c b/sys/dev/netif/re/if_re.c index cfb9a8292..5e540e70d 100644 --- a/sys/dev/netif/re/if_re.c +++ b/sys/dev/netif/re/if_re.c @@ -1890,7 +1890,7 @@ re_ioctl(struct ifnet *ifp, u_long command, caddr_t data, struct ucred *cr) if (ifp->if_capenable & IFCAP_TXCSUM) sc->re_tx_cstag = 1; else - sc->re_rx_cstag = 0; + sc->re_tx_cstag = 0; if (mask && (ifp->if_flags & IFF_RUNNING)) re_init(sc);
