書式
#include <sys/socket.h>
#include <netpacket/packet.h>
#include <net/ethernet.h> /* L2 プロトコル */
packet_socket = socket(AF_PACKET, int socket_type, int protocol);
説明
packet ソケットは、デバイスドライバ (OSI レイヤ 2) レベルで 生のパケット (raw packet) を送受信するために用いられる。 packet ソケットを使うと、ユーザー空間で物理層の上に プロトコルモジュールを実装することができる。socket_type には SOCK_RAW と SOCK_DGRAM のいずれかを指定する。 SOCK_RAW はリンクレベルヘッダを含む raw パケットを、 SOCK_DGRAM はリンクレベルヘッダが削除された加工済みパケットを示す。 リンクレベルヘッダ情報は sockaddr_ll で共通のフォーマットで入手できる。 protocol には IEEE 802.3 プロトコル番号を ネットワークバイトオーダーで指定する。 指定できるプロトコルのリストは、インクルードファイル <linux/if_ether.h> を参照。プロトコルを htons(ETH_P_ALL) にすると、全てのプロトコルが受信される。 外部から来たパケットのうち指定したプロトコルのものは、 カーネルに実装されているプロトコルに渡される前の段階で、 packet ソケットに渡される。
packet ソケットをオープンできるのは、 実効ユーザーID が 0 のプロセスか、 CAP_NET_RAW ケーパビリティを持つプロセスだけである。
SOCK_RAW パケットでは、パケットをデバイスドライバと受け渡しする際、 パケットデータに変更が行われることはない。 パケットの受信時には、アドレスの解析だけは行われ、 標準的な sockaddr_ll アドレス構造体に渡される。パケットの送信時には、ユーザが指定する バッファに物理層のヘッダが含まれている必要がある。 パケットはそのまま修正を受けずに、行き先アドレスから決定される インターフェースのネットワークドライバにキューイングされる。 デバイスドライバによっては、他のヘッダを常に追加するものもある。 SOCK_RAW は Linux 2.0 の obosolete な AF_INET/SOCK_PACKET と似ているが、互換性があるわけではない。
SOCK_DGRAM はやや高位のレベルで動作する。物理ヘッダは、パケットがユーザーに 渡される前に削除される。 SOCK_DGRAM の packet ソケットを通して送られるパケットは、 sockaddr_ll の行き先アドレスの情報に基づき、適切な物理層のヘッダが付加されてから、 キューに送られる。
デフォルトでは、指定したプロトコル型のパケットはすべて packet ソケットに送られる。特定のインターフェースからのパケットだけを 取得したい場合には、 struct sockaddr_ll にアドレスを指定して bind(2) を呼び、 packet ソケットをそのインターフェースに結び付ける (バインドする)。 バインドの際には、アドレスフィールドのうち sll_protocol と sll_ifindex だけが用いられる。
connect(2) 操作は packet ソケットではサポートされていない。
MSG_TRUNC フラグが recvmsg(2), recv(2), recvfrom(2) に渡されると、 (バッファサイズより大きかったとしても) 常に実際に通信された パケットの長さが返される。
アドレスのタイプ
sockaddr_ll はデバイスに依存しない物理層のアドレスである。
struct sockaddr_ll { unsigned short sll_family; /* 常に AF_PACKET */ unsigned short sll_protocol; /* 物理層のプロトコル */ int sll_ifindex; /* インターフェース番号 */ unsigned short sll_hatype; /* ARP ハードウェア種別 */ unsigned char sll_pkttype; /* パケット種別 */ unsigned char sll_halen; /* アドレスの長さ */ unsigned char sll_addr[8]; /* 物理層のアドレス */ };
sll_protocol は標準的なイーサネットプロトコルのタイプで、 ネットワーク バイトオーダーで記述する。 インクルードファイル <linux/if_ether.h> で定義されている。 これがこのソケットのプロト コルのデフォルトとなる。 sll_ifindex はそのインターフェースの interface index である (netdevice(7) を参照)。 0 は (バインドが許可されている) 任 意のインターフェースにマッチする。 sll_hatype は、インクルードファイル <linux/if_arp.h> で定義されている ARP 種別である。 sll_pkttype はパケット種別である。指定できる種別は以下のいずれかである: PACKET_HOST (ローカルホスト向けのパケット)、 PACKET_BORADCAST (物理層 のブロードキャストパケット)、 PACKET_MULTICAST (物理層のマルチキャストア ドレスに送るパケット)、 PACKET_OTHERHOST (他のホストに向けられたパケット のうち、 無差別モード (promiscuous mode: 後述) のデバイスドライバにより補足 されたもの)、 PACKET_OUTGOING (ローカルホストから発信され、 packet ソケッ トにループバックしてきたパケット)。 これらの種別が意味を持つのは受信時のみ である。 sll_addr と sll_halen は、物理層の (つまり IEEE 802.3 の) アドレスとその長さである。 厳密な解釈はデバイスに依存する。
パケットを送る場合は、 sll_family, sll_addr, sll_halen, sll_ifindex を指定すれば十分である。 その他のフィールドは 0 にしておくべきである。 sll_hatype と sll_pkttype には受信したパケットの情報が設定される。 バインドの際には、 sll_protocol と sll_ifindex だけが使用される。
ソケットオプション
パケットソケットのオプションは、レベル SOL_PACKET を指定して setsockopt(2) を呼び出すことで設定できる。- PACKET_ADD_MEMBERSHIP
- PACKET_DROP_MEMBERSHIP
-
packet ソケットは、物理層のマルチキャストや 無差別モード (promiscuous mode) を設定して使うことができる。
PACKET_ADD_MEMBERSHIP はバインドを追加し、 PACKET_DROP_MEMBERSHIP
はバインドを削除する。これらはいずれも packet_mreq 構造体を引き数に取る。
struct packet_mreq { int mr_ifindex; /* インターフェース番号 */ unsigned short mr_type; /* 動作 */ unsigned short mr_alen; /* アドレスの長さ */ unsigned char mr_address[8]; /* 物理層のアドレス */ };
mr_ifindex は、ステータスを変更したいインターフェースの インターフェース番号である。 mr_type パラメータは実行する動作を指定する: PACKET_MR_PROMISC は、共有している媒体からの全てのパケットを受信できるようにする (しばしば "無差別モード (promiscuous mode)" と呼ばれる)。 PACKET_MR_MULTICAST は、そのソケットを、 mr_address と mr_alen で指定される物理層のマルチキャストブループにバインドする。 PACKET_MR_ALLMULTI は socket を up にして、そのインターフェースに到達したすべての マルチキャストパケットを受信できるようにする。
昔からある ioctl だけでなく、 SIOCSIFFLAGS, SIOCADDMULTI, SIOCDELMULTI を同じ目的に用いることができる。
- PACKET_AUXDATA (Linux 2.6.21 以降)
-
ブール値のオプションを有効すると、 パケットソケットは、パケットと一緒にメタデータ構造体を recvmsg(2) コントロールフィールドで渡す。
この構造体は cmsg(3) を使って読むことができる。 定義は以下の通りである。
struct tpacket_auxdata { __u32 tp_status; __u32 tp_len; /* パケット長 */ __u32 tp_snaplen; /* キャプチャした長さ */ __u16 tp_mac; __u16 tp_net; __u16 tp_vlan_tci; __u16 tp_padding; };
- PACKET_FANOUT (Linux 3.1 以降)
-
スレッドにまたがって処理をスケールさせるため、 パケットソケットはファンアウトグループを構成することができる。 このモードでは、
マッチしたそれぞれのパケットはグループ内のいずれか一つのソケットにだけキューイングされる。 ソケットをファンアウトグループに参加させるには、 レベル
SOL_PACKET でオプション PACKET_FANOUT を指定して setsockopt(2) を呼び出す。
ネットワーク名前空間毎に最大 65536 個の独立したグループを持つことができる。 整数のオプション値の先頭 16 ビットに ID
をエンコードすることで、 ソケットはグループを選択する。 あるグループへの最初のパケットソケットの参加があった時点で、
グループは暗黙のうちに作成される。 既存のグループへの参加が成功するためには、 それ以降にそのグループに参加しようとするパケットソケットは、
プロトコロ、 デバイス設定、ファンアウトモード、フラグが同じである必要がある (下記参照)。 パケットソケットがファンアウトグループから抜けるのは、
そのソケットをクローズした場合だけである。 ファンアウトグループは最後のソケットがクローズした場合に削除される。
ファンアウトでは、 複数のソケットにトラフィックを分散させるアルゴリズムを複数サポートしている。 デフォルトのモードである PACKET_FANOUT_HASH では、同じフローのパケットは同じソケットに送信され、 フロー単位の順序が維持される。 パケットごとに、パケットフローのハッシュの、そのグループのソケット数に対する剰余が計算され、ソケットが選択される。 なお、フローハッシュはネットワーク層のアドレスとトランスポート層のポートフィールドに対するハッシュである (トランスポート層ポートは存在する場合のみ)。 負荷分散モード PACKET_FANOUT_LB はラウンドロビンアルゴリズムが採用されている。 PACKET_FANOUT_CPU では、 パケットが到着した CPU に基づいてソケットを選択する。 PACKET_FANOUT_ROLLOVER はすべてのデータを一つのソケットで処理し、 そのソケットで処理待ち (backlog) が発生した場合に次のソケットに移る。 PACKET_FANOUT_RND では擬似乱数発生器を使ってソケットが選択される。 PACKET_FANOUT_QM (Linux 3.14 以降で利用可能) では受信 skb に記録された queue_mapping を使ってソケットが選択される。
ファンアウトモードでは追加のオプションがある。 IP フラグメンテーションが起こると、 同じフローのパケットのフローハッシュが異なるハッシュを持つことになる。 フラグ PACKET_FANOUT_FLAG_DEFRAG をセットすると、 パケットはファンアウトを行う前にフラグメント再構築が行われるようになり、 フラグメントがあった場合でも順序が維持される。 ファンアウトモードとオプションは、 整数のオプション値の下位 16 ビットで指定される。 フラグ PACKET_FANOUT_FLAG_ROLLOVER を指定すると、 バックアップ戦略としてロールオーバー方式が有効になる。 元のファンアウトアルゴリズムが backlog ソケットを選択していれば、 パケットは次の利用可能なソケットにロールオーバーされる。
- PACKET_LOSS (PACKET_TX_RING で使用)
- 有効にすると、転送エラーの場合にパケットをエラーなしに黙って破棄せず、 ステータスを TP_STATUS_WRONG_FORMAT にセットして返る。
- PACKET_RESERVE (PACKET_RX_RING で使用)
- デフォルトでは、パケット受信リングはメタデータ構造体とアライメント用のパディングの直後にパケットを書き込む。 この整数オプションを設定すると、パケットの前に追加で領域が予約される。
- PACKET_RX_RING
- 非同期でのパケット受信用のメモリマップされたリングバッファを作成する。 パケットソケットはアプリケーションのアドレス空間に連続する領域を確保し、 そこにパケットスロットの配列を構成し、 (最大 tp_snaplen 個の) パケットを順にスロットにコピーする。 各パケットの前には tpacket_auxdata に似たメタデータ構造体が置かれる。 プロトコルフィールドには、データの、メタデータヘッダーの先頭からのオフセットが入る。 tp_net にはネットワーク層へのオフセットが格納される。 パケットソケットが SOCK_DGRAM 型の場合、 tp_mac も同じである。 SOCK_RAW 型の場合、 tp_net にはリンク層のフレームへのオフセットが入る。 パケットソケットとアプリケーションは tp_status フィールドを通してリングの先頭 (head) と末尾 (tail) の情報を受け渡す。 パケットソケットはすべてのスロットをステータス TP_STATUS_KERNEL で所有しており、 スロットにデータが入ると、パケットソケットはそのスロットのステータスをアプリケーションに所有権を渡す状態に変更する。 通常の動作では、新しいステータスは TP_STATUS_USER であり、これは正しく受信されたパケットが格納されたことを示している。 アプリケーションがパケットの処理を終えると、アプリケーションはそのスロットのステータスを TP_STATUS_KERNEL に設定し、そのスロットの所有権をソケットに返す。 パケットソケットは、複数バージョンのパケットリングを実装している。 実装の詳細は Linux カーネルソースツリーの Documentation/networking/packet_mmap.txt で説明されている。
- PACKET_STATISTICS
-
パケットソケットの統計情報を次の構造体形式で取得する。
struct tpacket_stats { unsigned int tp_packets; /* 総パケット数 */ unsigned int tp_drops; /* ドロップパケット数 */ };
統計情報を取得すると、内部カウンターはリセットされる。 TPACKET_V3 のリングを使う場合には、統計情報構造体は違うものになる。
- PACKET_TIMESTAMP (PACKET_RX_RING で使用; Linux 2.6.36 以降)
- パケット受信リングでは常にタイムスタンプがメタデータヘッダーに格納される。 デフォルトでは、タイムスタンプはパケットがリングにコピーされた時点で生成されるソフトウェアによるタイムスタンプである。 この整数オプションによりタイムスタンプの種類を選択できる。 デフォルト以外では、 Linux カーネルソースツリーの Documentation/networking/timestamping.txt に説明がある 2 種類のハードウェアフォーマットがサポートされている。
- PACKET_TX_RING (Linux 2.6.31 以降)
- パケット送信用のメモリマップされたリングバッファを作成する。 このオプションは PACKET_RX_RING と同様で、同じ引き数を取る。 アプリケーションはステータスが TP_STATUS_AVAILABLE のスロットにパケットを書き込み、 TP_STATUS_SEND_REQUEST にステータスを変更することでそのパケットが送信できるようにする。 パケットの送信準備ができたら、アプリケーションは続けて send(2) 系のシステムコールを呼び出す。 システムコールの引き数 buf と len は無視される。 sendto(2) や sendmsg(2) を使ってアドレスが渡された場合、 ソケットのデフォルト値ではなくそのアドレスが使用される。 送信に成功すると、ソケットはそのスロットを TP_STATUS_AVAILABLE に戻す。 エラーの場合、 PACKET_LOSS がセットされていなければエラーなしでパケットは廃棄される。
- PACKET_VERSION (PACKET_RX_RING で使用; Linux 2.6.27 以降)
- デフォルトでは、 PACKET_RX_RING は TPACKET_V1 のパケット受信リングを作成する。別のバージョンのリングを作成するには、そのリングを作成する前に希望するバージョンが使われるようにこの整数オプションを設定すること。
- PACKET_QDISC_BYPASS (Linux 3.14 以降)
- デフォルトでは、パケットはカーネルの qdisc (トラフィック制御) レイヤー経由で渡される。 これは大半のユースケースに合っている。 ネットワークに対して可能な限りパケットを送信する (例えば pkggen と同様の方法で負荷対象のデバイスを試験する) のにパケットソケットを使うトラフィック生成アプライアンスでは、この整数オプションを 1 に設定することで qdisc レイヤーを飛ばすことができる。 qdisc レイヤーでのパケットバッファが行われなくなるという副作用がある。 これにより、 ネットワークデバイスの送信キューの使用量が高い場合にパケット廃棄が起きやすくなる。
ioctl
SIOCGSTAMP を用いると、最後に受信したパケットのタイムスタンプを得ることができる。 引き数は struct timeval 型の変数である。さらに、 netdevice(7) および socket(7) で定義されている標準の ioctl はいずれも packet ソケットに指定可能である。
エラー処理
packet ソケットは、パケットをデバイスドライバに渡すときに 起きたエラーしか処理しない。遅延エラー (pending error) に関する概念は持っていない。エラー
- EADDRNOTAVAIL
- 不明なマルチキャストグループアドレスが渡された。
- EFAULT
- ユーザが渡したメモリアドレスが不正。
- EINVAL
- 引き数が不正。
- EMSGSIZE
- パケットがインターフェースの MTU より大きい。
- ENETDOWN
- インターフェースが up でない。
- ENOBUFS
- パケットに割り当てるメモリが足りない。
- ENODEV
- デバイス名が不明。あるいはインターフェースアドレスで指定された インターフェースインデックスが不明。
- ENOENT
- パケットを一つも受信していない。
- ENOTCONN
- インターフェースアドレスが渡されなかった。
- ENXIO
- インターフェースアドレスに不正なインターフェースインデックスが含まれている。
- EPERM
-
この操作を行うのに必要な権限をユーザが持っていない。
上記以外のエラーが、低レベルのドライバで生成されることがある。
バージョン
AF_PACKET は Linux 2.2 の新機能である。これより古いバージョンの Linux では SOCK_PACKET のみをサポートしていた。インクルードファイル <netpacket/packet.h> が存在するのは glibc 2.1 以降である。 それ以前のシステムでは以下のようにする必要がある:
#include <asm/types.h> #include <linux/if_packet.h> #include <linux/if_ether.h> /* The L2 protocols */
注意
移植性の必要なプログラムでは、 pcap(3) 経由で AF_PACKET を用いることをお薦めする。ただし、この方法では AF_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 に影響をうけない。
移植性
Linux 2.0 では、 packet ソケットを得る方法は socket(AF_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 はデバイスの名前をヌル終端された文字列で与えたもの (例: eth0) である。
この構造体は obsolete であり、 新しくコードを書く時には用いるべきでない。
バグ
glibc 2.1 には SOL_PACKET の定義がない。回避策としては、以下のようにするとよい。#ifndef SOL_PACKET #define SOL_PACKET 263 #endifこの問題は新しいバージョンの glibc では修正されている。 libc5 のシステムにはこの問題はない。
IEEE 802.2/803.3 の LLC の扱い方は、バグと考えても良いだろう。
ソケットフィルターについて記載されていない。
MSG_TRUNC recvmsg(2) 拡張は非常にまずい対処であり、制御メッセージで置き換えるべきである。 今のところ SOCK_DGRAM 経由でパケットについていた宛先アドレスを得る方法がない。
この文書について
この man ページは Linux man-pages プロジェクトのリリース 3.65 の一部 である。プロジェクトの説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。