bugzilla-daemon at netfilter.org
2014-May-21 17:28 UTC
[Bug 945] New: Transmit performance regression with NAT and 3.14
https://bugzilla.netfilter.org/show_bug.cgi?id=945
Summary: Transmit performance regression with NAT and 3.14
Product: netfilter/iptables
Version: unspecified
Platform: x86_64
URL: http://www.linuxquestions.org/questions/linux-networki
ng-3/linux-router-non-local-uploads-have-horrible-perf
ormance-4175505617/
OS/Version: other
Status: NEW
Severity: major
Priority: P3
Component: NAT
AssignedTo: netfilter-buglog at lists.netfilter.org
ReportedBy: rpower at sysreset.com
Estimated Hours: 0.0
The short version is I have a Linux router running PPPoE on a DSL modem in
bridge mode. This is a Slackware64 machine.
Everything works great on the router itself but the problem is anything else on
the LAN using this machine as a router has crap upload performance. WAN
downloads via the LAN are unimpaired and run at the maximum DSL speed. Uploads
from the router itself will hit ~550KBps. Uploads from any other machine on
the LAN to the WAN struggle to exceed 10KBps. Wireshark/tcpdump show a massive
number of retransmits on client machines, but only when trying to send data
over the WAN. Oddly none of these retransmit packets seem to be passing though
ppp0.
Transfers to and from the router over the local LAN will hit the line speed, so
it's not related to the switch or eth0. On a whim I've also replaced the
network cards in several machines as well as the switch to no avail. Turning
off network offload on all devices has no impact as well. The MTU is set the
same on all devices.
I've tried a couple different kernel versions, and I'm fairly certain
the
change that broke things was in 3.14.0.
Currently I've tested the following:
3.10.40: OK
3.12.20: OK
3.13.11: OK
3.14.0: FAIL
3.14.4: FAIL
--
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
bugzilla-daemon at netfilter.org
2014-May-21 17:34 UTC
[Bug 945] Transmit performance regression with NAT and 3.14
https://bugzilla.netfilter.org/show_bug.cgi?id=945 --- Comment #1 from Ryan Power <rpower at sysreset.com> 2014-05-21 19:34:47 CEST --- My iptables settings are as follows: /usr/sbin/iptables --flush /usr/sbin/iptables -t nat --flush /usr/sbin/iptables -t mangle --flush /usr/sbin/iptables -A INPUT -i ppp0 -s 10.0.0.0/8 -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -s 127.0.0.0/8 -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -s 169.254.0.0/16 -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -s 172.16.0.0/12 -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -s 192.168.0.0/16 -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -m state --state INVALID -j NFLOG --nflog-group 0 /usr/sbin/iptables -A INPUT -i ppp0 -m state --state INVALID -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -p icmp -m icmp --icmp-type address-mask-request -j NFLOG --nflog-group 1 /usr/sbin/iptables -A INPUT -i ppp0 -p icmp -m icmp --icmp-type address-mask-request -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -p icmp -m icmp --icmp-type timestamp-request -j NFLOG --nflog-group 1 /usr/sbin/iptables -A INPUT -i ppp0 -p icmp -m icmp --icmp-type timestamp-request -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -p icmp -m icmp --icmp-type any -m limit --limit 5/second -j ACCEPT /usr/sbin/iptables -A INPUT -i ppp0 -p tcp -m multiport --dports 25,80,443,993 -j ACCEPT /usr/sbin/iptables -A INPUT -i ppp0 -p udp -m multiport --dports 1,67,513 -j DROP /usr/sbin/iptables -A INPUT -i ppp0 -m state --state NEW -j NFLOG --nflog-group 0 /usr/sbin/iptables -A INPUT -i ppp0 -m state --state NEW -j DROP /usr/sbin/iptables -P FORWARD DROP /usr/sbin/iptables -A FORWARD -i ppp0 -d 10.0.0.0/8 -j ACCEPT /usr/sbin/iptables -A FORWARD -i eth0 -s 10.0.0.6 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu /usr/sbin/iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j ACCEPT /usr/sbin/iptables -A FORWARD -j NFLOG --nflog-group 1 /usr/sbin/iptables -A POSTROUTING -t nat -o ppp0 -j SNAT --to X.X.X.X -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
bugzilla-daemon at netfilter.org
2014-May-21 17:42 UTC
[Bug 945] Transmit performance regression with NAT and 3.14
https://bugzilla.netfilter.org/show_bug.cgi?id=945 --- Comment #2 from Ryan Power <rpower at sysreset.com> 2014-05-21 19:42:52 CEST --- I've verified that this problem occurs with both SNAT and MASQUERADE targets. -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
bugzilla-daemon at netfilter.org
2014-May-21 19:38 UTC
[Bug 945] Transmit performance regression with NAT and 3.14
https://bugzilla.netfilter.org/show_bug.cgi?id=945
Ryan Power <rpower at sysreset.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #3 from Ryan Power <rpower at sysreset.com> 2014-05-21
21:38:07 CEST ---
Please disregard this bug entry, this appeared to have been fixed in the
following patch:
http://patchwork.ozlabs.org/patch/339082/
Vlad Yasevich - April 14, 2014, 9:37 p.m.
Sometimes, when the packet arrives at skb_mac_gso_segment()
its skb->mac_len already accounts for some of the mac lenght
headers in the packet. This seems to happen when forwarding
through and OpenSSL tunnel.
When we start looking for any vlan headers in skb_network_protocol()
we seem to ignore any of the already known mac headers and start
with an ETH_HLEN. This results in an incorrect offset, dropped
TSO frames and general slowness of the connection.
We can start counting from the known skb->mac_len
and return at least that much if all mac level headers
are known and accounted for.
Fixes: 53d6471cef17262d3ad1c7ce8982a234244f68ec (net: Account for all vlan
headers in skb_mac_gso_segment)
CC: Eric Dumazet <eric.dumazet at gmail.com>
CC: Daniel Borkman <dborkman at redhat.com>
Tested-by: Martin Filip <nexus+kernel at smoula.net>
Signed-off-by: Vlad Yasevich <vyasevic at redhat.com>
---
net/core/dev.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.