netdev - Claimed reduction in ARP table size when ARPD is configured

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

Message-ID: <7FEA3773D8EA0A42B611AB23563EA2F2E9A69D03@HQ-EXCH-7.corp.brocade.com>
Date:	Thu, 23 Jul 2009 14:23:26 -0700
From:	Jeff Haran <jharan@...cade.COM>
To:	netdev <netdev@...r.kernel.org>
Subject: Claimed reduction in ARP table size when ARPD is configured

Johathan Layes,

Your name shows up in the list of maintainers for ARPD, so I am asking you my question. If this is inappropriate, my apologies, please let me know who I could forward the question to.

net/ipv4/Kconfig contains the following text about config ARPD:

"If you say Y here, the kernel's internal ARP cache will never grow to more than 256 entries"

Yet, try as I might, I cannot see where in the kernel sources any #ifdef CONFIG_ARPD'ed code would actually change the maximum size of the kernel resident ARP cache.

Is this statement about the maximum internal ARP cache size when ARPD is configured no longer accurate or am I missing something?

If kernel code did at one time reduce the maximum internal ARP cache size, what is the latest version in which it did?

BTW, I know ARPD is described as obsolete, but we have a use for the notifications it provides that has nothing to do with user space ARP daemons and if it goes away in the future we will deal with it then.

Please response to my email directly, as I do not subscribe to netdev.

Thanks,

Jeffrey Haran
Brocade Communications
--
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