CFT: Realtek network driver update
Daniel Bilik
ddb at neosystem.org
Thu Feb 23 12:57:41 PST 2017
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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_re-txcsum.diff
Type: text/x-diff
Size: 448 bytes
Desc: not available
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20170223/4b2af451/attachment-0002.bin>
More information about the Users
mailing list