Wireshark を使用した SMPP プロトコル分析

この記事では、Adobe Campaign Classic用 Wireshark を使用した SMPP プロトコル分析の実行方法を示します。

説明 description

環境

Adobe Campaign Classic(ACC)

問題／症状

Wireshark を使用して SMPP トラフィックを分析する方法を説明します。

ほとんどの高スループットのショートメッセージサービスセンター (SMS-C) は、SMPP プロトコルバージョン 3.4 と互換性があります。このプロトコルを使用すると、SMS の送信と SMS の配信に関する情報の受信が可能になります。 SMPP プロトコルは、SMPP プロトコル仕様 v3.4 に記載されており、インターネット上で PDF 文書として入手できます。

この記事は、この仕様の代わりになるものではありません。Adobe Campaignと SMS-C パートナー間の問題のトラブルシューティングに役立つように、プロトコル仕様を解釈し、Wireshark 表示と照合する方法に関する実用的なヒントを提供します。

SMPP プロトコルには実装チームの解釈に残された多くの部分が含まれているので、SMS-C には違いがあります。

トラブルシューティングの際には、常に SMS-C パートナーに問い合わせて、情報を得たり、得られた情報を再確認したりするようにしてください。SMS-C からエラーが返ってきた場合、そのようなエラーが返ってきた理由を伝えることができるのは、SMS-C パートナーです。実際の SMS-C に接続するのではなく、SMPP シミュレーターを使用している場合は、ソースコード（またはデバッガー）を使用して何が起こっているのかを把握する必要があります。

解決策 resolution

Wireshark を使用しないネットワークトラフィックのキャプチャ

マシンに直接アクセスできない場合は、tcpdump のようなコマンドラインツールを使用してキャプチャする必要がある場合があります。 接続の TCP ポートが既にわかっている場合は、すべてのトラフィックをキャプチャしないように、正しいフィルターを設定します。次に、ポート12345をに取り込むための tcpdump コマンドラインの例を示します。  outfile.pcap:

tcpdump -i any -w outfile.pcap tcp port 12345

ファイル  outfile.pcap  その後、Wireshark で開いてさらに分析できます。

Wireshark の処理

このトピックでは、パケットのキャプチャ、単純なフィルターの定義、パケットの詳細の読み取りなど、Wireshark の基本に精通していることを前提としています。 以下に簡単な紹介を示します。 howtogeek - Wireshark を使用してパケットをキャプチャ、フィルタリング、およびInspectする方法.

Wireshark の SMPP トラフィックを除外するには、次の 3 つの重要な機能があります。

SMPP プロトコル

このプロトコルは TCP 経由で機能し、完全にバイナリです。つまり、ストリームの内容を復号化するには、Wireshark（または 16 進数エディター）などの特別なツールが必要です。

ストリームは、独立した PDU で構成されており、各 PDU は、コマンド、ステータス、シーケンス番号およびコマンドに基づくその他の情報を含むメッセージです。

ストリームプロトコルとしての TCP の性質上、TCP パケットには複数の PDU が含まれることがあり、PDU は 2 つ以上の TCP パケットにまたがることがあります。Wireshark は PDU を正しく再構成するので、Wireshark ユーザーに対してはほとんど透明です。

MT を送信し、SR を受け取ったときにネットワークを通過する PDU の例を次に示します。

注意：標準コマンドのリストは、SMPP 仕様（SMPP コマンドセット）の 5.1.2.1 節に記載されています。

SMPP 応答

SMPP プロトコルでは、すべてのコマンドが応答 PDU によって確認される必要があります。

BIND_TRANSMITTER は次の方法で確認されます：  BIND_TRANSMITTER_RESP,  SUBMIT_SM  は次の点で認識されます：  SUBMIT_SM_RESP ​など

応答にはタイムアウトがあり、通常は 10 秒、30 秒または 60 秒です。 応答に正の確認 (command _status = 0) が含まれる場合もあれば、エラー（5.1.3 を参照）が含まれる場合もあります。  command_status,  表 5-2  （標準エラーのリストの SMPP 仕様）。 ほとんどの場合、これらの応答は即時におこなわれ、応答タイムアウトには達しません。

SMPP 応答エラーと SR エラーコードを必ず区別してください。同じエラーコードでも、応答エラーと SR エラーフィールドでは、異なる意味を持つことがあります。エラーコードを報告する際は、値の意味がコンテキストに依存するので、エラーコードの見つけ方には細心の注意を払う必要があります。

SMPP 接続の初期化

SMPP 接続は、TCP を使用して接続することから開始します。 次に、BIND 操作がキャンペーンによって送信され、BIND RESP によって確認されます。 これらの操作については、SMPP 仕様の 4.1 節（BIND 操作）で説明します。

バインド操作は、ログイン/パスワードのチェックを行い、仕様に記載されているプラットフォーム名、バージョン、その他のフィールドに関する情報を交換します。

注意：ログイン情報は system_id フィールドにあります。

Campaign では、  BIND_TRANSMITTER  MT 転送を開始する際にパケットを送信し、  BIND_RECEIVER  次の場合にパケットを送信  nlsm s  トリガーと MO/SR 接続。

トランスミッター、レシーバーおよびトランシーバー： Campaign Classic 用 SMPP コネクタは、別のトランスミッター／レシーバーモードで動作します（MT の送信用と MO および SR の受信用の 2 つの TCP 接続があります）。TCP 接続は、レシーバーモードでも、Campaign によって常に開始されることに注意してください。

SMPP にはトランシーバーモードもありますが、Campaign Classic の SMPP コネクタには、このモードは実装されていません。

SMPP コネクタは、複数の接続を並行して使用して MT を送信します。コネクタの設計方法が原因で、これを制御できません。

MO の受信
受信機がバインドされると、SMS-C はいつでも MO を送信できます。 MO は、  DELIVER_SM  ビット 2～5 の PDU  esm_clas  クリア（多くの場合）  esm_class  は 0 だけです )。

The *DELIVER_SM* PDU は、 *DELIVER_SM_RESP* 同じ PDU *sequence_number*.

MT の送信
MT を送信するには、トランスミッターが正常にバインドされている必要があります。 何よりも先に、バインド処理が正常に実行されたことを確認してください。

MT は、  SUBMIT_SM  PDU。 SMS-C は、  SUBMIT_SM_RESP  PDU：この応答パケットは特別です。SMS-C のデータベースにメッセージの ID が含まれています（SMS-C パートナーとの通信時には、より迅速にメッセージを見つけられるように、この ID を必ず含めます）。 この ID は、SR に含まれ、MT を対応する SR と照合させる唯一の方法です。

フィールド  registered_delivery  （仕様のセクション 5.2.17 で説明）は、SR がこの特定の MT に対して要求されているかどうかを SMS-C に示します。 特定のメッセージの SR を受け取らない場合は、  SUBMIT_SM  PDU。

MT のエンコード

注意： SMS エンコーディングは、多くのトラップや様々な実装を伴う複雑な件名です。

エンコードの問題が発生した場合は、常に SMS-C パートナーに連絡することをお勧めします。 SMS パートナーは、サポートされるエンコーディングと、技術プラットフォームの制限により適用される可能性のある特別なルールに関する正確な知識を持っています。 何を送信し、何を返信したかを確認させます。 これは、正常で安定した相互接続への唯一のパスです。

SMS メッセージは、特殊な 7 ビットエンコーディングを使用します。通常、GSM7 エンコーディングと呼ばれます。Wikipedia GSM 03.38（英語）を参照してください。

SMPP プロトコルでは、トラブルシューティングを容易にするために、GSM7 のテキストが 1 文字あたり 8 ビットに拡張されます。SMS-C は、携帯電話に送信される前に、1 文字あたり 7 ビットにパックします。つまり、SMS の short_message フィールドの長さは SMPP フレームで最大 160 バイトになりますが、モバイルネットワークで送信される場合は 140 バイトに制限されます（最上位ビットは単に廃棄されます）。

エンコードの問題が発生した場合は、次の点を確認してください。

The  data_coding  フィールドは、使用されるエンコーディングを示します。 唯一の問題は、値 0 は、仕様ではデフォルト SMS-C エンコーディングを意味しますが、一般的には GSM7 を意味することです。SMS-C での確認  partner data_coding に関連付けられているエンコーディング= 0(Adobe Campaignは data_coding の GSM7 のみをサポートします )  = 0)。

メッセージの最大サイズは、エンコーディングによって異なります。次の表に、すべての関連情報をまとめます。

ユーザーデータヘッダー (UDH)
UDH（ユーザーデータヘッダー）は、SMS のテキストに追加される小さなバイナリヘッダーです。 これにより、SMS 連結、各国語シフトテーブル、ロゴ／画像（ほとんど使用されない）、WAP プッシュなどの特別な機能をトリガーできます。

UDH はテキストフィールド（short_message SMPP フィールド）の一部なので、SMS の有効サイズを短くすることができます。例えば、連結された SMS UDH は、SMS パートあたり 6 バイト（7 ビット文字ではなく、実際の 8 ビットの 6 バイト）を消費し、メッセージパートあたり 152 個の 7 ビット文字のみが入る十分なスペースが残ります。

Wikipedia には、ユーザーデータヘッダーと連結された SMS（英語）に関する優れた記事が用意されています。

short_message に UDH が含まれているかどうかを把握するには、esm_class の 6 ビットと 7 ビットを確認します（仕様の 5.2.12 節を参照）。Wireshark はインターフェイスで UDH を解析し、正確な情報を提供します。

上のスクリーンショットでは、メッセージフィールド (1)、UDH(2) に含まれる情報、およびパケットに属さない一部の追加情報 (3): Short Message body フィールドは、Wireshark によって再構成された完全なメッセージを含むので特に興味深い。

SR の受信
受信者がバインドされている場合、SMS-C はいつでも SR を送信できます。 SR は、のビット 2～5 で DELIVER_SM PDU を使用して送信されます  esm_class ​設定します。

The  DELIVER_SM  PDU は、  DELIVER_SM_RESP  同じ PDU  sequence_number. この SR に一致する MT を見つけるには、  SUBMIT_SM_RESP  を同じ ID に設定します。 例えば、SR に一致する MT は次のようになります。

SR は、  registered_delivery  フィールドが MT に設定されている。

注意： Adobe Campaign Classic SMPP コネクタは、  SUBMIT_SM_RESP  パケット。 仕様では、この動作を明示的に禁止してはいませんが、悪い動作と見なされます（メッセージが送信される前に受信されたことになります）。このケースが頻繁に発生する場合は、SMS-C パートナーにプラットフォームの修正を依頼してください。

SR の short_message フィールドの復号化
SR PDU のテキストフィールドには、SMPP プロトコル仕様の付録 B に記載されている特別なエンコーディングがあります。 残念ながら、ほとんどの SMS-C が多かれ少なかれこの形式を尊重しているにもかかわらず、この形式はプロトコルの一部ではなく、単なるレコメンデーションです。

SMS-C パートナーに直接独自の実装のドキュメントを求め、Wireshark に表示される内容と一致することを再度確認する必要があります。 大抵の場合、SMS-C の実装者が自分の実装を把握しておらず、これが問題や誤解につながっています。このフィールド（特にエラーコード）について疑問がある場合は、遠慮なく SMS-C パートナーにお問い合わせください。

基本的な形式を次に示します。

id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:EEE
Text:........

次に、上記の行の読み方の一般的なガイドラインを示します。

同じ MT に対する複数の SR
一部の SMS-C は、同じ MT に対して複数の SR を送信し、ネットワーク内の MT の進行を追跡します。 大抵の場合、クライアントは、いつメッセージを受け取ったかのみを把握したい（これは、通常、最後の SR）ので、これは、ほとんど役に立ちません。

不明な場合は、SMS-C から受け取った最新の SR に対してのみ作業して、メッセージの状態を見つけます。

SMPP ウィンドウ
操作と応答は非同期なので、応答を待つ前に複数の操作 PDU を送信することで、転送率を最適化できます。 返信がないメッセージの数は、ウィンドウと呼ばれます。

最大ウィンドウが 4 の送信の例：

現在の実装では、ウィンドウは制御されず、リモート SMS-C が MT を処理するのに十分な速度であることを期待しています。