netdev - Re: [RFC PATCH] dont create cached routes from ARP requests

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, 24 Sep 2010 18:05:52 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ulrich Weber <uweber@...aro.com>
Cc:	Ulrich Weber <ulrich.weber@...glemail.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] dont create cached routes from ARP requests

Le vendredi 24 septembre 2010 à 17:38 +0200, Ulrich Weber a écrit :
> Yes, as I wrote before my Cable ISP is flooding me with
> ARP requests from 10.0.0.0/8, which get a route
> via the primary PPP link.
> 
> I know thats not a common setup but why do that
> kind of routes have to be cached ? :)
> 
> 
> steps to reproduce:
> server:
>  ip route add 1.0.0.0/8 dev dummy0
> 
> client:
>  ip route add 1.0.0.0/8 dev eth0
>  nmap --min-rate 500 -sP 1.0.0.0/8
> 

Great, you use nmap and fill 'client' neighbour cache.

Now, back to the _real_ problem, please ?

<quote>

Background: At home I have two Internet connections, DSL and Cable.
DSL is the primary uplink while Cable is the secondary.
My Cable ISP is flooding me with ARP request from 10.0.0.0/8,
which creates routes via the primary uplink.
There are thousands of cached routes and after some time
I get "Neighbour table overflow" messages.

</quote>

You receive an ARP request on device eth1,
this creates a route on eth0 ?

Could you send your routing/address setup ?

ip addr
ip ro

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