1tcpconnect(8)               System Manager's Manual              tcpconnect(8)
2
3
4

NAME

6       tcpconnect  -  Trace  TCP  active  connections  (connect()). Uses Linux
7       eBPF/bcc.
8

SYNOPSIS

10       tcpconnect [-h] [-c] [-t] [-p PID] [-P PORT] [-4 | -6]  [-L]  [-u  UID]
11       [-U] [--cgroupmap MAPPATH] [--mntnsmap MAPPATH] [-d]
12

DESCRIPTION

14       This  tool  traces active TCP connections (eg, via a connect() syscall;
15       accept() are passive connections). This can be useful for general trou‐
16       bleshooting to see what connections are initiated by the local server.
17
18       All connection attempts are traced, even if they ultimately fail.
19
20       This  works by tracing the kernel tcp_v4_connect() and tcp_v6_connect()
21       functions using dynamic tracing, and will need updating  to  match  any
22       changes to these functions.
23
24       When  provided  with the -d or --dns option, this tool will also corre‐
25       late connect calls with the most recent DNS query that matches  the  IP
26       connected.   This  feature  works  by  tracing the kernel udp_recvmsg()
27       function to collect DNS responses.
28
29       Since this uses BPF, only the root user can use this tool.
30

REQUIREMENTS

32       CONFIG_BPF and bcc.
33
34       If using the -d or --dns option, you  must  have  the  dnslib  and  ca‐
35       chetools  python packages installed.  You can install them with pip3 or
36       with apt on Ubuntu 18.04+  using  the  python3-dnslib  and  python3-ca‐
37       chetools packages.
38

OPTIONS

40       -h     Print usage message.
41
42       -t     Include a timestamp column.
43
44       -c     Count connects per src ip and dest ip/port.
45
46       -p PID Trace this process ID only (filtered in-kernel).
47
48       -P PORT
49              Comma-separated list of destination ports to trace (filtered in-
50              kernel).
51
52       -4     Trace IPv4 family only.
53
54       -6     Trace IPv6 family only.
55
56       -L     Include a LPORT column.
57
58       -U     Include a UID column.
59
60       -u UID Trace this UID only (filtered in-kernel).
61
62       --cgroupmap MAPPATH
63              Trace cgroups in this BPF map only (filtered in-kernel).
64
65       --mntnsmap  MAPPATH
66              Trace mount namespaces in this BPF map  only  (filtered  in-ker‐
67              nel).
68
69       -d     Shows  the  most recent DNS query for the IP address in the con‐
70              nect call.  This is likely related to the TCP connection details
71              in the other columns, but is not guaranteed.  This feature works
72              by tracing the udp_recvmsg kernel function and tracking DNS  re‐
73              sponses  received by the server.  It only supports UDP DNS pack‐
74              ets up to 512 bytes in length.  The python code keeps a cache of
75              10k DNS responses in memory for up 24 hours.
76
77              If  the  time difference in milliseconds between when the system
78              received a DNS response and when a connect  syscall  was  traced
79              using  an  IP  in  that DNS response is greater than 100ms, this
80              tool will report this  delta  after  the  query.   These  deltas
81              should  be relatively short for most applications.  A long delay
82              between the response and connect could be either  anomalous  ac‐
83              tivity  or  indicate  a  misattribution between the DNS name re‐
84              quested and the IP that the connect syscall is using.
85
86              The -d option may not be used with the count feature (option -c)
87

EXAMPLES

89       Trace all active TCP connections:
90              # tcpconnect
91
92       Trace all TCP connects, and include timestamps:
93              # tcpconnect -t
94
95       Trace all TCP connects, and include most recent matching DNS query  for
96       each connected IP
97              # tcpconnect -d
98
99       Trace PID 181 only:
100              # tcpconnect -p 181
101
102       Trace ports 80 and 81 only:
103              # tcpconnect -P 80,81
104
105       Trace IPv4 family only:
106              # tcpconnect -4
107
108       Trace IPv6 family only:
109              # tcpconnect -6
110
111       Trace all TCP connects, and include LPORT:
112              # tcpconnect -L
113
114       Trace all TCP connects, and include UID:
115              # tcpconnect -U
116
117       Trace UID 1000 only:
118              # tcpconnect -u 1000
119
120       Count connects per src ip and dest ip/port:
121              # tcpconnect -c
122
123       Trace  a set of cgroups only (see special_filtering.md from bcc sources
124       for more details):
125              # tcpconnect --cgroupmap /sys/fs/bpf/test01
126
127       Trace a set of mount namespaces only (see special_filtering.md from bcc
128       sources for more details):
129              # tcpconnect --mntnsmap /sys/fs/bpf/mnt_ns_set
130

FIELDS

132       TIME(s)
133              Time of the call, in seconds.
134
135       UID    User ID
136
137       PID    Process ID
138
139       COMM   Process name
140
141       IP     IP address family (4 or 6)
142
143       SADDR  Source IP address.
144
145       LPORT  Source port
146
147       DADDR  Destination IP address.
148
149       DPORT  Destination port
150
151       CONNECTS
152              Accumulated active connections since start.
153
154       QUERY  Shows  the  most recent DNS query for the IP address in the con‐
155              nect call.  This is likely related to the TCP connection details
156              in the other columns, but is not guaranteed.
157

OVERHEAD

159       This  traces  the  kernel tcp_v[46]_connect functions and prints output
160       for each event. As the rate of this is generally expected to be low  (<
161       1000/s), the overhead is also expected to be negligible. If you have an
162       application that is calling a high rate of connect()s, such as a  proxy
163       server, then test and understand this overhead before use.
164
165       If  you  are  using the -d option to track DNS requests, this tool will
166       trace the udp_recvmsg function and generate an event  for  any  packets
167       from  UDP  port  53.   This  event  contains up to 512 bytes of the UDP
168       packet payload.  Typical applications do not extensively  use  UDP,  so
169       the  performance overhead of tracing udp_recvmsg is expected to be neg‐
170       ligible,   However, if you have an application that receives  many  UDP
171       packets,  then  you  should test and understand the overhead of tracing
172       every received UDP message.  Furthermore, performance overhead of  run‐
173       ning  this  tool  on a DNS server is expected to be higher than average
174       because all DNS response packets will be copied to userspace.
175

SOURCE

177       This is from bcc.
178
179              https://github.com/iovisor/bcc
180
181       Also look in the bcc distribution for a  companion  _examples.txt  file
182       containing example usage, output, and commentary for this tool.
183

OS

185       Linux
186

STABILITY

188       Unstable - in development.
189

AUTHOR

191       Brendan Gregg
192

SEE ALSO

194       tcptracer(8), tcpaccept(8), funccount(8), tcpdump(8)
195
196
197
198USER COMMANDS                     2020-02-20                     tcpconnect(8)
Impressum