[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100119211818.28f48713@opy.nosense.org>
Date: Tue, 19 Jan 2010 21:18:18 +1030
From: Mark Smith <lk-netdev@...netdev.nosense.org>
To: David Miller <davem@...emloft.net>
Cc: opurdila@...acom.com, ja@....bg, chavey@...gle.com,
netdev@...r.kernel.org
Subject: Re: [net-next PATCH v3] ipv4: allow warming up the ARP cache with
request type gratuitous ARP
Hi Dave,
On Tue, 19 Jan 2010 02:11:38 -0800 (PST)
David Miller <davem@...emloft.net> wrote:
> From: Mark Smith <lk-netdev@...netdev.nosense.org>
> Date: Tue, 19 Jan 2010 10:09:13 +1030
>
> > I don't think this complies with the ARP RFC (RFC826). Walking through
> > the validation steps, Gratuitous ARP seems to only pass if there is an
> > existing entry in the table, otherwise they'd fail, as the target
> > address in the GA packet doesn't match that of the receiving host.
>
> It's fine if it's guarded by the per-device ARP_ACCEPT sysctl which
> defaults to off, and that's what he's doing.
Fair enough.
I wasn't familiar with the ARP_ACCEPT sysctl. It seems that this patch
is not only adding the feature of creating new ARP table entries in
response to GARPs, but is also fixing the ARP implementation because it
looks like the default wasn't to accept GARPs, despite the validation
steps in RFC826 allowing them.
ARP_ACCEPT / the /proc "arp_accept" file is really confusingly named -
unless you knew better I doubt anybody would guess it's only referring
to GARPs. Is there any chance of renaming it or symlinking a new name
of something like "garp_accept" to the old one? Is this a significant
enough behaviour change that it creates that opportunity?
Regards,
Mark.
--
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
Powered by blists - more mailing lists