netdev - Re: Missing IPv4 routes

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:	Fri, 23 Oct 2015 15:32:24 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Brian Rak <brak@...tr.com>, netdev@...r.kernel.org
Subject: Re: Missing IPv4 routes

On 10/23/2015 02:34 PM, Brian Rak wrote:
> I've got a weird situation here.  I have a route that the kernel knows
> about, but won't display via the general RTM_GETROUTE call, but will
> display if I query for that particular route:
>
> # ip -4 route show | grep 108.61.171.x

The use of 'x' here is going to make things confusing.  I assume you are 
using a value of 0 here, or is this a route to a specific IP address 
that you have.  If not you should be using a 0 for all bits that would 
be outside of your subnet mask.

> # ip route get 108.61.171.x
> 108.61.171.x dev MYIF
>      cache

The 'x' being the actual value here should work as this will perform a 
lookup as I recall.

> # cat /proc/net/route | grep 108.61.171.x

The IPs are in network order and as just hex so this won't work.

> # cat /proc/net/route  | grep -i 6c3dac

The byte ordering you are using is backwards here from what I can tell. 
  So it should be ac3d6c you are checking for, not the other way around. 
  So for example if I was using 192.168.1.x I would want to look for 01A8C0.

> # ip route add 108.61.171.x dev MYIF
> RTNETLINK answers: File exists
> # ip route del 108.61.171.x  <---- it deletes successfully once
> # ip route del 108.61.171.x
> RTNETLINK answers: No such process
>

So at least we have the routes in the FIB.  It looks like this just 
might be a display issue.

> This is on a machine running 4.1.3, but I have seen it on earlier
> versions in the past.
>
> I don't have great reproduction steps here, I've seen this 4-5 times in
> the past few months (on different hardware).  So far, I haven't really
> found any way of fixing it (deleting and readding the route has no
> effect).  I thought at first this might be related to
> e55ffaf457bcc8ec4e9d9f56f955971f834d65b3, but as far as I can tell that
> only relates to /proc/net/route.
>
> Any suggestions on further troubleshooting here?  I'm all out of ideas
> (and since I can't easily reproduce it yet, I can't reboot to a newer
> kernel to see if it goes away)

How many routes do you have on your system?  I'm just wondering if it 
might be possible that the route could be at a boundary for the dump 
call and if it might be possibly losing the data there.  Although I 
would expect

Also have you tried double checking to verify that grep isn't somehow 
missing the line?

- Alex

--
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