On Fri, Feb 24, 2017 at 4:57 AM, Daniel Bilik <[email protected]> wrote: > 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. >
Oh, thank you very much! It is committed! > 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. Can you try this patch? https://leaf.dragonflybsd.org/~sephe/re_autopad.diff It's a quick test. BTW, can you give me the dmesg output related to re(4)? Tcpdump output would be helpful, if the patch did not fix your issue. Thanks, sephe -- Tomorrow Will Never Die
