1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
<table class="head">
<tr>
<td class="head-ltitle">LO(4)</td>
<td class="head-vol">Device Drivers Manual</td>
<td class="head-rtitle">LO(4)</td>
</tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp"><code class="Nm">lo</code> — <span class="Nd">software
loopback network interface</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp"><code class="Cd">device loop</code></p>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">The <code class="Nm">loop</code> interface is a software loopback
mechanism which may be used for performance analysis, software testing,
and/or local communication. As with other network interfaces, the loopback
interface must have network addresses assigned for each address family with
which it is to be used. These addresses may be set with the appropriate
<a class="Xr">ioctl(2)</a> commands for corresponding address families. The
loopback interface should be the last interface configured, as protocols may
use the order of configuration as an indication of priority. The loopback
should
<a class="permalink" href="#never"><i class="Em" id="never">never</i></a> be
configured first unless no hardware interfaces exist.</p>
<p class="Pp">If the transmit checksum offload capability flag is enabled on a
loopback interface, checksums will not be generated by IP, UDP, TCP, or SCTP
for packets sent on the interface.</p>
<p class="Pp">If the receive checksum offload capability flag is enabled on a
loopback interface, checksums will not be validated by IP, UDP, TCP, or SCTP
for packets received on the interface.</p>
<p class="Pp">By default, both receive and transmit checksum flags will be
enabled, in order to avoid the overhead of checksumming for local
communication where data corruption is unlikely. If transmit checksum
generation is disabled, then validation should also be disabled in order to
avoid packets being dropped due to invalid checksums.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="DIAGNOSTICS"><a class="permalink" href="#DIAGNOSTICS">DIAGNOSTICS</a></h1>
<dl class="Bl-diag">
<dt>lo%d: can't handle af%d.</dt>
<dd>The interface was handed a message with addresses formatted in an
unsuitable address family; the packet was dropped.</dd>
</dl>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
ALSO</a></h1>
<p class="Pp"><a class="Xr">inet(4)</a>, <a class="Xr">intro(4)</a></p>
</section>
<section class="Sh">
<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1>
<p class="Pp">The <code class="Nm">lo</code> device appeared in
<span class="Ux">4.2BSD</span>. The current checksum generation and
validation avoidance policy appeared in <span class="Ux">FreeBSD
8.0</span>.</p>
</section>
</div>
<table class="foot">
<tr>
<td class="foot-date">June 23, 2024</td>
<td class="foot-os">FreeBSD 15.0</td>
</tr>
</table>
|
