CFT: Realtek network driver update

[Sepherosa Ziehau]

On Fri, Feb 24, 2017 at 4:57 AM, Daniel Bilik <ddb at neosystem.org> wrote:
> On Thu, 16 Feb 2017 22:16:49 +0800
> Sepherosa Ziehau <sepherosa at gmail.com> 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