CFT: Realtek network driver update
sepherosa at gmail.com
Thu Feb 23 17:43:31 PST 2017
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:
> 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?
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
Tomorrow Will Never Die
More information about the Users