#
6fe4d839 |
|
08-Apr-2024 |
Zhenlei Huang <zlei@FreeBSD.org> |
debugnet: Fix logging of frame length MFC after: 1 week
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
b498331b |
|
26-May-2023 |
John Reimer <John_Reimer@Dell.com> |
netgdb: Fix netgdb double ack, print proxy address - Fixes netgdb's double ack - Moving ack responsibility to debugnet, decision to ack made by netdump/netgdb. - Finish responsibility moved to debugnet, new finish handler. - netgdb now prints the address to connect to in case the user doesn't have access to the proxy machine. Sponsored by: Dell EMC Reviewed By: markj, bdrewery (earlier version) Differential Revision: https://reviews.freebsd.org/D40064
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
2c2b37ad |
|
13-Jan-2023 |
Justin Hibbits <jhibbits@FreeBSD.org> |
ifnet/API: Move struct ifnet definition to a <net/if_private.h> Hide the ifnet structure definition, no user serviceable parts inside, it's a netstack implementation detail. Include it temporarily in <net/if_var.h> until all drivers are updated to use the accessors exclusively. Reviewed by: glebius Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D38046
|
#
346b8b25 |
|
16-Dec-2022 |
Franco Fichtner <franco@opnsense.org> |
debugnet: remove spurious message on boot In non-INVARIANTS kernels, hide the warning message printed by debugnet when an interface MTU is configured or link state changes, and debugnet cannot infer the number of mbuf clusters to reserve. The warning isn't really actionable and mostly serves to confuse users. Reviewed by: vangyzen, markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D34393
|
#
c262d5e8 |
|
16-Jun-2022 |
Mark Johnston <markj@FreeBSD.org> |
debugnet: Fix an error handling bug in the DDB command tokenizer MFC after: 2 weeks Sponsored by: The FreeBSD Foundation
|
#
84143314 |
|
16-Jun-2022 |
Mark Johnston <markj@FreeBSD.org> |
debugnet: Handle batches of packets from if_input Some drivers will collect multiple mbuf chains, linked by m_nextpkt, before passing them to upper layers. debugnet_pkt_in() didn't handle this and would process only the first packet, typically leading to retransmits. MFC after: 2 weeks Sponsored by: The FreeBSD Foundation
|
#
a84bf5ea |
|
14-May-2022 |
Mitchell Horne <mhorne@FreeBSD.org> |
debugnet: fix an errant assertion We may call debugnet_free() before g_debugnet_pcb_inuse is true, specifically in the cases where the interface is down or does not support debugnet. pcb->dp_drv_input is used to hold the real driver if_input callback while debugnet is in use, so we can check the status of this field in the assertion. This can be triggered trivially by trying to configure netdump on an unsupported interface at the ddb prompt. Initializing the dp_drv_input field to NULL explicitly is not necessary but helps display the intent. PR: 263929 Reported by: Martin Filla <freebsd@sysctl.cz> Reviewed by: cem, markj MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D35179
|
#
b1746faa |
|
14-Sep-2021 |
Mark Johnston <markj@FreeBSD.org> |
debugnet: Include some required headers Don't depend on pollution from net/vnet.h. PR: 258496 MFC after: 1 week Sponsored by: The FreeBSD Foundation
|
#
62e1a437 |
|
22-Aug-2021 |
Zhenlei Huang <zlei.huang@gmail.com> |
routing: Allow using IPv6 next-hops for IPv4 routes (RFC 5549). Implement kernel support for RFC 5549/8950. * Relax control plane restrictions and allow specifying IPv6 gateways for IPv4 routes. This behavior is controlled by the net.route.rib_route_ipv6_nexthop sysctl (on by default). * Always pass final destination in ro->ro_dst in ip_forward(). * Use ro->ro_dst to exract packet family inside if_output() routines. Consistently use RO_GET_FAMILY() macro to handle ro=NULL case. * Pass extracted family to nd6_resolve() to get the LLE with proper encap. It leverages recent lltable changes committed in c541bd368f86. Presence of the functionality can be checked using ipv4_rfc5549_support feature(3). Example usage: route add -net 192.0.0.0/24 -inet6 fe80::5054:ff:fe14:e319%vtnet0 Differential Revision: https://reviews.freebsd.org/D30398 MFC after: 2 weeks
|
#
caf2f627 |
|
05-Apr-2021 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Allow to specify debugnet fib in sysctl/tunable. Differential Revision: https://reviews.freebsd.org/D29593 Reviewed by: donner MFC after: 2 weeks
|
#
55f57ca9 |
|
26-Apr-2020 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Convert debugnet to the new routing KPI. Introduce new fib[46]_lookup_debugnet() functions serving as a special interface for the crash-time operations. Underlying implementation will try to return lookup result if datastructures are not corrupted, avoding locking. Convert debugnet to use fib4_lookup_debugnet() and switch it to use nexthops instead of rtentries. Reviewed by: cem Differential Revision: https://reviews.freebsd.org/D24555
|
#
7029da5c |
|
26-Feb-2020 |
Pawel Biernacki <kaktus@FreeBSD.org> |
Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many) r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718
|
#
65366903 |
|
23-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Prevent a panic when a driver provides bogus debugnet parameters This is just a bandaid; we should fix the driver(s) too. Introduced in r353685. PR: 241403 X-MFC-With: r353685 Reported by: np and others
|
#
4ad8cb68 |
|
19-Oct-2019 |
Michael Tuexen <tuexen@FreeBSD.org> |
Fix compile issues when building a kernel without the VIMAGE option. Thanks to cem@ for discussing the issue which resulted in this patch. Reviewed by: cem@ Sponsored by: Netflix, Inc. Differential Revision: https://reviews.freebsd.org/D22089
|
#
0634308d |
|
18-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Fix debugnet(4) link/build fallout on some configurations Introduced in r353685 (sys/conf/files), r353694 (debugnet.c db_printf). Submitted by: kevans Reported by: cy X-MFC-With: r353685, r353694
|
#
dda17b36 |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Implement NetGDB(4) NetGDB(4) is a component of a system using a panic-time network stack to remotely debug crashed FreeBSD kernels over the network, instead of traditional serial interfaces. There are three pieces in the complete NetGDB system. First, a dedicated proxy server must be running to accept connections from both NetGDB and gdb(1), and pass bidirectional traffic between the two protocols. Second, the NetGDB client is activated much like ordinary 'gdb' and similarly to 'netdump' in ddb(4) after a panic. Like other debugnet(4) clients (netdump(4)), the network interface on the route to the proxy server must be online and support debugnet(4). Finally, the remote (k)gdb(1) uses 'target remote <proxy>:<port>' (like any other TCP remote) to connect to the proxy server. The NetGDB v1 protocol speaks the literal GDB remote serial protocol, and uses a 1:1 relationship between GDB packets and sequences of debugnet packets (fragmented by MTU). There is no encryption utilized to keep debugging sessions private, so this is only appropriate for local segments or trusted networks. Submitted by: John Reimer <john.reimer AT emc.com> (earlier version) Discussed some with: emaste, markj Relnotes: sure Differential Revision: https://reviews.freebsd.org/D21568
|
#
e9c69625 |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
debugnet(4): Add optional full-duplex mode It remains unattached to any client protocol. Netdump is unaffected (remaining half-duplex). The intended consumer is NetGDB. Submitted by: John Reimer <john.reimer AT emc.com> (earlier version) Discussed with: markj Differential Revision: https://reviews.freebsd.org/D21541
|
#
fde2cf65 |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
debugnet(4): Infer non-server connection parameters Loosen requirements for connecting to debugnet-type servers. Only require a destination address; the rest can theoretically be inferred from the routing table. Relax corresponding constraints in netdump(4) and move ifp validation to debugnet connection time. Submitted by: John Reimer <john.reimer AT emc.com> (earlier version) Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D21482
|
#
8270d35e |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Add ddb(4) 'netdump' command to netdump a core without preconfiguration Add a 'X -s <server> -c <client> [-g <gateway>] -i <interface>' subroutine to the generic debugnet code. The imagined use is both netdump, shown here, and NetGDB (vaporware). It uses the ddb(4) lexer, with some new extensions, to parse out IPv4 addresses. 'Netdump' uses the generic debugnet routine to load a configuration and start a dump, without any netdump configuration prior to panic. Loosely derived from work by: John Reimer <john.reimer AT emc.com> Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D21460
|
#
6d567ec2 |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
debugnet: Respond to broadcast ARP requests The in-tree netdump code has always ignored non-directed ARP requests, and that seems to work most of the time for netdump. In my work and testing on NetGDB, it seems like sometimes the remote FreeBSD conversant (the non-panic system) will send broadcast-destination ARP requests to the debugnet kernel; without this change, those are dropped and the remote will see EHOSTDOWN "Host is down" errors from the userspace interface of the network stack. Discussed with: markj
|
#
7790c8c1 |
|
17-Oct-2019 |
Conrad Meyer <cem@FreeBSD.org> |
Split out a more generic debugnet(4) from netdump(4) Debugnet is a simplistic and specialized panic- or debug-time reliable datagram transport. It can drive a single connection at a time and is currently unidirectional (debug/panic machine transmit to remote server only). It is mostly a verbatim code lift from netdump(4). Netdump(4) remains the only consumer (until the rest of this patch series lands). The INET-specific logic has been extracted somewhat more thoroughly than previously in netdump(4), into debugnet_inet.c. UDP-layer logic and up, as much as possible as is protocol-independent, remains in debugnet.c. The separation is not perfect and future improvement is welcome. Supporting INET6 is a long-term goal. Much of the diff is "gratuitous" renaming from 'netdump_' or 'nd_' to 'debugnet_' or 'dn_' -- sorry. I thought keeping the netdump name on the generic module would be more confusing than the refactoring. The only functional change here is the mbuf allocation / tracking. Instead of initiating solely on netdump-configured interface(s) at dumpon(8) configuration time, we watch for any debugnet-enabled NIC for link activation and query it for mbuf parameters at that time. If they exceed the existing high-water mark allocation, we re-allocate and track the new high-water mark. Otherwise, we leave the pre-panic mbuf allocation alone. In a future patch in this series, this will allow initiating netdump from panic ddb(4) without pre-panic configuration. No other functional change intended. Reviewed by: markj (earlier version) Some discussion with: emaste, jhb Objection from: marius Differential Revision: https://reviews.freebsd.org/D21421
|