kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke
wrong dst MAC in TCP packets
Dennis Yusupoff
dyr at smartspb.net
Wed Dec 30 10:40:04 UTC 2009
The following reply was made to PR kern/141843; it has been noted by GNATS.
From: Dennis Yusupoff <dyr at smartspb.net>
To: pyunyh at gmail.com
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/141843: [em] [vlan] Intel txcsum and assigned vlan invoke
wrong dst MAC in TCP packets
Date: Wed, 30 Dec 2009 13:34:30 +0300
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig42235F443B11536DEDB37A0B
Content-Type: multipart/alternative;
boundary="------------060207040500050208050702"
This is a multi-part message in MIME format.
--------------060207040500050208050702
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
29.12.2009 21:51, Pyun YongHyeon ?????:
> On Mon, Dec 21, 2009 at 11:53:22PM +0000, linimon at freebsd.org wrote:
> =20
>> Old Synopsis: Intel txcsum and assigned vlan invoke wrong dst MAC in T=
CP packets
>> New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong =
dst MAC in TCP packets
>>
>> Responsible-Changed-From-To: freebsd-bugs->freebsd-net
>> Responsible-Changed-By: linimon
>> Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009
>> Responsible-Changed-Why:=20
>> Over to maintainer(s).
>>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D141843
>> =20
> I'm not sure whether you're seeing one of edge case of em(4)/igb(4)
> checksum offload issue. Personally I couldn't reproduce the issue
> but I guess the checksum offload/TSO handling might cause
> unexpected result. If you disable Tx checksum offload or TSO em(4)
> work as expected, right?=20
Not exactly.
Only checksum offload gives this issue, TSO on/off doesn't matter.
By the way, we checked UDP also and found something interested.
For it, we run echo service on server ("|echo dgram udp wait =20
root internal|" in //etc/inetd.conf/) and send strings by "|nc -4 -u
server 7|" from client.
So...UDP works fine before, while and after "ifconfig vlanX vlan X
vlandev em0" command given at server. And the most interesting things is
what while server "hangs" for TCP-connections, "establishing" UDP
connections between client and server...helps it to "unhang" TCP, so it
begins to works correctly.
> If so, would you try the following patch
> and let me know whether it makes any difference?
>
> http://people.freebsd.org/~yongari/em.csum_tso.20091229.patch
> =20
Doesn't help, same behavior. And moreover, UDP also doesn't "help" and
doesn't work so.
If you'd like, I could give you an access to this server via SSH, would y=
ou?
--------------060207040500050208050702
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
<title></title>
</head>
<body bgcolor=3D"#ffffff" text=3D"#000000">
29.12.2009 21:51, Pyun YongHyeon пишет:
<blockquote cite=3D"mid:20091229185119.GF1166 at michelle.cdnetworks.com"
type=3D"cite">
<pre wrap=3D"">On Mon, Dec 21, 2009 at 11:53:22PM +0000, <a class=3D"mo=
z-txt-link-abbreviated" href=3D"mailto:linimon at freebsd.org">linimon at freeb=
sd.org</a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"">Old Synopsis: Intel txcsum and assigned vlan invoke wr=
ong dst MAC in TCP packets
New Synopsis: [em] [vlan] Intel txcsum and assigned vlan invoke wrong dst=
MAC in TCP packets
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Dec 21 23:51:33 UTC 2009
Responsible-Changed-Why:=20
Over to maintainer(s).
<a class=3D"moz-txt-link-freetext" href=3D"http://www.freebsd.org/cgi/que=
ry-pr.cgi?pr=3D141843">http://www.freebsd.org/cgi/query-pr.cgi?pr=3D14184=
3</a>
</pre>
</blockquote>
<pre wrap=3D"">
I'm not sure whether you're seeing one of edge case of em(4)/igb(4)
checksum offload issue. Personally I couldn't reproduce the issue
but I guess the checksum offload/TSO handling might cause
unexpected result. If you disable Tx checksum offload or TSO em(4)
work as expected, right? </pre>
</blockquote>
Not exactly.<br>
Only checksum offload gives this issue, TSO on/off doesn't matter.<br>
By the way, we checked UDP also and found something interested.<br>
For it, we run echo service on server ("<code>echo dgra=
m udp
wait root internal</code>" in <=
i>/etc/inetd.conf</i>) and send
strings by "<code>nc -4 -u server 7</code>" from client.<br>
So...UDP works fine before, while and after "ifconfig vlanX vlan X
vlandev em0" command given at server. And the most interesting things
is what while server "hangs" for TCP-connections, "establishing" UDP
connections between client and server...helps it to "unhang" TCP, so it
begins to works correctly.<br>
<br>
<blockquote cite=3D"mid:20091229185119.GF1166 at michelle.cdnetworks.com"
type=3D"cite">
<pre wrap=3D"">If so, would you try the following patch
and let me know whether it makes any difference?
<a class=3D"moz-txt-link-freetext" href=3D"http://people.freebsd.org/~yon=
gari/em.csum_tso.20091229.patch">http://people.freebsd.org/~yongari/em.cs=
um_tso.20091229.patch</a>
</pre>
</blockquote>
Doesn't help, same behavior. And moreover, UDP also doesn't "help" and
doesn't work so.<br>
<br>
If you'd like, I could give you an access to this server via SSH, would
you?<br>
</body>
</html>
--------------060207040500050208050702--
--------------enig42235F443B11536DEDB37A0B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJLOyy2AAoJEBUTaqBS2NB4Le8IAIkQsJHiS2y3JjHRmYK/2OFz
jHtHZGOnWw8cHzR275Sr75Os1z8hTJCwDhPwaMaqAr45pA+zg6E9QkKlr3ZbEPgW
PNoxdIo+HN7xqJFAt9ye8BviE/HC0gelRSf0rUdc+qS2sR1MH7Pwa8uNwgg1/bpy
BMNPWBjCAmsvx5AyaUi7zuGDzhz0UUMcO+k7DlXnJO1GX8ABR6T4mdU2ZzXYGGk7
e5oaT2++ezm5nKN/ABfseQ3UXzG10gv7N0H+4FpWJD5H1lm0pw3tphHGehzbwzBV
6YZmMYq0dHw+E4X5Ybbxe/jnrEsw2aeZdDIfBEqyOgGsudW/7j9zF/VsJPbY57g=
=tVqG
-----END PGP SIGNATURE-----
--------------enig42235F443B11536DEDB37A0B--
More information about the freebsd-net
mailing list