release/man7/packet.7

   1 .\" This man page is Copyright (C) 1999 Andi Kleen <ak@muc.de>.
   2 .\"
   3 .\" %%%LICENSE_START(VERBATIM_ONE_PARA)
   4 .\" Permission is granted to distribute possibly modified copies
   5 .\" of this page provided the header is included verbatim,
   6 .\" and in case of nontrivial modification author and date
   7 .\" of the modification is added to the header.
   8 .\" %%%LICENSE_END
   9 .\"
  10 .\" $Id: packet.7,v 1.13 2000/08/14 08:03:45 ak Exp $
  11 .\"
  12 .\"*******************************************************************
  13 .\"
  14 .\" This file was generated with po4a. Translate the source file.
  15 .\"
  16 .\"*******************************************************************
  17 .\"
  18 .\" Japanese Version Copyright (c) 1999 NAKANO Takeo all rights reserved.
  19 .\" Translated 1999-12-06, NAKANO Takeo <nakano@apm.seikei.ac.jp>
  20 .\" Updated 2001-02-13, Kentaro Shirakata <argrath@ub32.org>
  21 .\" Updated 2005-02-21, Akihiro MOTOKI <amotoki@dd.iij4u.or.jp>
  22 .\"
  23 .TH PACKET 7 2014\-02\-26 Linux "Linux Programmer's Manual"
  24 .SH 名前
  25 packet \- デバイスレベルのパケットインターフェース
  26 .SH 書式
  27 .nf
  28 \fB#include <sys/socket.h>\fP
  29 .br
  30 \fB#include <netpacket/packet.h>\fP
  31 .br
  32 \fB#include <net/ethernet.h> /* the L2 protocols */\fP
  33 .sp
  34 \fBpacket_socket = socket(AF_PACKET, int \fP\fIsocket_type\fP\fB, int \fP\fIprotocol\fP\fB);\fP
  35 .fi
  36 .SH 説明
  37 packet ソケットは、デバイスドライバ (OSI レイヤ 2) レベルで 生のパケット (raw packet) を送受信するために用いられる。
  38 packet ソケットを使うと、ユーザー空間で物理層の上に プロトコルモジュールを実装することができる。
  39
  40 \fIsocket_type\fP には \fBSOCK_RAW\fP と \fBSOCK_DGRAM\fP のいずれかを指定する。 \fBSOCK_RAW\fP
  41 はリンクレベルヘッダを含む raw パケットを、 \fBSOCK_DGRAM\fP はリンクレベルヘッダが削除された加工済みパケットを示す。
  42 リンクレベルヘッダ情報は \fIsockaddr_ll\fP で共通のフォーマットで入手できる。 \fIprotocol\fP には IEEE 802.3
  43 プロトコル番号を ネットワークバイトオーダーで指定する。 指定できるプロトコルのリストは、インクルードファイル
  44 \fI<linux/if_ether.h>\fP を参照。プロトコルを \fBhtons(ETH_P_ALL)\fP
  45 にすると、全てのプロトコルが受信される。 外部から来たパケットのうち指定したプロトコルのものは、
  46 カーネルに実装されているプロトコルに渡される前の段階で、 packet ソケットに渡される。
  47
  48 packet ソケットをオープンできるのは、 実効ユーザーID が 0 のプロセスか、 \fBCAP_NET_RAW\fP
  49 ケーパビリティを持つプロセスだけである。
  50
  51 \fBSOCK_RAW\fP パケットでは、パケットをデバイスドライバと受け渡しする際、 パケットデータに変更が行われることはない。
  52 パケットの受信時には、アドレスの解析だけは行われ、 標準的な \fIsockaddr_ll\fP
  53 アドレス構造体に渡される。パケットの送信時には、ユーザが指定する バッファに物理層のヘッダが含まれている必要がある。
  54 パケットはそのまま修正を受けずに、行き先アドレスから決定される インターフェースのネットワークドライバにキューイングされる。
  55 デバイスドライバによっては、他のヘッダを常に追加するものもある。 \fBSOCK_RAW\fP は Linux 2.0 の obosolete な
  56 \fBAF_INET/SOCK_PACKET\fP と似ているが、互換性があるわけではない。
  57
  58 \fBSOCK_DGRAM\fP はやや高位のレベルで動作する。物理ヘッダは、パケットがユーザーに 渡される前に削除される。 \fBSOCK_DGRAM\fP の
  59 packet ソケットを通して送られるパケットは、 \fIsockaddr_ll\fP の行き先アドレスの情報に基づき、適切な物理層のヘッダが付加されてから、
  60 キューに送られる。
  61
  62 デフォルトでは、指定したプロトコル型のパケットはすべて packet ソケットに送られる。特定のインターフェースからのパケットだけを
  63 取得したい場合には、 \fIstruct sockaddr_ll\fP にアドレスを指定して \fBbind\fP(2)  を呼び、 packet
  64 ソケットをそのインターフェースに結び付ける (バインドする)。 バインドの際には、アドレスフィールドのうち \fIsll_protocol\fP と
  65 \fIsll_ifindex\fP だけが用いられる。
  66
  67 \fBconnect\fP(2)  操作は packet ソケットではサポートされていない。
  68
  69 \fBMSG_TRUNC\fP フラグが \fBrecvmsg\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2)  に渡されると、
  70 (バッファサイズより大きかったとしても) 常に実際に通信された パケットの長さが返される。
  71 .SS アドレスのタイプ
  72 \fIsockaddr_ll\fP はデバイスに依存しない物理層のアドレスである。
  73
  74 .in +4n
  75 .nf
  76 struct sockaddr_ll {
  77     unsigned short sll_family;   /* 常に AF_PACKET */
  78     unsigned short sll_protocol; /* 物理層のプロトコル */
  79     int            sll_ifindex;  /* インターフェース番号 */
  80     unsigned short sll_hatype;   /* ARP ハードウェア種別 */
  81     unsigned char  sll_pkttype;  /* パケット種別 */
  82     unsigned char  sll_halen;    /* アドレスの長さ */
  83     unsigned char  sll_addr[8];  /* 物理層のアドレス */
  84 };
  85 .fi
  86 .in
  87
  88 \fIsll_protocol\fP は標準的なイーサネットプロトコルのタイプで、 ネットワーク
  89 バイトオーダーで記述する。 インクルードファイル
  90 \fI<linux/if_ether.h>\fP で定義されている。 これがこのソケットのプロト
  91 コルのデフォルトとなる。 \fIsll_ifindex\fP はそのインターフェースの interface
  92 index である (\fBnetdevice\fP(7) を参照)。 0 は (バインドが許可されている) 任
  93 意のインターフェースにマッチする。 \fIsll_hatype\fP は、インクルードファイル
  94 \fI<linux/if_arp.h>\fP で定義されている ARP 種別である。
  95 \fIsll_pkttype\fP はパケット種別である。指定できる種別は以下のいずれかである:
  96 \fBPACKET_HOST\fP (ローカルホスト向けのパケット)、 \fBPACKET_BORADCAST\fP (物理層
  97 のブロードキャストパケット)、 \fBPACKET_MULTICAST\fP (物理層のマルチキャストア
  98 ドレスに送るパケット)、 \fBPACKET_OTHERHOST\fP (他のホストに向けられたパケット
  99 のうち、 無差別モード (promiscuous mode: 後述) のデバイスドライバにより補足
 100 されたもの)、 \fBPACKET_OUTGOING\fP (ローカルホストから発信され、 packet ソケッ
 101 トにループバックしてきたパケット)。 これらの種別が意味を持つのは受信時のみ
 102 である。 \fIsll_addr\fP と \fIsll_halen\fP は、物理層の (つまり IEEE 802.3 の)
 103 アドレスとその長さである。 厳密な解釈はデバイスに依存する。
 104
 105 パケットを送る場合は、 \fIsll_family\fP, \fIsll_addr\fP, \fIsll_halen\fP, \fIsll_ifindex\fP
 106 を指定すれば十分である。 その他のフィールドは 0 にしておくべきである。 \fIsll_hatype\fP と \fIsll_pkttype\fP
 107 には受信したパケットの情報が設定される。 バインドの際には、 \fIsll_protocol\fP と \fIsll_ifindex\fP だけが使用される。
 108 .SS ソケットオプション
 109 パケットソケットのオプションは、レベル \fBSOL_PACKET\fP を指定して \fBsetsockopt\fP(2) を呼び出すことで設定できる。
 110 .TP
 111 \fBPACKET_ADD_MEMBERSHIP\fP
 112 .PD 0
 113 .TP
 114 \fBPACKET_DROP_MEMBERSHIP\fP
 115 .PD
 116 packet ソケットは、物理層のマルチキャストや 無差別モード (promiscuous mode) を設定して使うことができる。
 117 \fBPACKET_ADD_MEMBERSHIP\fP はバインドを追加し、 \fBPACKET_DROP_MEMBERSHIP\fP
 118 はバインドを削除する。これらはいずれも \fIpacket_mreq\fP 構造体を引き数に取る。
 119
 120 .in +4n
 121 .nf
 122 struct packet_mreq {
 123     int            mr_ifindex;    /* インターフェース番号 */
 124     unsigned short mr_type;       /* 動作 */
 125     unsigned short mr_alen;       /* アドレスの長さ */
 126     unsigned char  mr_address[8]; /* 物理層のアドレス */
 127 };
 128 .fi
 129 .in
 130
 131 \fImr_ifindex\fP は、ステータスを変更したいインターフェースの インターフェース番号である。 \fImr_type\fP
 132 パラメータは実行する動作を指定する: \fBPACKET_MR_PROMISC\fP は、共有している媒体からの全てのパケットを受信できるようにする
 133 (しばしば "無差別モード (promiscuous mode)" と呼ばれる)。 \fBPACKET_MR_MULTICAST\fP は、そのソケットを、
 134 \fImr_address\fP と \fImr_alen\fP で指定される物理層のマルチキャストブループにバインドする。
 135 \fBPACKET_MR_ALLMULTI\fP は socket を up にして、そのインターフェースに到達したすべての
 136 マルチキャストパケットを受信できるようにする。
 137
 138 昔からある ioctl だけでなく、 \fBSIOCSIFFLAGS\fP, \fBSIOCADDMULTI\fP, \fBSIOCDELMULTI\fP
 139 を同じ目的に用いることができる。
 140 .TP
 141 \fBPACKET_AUXDATA\fP (Linux 2.6.21 以降)
 142 .\" commit 8dc4194474159660d7f37c495e3fc3f10d0db8cc
 143 If this binary option is enabled, the packet socket passes a metadata
 144 structure along with each packet in the \fBrecvmsg\fP(2)  control field.  The
 145 structure can be read with \fBcmsg\fP(3).  It is defined as
 146
 147 .in +4n
 148 .nf
 149 struct tpacket_auxdata {
 150     __u32 tp_status;
 151     __u32 tp_len;      /* packet length */
 152     __u32 tp_snaplen;  /* captured length */
 153     __u16 tp_mac;
 154     __u16 tp_net;
 155     __u16 tp_vlan_tci;
 156     __u16 tp_padding;
 157 };
 158 .fi
 159 .in
 160 .TP
 161 \fBPACKET_FANOUT\fP (Linux 3.1 以降)
 162 .\" commit dc99f600698dcac69b8f56dda9a8a00d645c5ffc
 163 To scale processing across threads, packet sockets can form a fanout group.
 164 In this mode, each matching packet is enqueued onto only one socket in the
 165 group.  A socket joins a fanout group by calling \fBsetsockopt\fP(2)  with
 166 level \fBSOL_PACKET\fP and option \fBPACKET_FANOUT\fP.  Each network namespace can
 167 have up to 65536 independent groups.  A socket selects a group by encoding
 168 the ID in the first 16 bits of the integer option value.  The first packet
 169 socket to join a group implicitly creates it.  To successfully join an
 170 existing group, subsequent packet sockets must have the same protocol,
 171 device settings, fanout mode and flags (see below).  Packet sockets can
 172 leave a fanout group only by closing the socket.  The group is deleted when
 173 the last socket is closed.
 174
 175 .\" commit 2d36097d26b5991d71a2cf4a20c1a158f0f1bfcd
 176 Fanout supports multiple algorithms to spread traffic between sockets.  The
 177 default mode, \fBPACKET_FANOUT_HASH\fP, sends packets from the same flow to the
 178 same socket to maintain per\-flow ordering.  For each packet, it chooses a
 179 socket by taking the packet flow hash modulo the number of sockets in the
 180 group, where a flow hash is a hash over network\-layer address and optional
 181 transport\-layer port fields.  The load\-balance mode \fBPACKET_FANOUT_LB\fP
 182 implements a round\-robin algorithm.  \fBPACKET_FANOUT_CPU\fP selects the socket
 183 based on the CPU that the packet arrived on.  \fBPACKET_FANOUT_ROLLOVER\fP
 184 processes all data on a single socket, moves to the next when one becomes
 185 backlogged.  \fBPACKET_FANOUT_RND\fP selects the socket using a pseudo\-random
 186 number generator.  \fBPACKET_FANOUT_QM\fP (available since Linux 3.14)  selects
 187 the socket using the recorded queue_mapping of the received skb.
 188
 189 Fanout modes can take additional options.  IP fragmentation causes packets
 190 from the same flow to have different flow hashes.  The flag
 191 \fBPACKET_FANOUT_FLAG_DEFRAG\fP, if set, causes packet to be defragmented
 192 before fanout is applied, to preserve order even in this case.  Fanout mode
 193 and options are communicated in the second 16 bits of the integer option
 194 value.  The flag \fBPACKET_FANOUT_FLAG_ROLLOVER\fP enables the roll over
 195 mechanism as a backup strategy: if the original fanout algorithm selects a
 196 backlogged socket, the packet rolls over to the next available one.
 197 .TP
 198 \fBPACKET_LOSS\fP (with \fBPACKET_TX_RING\fP)
 199 If set, do not silently drop a packet on transmission error, but return it
 200 with status set to \fBTP_STATUS_WRONG_FORMAT\fP.
 201 .TP
 202 \fBPACKET_RESERVE\fP (with \fBPACKET_RX_RING\fP)
 203 By default, a packet receive ring writes packets immediately following the
 204 metadata structure and alignment padding.  This integer option reserves
 205 additional headroom.
 206 .TP
 207 \fBPACKET_RX_RING\fP
 208 Create a memory\-mapped ring buffer for asynchronous packet reception.  The
 209 packet socket reserves a contiguous region of application address space,
 210 lays it out into an array of packet slots and copies packets (up to
 211 \fItp_snaplen\fP)  into subsequent slots.  Each packet is preceded by a
 212 metadata structure similar to \fItpacket_auxdata\fP.  The protocol fields
 213 encode the offset to the data from the start of the metadata header.
 214 \fItp_net\fP stores the offset to the network layer.  If the packet socket is
 215 of type \fBSOCK_DGRAM\fP, then \fItp_mac\fP is the same.  If it is of type
 216 \fBSOCK_RAW\fP, then that field stores the offset to the link\-layer frame.
 217 Packet socket and application communicate the head and tail of the ring
 218 through the \fItp_status\fP field.  The packet socket owns all slots with
 219 status \fBTP_STATUS_KERNEL\fP.  After filling a slot, it changes the status of
 220 the slot to transfer ownership to the application.  During normal operation,
 221 the new status is \fBTP_STATUS_USER\fP, to signal that a correctly received
 222 packet has been stored.  When the application has finished processing a
 223 packet, it transfers ownership of the slot back to the socket by setting the
 224 status to \fBTP_STATUS_KERNEL\fP.  Packet sockets implement multiple variants
 225 of the packet ring.  The implementation details are described in
 226 \fIDocumentation/networking/packet_mmap.txt\fP in the Linux kernel source tree.
 227 .TP
 228 \fBPACKET_STATISTICS\fP
 229 Retrieve packet socket statistics in the form of a structure
 230
 231 .in +4n
 232 .nf
 233 struct tpacket_stats {
 234     unsigned int tp_packets;  /* Total packet count */
 235     unsigned int tp_drops;    /* Dropped packet count */
 236 };
 237 .fi
 238 .in
 239
 240 Receiving statistics resets the internal counters.  The statistics structure
 241 differs when using a ring of variant \fBTPACKET_V3\fP.
 242 .TP
 243 \fBPACKET_TIMESTAMP\fP (with \fBPACKET_RX_RING\fP; since Linux 2.6.36)
 244 .\" commit 614f60fa9d73a9e8fdff3df83381907fea7c5649
 245 The packet receive ring always stores a timestamp in the metadata header.
 246 By default, this is a software generated timestamp generated when the packet
 247 is copied into the ring.  This integer option selects the type of
 248 timestamp.  Besides the default, it support the two hardware formats
 249 described in \fIDocumentation/networking/timestamping.txt\fP in the Linux
 250 kernel source tree.
 251 .TP
 252 \fBPACKET_TX_RING\fP (Linux 2.6.31 以降)
 253 .\" commit 69e3c75f4d541a6eb151b3ef91f34033cb3ad6e1
 254 Create a memory\-mapped ring buffer for packet transmission.  This option is
 255 similar to \fBPACKET_RX_RING\fP and takes the same arguments.  The application
 256 writes packets into slots with status \fBTP_STATUS_AVAILABLE\fP and schedules
 257 them for transmission by changing the status to \fBTP_STATUS_SEND_REQUEST\fP.
 258 When packets are ready to be transmitted, the application calls \fBsend\fP(2)
 259 or a variant thereof.  The \fIbuf\fP and \fIlen\fP fields of this call are
 260 ignored.  If an address is passed using \fBsendto\fP(2)  or \fBsendmsg\fP(2), then
 261 that overrides the socket default.  On successful transmission, the socket
 262 resets the slot to \fBTP_STATUS_AVAILABLE\fP.  It discards packets silently on
 263 error unless \fBPACKET_LOSS\fP is set.
 264 .TP
 265 \fBPACKET_VERSION\fP (with \fBPACKET_RX_RING\fP; since Linux 2.6.27)
 266 .\" commit bbd6ef87c544d88c30e4b762b1b61ef267a7d279
 267 By default, \fBPACKET_RX_RING\fP creates a packet receive ring of variant
 268 \fBTPACKET_V1\fP.  To create another variant, configure the desired variant by
 269 setting this integer option before creating the ring.
 270 .TP
 271 \fBPACKET_QDISC_BYPASS\fP (Linux 3.14 以降)
 272 .\" commit d346a3fae3ff1d99f5d0c819bf86edf9094a26a1
 273 By default, packets sent through packet sockets pass through the kernel's
 274 qdisc (traffic control) layer, which is fine for the vast majority of use
 275 cases.  For traffic generator appliances using packet sockets that intend to
 276 brute\-force flood the network\(emfor example, to test devices under load in
 277 a similar fashion to pktgen\(emthis layer can be bypassed by setting this
 278 integer option to 1.  A side effect is that packet buffering in the qdisc
 279 layer is avoided, which will lead to increased drops when network device
 280 transmit queues are busy; therefore, use at your own risk.
 281 .SS ioctl
 282 .\" FIXME Document SIOCGSTAMPNS
 283 \fBSIOCGSTAMP\fP を用いると、最後に受信したパケットのタイムスタンプを得ることができる。 引き数は \fIstruct timeval\fP
 284 型の変数である。
 285
 286 さらに、 \fBnetdevice\fP(7)  および \fBsocket\fP(7)  で定義されている標準の ioctl はいずれも packet
 287 ソケットに指定可能である。
 288 .SS エラー処理
 289 packet ソケットは、パケットをデバイスドライバに渡すときに 起きたエラーしか処理しない。遅延エラー (pending error)
 290 に関する概念は持っていない。
 291 .SH エラー
 292 .TP
 293 \fBEADDRNOTAVAIL\fP
 294 不明なマルチキャストグループアドレスが渡された。
 295 .TP
 296 \fBEFAULT\fP
 297 ユーザが渡したメモリアドレスが不正。
 298 .TP
 299 \fBEINVAL\fP
 300 引き数が不正。
 301 .TP
 302 \fBEMSGSIZE\fP
 303 パケットがインターフェースの MTU より大きい。
 304 .TP
 305 \fBENETDOWN\fP
 306 インターフェースが up でない。
 307 .TP
 308 \fBENOBUFS\fP
 309 パケットに割り当てるメモリが足りない。
 310 .TP
 311 \fBENODEV\fP
 312 デバイス名が不明。あるいはインターフェースアドレスで指定された インターフェースインデックスが不明。
 313 .TP
 314 \fBENOENT\fP
 315 パケットを一つも受信していない。
 316 .TP
 317 \fBENOTCONN\fP
 318 インターフェースアドレスが渡されなかった。
 319 .TP
 320 \fBENXIO\fP
 321 インターフェースアドレスに不正なインターフェースインデックスが含まれている。
 322 .TP
 323 \fBEPERM\fP
 324 この操作を行うのに必要な権限をユーザが持っていない。
 325
 326 上記以外のエラーが、低レベルのドライバで生成されることがある。
 327 .SH バージョン
 328 \fBAF_PACKET\fP は Linux 2.2 の新機能である。これより古いバージョンの Linux では \fBSOCK_PACKET\fP
 329 のみをサポートしていた。
 330 .PP
 331 インクルードファイル \fI<netpacket/packet.h>\fP が存在するのは glibc 2.1 以降である。
 332 それ以前のシステムでは以下のようにする必要がある:
 333 .sp
 334 .in +4n
 335 .nf
 336 #include <asm/types.h>
 337 #include <linux/if_packet.h>
 338 #include <linux/if_ether.h>  /* The L2 protocols */
 339 .fi
 340 .in
 341 .SH 注意
 342 移植性の必要なプログラムでは、 \fBpcap\fP(3)  経由で \fBAF_PACKET\fP を用いることをお薦めする。ただし、この方法では
 343 \fBAF_PACKET\fP の機能すべてを利用することはできない。
 344
 345 \fBSOCK_DGRAM\fP packet ソケットは、IEEE 802.3 フレームの IEEE 802.2 LLC ヘッダの
 346 生成や解析を行おうとしない。 \fBETH_P_802_3\fP が送信プロトコルに指定されると、カーネルは 802.3 フレームを 生成して length
 347 フィールドに書き込む。 完全に準拠したパケットを得るためにはユーザーが LLC ヘッダを 与える必要がある。到着した 802.3 パケットでは、
 348 DSAP/SSAP protocol の各フィールドは多重化 (multiplex) されていない。 代わりにこれらは LLC ヘッダが前置された
 349 \fBETH_P_802_2\fP プロトコルとして与えられる。したがって、 \fBETH_P_802_3\fP にバインドすることはできない。かわりに
 350 \fBETH_P_802_2\fP にバインドし、自分自身でプロトコルの多重化を行うこと。 送信のデフォルトは、プロトコルフィールドを持つ 標準の
 351 Ethernet DIX encapsulation である。
 352
 353 packet ソケットは入出力の firewall chain に影響をうけない。
 354 .SS 移植性
 355 Linux 2.0 では、 packet ソケットを得る方法は \fBsocket(AF_INET, SOCK_PACKET,
 356 \fP\fIprotocol\fP\fB)\fP を呼ぶやり方しかなかった。この方法はまだサポートされているが、 用いないことを強く推奨する。現在の方法との主な違いは、
 357 \fBSOCK_PACKET\fP ではインターフェースの指定に古い \fIstruct sockaddr_pkt\fP
 358 を用いる点である。これには物理層からの独立性がない。
 359
 360 .in +4n
 361 .nf
 362 struct sockaddr_pkt {
 363     unsigned short spkt_family;
 364     unsigned char  spkt_device[14];
 365     unsigned short spkt_protocol;
 366 };
 367 .fi
 368 .in
 369
 370 \fIspkt_family\fP はデバイスのタイプ、 \fIspkt_protocol\fP は \fI<sys/if_ether.h>\fP
 371 で定義されている IEEE 802.3 プロトコルタイプ、 \fIspkt_device\fP はデバイスの名前を NULL 終端された文字列で与えたもの
 372 (例: eth0) である。
 373
 374 この構造体は obsolete であり、 新しくコードを書く時には用いるべきでない。
 375 .SH バグ
 376 glibc 2.1 には \fBSOL_PACKET\fP の定義がない。回避策としては、以下のようにするとよい。
 377 .in +4n
 378 .nf
 379
 380 #ifndef SOL_PACKET
 381 #define SOL_PACKET 263
 382 #endif
 383
 384 .fi
 385 .in
 386 この問題は新しいバージョンの glibc では修正されている。 libc5 のシステムにはこの問題はない。
 387
 388 IEEE 802.2/803.3 の LLC の扱い方は、バグと考えても良いだろう。
 389
 390 ソケットフィルターについて記載されていない。
 391
 392 .\" .SH CREDITS
 393 .\" This man page was written by Andi Kleen with help from Matthew Wilcox.
 394 .\" AF_PACKET in Linux 2.2 was implemented
 395 .\" by Alexey Kuznetsov, based on code by Alan Cox and others.
 396 \fBMSG_TRUNC\fP \fBrecvmsg\fP(2)  拡張は非常にまずい対処であり、制御メッセージで置き換えるべきである。 今のところ
 397 \fBSOCK_DGRAM\fP 経由でパケットについていた宛先アドレスを得る方法がない。
 398 .SH 関連項目
 399 \fBsocket\fP(2), \fBpcap\fP(3), \fBcapabilities\fP(7), \fBip\fP(7), \fBraw\fP(7),
 400 \fBsocket\fP(7)
 401
 402 標準 IP Ethernet encapsulation に関しては RFC\ 894 を、 IEEE 802.3 IP encapsulation
 403 に関しては RFC\ 1700 を参照。
 404
 405 物理層のプロトコルに関する記述は \fI<linux/if_ether.h>\fP インクルードファイルにある。
 406 .SH この文書について
 407 この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.65 の一部
 408 である。プロジェクトの説明とバグ報告に関する情報は
 409 http://www.kernel.org/doc/man\-pages/ に書かれている。