CVSROOT: /cvs
Module name: src
Changes by: s...@cvs.openbsd.org 2018/04/17 12:50:27
Modified files:
sys/netinet : Tag: OPENBSD_6_3 if_ether.c
Log message:
Merge if_ether.c revision 1.235 to 6.3-stable:
revision 1.235
date: 2018/03/31 15:07:09; author: stsp; state: Exp; lines: +9 -4;
commitid: bhSrWmJtthQEPonD;
When reusing an mbuf to send an ARP response, don't forget to clear
the mbuf packet header. Otherwise, stale mbuf state related to the
ARP request packet might affect the fate of the ARP reply packet.
For example, I observed that for an ARP request to a carp IP, where the
underlying carpdev interface is part of a bridge, ARP replies were always
sent out on the carpdev interface, even if the corresponding ARP request
was received not on the carpdev but on a different bridge member interface.
This happened because the M_PROTO1 mbuf flag was set on the ARP request mbuf
when it left the bridge towards carp, and was still set on the ARP reply,
which reused the same mbuf, sent back towards the bridge. The bridge's loop
detection saw the M_PROTO1 flag and prevented the ARP reply from entering
the bridge, so the reply was instead sent out directly on the carpdev...
ok bluhm@ mpi@
