#
343139 |
|
18-Jan-2019 |
hselasky |
MFC r342884: Fix loopback traffic when using non-lo0 link local IPv6 addresses.
The loopback interface can only receive packets with a single scope ID, namely the scope ID of the loopback interface itself. To mitigate this packets which use the scope ID are appearing as received by the real network interface, see "origifp" in the patch. The current code would drop packets which are designated for loopback which use a link-local scope ID in the destination address or source address, because they won't match the lo0's scope ID. To fix this restore the network interface pointer from the scope ID in the destination address for the problematic cases. See comments added in patch for a more detailed description.
This issue was introduced with route caching by karels@ .
Reviewed by: bz (network) Differential Revision: https://reviews.freebsd.org/D18769 Sponsored by: Mellanox Technologies
|
#
317335 |
|
23-Apr-2017 |
kp |
MFC r317186
pf: Fix possible incorrect IPv6 fragmentation
When forwarding pf tracks the size of the largest fragment in a fragmented packet, and refragments based on this size. It failed to ensure that this size was a multiple of 8 (as is required for all but the last fragment), so it could end up generating incorrect fragments.
For example, if we received an 8 byte and 12 byte fragment pf would emit a first fragment with 12 bytes of payload and the final fragment would claim to be at offset 8 (not 12).
We now assert that the fragment size is a multiple of 8 in ip6_fragment(), so other users won't make the same mistake.
Reported by: Antonios Atlasis <aatlasis at secfu net>
|
#
284572 |
|
18-Jun-2015 |
kp |
Merge r280955
Preserve IPv6 fragment IDs accross reassembly and refragmentation
When forwarding fragmented IPv6 packets and filtering with PF we reassemble and refragment. That means we generate new fragment headers and a new fragment ID.
We already save the fragment IDs so we can do the reassembly so it's straightforward to apply the incoming fragment ID on the refragmented packets.
Differential Revision: https://reviews.freebsd.org/D2817 Reviewed by: gnn
|
#
284570 |
|
18-Jun-2015 |
kp |
Merge r278842
Factor out ip6_fragment() function, to be used in IPv6 stack and pf(4).
Differential Revision: https://reviews.freebsd.org/D2815 Reviewed by: gnn
|
#
282894 |
|
14-May-2015 |
ae |
MFC r282578: Mark data checksum as valid for multicast packets, that we send back to myself via simloop. Also remove duplicate check under #ifdef DIAGNOSTIC.
PR: 180065
|
#
279911 |
|
12-Mar-2015 |
ae |
MFC r279588: Fix deadlock in IPv6 PCB code.
When several threads are trying to send datagram to the same destination, but fragmentation is disabled and datagram size exceeds link MTU, ip6_output() calls pfctlinput2(PRC_MSGSIZE). It does notify all sockets wanted to know MTU to this destination. And since all threads hold PCB lock while sending, taking the lock for each PCB in the in6_pcbnotify() leads to deadlock.
RFC 3542 p.11.3 suggests notify all application wanted to receive IPV6_PATHMTU ancillary data for each ICMPv6 packet too big message. But it doesn't require this, when we don't receive ICMPv6 message.
Change ip6_notify_pmtu() function to be able use it directly from ip6_output() to notify only one socket, and to notify all sockets when ICMPv6 packet too big message received.
MFC r279684: tcp6_ctlinput() doesn't pass MTU value to in6_pcbnotify(). Check cmdarg isn't NULL before dereference, this check was in the ip6_notify_pmtu() before r279588.
PR: 197059 Sponsored by: Yandex LLC
|
#
274132 |
|
05-Nov-2014 |
ae |
MFC r266800 by vanhu: IPv4-in-IPv6 and IPv6-in-IPv4 IPsec tunnels. For IPv6-in-IPv4, you may need to do the following command on the tunnel interface if it is configured as IPv4 only: ifconfig <interface> inet6 -ifdisabled
Code logic inspired from NetBSD. PR: kern/169438
MC r266822 by bz: Use IPv4 statistics in ipsec4_process_packet() rather than the IPv6 version. This also unbreaks the NOINET6 builds after r266800.
MFC r268083 by zec: The assumption in ipsec4_process_packet() that the payload may be only IPv4 is wrong, so check the IP version before mangling the payload header.
MFC r272394: Do not strip outer header when operating in transport mode. Instead requeue mbuf back to IPv4 protocol handler. If there is one extra IP-IP encapsulation, it will be handled with tunneling interface. And thus proper interface will be exposed into mbuf's rcvif. Also, tcpdump that listens on tunneling interface will see packets in both directions.
PR: 194761
|
#
263478 |
|
21-Mar-2014 |
glebius |
Merge r262763, r262767, r262771, r262806 from head: - Remove rt_metrics_lite and simply put its members into rtentry. - Use counter(9) for rt_pksent (former rt_rmx.rmx_pksent). This removes another cache trashing ++ from packet forwarding path. - Create zini/fini methods for the rtentry UMA zone. Via initialize mutex and counter in them. - Fix reporting of rmx_pksent to routing socket. - Fix netstat(1) to report "Use" both in kvm(3) and sysctl(3) mode.
|
#
262743 |
|
04-Mar-2014 |
glebius |
Merge r261582, r261601, r261610, r261613, r261627, r261640, r261641, r261823, r261825, r261859, r261875, r261883, r261911, r262027, r262028, r262029, r262030, r262162 from head.
Large flowtable revamp. See commit messages for merged revisions for details.
Sponsored by: Netflix
|
#
284572 |
|
18-Jun-2015 |
kp |
Merge r280955
Preserve IPv6 fragment IDs accross reassembly and refragmentation
When forwarding fragmented IPv6 packets and filtering with PF we reassemble and refragment. That means we generate new fragment headers and a new fragment ID.
We already save the fragment IDs so we can do the reassembly so it's straightforward to apply the incoming fragment ID on the refragmented packets.
Differential Revision: https://reviews.freebsd.org/D2817 Reviewed by: gnn
|
#
284570 |
|
18-Jun-2015 |
kp |
Merge r278842
Factor out ip6_fragment() function, to be used in IPv6 stack and pf(4).
Differential Revision: https://reviews.freebsd.org/D2815 Reviewed by: gnn
|
#
282894 |
|
14-May-2015 |
ae |
MFC r282578: Mark data checksum as valid for multicast packets, that we send back to myself via simloop. Also remove duplicate check under #ifdef DIAGNOSTIC.
PR: 180065
|
#
279911 |
|
12-Mar-2015 |
ae |
MFC r279588: Fix deadlock in IPv6 PCB code.
When several threads are trying to send datagram to the same destination, but fragmentation is disabled and datagram size exceeds link MTU, ip6_output() calls pfctlinput2(PRC_MSGSIZE). It does notify all sockets wanted to know MTU to this destination. And since all threads hold PCB lock while sending, taking the lock for each PCB in the in6_pcbnotify() leads to deadlock.
RFC 3542 p.11.3 suggests notify all application wanted to receive IPV6_PATHMTU ancillary data for each ICMPv6 packet too big message. But it doesn't require this, when we don't receive ICMPv6 message.
Change ip6_notify_pmtu() function to be able use it directly from ip6_output() to notify only one socket, and to notify all sockets when ICMPv6 packet too big message received.
MFC r279684: tcp6_ctlinput() doesn't pass MTU value to in6_pcbnotify(). Check cmdarg isn't NULL before dereference, this check was in the ip6_notify_pmtu() before r279588.
PR: 197059 Sponsored by: Yandex LLC
|
#
274132 |
|
05-Nov-2014 |
ae |
MFC r266800 by vanhu: IPv4-in-IPv6 and IPv6-in-IPv4 IPsec tunnels. For IPv6-in-IPv4, you may need to do the following command on the tunnel interface if it is configured as IPv4 only: ifconfig <interface> inet6 -ifdisabled
Code logic inspired from NetBSD. PR: kern/169438
MC r266822 by bz: Use IPv4 statistics in ipsec4_process_packet() rather than the IPv6 version. This also unbreaks the NOINET6 builds after r266800.
MFC r268083 by zec: The assumption in ipsec4_process_packet() that the payload may be only IPv4 is wrong, so check the IP version before mangling the payload header.
MFC r272394: Do not strip outer header when operating in transport mode. Instead requeue mbuf back to IPv4 protocol handler. If there is one extra IP-IP encapsulation, it will be handled with tunneling interface. And thus proper interface will be exposed into mbuf's rcvif. Also, tcpdump that listens on tunneling interface will see packets in both directions.
PR: 194761
|
#
263478 |
|
21-Mar-2014 |
glebius |
Merge r262763, r262767, r262771, r262806 from head: - Remove rt_metrics_lite and simply put its members into rtentry. - Use counter(9) for rt_pksent (former rt_rmx.rmx_pksent). This removes another cache trashing ++ from packet forwarding path. - Create zini/fini methods for the rtentry UMA zone. Via initialize mutex and counter in them. - Fix reporting of rmx_pksent to routing socket. - Fix netstat(1) to report "Use" both in kvm(3) and sysctl(3) mode.
|
#
262743 |
|
04-Mar-2014 |
glebius |
Merge r261582, r261601, r261610, r261613, r261627, r261640, r261641, r261823, r261825, r261859, r261875, r261883, r261911, r262027, r262028, r262029, r262030, r262162 from head.
Large flowtable revamp. See commit messages for merged revisions for details.
Sponsored by: Netflix
|