Provided by: manpages-ja_0.5.0.0.20060115-1_all bug

IOCTL

       SIOCGSTAMP
       を用いると、最後に受信したパケットのタイムスタンプを得ることがでい襦
       引た瑤 struct timeval である。

       さらに、 netdevice(7)  および  socket(7)  で定義されている標準の  ioctl
       はいずれも packet ソケットに指定可能である。

理
       packet      ソケットは、パケットをデバイスドライバに渡すとい      起-
       たエラーしか処理しない。遅延エラー           (pending            error)
       に関する概念は持っていない。

∪
       Linux    2.0   では、   packet   ソケットを得る方法は   socket(PF_INET,
       SOCK_PACKET,                                                  protocol)
       を呼ぶやり方しかなかった。この方法はまだサポートされているが、
       用いないことを強く推奨する。現在の方法との主な違いは、      SOCK_PACKET
       ではインターフェースの指定に古い           struct          sockaddr_pkt
       を用いる点である。これには物理層からの独立世ない。

              struct sockaddr_pkt {
                  unsigned short  spkt_family;
                  unsigned char   spkt_device[14];
                  unsigned short  spkt_protocol;
              };

       spkt_family  はデバイスのタイプ、  spkt_protocol<sys/if_ether.h>
       で定義されている     IEEE    802.3    プロトコルタイプ、    spkt_device
       はデバイスの名前を   NULL   終端された文字列で与えたもの   (例:   eth0)
       である。

       この構造体は   obsolete   であり、   新しくコードを書く時には用いるべ-
       でない。

意
       移植世良要なプログラムでは、      pcap(3)       経由で       PF_PACKET
       を用いることをお薦めする。ただし、この方法では                PF_PACKET
       の機能すべてを利用することはでい覆ぁ

       SOCK_DGRAM packet ソケットは、IEEE  802.3  フレームの  IEEE  802.2  LLC
       ヘッダの            生成や解析を行おうとしない。            ETH_P_802_3
       が送信プロトコルに指定されると、カーネルは  802.3  フレームを  生成して
       length                                            フィールドに書すむ。
       完全に準拠したパケットを得るためにはユーザーが       LLC       ヘッダを
       与える必要がある。到着した   802.3  パケットでは、  DSAP/SSAP  protocol
       の各フィールドは多重化 (multiplex) されていない。 代わりにこれらは  LLC
       ヘッダが前置された ETH_P_802_2 プロトコルとして与えられる。したがって、
       ETH_P_802_3      にバインドすることはでい覆ぁかわりに      ETH_P_802_2
       にバインドし、自分自身でプロトコルの多重化を行うこと。
       送信のデフォルトは、プロトコルフィールドを持つ  標準の   Ethernet   DIX
       encapsulation である。

       packet ソケットは入出力の firewall chain に影響をうけない。

ー
       ENETDOWN
              インターフェースが up でない。

       ENOTCONN
              インターフェースアドレスが渡されなかった。

       ENODEV デバイス名が不明。あるいはインターフェースアドレスで指定された
              インターフェースインデックスが不明。

       EMSGSIZE
              パケットがインターフェースの MTU より大いぁ

       ENOBUFS
              パケットに割り当てるメモリが造蠅覆ぁ

       EFAULT ユーザが渡したメモリアドレスが不正。

       EINVAL 引た瑤不正。

       ENXIO  インターフェースアドレスに不正なインターフェースインデックスが含まれている。

       EPERM  この操作を行うのに必要な権限をユーザが持っていない。

       EADDRNOTAVAIL
              不明なマルチゥ礇好肇哀襦璽廛▲疋譽垢渡された。

       ENOENT パケットを一つも受信していない。

              上軌奮阿離┘蕁爾、低レベルのドライバで生成されることがある。

ン
       PF_PACKET  は  Linux 2.2 の新機能である。これより古いバージョンの Linux
       では SOCK_PACKET のみをサポートしていた。

グ
       glibc                2.1                には                 SOL_PACKET
       の定義がない。回避策としては、以下のようにするとよい。
              #ifndef SOL_PACKET
              #define SOL_PACKET 263
              #endif
       この問題は新しいバージョンの     glibc    では修正されている。    libc5
       のシステムにはこの問題はない。

       IEEE 802.2/803.3 の LLC の扱い方は、バグと考えても良いだろう。

       ソケットフィルターについて戯椶気譴討い覆ぁ

       MSG_TRUNC recvmsg()  拡張は非常にまずい対処であり、制御メッセージで置-
       換えるべい任△襦                 今のところ                 SOCK_DGRAM
       経由でパケットについていた宛先アドレスを得る方法がない。

史
       インクルードファイル   <netpacket/packet.h>   が存在するのは   glibc2.1
       以降である。 それ以前のシステムでは以下のようにする必要がある:

       #include <asm/types.h>
       #include <linux/if_packet.h>
       #include <linux/if_ether.h> /* The L2 protocols */

目
       socket(2), pcap(3), capabilities(7), ip(7), raw(7), socket(7)

       標準 IP Ethernet encapsulation に関する情報は RFC 894 にある。

       IEEE 802.3 IP encapsulation に関する情報は RFC 1700 にある。

       物理層のプロトコルに関する欺劼                      <linux/if_ether.h>
       インクルードファイルにある。