netdev - Re: [DANGER 8/7]: ipv4: Cache output routes in fib

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, 12 Jul 2012 17:52:54 -0700
From:	Vijay Subramanian <subramanian.vijay@...il.com>
To:	David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>
Subject: Re: [DANGER 8/7]: ipv4: Cache output routes in fib_info nexthops.

>
> Something is flaky about it, when I ssh into my test system
> for the first time after a boot there is a strange delay of
> some sort.  It's as if the SYN-ACK is dropped on the way out
> of the test machine, and my desktop has to retry the initial
> SYN.  I plan to investigate this after some sleep.

Dave,
I applied these patches and got the same symptoms. It takes a long
time for ssh to work right after boot but it starts working after
about a minute.
(I am sshing into the machine with the patches applied). My  knowledge
of routing code is rudimentary but I traced the following.

 I think this is because the SYN packets do not even reach the TCP
handler. It looks like ip_route_input_slow() sets the dst.input
function to ip_error().

The code path I saw was as follows:
ip_rcv_finish() eventually calls ip_route_input_slow() wherein
fib_lookup() initially returns a res.type of RTN_UNICAST (why not
RTN_LOCAL?).
However, the following code
 if (!IN_DEV_FORWARD(in_dev))
                goto no_route;

is executed and sets the res.type to RTN_UNREACHABLE.
After the jump to local_input, rth->dst.input is set first to
ip_local_deliver() but again to ip_error().
Due to this, the SYN packet does not even make it to ip_local_deliver
and so the TCP handler is never called.

I did not get a chance to see why it suddenly starts working. Hope
this helps. I will dig around more.

Thanks,
Vijay
--
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