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
| ||
|
Message-ID: <CAKwN9=AtFWADVRFXJROGJxF9g_3O_t9sWTRP3T9G1amzdaGMdA@mail.gmail.com> Date: Tue, 16 May 2017 08:01:34 -0700 From: Ihar Hrachyshka <ihrachys@...hat.com> To: "David S. Miller" <davem@...emloft.net> Cc: netdev@...r.kernel.org, Ihar Hrachyshka <ihrachys@...hat.com> Subject: Re: [PATCH] arp: honour gratuitous ARP _replies_ On Mon, May 15, 2017 at 2:16 PM, Ihar Hrachyshka <ihrachys@...hat.com> wrote: > When arp_accept is 1, gratuitous ARPs are supposed to override matching > entries irrespective of whether they arrive during locktime. This was > implemented in commit 56022a8fdd87 ("ipv4: arp: update neighbour address > when a gratuitous arp is received and arp_accept is set") > > There is a glitch in the patch though. RFC 2002, section 4.6, "ARP, > Proxy ARP, and Gratuitous ARP", defines gratuitous ARPs so that they can > be either of Request or Reply type. Those Reply gratuitous ARPs can be > triggered with standard tooling, for example, arping -A option does just > that. > > This patch fixes the glitch, making both Request and Reply flavours of > gratuitous ARPs to behave identically. > > As per RFC, if gratuitous ARPs are of Reply type, their Target Hardware > Address field should also be set to the link-layer address to which this > cache entry should be updated. The field is present in ARP over Ethernet > but not in IEEE 1394. In this patch, I don't consider any broadcasted > ARP replies as gratuitous if the field is not present, to conform the > standard. It's not clear whether there is such a thing for IEEE 1394 as > a gratuitous ARP reply; until it's cleared up, we will ignore such > broadcasts. Note that they will still update existing ARP cache entries, > assuming they arrive out of locktime time interval. > > Signed-off-by: Ihar Hrachyshka <ihrachys@...hat.com> Please disregard this email, I forgot to update the patch version to v2 and provide changelog. I posted (hopefully) correct version. Still learning the process... Ihar
Powered by blists - more mailing lists