2021-01-18 13:13:51 +01:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
2021-01-26 18:34:23 +01:00
|
|
|
#ifndef PPING_H
|
|
|
|
#define PPING_H
|
|
|
|
|
2020-12-11 19:25:35 +01:00
|
|
|
#include <linux/types.h>
|
2021-02-08 20:28:46 +01:00
|
|
|
#include <linux/in6.h>
|
2021-06-22 15:22:11 +02:00
|
|
|
#include <stdbool.h>
|
2020-12-11 19:25:35 +01:00
|
|
|
|
2022-02-10 16:11:21 +01:00
|
|
|
typedef __u64 fixpoint64;
|
|
|
|
#define FIXPOINT_SHIFT 16
|
|
|
|
#define DOUBLE_TO_FIXPOINT(X) ((fixpoint64)((X) * (1UL << FIXPOINT_SHIFT)))
|
|
|
|
#define FIXPOINT_TO_UINT(X) ((X) >> FIXPOINT_SHIFT)
|
|
|
|
|
2021-06-22 15:22:11 +02:00
|
|
|
/* For the event_type members of rtt_event and flow_event */
|
|
|
|
#define EVENT_TYPE_FLOW 1
|
|
|
|
#define EVENT_TYPE_RTT 2
|
|
|
|
|
|
|
|
enum __attribute__((__packed__)) flow_event_type {
|
2021-06-22 15:36:35 +02:00
|
|
|
FLOW_EVENT_NONE,
|
2021-06-22 15:22:11 +02:00
|
|
|
FLOW_EVENT_OPENING,
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
FLOW_EVENT_CLOSING,
|
|
|
|
FLOW_EVENT_CLOSING_BOTH
|
2021-06-22 15:22:11 +02:00
|
|
|
};
|
|
|
|
|
2021-06-22 15:36:35 +02:00
|
|
|
enum __attribute__((__packed__)) flow_event_reason {
|
2021-06-22 15:22:11 +02:00
|
|
|
EVENT_REASON_SYN,
|
|
|
|
EVENT_REASON_SYN_ACK,
|
|
|
|
EVENT_REASON_FIRST_OBS_PCKT,
|
|
|
|
EVENT_REASON_FIN,
|
|
|
|
EVENT_REASON_RST,
|
|
|
|
EVENT_REASON_FLOW_TIMEOUT
|
|
|
|
};
|
|
|
|
|
2021-06-22 15:36:35 +02:00
|
|
|
enum __attribute__((__packed__)) flow_event_source {
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
EVENT_SOURCE_PKT_SRC,
|
|
|
|
EVENT_SOURCE_PKT_DEST,
|
2021-06-22 15:36:35 +02:00
|
|
|
EVENT_SOURCE_USERSPACE
|
|
|
|
};
|
|
|
|
|
2021-04-15 14:13:54 +02:00
|
|
|
struct bpf_config {
|
2021-03-22 12:23:27 +01:00
|
|
|
__u64 rate_limit;
|
2022-02-10 16:11:21 +01:00
|
|
|
fixpoint64 rtt_rate;
|
|
|
|
bool use_srtt;
|
2022-02-02 11:38:53 +01:00
|
|
|
bool track_tcp;
|
|
|
|
bool track_icmp;
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
bool localfilt;
|
|
|
|
__u32 reserved;
|
2021-03-22 12:23:27 +01:00
|
|
|
};
|
|
|
|
|
2021-02-08 20:28:46 +01:00
|
|
|
/*
|
2021-02-09 18:09:30 +01:00
|
|
|
* Struct that can hold the source or destination address for a flow (l3+l4).
|
2021-02-08 20:28:46 +01:00
|
|
|
* Works for both IPv4 and IPv6, as IPv4 addresses can be mapped to IPv6 ones
|
2021-02-09 18:09:30 +01:00
|
|
|
* based on RFC 4291 Section 2.5.5.2.
|
|
|
|
*/
|
|
|
|
struct flow_address {
|
|
|
|
struct in6_addr ip;
|
|
|
|
__u16 port;
|
|
|
|
__u16 reserved;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Struct to hold a full network tuple
|
|
|
|
* The ipv member is technically not necessary, but makes it easier to
|
|
|
|
* determine if saddr/daddr are IPv4 or IPv6 address (don't need to look at the
|
|
|
|
* first 12 bytes of address). The proto memeber is not currently used, but
|
|
|
|
* could be useful once pping is extended to work for other protocols than TCP.
|
2021-02-08 20:28:46 +01:00
|
|
|
*/
|
|
|
|
struct network_tuple {
|
2021-02-09 18:09:30 +01:00
|
|
|
struct flow_address saddr;
|
|
|
|
struct flow_address daddr;
|
2021-02-08 20:28:46 +01:00
|
|
|
__u16 proto; //IPPROTO_TCP, IPPROTO_ICMP, QUIC etc
|
2021-02-09 18:09:30 +01:00
|
|
|
__u8 ipv; //AF_INET or AF_INET6
|
|
|
|
__u8 reserved;
|
2020-12-11 19:25:35 +01:00
|
|
|
};
|
|
|
|
|
2021-03-01 18:16:48 +01:00
|
|
|
struct flow_state {
|
pping: Add timestamp and min-RTT to output
To add timestamp to output, push the timestamp when packet was
processed from kernel as part of the rtt-event. Also keep track of
minimum encountered RTT for each flow in kernel, and also push that as
part of the RTT-event.
Additionally, avoid pushing RTT messages at all if no flow-state
information can be found (due to ex. being deleted from egress side),
as no valid min-RTT can then be given. Furthermore, no longer delete
flow-information once seeing the FIN-flag on egress in order to keep
useful flow-state around for RTT-messages longer. Due to the
FIN-handshake process, it is sufficient if the ingress program deletes
the flow-state upon seeing FIN. However, still delete flow-state from
either ingress or egress upon seeing RST flag, as RST does not have a
handshake process allowing for delayed deletion.
While minimum RTT could also be tracked from the userspace process,
userspace is not aware of when the flow is closed so would have to add
additional logic to keep track of minimum RTT for each flow and
periodically clean them up. Furthermore, keeping RTT statistics in the
flow-state map is useful for implementing future features, such as an
RTT-based sampling interval. It would also be useful in case pping is
changed to no longer have a long-running userspace process printing
out all the calculated RTTs, but instead simply occasionally looks up
the RTT from the flow-state map.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2021-04-29 18:55:06 +02:00
|
|
|
__u64 min_rtt;
|
2022-02-10 16:11:21 +01:00
|
|
|
__u64 srtt;
|
2021-03-01 18:16:48 +01:00
|
|
|
__u64 last_timestamp;
|
2021-05-07 14:54:12 +02:00
|
|
|
__u64 sent_pkts;
|
|
|
|
__u64 sent_bytes;
|
|
|
|
__u64 rec_pkts;
|
|
|
|
__u64 rec_bytes;
|
2021-03-01 18:16:48 +01:00
|
|
|
__u32 last_id;
|
2022-02-03 12:03:22 +01:00
|
|
|
bool has_opened;
|
|
|
|
enum flow_event_reason opening_reason;
|
|
|
|
__u16 reserved;
|
2021-03-01 18:16:48 +01:00
|
|
|
};
|
|
|
|
|
2021-02-08 20:28:46 +01:00
|
|
|
struct packet_id {
|
|
|
|
struct network_tuple flow;
|
|
|
|
__u32 identifier; //tsval for TCP packets
|
2020-12-11 19:25:35 +01:00
|
|
|
};
|
|
|
|
|
2021-06-22 15:22:11 +02:00
|
|
|
/*
|
|
|
|
* An RTT event message that can be passed from the bpf-programs to user-space.
|
|
|
|
* The initial event_type memeber is used to allow multiplexing between
|
|
|
|
* different event types in a single perf buffer. Memebers up to and including
|
|
|
|
* flow are identical to other event types.
|
|
|
|
* Uses explicit padding instead of packing based on recommendations in cilium's
|
|
|
|
* BPF reference documentation at https://docs.cilium.io/en/stable/bpf/#llvm.
|
|
|
|
*/
|
2021-01-18 18:08:35 +01:00
|
|
|
struct rtt_event {
|
2021-06-22 15:22:11 +02:00
|
|
|
__u64 event_type;
|
|
|
|
__u64 timestamp;
|
|
|
|
struct network_tuple flow;
|
|
|
|
__u32 padding;
|
2021-01-18 18:08:35 +01:00
|
|
|
__u64 rtt;
|
pping: Add timestamp and min-RTT to output
To add timestamp to output, push the timestamp when packet was
processed from kernel as part of the rtt-event. Also keep track of
minimum encountered RTT for each flow in kernel, and also push that as
part of the RTT-event.
Additionally, avoid pushing RTT messages at all if no flow-state
information can be found (due to ex. being deleted from egress side),
as no valid min-RTT can then be given. Furthermore, no longer delete
flow-information once seeing the FIN-flag on egress in order to keep
useful flow-state around for RTT-messages longer. Due to the
FIN-handshake process, it is sufficient if the ingress program deletes
the flow-state upon seeing FIN. However, still delete flow-state from
either ingress or egress upon seeing RST flag, as RST does not have a
handshake process allowing for delayed deletion.
While minimum RTT could also be tracked from the userspace process,
userspace is not aware of when the flow is closed so would have to add
additional logic to keep track of minimum RTT for each flow and
periodically clean them up. Furthermore, keeping RTT statistics in the
flow-state map is useful for implementing future features, such as an
RTT-based sampling interval. It would also be useful in case pping is
changed to no longer have a long-running userspace process printing
out all the calculated RTTs, but instead simply occasionally looks up
the RTT from the flow-state map.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2021-04-29 18:55:06 +02:00
|
|
|
__u64 min_rtt;
|
2021-05-07 14:54:12 +02:00
|
|
|
__u64 sent_pkts;
|
|
|
|
__u64 sent_bytes;
|
|
|
|
__u64 rec_pkts;
|
|
|
|
__u64 rec_bytes;
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
bool match_on_egress;
|
|
|
|
__u8 reserved[7];
|
2021-06-22 15:36:35 +02:00
|
|
|
};
|
|
|
|
|
2021-06-22 15:22:11 +02:00
|
|
|
/*
|
|
|
|
* A flow event message that can be passed from the bpf-programs to user-space.
|
|
|
|
* The initial event_type memeber is used to allow multiplexing between
|
|
|
|
* different event types in a single perf buffer. Memebers up to and including
|
|
|
|
* flow are identical to other event types.
|
|
|
|
*/
|
|
|
|
struct flow_event {
|
|
|
|
__u64 event_type;
|
pping: Add timestamp and min-RTT to output
To add timestamp to output, push the timestamp when packet was
processed from kernel as part of the rtt-event. Also keep track of
minimum encountered RTT for each flow in kernel, and also push that as
part of the RTT-event.
Additionally, avoid pushing RTT messages at all if no flow-state
information can be found (due to ex. being deleted from egress side),
as no valid min-RTT can then be given. Furthermore, no longer delete
flow-information once seeing the FIN-flag on egress in order to keep
useful flow-state around for RTT-messages longer. Due to the
FIN-handshake process, it is sufficient if the ingress program deletes
the flow-state upon seeing FIN. However, still delete flow-state from
either ingress or egress upon seeing RST flag, as RST does not have a
handshake process allowing for delayed deletion.
While minimum RTT could also be tracked from the userspace process,
userspace is not aware of when the flow is closed so would have to add
additional logic to keep track of minimum RTT for each flow and
periodically clean them up. Furthermore, keeping RTT statistics in the
flow-state map is useful for implementing future features, such as an
RTT-based sampling interval. It would also be useful in case pping is
changed to no longer have a long-running userspace process printing
out all the calculated RTTs, but instead simply occasionally looks up
the RTT from the flow-state map.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2021-04-29 18:55:06 +02:00
|
|
|
__u64 timestamp;
|
2021-02-09 13:00:28 +01:00
|
|
|
struct network_tuple flow;
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
enum flow_event_type flow_event_type;
|
|
|
|
enum flow_event_reason reason;
|
2021-06-22 15:36:35 +02:00
|
|
|
enum flow_event_source source;
|
2021-06-22 15:22:11 +02:00
|
|
|
__u8 reserved;
|
2021-01-07 18:14:27 +01:00
|
|
|
};
|
|
|
|
|
2021-06-10 18:23:37 +02:00
|
|
|
union pping_event {
|
|
|
|
__u64 event_type;
|
|
|
|
struct rtt_event rtt_event;
|
|
|
|
struct flow_event flow_event;
|
|
|
|
};
|
|
|
|
|
pping: Do both timestamping and matching on ingress and egress
Perform both timestamping and matching on both ingress and egress
hooks. This makes it more similar to Kathie's pping, allowing the tool
to capture RTTs in both directions when deployed on just a single
interface.
Like Kathie's pping, by default filter out RTTs for packets going to
the local machine (will only include local processing delays). This
behavior can be disabled by passing the -l/--include-local option.
As packets that are timestamped on ingress and matched on egress will
include the local machines processing delay, add the "match_on_egress"
member to the JSON output that can be used to differentiate between
RTTs that include the local processing delay, and those which don't.
Finally, report the source and destination addresses from the perspective
of the reply packet, rather than the timestamped packet, to be
consistent with Kathie's pping.
Overall, refactor large parts of pping_kern to allow both timestamping
and matching, as well as updating both the flow and reverse flow and
handle flow-events related to them, in one go. Also update README to
reflect changes.
Signed-off-by: Simon Sundberg <simon.sundberg@kau.se>
2022-02-10 16:16:24 +01:00
|
|
|
/*
|
|
|
|
* Convenience function for getting the corresponding reverse flow.
|
|
|
|
* PPing needs to keep track of flow in both directions, and sometimes
|
|
|
|
* also needs to reverse the flow to report the "correct" (consistent
|
|
|
|
* with Kathie's PPing) src and dest address.
|
|
|
|
*/
|
|
|
|
static void reverse_flow(struct network_tuple *dest, struct network_tuple *src)
|
|
|
|
{
|
|
|
|
dest->ipv = src->ipv;
|
|
|
|
dest->proto = src->proto;
|
|
|
|
dest->saddr = src->daddr;
|
|
|
|
dest->daddr = src->saddr;
|
|
|
|
dest->reserved = 0;
|
|
|
|
}
|
|
|
|
|
2020-12-11 19:25:35 +01:00
|
|
|
#endif
|