netdev - Re: Problem with fragmented packets on tun/tap interface

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Aug 2015 12:52:05 +0530
From:	Prashant Upadhyaya <praupadhyaya@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: Problem with fragmented packets on tun/tap interface

On Fri, Jul 31, 2015 at 4:51 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Fri, 2015-07-31 at 16:42 +0530, Prashant Upadhyaya wrote:
>> On Fri, Jul 31, 2015 at 1:26 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>> > On Fri, 2015-07-31 at 12:30 +0530, Prashant Upadhyaya wrote:
>> >
>> >> The delays work for me but is clearly not good for the performance of
>> >> the slow path. And more importantly, I was looking for a fundamental
>> >> reason regarding why it works with delays and why not without it. The
>> >> issue is reproducible with a big ping (3.11.10-301.fc20.x86_64)
>> >
>> > How big ping needs to be to reproduce the problem ?
>> >
>> >
>>
>> If the MTU is 1500, I start getting problems anywhere starting from
>> 2900 bytes and surely comes when further big pings are used eg. 10 K.
>> (ping <IP> -s <Size> eg. ping 10.3.10.244 -s 10000)
>> And the big pings do work, as I said, with the delay hack.
>
> It might help trying this while you receive such frags :
>
> perf record -a -g skb:kfree_skb sleep 10
>
> ...
>
> perf report
>
>
>

Hi,

I think I have a clue to the root cause of my issue, but I do not know
a solution.
Let me describe what I think is the problem.

Fragmented packets enter into the kernel through eth0 and the kernel
starts assembling them.
Simultaneously, my packet socket implementation also injects the very
same packets into the kernel via the tap. The kernel sees them as
overlapped packets during assembly and drops the packets injected via
the tap.
Eventually when the assembly gets complete inside kernel for all the
packets which entered via eth0, the whole packet gets dropped due to
the iptables rules that I have set on eth0.
So naturally there is no response to the bigger ping, because
everything got dropped one way or the other.

When I do introduce the delays (and it turns out that the delay that
matters is when injecting via tap), the kernel has already completed
the assembly of the packets via eth0 (during the delay I introduce for
submission on tap), and then the submission via tap works well because
it undergoes a fresh assembly (and ofcourse it does not get dropped
because iptables drop rule is only on eth0)

Now then, the question is -- how do I prevent the kernel from trying
to assemble the packets arriving on eth0 and drop them right away even
before assembly is attempted. This way the same packet injected via
the tap would be the only one undergoing assembly and hopefully it
would work.

Regards
-Prashant
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html