Commit | Line | Data |
---|---|---|
a62f8e8a MW |
1 | .\" -*-nroff-*- |
2 | .\". | |
3 | .\" Manual for the connect service | |
4 | .\" | |
5 | .\" (c) 2008 Straylight/Edgeware | |
6 | .\" | |
7 | . | |
8 | .\"----- Licensing notice --------------------------------------------------- | |
9 | .\" | |
10 | .\" This file is part of Trivial IP Encryption (TrIPE). | |
11 | .\" | |
12 | .\" TrIPE is free software; you can redistribute it and/or modify | |
13 | .\" it under the terms of the GNU General Public License as published by | |
14 | .\" the Free Software Foundation; either version 2 of the License, or | |
15 | .\" (at your option) any later version. | |
16 | .\" | |
17 | .\" TrIPE is distributed in the hope that it will be useful, | |
18 | .\" but WITHOUT ANY WARRANTY; without even the implied warranty of | |
19 | .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
20 | .\" GNU General Public License for more details. | |
21 | .\" | |
22 | .\" You should have received a copy of the GNU General Public License | |
23 | .\" along with TrIPE; if not, write to the Free Software Foundation, | |
24 | .\" Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. | |
25 | . | |
26 | .\"-------------------------------------------------------------------------- | |
27 | .so ../defs.man.in \"@@@PRE@@@ | |
28 | . | |
29 | .\"-------------------------------------------------------------------------- | |
0647ba7c | 30 | .TH connect 8tripe "11 December 2007" "Straylight/Edgeware" "TrIPE: Trivial IP Encryption" |
a62f8e8a MW |
31 | . |
32 | .\"-------------------------------------------------------------------------- | |
33 | .SH "NAME" | |
34 | . | |
d64ce4ae | 35 | connect \- tripe service to handle addition and removal of peers |
a62f8e8a MW |
36 | . |
37 | .\"-------------------------------------------------------------------------- | |
38 | .SH "SYNOPSIS" | |
39 | . | |
40 | .B connect | |
41 | .RB [ \-a | |
42 | .IR socket ] | |
43 | .RB [ \-d | |
44 | .IR dir ] | |
45 | .RB [ \-p | |
46 | .IR file ] | |
47 | .br | |
48 | \& \c | |
49 | .RB [ \-\-daemon ] | |
50 | .RB [ \-\-debug ] | |
51 | .RB [ \-\-startup ] | |
52 | . | |
53 | .\"-------------------------------------------------------------------------- | |
54 | .SH "DESCRIPTION" | |
55 | . | |
56 | The | |
57 | .B connect | |
d64ce4ae MW |
58 | service tracks associations with peers and performs various actions at |
59 | appropriate stages in the assocations' lifecycles. It also registers | |
60 | new peers with the | |
a62f8e8a | 61 | .BR tripe (8) |
d64ce4ae MW |
62 | server on demand. |
63 | .PP | |
64 | For example: | |
65 | .hP \*o | |
66 | When a peer is added, it arranges to configure the corresponding network | |
67 | interface correctly, and (if necessary) to initiate a dynamic | |
68 | connection. | |
69 | .hP \*o | |
70 | When a peer is removed, it arranges to bring down the network interface. | |
71 | .hP \*o | |
72 | While the peer is known, it | |
73 | .BR PING s | |
74 | it at regular intervals. If the peer fails to respond, it can be | |
75 | removed or reconnected. | |
a62f8e8a MW |
76 | .PP |
77 | A peer may participate | |
78 | .I actively | |
79 | or | |
80 | .I passively | |
81 | in a connection. A peer participating actively (an | |
82 | .IR "active peer" ) | |
83 | must already know its peer's connection details \(en its server's IP | |
84 | address and port. Active connection is suitable when the peer is a | |
85 | well-known server with stable details. | |
86 | .PP | |
87 | A server participating passively (a | |
88 | .IR "passive peer" ) | |
89 | waits to be contacted by its peer, and discovers the peer's IP address | |
90 | and port as a result of a simple protocol described below. Passive | |
91 | connection is suitable when the peer's IP address or port can vary over | |
92 | time \(en e.g., if its IP address is assigned dynamically by DHCP or | |
93 | PPP, or if it is hidden behind a NAT firewall. | |
94 | .PP | |
95 | If both peers are active, we say that they establish an | |
96 | .IR "static connection" ; | |
97 | if one is passive, we say that they establish a | |
98 | .IR "dynamic connection" . | |
99 | At least one of the peers must be active; it is not possible to | |
100 | establish a connection if both peers are passive. | |
101 | .SS "Command line" | |
102 | In addition to the standard options described in | |
103 | .BR tripe-service (7), | |
104 | the following command-line options are recognized. | |
105 | .TP | |
106 | .BI "\-p, \-\-peerdb=" file | |
107 | Use | |
108 | .I file | |
109 | as the (CDB format) peer database. In the absence of this option, the | |
110 | file named by the | |
111 | .B TRIPEPEERDB | |
112 | environment variable is used; if that's not set either, then the default | |
113 | default of | |
114 | .B peers.cdb | |
115 | in the current working directory is used instead. | |
d64ce4ae MW |
116 | . |
117 | .\"-------------------------------------------------------------------------- | |
118 | .SH "BEHAVIOUR" | |
119 | . | |
120 | .SS "Adoption" | |
121 | The | |
122 | .B connect | |
123 | service maintains a list of peers which it has adopted. A peer is | |
124 | .I eligible for adoption | |
125 | if it has a record in the peer database | |
126 | .BR peers.cdb (5) | |
127 | in which the | |
128 | .B watch | |
129 | key is assigned the value | |
130 | .BR t , | |
131 | .BR true , | |
132 | .BR y , | |
133 | .BR yes , | |
134 | or | |
135 | .BR on . | |
136 | .PP | |
137 | The service pings adopted peers periodically in order to ensure that | |
138 | they are alive, and takes appropriate action if no replies are received. | |
a62f8e8a | 139 | .PP |
d64ce4ae MW |
140 | A peer is said to be |
141 | .I adopted | |
142 | when it is added to this list, and | |
143 | .I disowned | |
144 | when it removed. | |
145 | . | |
146 | .SS "Configuring interfaces" | |
147 | The | |
148 | .B connect | |
149 | service configures network interfaces by invoking an | |
150 | .B ifup | |
151 | script. The script is invoked as | |
152 | .IP | |
153 | .I script | |
154 | .IR args ... | |
155 | .I peer | |
156 | .I ifname | |
157 | .IR addr ... | |
158 | .PP | |
159 | where the elements are as described below. | |
160 | .TP | |
161 | .IR script " and " args | |
162 | The peer's database record is retrieved; the value assigned to the | |
163 | .B ifup | |
164 | key is split into words (quoting is allowed; see | |
165 | .BR tripe-admin (5) | |
166 | for details). The first word is the | |
167 | .IR script ; | |
168 | subsequent words are gathered to form the | |
169 | .IR args . | |
170 | .TP | |
171 | .I peer | |
172 | The name of the peer. | |
173 | .TP | |
174 | .I ifname | |
175 | The name of the network interface associated with the peer, as returned | |
176 | by the | |
177 | .B IFNAME | |
178 | administration command (see | |
179 | .BR tripe-admin (5)). | |
180 | .TP | |
181 | .I addr | |
182 | The network address of the peer's TrIPE server, in the form output by | |
183 | the | |
184 | .B ADDR | |
185 | administration command (see | |
186 | .BR tripe-admin (5)). | |
187 | The first word of | |
188 | .I addr | |
189 | is therefore a network address family, e.g., | |
190 | .BR INET . | |
191 | .PP | |
192 | The | |
193 | .B connect | |
194 | service deconfigures interfaces by invoking an | |
195 | .B ifdown | |
196 | script, in a similar manner. The script is invoked as | |
197 | .IP | |
198 | .I script | |
199 | .IR args ... | |
200 | .I peer | |
201 | .PP | |
202 | where the elements are as above, except that | |
203 | .I script | |
204 | and | |
205 | .I args | |
206 | are formed by splitting the value associated with the peer record's | |
207 | .B ifdown | |
208 | key. | |
209 | .PP | |
210 | In both of the above cases, if the relevant key (either | |
211 | .B ifup | |
212 | or | |
213 | .BR ifdown ) | |
214 | is absent, no action is taken. | |
215 | .PP | |
216 | The key/value pairs in the peer's database record and the server's | |
217 | response to the | |
218 | .B ALGS | |
219 | administration command (see | |
220 | .BR tripe-admin (5)) | |
221 | are passed to the | |
222 | .B ifup | |
223 | and | |
224 | .B ifdown | |
225 | scripts as environment variables. The environment variable name | |
226 | corresponding to a key is determined as follows: | |
227 | .hP \*o | |
228 | Convert all letters to upper-case. | |
229 | .hP \*o Convert all sequences of one or more non-alphanumeric characters | |
230 | to an underscore | |
231 | .RB ` _ '. | |
232 | .hP \*o Prefix the resulting name by | |
233 | .RB ` P_ ' | |
234 | or | |
235 | .RB ` A_ ' | |
236 | depending on whether it came from the peer's database record or the | |
237 | .B ALGS | |
238 | output respectively. | |
239 | .PP | |
240 | For example, | |
241 | .B ifname | |
242 | becomes | |
243 | .BR P_IFNAME ; | |
244 | and | |
245 | .B cipher-blksz | |
246 | becomes | |
247 | .BR A_CIPHER_BLKSZ . | |
248 | . | |
249 | .SS "Dynamic connection" | |
250 | If a peer's database record assigns a value to the | |
251 | .B connect | |
252 | key, then the | |
253 | .B connect | |
254 | service will attempt to establish a connection dynamically with the | |
255 | peer. The value of the | |
256 | .B connect | |
257 | key is invoked as a Bourne shell command, i.e., | |
258 | .IP | |
259 | .B /bin/sh \-c | |
260 | .I connect | |
261 | .PP | |
262 | is executed. The command is expected to contact the remote server and | |
263 | report, on standard output, a challenge string, typically by issuing | |
264 | a | |
265 | .B passive | |
266 | command to the instance of the | |
267 | .B connect | |
268 | service running on the peer. The | |
269 | .B connect | |
270 | service reads this challenge, and submits the command | |
271 | .IP | |
272 | .B GREET | |
273 | .I peer | |
274 | .I challenge | |
275 | .PP | |
276 | Typically, the | |
277 | .B connect | |
278 | command will issue a command such as | |
279 | .IP | |
280 | .B SVCSUBMIT connect passive | |
281 | .I our-name | |
282 | .PP | |
283 | where | |
284 | .I our-name | |
285 | is the remote peer's name for this host. | |
286 | .PP | |
287 | Similarly, if the database record has a | |
288 | .B disconnect | |
289 | entry, then | |
290 | .B connect | |
291 | will use this to give the peer explicit notification that its services | |
292 | are no longer needed. The value of the | |
293 | .B disconnect | |
294 | key is invoked as a Bourne shell command. This ought to result in a | |
295 | .B KILL | |
296 | command being issued to the peer's server. | |
297 | .PP | |
298 | In detail, the protocol for passive connection works as follows. | |
a62f8e8a MW |
299 | .hP 1. |
300 | The active peer | |
301 | .BR ADD s | |
302 | its partner, typically using the | |
303 | .B \-cork | |
304 | option to suppress the key-exchange message which the server usually | |
305 | sends immediately, since otherwise the passive peer will warn about it. | |
306 | .hP 2. | |
d64ce4ae | 307 | The active peer issues the command |
a62f8e8a MW |
308 | .RS |
309 | .IP | |
310 | .B SVCSUBMIT connect passive | |
311 | .I user | |
312 | .PP | |
313 | to the passive peer's server. (Here, | |
314 | .I user | |
d64ce4ae MW |
315 | is a name identifying the active peer; see below.) Doing this is the |
316 | responsibility of the | |
317 | .B connect | |
318 | command. | |
a62f8e8a MW |
319 | .RE |
320 | .hP 3. | |
321 | The | |
322 | .B connect | |
323 | service on the passive peer responds with a | |
324 | .I challenge | |
325 | \(en a short Base64-encoded string. Somehow this challenge is sent back | |
326 | to the passive peer without being intercepted. | |
327 | .hP 4. | |
328 | The active peer sends a | |
329 | .BR GREET ing | |
330 | containing the challenge to its passive partner. The passive server | |
331 | announces the arrival of this message, and the originating address and | |
332 | port. | |
333 | .hP 5. | |
334 | The | |
335 | .B connect | |
336 | service running on the passive host receives the notification, matches | |
337 | it up with the | |
338 | .I user | |
339 | from the initial connection request, and | |
340 | .BR ADD s | |
341 | the appropriate peer, with the address from the | |
342 | .BR GREET ing. | |
d64ce4ae MW |
343 | . |
344 | .SS "Operation" | |
345 | On startup, | |
346 | .B connect | |
347 | requests a list of current peers from the | |
348 | .BR tripe (8) | |
349 | server, and adopts any eligible peers. If the | |
350 | .B \-\-startup | |
351 | flag was passed on the command line, the newly adopted peers have their | |
352 | interfaces configured and connection attempts are made. | |
a62f8e8a | 353 | .PP |
d64ce4ae MW |
354 | Adopted peers are pinged at regular intervals (using the |
355 | .B PING | |
356 | administrative command; see | |
357 | .BR tripe-admin (5)). | |
358 | This process can be configured by assigning values to keys in the peer's | |
359 | database record. Some of these parameters are time intervals, | |
360 | expressed as a nonnegative integer followed optionally by | |
361 | .BR d , | |
362 | .BR h , | |
363 | .BR m , | |
364 | or | |
365 | .B s | |
366 | for days, hours, minutes, or seconds, respectively; if no suffix is | |
367 | given, seconds are assumed. | |
368 | .PP | |
369 | The parameters are as follows. | |
370 | .TP | |
371 | .B every | |
372 | A time interval: how often to ping the peer to ensure that it's still | |
02c99524 MW |
373 | alive. The default is 30 seconds for active dynamic peers, and 5 |
374 | minutes for passive peers. | |
375 | .IP | |
376 | The period for dynamic peers should be no longer than | |
377 | .I timeout | |
378 | \(mu | |
379 | .RI ( retries | |
380 | \- 1). Consider an idle mobile peer which has its IP address changed | |
381 | just before its passive peer begins pinging. The static peer's pings | |
382 | will go to the old address until it receives a ping back from the mobile | |
383 | peer. Therefore, the static peer has to keep pinging until it would | |
384 | definitely have received an unsolicited ping from the mobile peer, and | |
385 | therefore be informed of the change of address. And it's no use | |
386 | learning about the change of address just after sending the last ping to | |
387 | the old address, so the last retry doesn't count for the purposes of | |
388 | this calculation. | |
389 | .IP | |
390 | Besides, the consequences of failed pinging differ between dynamic and | |
391 | passive peers. In the former case, a failure provokes a reconnection | |
392 | attempt, after which (hopefully) things will work again: it's probably a | |
393 | good thing to check frequently and fail fast. In the latter case, the | |
394 | dynamic peer will certainly have to notice that it's been abandoned and | |
395 | arrange to retry, causing a communication failure where maybe there | |
396 | wasn't really one before. | |
d64ce4ae MW |
397 | .TP |
398 | .B timeout | |
399 | A time interval: how long to wait for a reply before retrying or giving | |
400 | up. The default is 10 seconds. | |
401 | .TP | |
402 | .B retries | |
403 | An integer: how many failed attempts to make before deciding that the | |
404 | peer is unreachable and taking action. The default is 5 attempts. | |
405 | .PP | |
406 | The algorithm is as follows. Send up to | |
407 | .I retries | |
408 | pings; if a reply is received before the | |
409 | .I timeout | |
410 | then the peer is alive; wait | |
411 | .I every | |
412 | and check again. If no reply is received within the | |
413 | .IR timeout , | |
414 | then try again up to | |
415 | .I retries | |
416 | times. If no attempt succeeds, the peer is declared unreachable. If | |
417 | the peer has a | |
418 | .B connect | |
419 | command (i.e., it connects dynamically) then another connection attempt | |
420 | is made. Otherwise the peer is killed. | |
a62f8e8a MW |
421 | . |
422 | .\"-------------------------------------------------------------------------- | |
423 | .SH "SERVICE COMMAND REFERENCE" | |
424 | . | |
425 | .\"* 10 Service commands | |
426 | The commands provided by the service are as follows. | |
427 | .SP | |
428 | .BI "active " peer | |
429 | Make an active connection to the named | |
430 | .IR peer . | |
431 | The service will submit the command | |
432 | .RS | |
433 | .IP | |
434 | .B ADD | |
435 | .RB [ \-cork ] | |
436 | .RB [ \-keepalive | |
437 | .IR time ] | |
48b84569 MW |
438 | .RB [ \-key |
439 | .IR tag ] | |
d64ce4ae MW |
440 | .RB [ \-priv |
441 | .IR tag ] | |
6411163d | 442 | .RB [ \-mobile ] |
a62f8e8a MW |
443 | .RB [ \-tunnel |
444 | .IR driver ] | |
445 | .I address | |
446 | .PP | |
447 | Specifically: | |
448 | .hP \*o | |
449 | The option | |
450 | .B \-cork | |
451 | is provided if the peer's database record assigns the | |
452 | .B cork | |
453 | key one of the values | |
454 | .BR t , | |
455 | .BR true , | |
456 | .BR y , | |
457 | .BR yes, | |
458 | or | |
459 | .BR on . | |
460 | .hP \*o | |
461 | The option | |
462 | .B \-keepalive | |
463 | .I time | |
464 | is provided if the database record assigns a value | |
465 | .I time | |
466 | to the | |
467 | .B keepalive | |
468 | key. | |
469 | .hP \*o | |
470 | The option | |
48b84569 MW |
471 | .B \-key |
472 | .I tag | |
473 | is provided if the database record assigns a value | |
474 | .I tag | |
475 | to the | |
476 | .B key | |
477 | key. | |
478 | .hP \*o | |
479 | The option | |
d64ce4ae MW |
480 | .B \-priv |
481 | .I tag | |
482 | is provided if the database record assigns a value | |
483 | .I tag | |
484 | to the | |
485 | .B priv | |
486 | key. | |
487 | .hP \*o | |
488 | The option | |
6411163d MW |
489 | .B \-mobile |
490 | is provided if the peer's database record assigns the | |
491 | .B mobile | |
492 | key one of the values | |
493 | .BR t , | |
494 | .BR true , | |
495 | .BR y , | |
496 | .BR yes, | |
497 | or | |
498 | .BR on . | |
499 | .hP \*o | |
500 | The option | |
a62f8e8a MW |
501 | .B \-tunnel |
502 | .I driver | |
503 | is provided if the database record assigns a value | |
504 | .I driver | |
505 | to the | |
506 | .B tunnel | |
507 | key. | |
508 | .hP \*o | |
509 | The | |
510 | .I address | |
511 | is the value assigned to the | |
512 | .B peer | |
513 | key in the database record. | |
514 | .RE | |
515 | .SP | |
d64ce4ae MW |
516 | .B adopted |
517 | For each peer being tracked by the | |
518 | .B connect | |
519 | service, write a line | |
520 | .B INFO | |
521 | .IR name . | |
522 | (Compatibility note: it's possible that further information will be | |
523 | provided about each peer, in the form of subsequent tokens. Clients | |
524 | should be prepared to ignore such tokens.) | |
525 | .SP | |
a62f8e8a MW |
526 | .BI "info " peer |
527 | Lists the database record for the named | |
528 | .IR peer . | |
529 | For each key/value pair, a line | |
530 | .RS | |
531 | .IP | |
532 | .B INFO | |
533 | .IB key = value | |
534 | .PP | |
535 | is output. The key/value pairs are output in an arbitrary order. | |
536 | .RE | |
d64ce4ae MW |
537 | .SP |
538 | .BI "kick " peer | |
539 | If | |
540 | .I peer | |
541 | is currently added, and its record in the peer database contains a | |
542 | .B connect | |
543 | key (see | |
544 | .BR peers.in ) | |
545 | then force a reconnection attempt. See | |
546 | .BR "Dynamic connection" . | |
547 | .SP | |
548 | .B "list-active" | |
a62f8e8a MW |
549 | Output a list of peers in the database. For each peer name |
550 | .IR peer , | |
551 | a line | |
552 | .RS | |
553 | .IP | |
554 | .B INFO | |
555 | .I peer | |
556 | .PP | |
557 | is output. | |
558 | .RE | |
559 | .SP | |
560 | .BI "passive \fR[" options "\fR]\fP " user | |
561 | If the database contains a user record mapping | |
562 | .I user | |
563 | to some | |
564 | .I peer | |
565 | then an | |
566 | .B INFO | |
567 | line is written containing a freshly chosen challenge string. If the | |
568 | server receives a | |
569 | .BR GREET ing | |
570 | message quoting this challenge within 30 seconds, the | |
571 | .B connect | |
572 | service will issue an | |
573 | .B ADD | |
574 | request for the peer, as for the | |
575 | .B active | |
576 | command, except that the origin of the | |
577 | .BR GREET ing | |
578 | packet is used as the peer's address. | |
579 | .RS | |
580 | .\"+opts | |
581 | .PP | |
582 | The following option is recognized. | |
583 | .TP | |
584 | .BI "\-timeout " time | |
585 | Wait for | |
586 | .I time | |
587 | instead of 30 seconds. The | |
588 | .I time | |
589 | is expressed as a non-negative integer followed by | |
590 | .BR d , | |
591 | .BR h , | |
592 | .BR m , | |
593 | or | |
594 | .B s | |
595 | for days, hours, minutes or seconds respectively; if no suffix is given, | |
596 | seconds are assumed. | |
597 | .\"-opts | |
598 | .RE | |
d3731285 MW |
599 | .SP |
600 | .BI "userpeer " user | |
601 | Output a single | |
602 | .B INFO | |
603 | line identifying the peer corresponding to the | |
604 | .I user | |
605 | name. | |
a62f8e8a MW |
606 | . |
607 | .\"-------------------------------------------------------------------------- | |
d64ce4ae | 608 | .SH "NOTIFICATIONS" |
a62f8e8a | 609 | . |
d64ce4ae MW |
610 | .\"* 30 Notification broadcasts (NOTE codes) |
611 | All notifications issued by | |
612 | .B connect | |
613 | begin with the tokens | |
614 | .BR "USER connect" . | |
a62f8e8a | 615 | .SP |
d64ce4ae MW |
616 | .B "USER connect peerdb-update" |
617 | The peer database has changed. Other interested clients should reopen | |
618 | the database. | |
a62f8e8a | 619 | .SP |
d64ce4ae MW |
620 | .BI "USER connect ping-failed " peer " " error\fR... |
621 | An attempt to | |
622 | .B PING | |
623 | the named | |
a62f8e8a | 624 | .I peer |
d64ce4ae MW |
625 | failed; the server replied |
626 | .B FAIL | |
627 | .IR error ... | |
a62f8e8a | 628 | .SP |
d64ce4ae | 629 | .BI "USER connect " process\fR... " stdout " line |
a62f8e8a | 630 | The |
d64ce4ae MW |
631 | .I process |
632 | spawned by the | |
633 | .B connect | |
634 | service unexpectedly wrote | |
635 | .I line | |
636 | to its standard output. | |
a62f8e8a MW |
637 | . |
638 | .\"-------------------------------------------------------------------------- | |
639 | .SH "WARNINGS" | |
640 | . | |
641 | .\"* 40 Warning broadcasts (WARN codes) | |
642 | All warnings issued by | |
643 | .B connect | |
644 | begin with the tokens | |
645 | .BR "USER connect" . | |
646 | .SP | |
647 | .BI "USER connect auto-add-failed " name " " error\fR... | |
648 | The attempt to add the peer | |
649 | .I name | |
650 | automatically failed: the | |
651 | .B ADD | |
652 | command reported | |
653 | .B FAIL | |
654 | .IR error ... | |
d64ce4ae MW |
655 | .SP |
656 | .BI "USER connect ping-ok " peer | |
657 | A reply was received to a | |
658 | .B PING | |
659 | sent to the | |
660 | .IR peer , | |
661 | though earlier attempts had failed. | |
662 | .SP | |
663 | .BI "USER connect ping-timeout " peer " attempt " i " of " n | |
664 | No reply was received to a | |
665 | .B PING | |
666 | sent to the | |
667 | .IR peer . | |
668 | So far, | |
669 | .I i | |
670 | .BR PING s | |
671 | have been sent; if a total of | |
672 | .I n | |
673 | consecutive attempts time out, the | |
674 | .B connect | |
675 | service will take further action. | |
676 | .SP | |
677 | .B "USER connect reconnecting " peer | |
678 | The dynamically connected | |
679 | .I peer | |
680 | seems to be unresponsive. The | |
681 | .B connect | |
682 | service will attempt to reconnect. | |
683 | .SP | |
684 | .BI "USER connect " process\fR... " stderr " line | |
685 | The | |
686 | .I process | |
687 | spawned by the | |
688 | .B connect | |
689 | service wrote | |
690 | .I line | |
691 | to its standard error. | |
692 | .SP | |
693 | .BI "USER connect " process\fR... " exit-nonzero " code | |
694 | The | |
695 | .I process | |
696 | spawned by the | |
697 | .B connect | |
698 | service exited with the nonzero status | |
699 | .IR code . | |
700 | .SP | |
701 | .BI "USER connect " process\fR... " exit-signal S" code | |
702 | The | |
703 | .I process | |
704 | spawned by the | |
705 | .B connect | |
706 | service was killed by signal | |
707 | .IR code . | |
708 | Here, | |
709 | .I code | |
710 | is the numeric value of the fatal signal. | |
711 | .SP | |
712 | .BI "USER connect " process\fR... " exit-unknown " status | |
713 | The | |
714 | .I process | |
715 | spawned by the | |
716 | .B connect | |
717 | service exited with an unknown | |
718 | .IR status . | |
719 | Here, | |
720 | .I status | |
721 | is the raw exit status, as returned by | |
722 | .BR waitpid (2), | |
723 | in hexadecimal. | |
724 | . | |
725 | .\"-------------------------------------------------------------------------- | |
726 | .SH "CHILD PROCESS IDENTIFIERS" | |
727 | . | |
728 | .\"* 50 Child process identifiers | |
729 | Some of the warnings and notifications refer to processes spawned by | |
730 | .B connect | |
731 | under various circumstances. The process identifiers are as follows. | |
732 | .SP | |
733 | .BI "connect " peer | |
734 | A child spawned in order to establish a dynamic connection with | |
735 | .IR peer . | |
736 | .SP | |
737 | .BI "disconnect " peer | |
738 | A child spawned in order to shut down a dynamic connection with | |
739 | .IR peer . | |
740 | .SP | |
741 | .BI "ifdown " peer | |
742 | A child spawned to deconfigure the network interface for | |
743 | .IR peer . | |
744 | .SP | |
745 | .BI "ifup " peer | |
746 | A child spawned to configure the network interface for | |
747 | .IR peer . | |
a62f8e8a MW |
748 | . |
749 | .\"-------------------------------------------------------------------------- | |
750 | .SH "SUMMARY" | |
751 | . | |
752 | .\"= summary | |
753 | . | |
754 | .\"-------------------------------------------------------------------------- | |
755 | .SH "SEE ALSO" | |
756 | . | |
757 | .BR tripe-service (7), | |
758 | .BR peers.in (5), | |
a62f8e8a MW |
759 | .BR tripe (8). |
760 | . | |
761 | .\"-------------------------------------------------------------------------- | |
762 | .SH "AUTHOR" | |
763 | . | |
764 | Mark Wooding, <mdw@distorted.org.uk> | |
765 | . | |
766 | .\"----- That's all, folks -------------------------------------------------- |