netdev - Re: Route cache problem.

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

Message-ID: <20111118081734.GA25843@bitwizard.nl>
Date:	Fri, 18 Nov 2011 09:17:35 +0100
From:	Rogier Wolff <R.E.Wolff@...Wizard.nl>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	linux-kernel@...r.kernel.org, netdev <netdev@...r.kernel.org>
Subject: Re: Route cache problem.

On Thu, Nov 03, 2011 at 04:16:50PM +0100, Eric Dumazet wrote:
> Le jeudi 03 novembre 2011 à 15:37 +0100, Rogier Wolff a écrit :
> > Hi, 
> > 
> > My workstation has an incorrect route cache entry: 
> > 
> 
> What kernel version ?

Linux version 3.0.0-12-generic (from Ubunutu oneiric.)

> > assurancetourix:~> route -nC | head -2 ; route -nC | grep 234.34
> > Kernel IP routing cache
> > Source          Destination     Gateway         Flags Metric Ref    Use Iface
> > 192.168.235.8   192.168.234.34  192.168.235.251       0      0        3 eth0
> > 192.168.235.8   192.168.234.34  192.168.235.251       0      0        4 eth0
> > 192.168.235.8   192.168.234.34  192.168.235.251       0      0        2 eth0
> > 
> > (I don't know why there are three). 

Today there are four. 
> 192.168.20.108  10.37.168.112   192.168.20.254        0      1        2 eth3

That indeed got me a full complement of route cache entries. 

> Better use "ip -s route list cache" to diagnose problems (more
> information)

After doing the tos ping you suggested All TOS levels have a route
cache entry. 

192.168.234.34 from 192.168.235.8 tos 0x1c via 192.168.235.251 dev eth0 
    cache <redirected>  age 77sec ipid 0xaa09 rtt 47ms rttvar 15ms ssthresh 7 cwnd 9
192.168.234.34 tos 0x1c via 192.168.235.251 dev eth0  src 192.168.235.8 
    cache <redirected>  used 3 age 72sec ipid 0xaa09 rtt 47ms rttvar 15ms ssthresh 7 cwnd 9
192.168.234.34 from 192.168.235.8 tos 0x1c via 192.168.235.251 dev eth0 
    cache <redirected>  age 72sec ipid 0xaa09 rtt 47ms rttvar 15ms ssthresh 7 cwnd 9

> > Any suggestions? Any at all?

Last time, as well as this time, it is triggered by a network error
that leads to the 192.168.235.4 router not being able to reach 
192.168.234.34 or any other host on the 192.168.234.0/24 network. 

During that time the VPN to 192.168.234.0/24 is down, so 192.168.235.4
doesn't have a route to 192.168.234.0/24 and it is logical that
with that route gone, it sends packets for 192.168.234.0/24 to the default
router 192.168.235.251. As it sees itself forwarding packets that come
in on eth0 back to eth0, it will send a redirect. However that redirect
should somehow expire, and not survive things like dropping the route
to 192.168.234.0/24, dropping the default route, shutting down the 
interface or some time passing (that network problem was solved 20 
hours ago)...... 

	Roger. 

-- 
** R.E.Wolff@...Wizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
--
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