| blob | 27abc6a71b60525b55b87b786e0c14b135d0eebd |
1 '\" te
2 .\" Copyright (c) 2008, Sun Microsystems, Inc. All Rights Reserved.
3 .\" Copyright 2008 AT&T
4 .\" The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
5 .\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
6 .\" When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
7 .TH IP 7P "Dec 3, 2008"
8 .SH NAME
9 ip, IP \- Internet Protocol
10 .SH SYNOPSIS
11 .LP
12 .nf
13 \fB#include <sys/socket.h>\fR
14 .fi
16 .LP
17 .nf
18 \fB#include <netinet/in.h>\fR
19 .fi
21 .LP
22 .nf
23 \fBs = socket(AF_INET, SOCK_RAW, proto);\fR
24 .fi
26 .LP
27 .nf
28 \fBt = t_open ("/dev/rawip", O_RDWR);\fR
29 .fi
31 .SH DESCRIPTION
32 .sp
33 .LP
34 IP is the internetwork datagram delivery protocol that is central to the
35 Internet protocol family. Programs may use \fBIP\fR through higher-level
36 protocols such as the Transmission Control Protocol (TCP) or the User Datagram
37 Protocol (UDP), or may interface directly to IP. See \fBtcp\fR(7P) and
38 \fBudp\fR(7P). Direct access may be by means of the socket interface, using a
39 "raw socket," or by means of the Transport Level Interface (TLI). The protocol
40 options defined in the IP specification may be set in outgoing datagrams.
41 .sp
42 .LP
43 Packets sent to or from this system may be subject to IPsec policy. See
44 \fBipsec\fR(7P) for more information.
45 .SH APPLICATION PROGRAMMING INTERFACE
46 .sp
47 .LP
48 The STREAMS driver \fB/dev/rawip\fR is the TLI transport provider that provides
49 raw access to IP.
50 .sp
51 .LP
52 Raw IP sockets are connectionless and are normally used with the \fBsendto()\fR
53 and \fBrecvfrom()\fR calls (see \fBsend\fR(3SOCKET) and \fBrecv\fR(3SOCKET)),
54 although the \fBconnect\fR(3SOCKET) call may also be used to fix the
55 destination for future datagram. In this case, the \fBread\fR(2) or
56 \fBrecv\fR(3SOCKET) and \fBwrite\fR(2) or \fBsend\fR(3SOCKET) calls may be
57 used. If \fIproto\fR is \fBIPPROTO_RAW\fR or \fBIPPROTO_IGMP\fR, the
58 application is expected to include a complete IP header when sending.
59 Otherwise, that protocol number will be set in outgoing datagrams and used to
60 filter incoming datagrams and an IP header will be generated and prepended to
61 each outgoing datagram. In either case, received datagrams are returned with
62 the IP header and options intact.
63 .sp
64 .LP
65 If an application uses \fBIP_HDRINCL\fR and provides the IP header contents,
66 the IP stack does not modify the following supplied fields under any
67 conditions: Type of Service, DF Flag, Protocol, and Destination Address. The IP
68 Options and IHL fields are set by use of \fBIP_OPTIONS\fR, and \fBTotal
69 Length\fR is updated to include any options. Version is set to the default.
70 Identification is chosen by the normal IP ID selection logic. The source
71 address is updated if none was specified and the TTL is changed if the packet
72 has a broadcast destination address. Since an applicaton cannot send down
73 fragments (as IP assigns the IP ID), Fragment Offset is always 0. The IP
74 Checksum field is computed by IP. None of the data beyond the IP header are
75 changed, including the application-provided transport header.
76 .sp
77 .LP
78 The socket options supported at the IP level are:
79 .sp
80 .ne 2
81 .na
82 \fB\fBIP_OPTIONS\fR\fR
83 .ad
84 .RS 22n
85 IP options for outgoing datagrams. This socket option may be used to set IP
86 options to be included in each outgoing datagram. IP options to be sent are set
87 with \fBsetsockopt()\fR (see \fBgetsockopt\fR(3SOCKET)). The
88 \fBgetsockopt\fR(3SOCKET) call returns the IP options set in the last
89 \fBsetsockopt()\fR call. IP options on received datagrams are visible to user
90 programs only using raw IP sockets. The format of IP options given in
91 \fBsetsockopt()\fR matches those defined in the IP specification with one
92 exception: the list of addresses for the source routing options must include
93 the first-hop gateway at the beginning of the list of gateways. The first-hop
94 gateway address will be extracted from the option list and the size adjusted
95 accordingly before use. IP options may be used with any socket type in the
96 Internet family.
97 .RE
99 .sp
100 .ne 2
101 .na
102 \fB\fBIP_SEC_OPT\fR\fR
103 .ad
104 .RS 22n
105 Enable or obtain IPsec security settings for this socket. For more details on
106 the protection services of IPsec, see \fBipsec\fR(7P).
107 .RE
109 .sp
110 .ne 2
111 .na
112 \fB\fBIP_ADD_MEMBERSHIP\fR\fR
113 .ad
114 .RS 22n
115 Join a multicast group.
116 .RE
118 .sp
119 .ne 2
120 .na
121 \fB\fBIP_DROP_MEMBERSHIP\fR\fR
122 .ad
123 .RS 22n
124 Leave a multicast group.
125 .RE
127 .sp
128 .ne 2
129 .na
130 \fB\fBIP_BOUND_IF\fR\fR
131 .ad
132 .RS 22n
133 Limit reception and transmission of packets to this interface. Takes an
134 integer as an argument. The integer is the selected interface index.
135 .RE
137 .sp
138 .LP
139 The following options take \fBin_pktinfo_t\fR as the parameter:
140 .sp
141 .ne 2
142 .na
143 \fB\fBIP_PKTINFO\fR\fR
144 .ad
145 .sp .6
146 .RS 4n
147 Set the source address and/or transmit interface of the packet(s). Note that
148 the IP_BOUND_IF socket option takes precedence over the interface index passed
149 in IP_PKTINFO.
150 .sp
151 .in +2
152 .nf
153 struct in_pktinfo {
154 unsigned int ipi_ifindex;/* send/recv interface index */
155 struct in_addr ipi_spec_dst;/* matched source addr. */
156 struct in_addr ipi_addr;/* src/dst addr. in IP hdr */
157 } in_pktinfo_t;
158 .fi
159 .in -2
161 When passed in (on transmit) via ancillary data with IP_PKTINFO, ipi_spec_dst
162 is used as the source address and ipi_ifindex is used as the interface index to
163 send the packet out.
164 .RE
166 .sp
167 .ne 2
168 .na
169 \fB\fBIP_RECVPKTINFO\fR\fR
170 .ad
171 .sp .6
172 .RS 4n
173 Enable/disable receipt of the index of the interface the packet arrived on, the
174 local address that was matched for reception, and the inbound packet's actual
175 destination address. Takes boolean as the parameter. Returns struct
176 in_pktinfo_t as ancillary data.
177 .RE
179 .sp
180 .LP
181 The following options take a \fBstruct ip_mreq\fR as the parameter. The
182 structure contains a multicast address which must be set to the \fBCLASS-D\fR
183 \fBIP\fR multicast address and an interface address. Normally the interface
184 address is set to \fBINADDR_ANY\fR which causes the kernel to choose the
185 interface on which to join.
186 .sp
187 .ne 2
188 .na
189 \fB\fBIP_BLOCK_SOURCE\fR\fR
190 .ad
191 .RS 29n
192 Block multicast packets whose source address matches the given source address.
193 The specified group must be joined previously using IP_ADD_MEMBERSHIP or
194 MCAST_JOIN_GROUP.
195 .RE
197 .sp
198 .ne 2
199 .na
200 \fB\fBIP_UNBLOCK_SOURCE\fR\fR
201 .ad
202 .RS 29n
203 Unblock (begin receiving) multicast packets which were previously blocked using
204 IP_BLOCK_SOURCE.
205 .RE
207 .sp
208 .ne 2
209 .na
210 \fB\fBIP_ADD_SOURCE_MEMBERSHIP\fR\fR
211 .ad
212 .RS 29n
213 Begin receiving packets for the given multicast group whose source address
214 matches the specified address.
215 .RE
217 .sp
218 .ne 2
219 .na
220 \fB\fBIP_DROP_SOURCE_MEMBERSHIP\fR\fR
221 .ad
222 .RS 29n
223 Stop receiving packets for the given multicast group whose source address
224 matches the specified address.
225 .RE
227 .sp
228 .LP
229 The following options take a \fBstruct ip_mreq_source\fR as the parameter. The
230 structure contains a multicast address (which must be set to the CLASS-D IP
231 multicast address), an interface address, and a source address.
232 .sp
233 .ne 2
234 .na
235 \fB\fBMCAST_JOIN_GROUP\fR\fR
236 .ad
237 .RS 28n
238 Join a multicast group. Functionally equivalent to IP_ADD_MEMBERSHIP.
239 .RE
241 .sp
242 .ne 2
243 .na
244 \fB\fBMCAST_BLOCK_SOURCE\fR\fR
245 .ad
246 .RS 28n
247 Block multicast packets whose source address matches the given source address.
248 The specified group must be joined previously using IP_ADD_MEMBERSHIP or
249 MCAST_JOIN_GROUP.
250 .RE
252 .sp
253 .ne 2
254 .na
255 \fB\fBMCAST_UNBLOCK_SOURCE\fR\fR
256 .ad
257 .RS 28n
258 Unblock (begin receiving) multicast packets which were previously blocked using
259 MCAST_BLOCK_SOURCE.
260 .RE
262 .sp
263 .ne 2
264 .na
265 \fB\fBMCAST_LEAVE_GROUP\fR\fR
266 .ad
267 .RS 28n
268 Leave a multicast group. Functionally equivalent to IP_DROP_MEMBERSHIP.
269 .RE
271 .sp
272 .ne 2
273 .na
274 \fB\fBMCAST_JOIN_SOURCE_GROUP\fR\fR
275 .ad
276 .RS 28n
277 Begin receiving packets for the given multicast group whose source address
278 matches the specified address.
279 .RE
281 .sp
282 .ne 2
283 .na
284 \fB\fBMCAST_LEAVE_SOURCE_GROUP\fR\fR
285 .ad
286 .RS 28n
287 Stop receiving packets for the given multicast group whose source address
288 matches the specified address.
289 .RE
291 .sp
292 .LP
293 The following options take a struct \fBgroup_req\fR or struct
294 \fBgroup_source_req\fR as the parameter. The `\fBgroup_req\fR structure
295 contains an interface index and a multicast address which must be set to the
296 CLASS-D multicast address. The \fBgroup_source_req\fR structure is used for
297 those options which include a source address. It contains an interface index,
298 multicast address, and source address.
299 .sp
300 .ne 2
301 .na
302 \fB\fBIP_MULTICAST_IF\fR\fR
303 .ad
304 .RS 21n
305 The outgoing interface for multicast packets. This option takes a \fBstruct\fR
306 \fBin_addr\fR as an argument, and it selects that interface for outgoing IP
307 multicast packets. If the address specified is \fBINADDR_ANY\fR, it uses the
308 unicast routing table to select the outgoing interface (which is the default
309 behavior).
310 .RE
312 .sp
313 .ne 2
314 .na
315 \fB\fBIP_MULTICAST_TTL\fR\fR
316 .ad
317 .RS 21n
318 Time to live for multicast datagrams. This option takes an unsigned character
319 as an argument. Its value is the TTL that IP uses on outgoing multicast
320 datagrams. The default is \fB1\fR.
321 .RE
323 .sp
324 .ne 2
325 .na
326 \fB\fBIP_MULTICAST_LOOP\fR\fR
327 .ad
328 .RS 21n
329 Loopback for multicast datagrams. Normally multicast datagrams are delivered
330 to members on the sending host (or sending zone). Setting the unsigned
331 character argument to 0 causes the opposite behavior, meaning that when
332 multiple zones are present, the datagrams are delivered to all zones except the
333 sending zone.
334 .RE
336 .sp
337 .ne 2
338 .na
339 \fB\fBIP_RECVIF\fR\fR
340 .ad
341 .RS 21n
342 Receive the inbound interface index.
343 .RE
345 .sp
346 .ne 2
347 .na
348 \fB\fBIP_TOS\fR\fR
349 .ad
350 .RS 21n
351 This option takes an integer argument as its input value. The least significant
352 8 bits of the value are used to set the Type Of Service field in the IP header
353 of the outgoing packets.
354 .RE
356 .sp
357 .ne 2
358 .na
359 \fB\fBIP_NEXTHOP\fR\fR
360 .ad
361 .RS 21n
362 This option specifies the address of the onlink nexthop for traffic originating
363 from that socket. It causes the routing table to be bypassed and outgoing
364 traffic is sent directly to the specified nexthop. This option takes an
365 ipaddr_t argument representing the IPv4 address of the nexthop as the input
366 value. The IP_NEXTHOP option takes precedence over IPOPT_LSRR. IP_BOUND_IF and
367 SO_DONTROUTE take precedence over IP_NEXTHOP. This option has no meaning for
368 broadcast and multicast packets. The application must ensure that the specified
369 nexthop is alive. An application may want to specify the IP_NEXTHOP option on a
370 TCP listener socket only for incoming requests to a particular IP address. In
371 this case, it must avoid binding the socket to INADDR_ANY and instead must bind
372 the listener socket to the specific IP address. In addition, typically the
373 application may want the incoming and outgoing interface to be the same. In
374 this case, the application must select a suitable nexthop that is onlink and
375 reachable via the desired interface and do a setsockopt (IP_NEXTHOP) on it.
376 Then it must bind to the IP address of the desired interface. Setting the
377 IP_NEXTHOP option requires the PRIV_SYS_NET_CONFIG privilege.
378 .RE
380 .sp
381 .LP
382 The multicast socket options (IP_MULTICAST_IF, IP_MULTICAST_TTL,
383 IP_MULTICAST_LOOP and IP_RECVIF) can be used with any datagram socket type in
384 the Internet family.
385 .sp
386 .LP
387 At the socket level, the socket option \fBSO_DONTROUTE\fR may be applied. This
388 option forces datagrams being sent to bypass routing and forwarding by forcing
389 the IP Time To Live field to \fB1\fR, meaning that the packet will not be
390 forwarded by routers.
391 .sp
392 .LP
393 Raw IP datagrams can also be sent and received using the TLI connectionless
394 primitives.
395 .sp
396 .LP
397 Datagrams flow through the IP layer in two directions: from the network
398 \fIup\fR to user processes and from user processes \fIdown\fR to the network.
399 Using this orientation, IP is layered \fIabove\fR the network interface drivers
400 and \fIbelow\fR the transport protocols such as UDP and TCP. The Internet
401 Control Message Protocol (ICMP) is logically a part of IP. See \fBicmp\fR(7P).
402 .sp
403 .LP
404 IP provides for a checksum of the header part, but not the data part, of the
405 datagram. The checksum value is computed and set in the process of sending
406 datagrams and checked when receiving datagrams.
407 .sp
408 .LP
409 IP options in received datagrams are processed in the IP layer according to the
410 protocol specification. Currently recognized IP options include: security,
411 loose source and record route (LSRR), strict source and record route (SSRR),
412 record route, and internet timestamp.
413 .sp
414 .LP
415 By default, the IP layer will not forward IPv4 packets that are not addressed
416 to it. This behavior can be overridden by using \fBrouteadm\fR(1M) to enable
417 the ipv4-forwarding option. IPv4 forwarding is configured at boot time based on
418 the setting of \fBrouteadm\fR(1M)'s ipv4-forwarding option.
419 .sp
420 .LP
421 For backwards compatibility, IPv4 forwarding can be enabled or disabled using
422 \fBndd\fR(1M)'s ip_forwarding variable. It is set to 1 if IPv4 forwarding is
423 enabled, or 0 if it is disabled.
424 .sp
425 .LP
426 Additionally, finer-grained forwarding can be configured in IP. Each interface
427 can be configured to forward IP packets by setting the IFF_ROUTER interface
428 flag. This flag can be set and cleared using \fBifconfig\fR(1M)'s router and
429 router options. If an interface's IFF_ROUTER flag is set, packets can be
430 forwarded to or from the interface. If it is clear, packets will neither be
431 forwarded from this interface to others, nor forwarded to this interface.
432 Setting the ip_forwarding variable sets all of the IPv4 interfaces' IFF_ROUTER
433 flags.
434 .sp
435 .LP
436 For backwards compatibility, each interface creates an
437 \fB<ifname>:ip_forwarding /dev/ip\fR variable that can be modified using
438 \fBndd\fR(1M). An interface's \fB:ip_forwarding ndd\fR variable is a boolean
439 variable that mirrors the status of its IFF_ROUTER interface flag. It is set to
440 1 if the flag is set, or 0 if it is clear. This interface specific \fB<ifname>
441 :ip_forwarding ndd\fR variable is obsolete and may be removed in a future
442 release of Solaris. The \fBifconfig\fR(1M) router and -router interfaces are
443 preferred.
444 .sp
445 .LP
446 The IP layer sends an ICMP message back to the source host in many cases when
447 it receives a datagram that can not be handled. A "time exceeded" ICMP message
448 is sent if the "time to live" field in the IP header drops to zero in the
449 process of forwarding a datagram. A "destination unreachable" message is sent
450 if a datagram can not be forwarded because there is no route to the final
451 destination, or if it can not be fragmented. If the datagram is addressed to
452 the local host but is destined for a protocol that is not supported or a port
453 that is not in use, a destination unreachable message is also sent. The IP
454 layer may send an ICMP "source quench" message if it is receiving datagrams too
455 quickly. ICMP messages are only sent for the first fragment of a fragmented
456 datagram and are never returned in response to errors in other ICMP messages.
457 .sp
458 .LP
459 The IP layer supports fragmentation and reassembly. Datagrams are fragmented on
460 output if the datagram is larger than the maximum transmission unit (MTU) of
461 the network interface. Fragments of received datagrams are dropped from the
462 reassembly queues if the complete datagram is not reconstructed within a short
463 time period.
464 .sp
465 .LP
466 Errors in sending discovered at the network interface driver layer are passed
467 by IP back up to the user process.
468 .sp
469 .LP
470 Multi-Data Transmit allows more than one packet to be sent from the IP module
471 to another in a given call, thereby reducing the per-packet processing costs.
472 The behavior of Multi-Data Transmit can be overrideen by using \fBndd\fR(1M) to
473 set the \fB/dev/ip\fR variable, ip_multidata_outbound to 0. Note, the IP module
474 will only initiate Multi-Data Transmit if the network interface driver supports
475 it.
476 .SH PACKET EVENTS
477 .sp
478 .LP
479 Through the netinfo framework, this driver provides the following packet
480 events:
481 .sp
482 .ne 2
483 .na
484 \fBPhysical in\fR
485 .ad
486 .RS 16n
487 Packets received on a network interface from an external source.
488 .RE
490 .sp
491 .ne 2
492 .na
493 \fBPhysical out\fR
494 .ad
495 .RS 16n
496 Packets to be sent out a network interface.
497 .RE
499 .sp
500 .ne 2
501 .na
502 \fBForwarding\fR
503 .ad
504 .RS 16n
505 Packets being forwarded through this host to another network.
506 .RE
508 .sp
509 .ne 2
510 .na
511 \fBloopback in\fR
512 .ad
513 .RS 16n
514 Packets that have been sent by a local application to another.
515 .RE
517 .sp
518 .ne 2
519 .na
520 \fBloopback out\fR
521 .ad
522 .RS 16n
523 Packets about to be received by a local application from another.
524 .RE
526 .sp
527 .LP
528 Currently, only a single function may be registered for each event. As a
529 result, if the slot for an event is already occupied by someone else, a second
530 attempt to register a callback fails.
531 .sp
532 .LP
533 To receive packet events in a kernel module, it is first necessary to obtain a
534 handle for either IPv4 or IPv6 traffic. This is achieved by passing NHF_INET
535 or NHF_INET6 through to a net_protocol_lookup() call. The value returned from
536 this call must then be passed into a call to net_register_hook(), along with
537 a description of the hook to add. For a description of the structure passed
538 through to the callback, please see \fBhook_pkt_event\fR(9S). For IP
539 packets, this structure is filled out as follows:
540 .sp
541 .ne 2
542 .na
543 \fBhpe_ifp\fR
544 .ad
545 .RS 11n
546 Identifier indicating the inbound interface for packets received with the
547 "physical in" event.
548 .RE
550 .sp
551 .ne 2
552 .na
553 \fBhpe_ofp\fR
554 .ad
555 .RS 11n
556 Identifier indicating the outbound interface for packets received with the
557 "physical out" event.
558 .RE
560 .sp
561 .ne 2
562 .na
563 \fBhpe_hdr\fR
564 .ad
565 .RS 11n
566 Pointer to the start of the IP header (not the ethernet header).
567 .RE
569 .sp
570 .ne 2
571 .na
572 \fBhpe_mp\fR
573 .ad
574 .RS 11n
575 Pointer to the start of the mblk_t chain containing the IP packet.
576 .RE
578 .sp
579 .ne 2
580 .na
581 \fBhpe_mb\fR
582 .ad
583 .RS 11n
584 Pointer to the mblk_t with the IP header in it.
585 .RE
587 .SH NETWORK INTERFACE EVENTS
588 .sp
589 .LP
590 In addition to events describing packets as they move through the system, it is
591 also possible to receive notification of events relating to network interfaces.
592 These events are all reported back through the same callback. The list of
593 events is as follows:
594 .sp
595 .ne 2
596 .na
597 \fBplumb\fR
598 .ad
599 .RS 18n
600 A new network interface has been instantiated.
601 .RE
603 .sp
604 .ne 2
605 .na
606 \fBunplumb\fR
607 .ad
608 .RS 18n
609 A network interface is no longer associated with this protocol.
610 .RE
612 .sp
613 .ne 2
614 .na
615 \fBup\fR
616 .ad
617 .RS 18n
618 At least one logical interface is now ready to receive packets.
619 .RE
621 .sp
622 .ne 2
623 .na
624 \fBdown\fR
625 .ad
626 .RS 18n
627 There are no logical interfaces expecting to receive packets.
628 .RE
630 .sp
631 .ne 2
632 .na
633 \fBaddress change\fR
634 .ad
635 .RS 18n
636 An address has changed on a logical interface.
637 .RE
639 .SH SEE ALSO
640 .sp
641 .LP
642 \fBifconfig\fR(1M), \fBrouteadm\fR(1M), \fBndd\fR(1M), \fBread\fR(2),
643 \fBwrite\fR(2), \fBbind\fR(3SOCKET), \fBconnect\fR(3SOCKET),
644 \fBgetsockopt\fR(3SOCKET), \fBrecv\fR(3SOCKET), \fBsend\fR(3SOCKET),
645 \fBdefaultrouter\fR(4), \fBicmp\fR(7P), \fBif_tcp\fR(7P), \fBinet\fR(7P),
646 \fBip6\fR(7P), \fBipsec\fR(7P), \fBrouting\fR(7P), \fBtcp\fR(7P),
647 \fBudp\fR(7P), \fBnet_hook_register\fR(9F), \fBhook_pkt_event\fR(9S)
648 .sp
649 .LP
650 Braden, R., \fIRFC 1122, Requirements for Internet Hosts \(mi Communication
651 Layers\fR, Information Sciences Institute, University of Southern California,
652 October 1989.
653 .sp
654 .LP
655 Postel, J., \fIRFC 791, Internet Protocol \(mi DARPA Internet Program Protocol
656 Specification\fR, Information Sciences Institute, University of Southern
657 California, September 1981.
658 .SH DIAGNOSTICS
659 .sp
660 .LP
661 A socket operation may fail with one of the following errors returned:
662 .sp
663 .ne 2
664 .na
665 \fB\fBEACCES\fR\fR
666 .ad
667 .RS 17n
668 A \fBbind()\fR operation was attempted with a "reserved" port number and the
669 effective user ID of the process was not the privileged user.
670 .sp
671 Setting the IP_NEXTHOP was attempted by a process lacking the
672 PRIV_SYS_NET_CONFIG privilege.
673 .RE
675 .sp
676 .ne 2
677 .na
678 \fB\fBEADDRINUSE\fR\fR
679 .ad
680 .RS 17n
681 A \fBbind()\fR operation was attempted on a socket with a network address/port
682 pair that has already been bound to another socket.
683 .RE
685 .sp
686 .ne 2
687 .na
688 \fB\fBEADDRNOTAVAIL\fR\fR
689 .ad
690 .RS 17n
691 A \fBbind()\fR operation was attempted for an address that is not configured on
692 this machine.
693 .RE
695 .sp
696 .ne 2
697 .na
698 \fB\fBEINVAL\fR\fR
699 .ad
700 .RS 17n
701 A \fBsendmsg()\fR operation with a non-NULL \fBmsg_accrights\fR was attempted.
702 .RE
704 .sp
705 .ne 2
706 .na
707 \fB\fBEINVAL\fR\fR
708 .ad
709 .RS 17n
710 A \fBgetsockopt()\fR or \fBsetsockopt()\fR operation with an unknown socket
711 option name was given.
712 .RE
714 .sp
715 .ne 2
716 .na
717 \fB\fBEINVAL\fR\fR
718 .ad
719 .RS 17n
720 A \fBgetsockopt()\fR or \fBsetsockopt()\fR operation was attempted with the
721 \fBIP\fR option field improperly formed; an option field was shorter than the
722 minimum value or longer than the option buffer provided.
723 .RE
725 .sp
726 .ne 2
727 .na
728 \fB\fBEISCONN\fR\fR
729 .ad
730 .RS 17n
731 A \fBconnect()\fR operation was attempted on a socket on which a
732 \fBconnect()\fR operation had already been performed, and the socket could not
733 be successfully disconnected before making the new connection.
734 .RE
736 .sp
737 .ne 2
738 .na
739 \fB\fBEISCONN\fR\fR
740 .ad
741 .RS 17n
742 A \fBsendto()\fR or \fBsendmsg()\fR operation specifying an address to which
743 the message should be sent was attempted on a socket on which a \fBconnect()\fR
744 operation had already been performed.
745 .RE
747 .sp
748 .ne 2
749 .na
750 \fB\fBEMSGSIZE\fR\fR
751 .ad
752 .RS 17n
753 A \fBsend()\fR, \fBsendto()\fR, or \fBsendmsg()\fR operation was attempted to
754 send a datagram that was too large for an interface, but was not allowed to be
755 fragmented (such as broadcasts).
756 .RE
758 .sp
759 .ne 2
760 .na
761 \fB\fBENETUNREACH\fR\fR
762 .ad
763 .RS 17n
764 An attempt was made to establish a connection by means of \fBconnect()\fR, or
765 to send a datagram by means of \fBsendto()\fR or \fBsendmsg()\fR, where there
766 was no matching entry in the routing table; or if an ICMP "destination
767 unreachable" message was received.
768 .RE
770 .sp
771 .ne 2
772 .na
773 \fB\fBENOTCONN\fR\fR
774 .ad
775 .RS 17n
776 A \fBsend()\fR or \fBwrite()\fR operation, or a \fBsendto()\fR or
777 \fBsendmsg()\fR operation not specifying an address to which the message should
778 be sent, was attempted on a socket on which a \fBconnect()\fR operation had not
779 already been performed.
780 .RE
782 .sp
783 .ne 2
784 .na
785 \fB\fBENOBUFS\fR\fR
786 .ad
787 .RS 17n
788 The system ran out of memory for fragmentation buffers or other internal data
789 structures.
790 .RE
792 .sp
793 .ne 2
794 .na
795 \fB\fBENOBUFS\fR\fR
796 .ad
797 .RS 17n
798 \fBSO_SNDBUF\fR or \fBSO_RCVBUF\fR exceeds a system limit.
799 .RE
801 .sp
802 .ne 2
803 .na
804 \fB\fBEINVAL\fR\fR
805 .ad
806 .RS 17n
807 Invalid length for \fBIP_OPTIONS\fR.
808 .RE
810 .sp
811 .ne 2
812 .na
813 \fB\fBEHOSTUNREACH\fR\fR
814 .ad
815 .RS 17n
816 Invalid address for \fBIP_MULTICAST_IF\fR.
817 .sp
818 Invalid (offlink) nexthop address for IP_NEXTHOP.
819 .RE
821 .sp
822 .ne 2
823 .na
824 \fB\fBEINVAL\fR\fR
825 .ad
826 .RS 17n
827 Not a multicast address for \fBIP_ADD_MEMBERSHIP\fR and
828 \fBIP_DROP_MEMBERSHIP\fR.
829 .RE
831 .sp
832 .ne 2
833 .na
834 \fB\fBEADDRNOTAVAIL\fR\fR
835 .ad
836 .RS 17n
837 Bad interface address for \fBIP_ADD_MEMBERSHIP\fR and \fBIP_DROP_MEMBERSHIP\fR.
838 .RE
840 .sp
841 .ne 2
842 .na
843 \fB\fBEADDRINUSE\fR\fR
844 .ad
845 .RS 17n
846 Address already joined for \fBIP_ADD_MEMBERSHIP\fR.
847 .RE
849 .sp
850 .ne 2
851 .na
852 \fB\fBENOENT\fR\fR
853 .ad
854 .RS 17n
855 Address not joined for \fBIP_DROP_MEMBERSHIP\fR.
856 .RE
858 .sp
859 .ne 2
860 .na
861 \fB\fBENOPROTOOPT\fR\fR
862 .ad
863 .RS 17n
864 Invalid socket type.
865 .RE
867 .sp
868 .ne 2
869 .na
870 \fB\fBEPERM\fR\fR
871 .ad
872 .RS 17n
873 No permissions.
874 .RE
876 .SH NOTES
877 .sp
878 .LP
879 Raw sockets should receive \fBICMP\fR error packets relating to the protocol;
880 currently such packets are simply discarded.
881 .sp
882 .LP
883 Users of higher-level protocols such as \fBTCP\fR and \fBUDP\fR should be able
884 to see received IP options.