diff options
| author | Jon Maloy <jmaloy@redhat.com> | 2025-10-23 21:29:28 -0400 |
|---|---|---|
| committer | Stefano Brivio <sbrivio@redhat.com> | 2025-10-30 12:01:01 +0100 |
| commit | 7917155ba259185bf6a7a83f5d09cad267a6951f (patch) | |
| tree | 75528c0068fe2a713fb4d328280bb196cfc1a41b /test | |
| parent | e456c02a0e84bedba8011a6c0b6659a7409ad14b (diff) | |
| download | passt-7917155ba259185bf6a7a83f5d09cad267a6951f.tar passt-7917155ba259185bf6a7a83f5d09cad267a6951f.tar.gz passt-7917155ba259185bf6a7a83f5d09cad267a6951f.tar.bz2 passt-7917155ba259185bf6a7a83f5d09cad267a6951f.tar.lz passt-7917155ba259185bf6a7a83f5d09cad267a6951f.tar.xz passt-7917155ba259185bf6a7a83f5d09cad267a6951f.tar.zst passt-7917155ba259185bf6a7a83f5d09cad267a6951f.zip | |
arp/ndp: send ARP announcement / unsolicited NA when neigbour entry added
ARP announcements and unsolicited NAs should be handled with caution
because of the risk of malignant users emitting them to disturb
network communication.
There is however one case we where we know it is legitimate
and safe for us to send out such messages: The one time we switch
from using ctx->own_tap_mac to a MAC address received via the
recently added neigbour subscription function. Later changes to
the MAC address of a host in an existing entry cannot be fully
trusted, so we abstain from doing it in such cases.
When sending this type of messages, we notice that the guest accepts
the update, but shortly later asks for a confirmation in the form of
a regular ARP/NS request. This is responded to with the new value,
and we have exactly the effect we wanted.
This commit adds this functionality.
Signed-off-by: Jon Maloy <jmaloy@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
[sbrivio: Fix "announcment" typo in arp_announce()]
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions
