Provided by:
manpages-ja_0.5.0.0.20060115-1_all 
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>
インクルードファイルにある。