#
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
|