ローカルマシン上のインターフェイスのリストを、それらのIPアドレス、MAC、および一連のQoS測定値(遅延、ジッター、エラーレート、損失率、帯域幅)とともに取得する必要があります...
ローカルネットワークデバイスからこれらの情報を読み取るためのカーネルモジュールを作成しています。これまで、ジッターと帯域幅の両方を除いて、上記のすべてのものを抽出しました...
Linuxカーネル2.6.35を使用しています
ローカルマシン上のインターフェイスのリストを、それらのIPアドレス、MAC、および一連のQoS測定値(遅延、ジッター、エラーレート、損失率、帯域幅)とともに取得する必要があります...
ローカルネットワークデバイスからこれらの情報を読み取るためのカーネルモジュールを作成しています。これまで、ジッターと帯域幅の両方を除いて、上記のすべてのものを抽出しました...
Linuxカーネル2.6.35を使用しています
帯域幅の意味によって異なります。ほとんどの場合、PHYからビットレートと呼ばれるものしか得られません。むしろ、上位層で利用可能な帯域幅に関する何らかの情報が必要だと思います。これは、ICMPエコーのようなプローブパケットの送信や応答の調査など、アクティブまたはパッシブな測定を行わないと取得できません。また、利用可能な帯域幅を測定するネットワーク内の2つのポイント(実際のエンドポイントと通信レイヤーの両方)を明確にする必要があります。
ジッタに関しては、基本的に上記と同じ方法で、何らかの測定を行う必要があります。
これは古い投稿であることは知っていますが、RTCPパケットが利用可能かどうかを調べることで、少なくともジッターを取得することができます。それらはRTPポートの+1で着信し、私が見た限りでは任意のRTPストリームと一緒に着信します。RTCPから多くの情報を取得できますが、目的のために、基本的なソースの説明だけで取得できます。
編集:(プレビューを見ていませんでした)
プロトコルの詳細については、このリンクを確認してください。ただし、RTCPパケットからジッターを簡単に取得できます。
RTPストリームを何に使用しているかにもよりますが、拡張レポートのVoIPメトリクスレポートブロック(https://www.rfc-editor.org/rfc/rfc3611#page-25 )など、他にも多くのリソースがあります。 )。
編集:
Artemのリクエストによると、ここにあなたがそれを行う方法の基本的な流れがあります:
RTPストリームはポート16400で開始されます(これを実現するために必要なドライバー/メカニズムはすでに存在している可能性があります)。
ポート16401(RTPストリームのポートの1つ上)でもリッスンを開始するようにカーネルに指示します。これは、RTCPパケットが入り始めるところです。
RTCP pktが入ってくると、それらを処理したい場所に送信します(つまり、ユーザースペースなどで解析したい場合)。
目的のデータのpktsを解析します。これを行うための特定のlibを認識していませんが、エンディアンに注意しながら、構造体(C)を指定して逆参照するのは非常に簡単です。