The latest source address seen on the tap interface (ip4.addr_seen) is
taken to be the guest's and is used as the target for inbound port
forwarding. The update accepts any source address.
On a point-to-point tap that is always correct. But when the tap sits on
a shared L2 segment -- for example when it is bridged together with other
hosts -- pasta also sees frames from those other hosts. With a static
configuration (-a / address set, DHCP disabled), an overheard frame from
another host silently moves addr_seen to that host, and every subsequent
inbound forwarded connection is sent there instead of to the guest, so
connections are reset or hang.
I hit this running pasta with its tap enslaved to a Linux bridge that also
carries other traffic: inbound port forwarding to the guest broke as soon
as another address was seen on the segment.
Restrict the update so that, when DHCP is disabled (no_dhcp), only frames
sourced from the configured guest address may move addr_seen. With DHCP
enabled -- the default -- behaviour is unchanged, since the guest's
address is whatever pasta leases and tracking it is still correct.
The same reasoning applies to ip6.addr_seen on a shared segment; I left
IPv6 alone for now since I only exercise IPv4 in this setup, and would be
glad to extend it the same way if you prefer.
Signed-off-by: EJ Campbell