netdev - Re: Bug#708995: iptables firewall is dropping GRO'd packets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 21 May 2013 01:28:43 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	netdev <netdev@...r.kernel.org>
Cc:	708995@...s.debian.org
Subject: Re: Bug#708995: iptables firewall is dropping GRO'd packets

I'm seeing packet loss when forwarding from a LAN to PPP, whenever GRO
kicks in on the LAN interface.

On Mon, 2013-05-20 at 05:48 +0100, Ben Hutchings wrote:
[...]
> The Windows system is connected to the LAN interface (int0).  Turning
> off GRO on this interface works around the problem.  But since GRO is
> on by default, it clearly ought to work properly with iptables.
> 
> I'll try to work out where the drops are occurring, but the
> perf net_dropmonitor script is also broken...
[...]

I've fixed that script and now I can see that it's not iptables but
tbf_enqueue() that is dropping the GRO'd packets.  I do traffic-shaping
on the PPP link like this:

tc qdisc replace dev ppp0 root tbf rate 420kbit latency 50ms burst 1540

The local TCP will never generate an skb larger than the burst size
because it knows the PPP interface can't do GSO or TSO.  And the wifi
network doesn't seem to be fast enough for GRO to have much of an
effect.  But a peer on the wired network can trigger GRO and this
produces an skb that exceeds the burst size.

Is this a bug in sch_tbf, or should I accept it as a limitation?  It
seems like it should do GSO on entry to the queue if necessary.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)