History log of /freebsd-11-stable/sys/netinet/if_ether.c
Revision Date Author Comments
# 346389 19-Apr-2019 bz

MFC r340494:

Improve the comment for arpresolve_full() in if_ether.c.
No functional changes.


# 344282 19-Feb-2019 kp

MFC r344061:

garp: Fix vnet related panic for gratuitous arp

Gratuitous ARP packets are sent from a timer, which means we don't have a vnet
context set. As a result we panic trying to send the packet.

Set the vnet context based on the interface associated with the interface
address.

To reproduce:
sysctl net.link.ether.inet.garp_rexmit_count=2
ifconfig vtnet1 10.0.0.1/24 up

PR: 235699
Reviewed by: vangyzen@


# 337462 08-Aug-2018 ae

MFC r331098 (by melifaro):
Fix outgoing TCP/UDP packet drop on arp/ndp entry expiration.

Current arp/nd code relies on the feedback from the datapath indicating
that the entry is still used. This mechanism is incorporated into the
arpresolve()/nd6_resolve() routines. After the inpcb route cache
introduction, the packet path for the locally-originated packets changed,
passing cached lle pointer to the ether_output() directly. This resulted
in the arp/ndp entry expire each time exactly after the configured max_age
interval. During the small window between the ARP/NDP request and reply
from the router, most of the packets got lost.

Fix this behaviour by plugging datapath notification code to the packet
path used by route cache. Unify the notification code by using single
inlined function with the per-AF callbacks.


# 331722 29-Mar-2018 eadler

Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)


# 330897 14-Mar-2018 eadler

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg


# 315479 18-Mar-2017 ae

MFC r315050:
Fix the L2 address printed in the "arp: %s moved from %*D" message.

In the r292978 struct llentry was changed and the ll_addr field become
the pointer.

PR: 217667


# 315456 17-Mar-2017 vangyzen

MFC r313821 r315277 r315286

Use inet_ntoa_r() instead of inet_ntoa() throughout the kernel.

inet_ntoa() cannot be used safely in a multithreaded environment
because it uses a static local buffer. Instead, use inet_ntoa_r()
with a buffer on the caller's stack, except for KTR messages.
KTR can correctly log the immediate integral values passed to it,
as well as constant strings, but not non-constant strings,
since they might change by the time ktrdump retrieves them.
Therefore, use hex notation in KTR messages.

Sponsored by: Dell EMC


# 309337 30-Nov-2016 vangyzen

MFC r306577 r306652 306830

Add GARP retransmit capability

A single gratuitous ARP (GARP) is always transmitted when an IPv4
address is added to an interface, and that is usually sufficient.
However, in some circumstances, such as when a shared address is
passed between cluster nodes, this single GARP may occasionally be
dropped or lost. This can lead to neighbors on the network link
working with a stale ARP cache and sending packets destined for
that address to the node that previously owned the address, which
may not respond.

To avoid this situation, GARP retransmissions can be enabled by setting
the net.link.ether.inet.garp_rexmit_count sysctl to a value greater
than zero. The setting represents the maximum number of retransmissions.
The interval between retransmissions is calculated using an exponential
backoff algorithm, doubling each time, so the retransmission intervals
are: {1, 2, 4, 8, 16, ...} (seconds).

Due to the exponential backoff algorithm used for the interval
between GARP retransmissions, the maximum number of retransmissions
is limited to 16 for sanity. This limit corresponds to a maximum
interval between retransmissions of 2^16 seconds ~= 18 hours.
Increasing this limit is possible, but sending out GARPs spaced
days apart would be of little use.

Update arp(4) to document the net.link.ether.inet.garp_rexmit_count sysctl.

Submitted by: dab
Relnotes: yes
Sponsored by: Dell EMC


# 303698 03-Aug-2016 karels

MFC r303171: Fix per-connection L2 caching in fast path

r301217 re-added per-connection L2 caching from a previous change,
but it omitted caching in the fast path. Add it.

Reviewed By: gallatin
Approved by: gnn (mentor)
Approved by: re (kostikbel)
Differential Revision: https://reviews.freebsd.org/D7239