Wireshark を使用した SMPP プロトコルの分析
この記事では、Adobe Campaign Classic用の Wireshark を使用して SMPP プロトコルを分析する方法について説明します。
説明 description
環境
Adobe Campaign Classic（ACC）
問題／症状
Wireshark を使用して SMPP トラフィックを分析する方法を説明します。
ほとんどの高スループットの Short Message Service Center （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 の基本（パケットのキャプチャ、簡単なフィルターの定義、パケットの詳細の読み取り）に精通していることを前提としています。 簡単な概要は、次の場所で入手できます howtogeek - Wireshark を使用してパケットをキャプチャ、フィルタリング、Inspectする方法.
Wireshark で SMPP トラフィックをフィルタリングするには、次の 3 つの重要な機能があります。
-
SMS-C のポートで表示フィルターを使用します。例えば、SMS-C がポート 10000 を使用している場合、次のフィルターを使用します。
tcp.port == 10000 -
電話番号やテキストの内容でパケットを分離するには、次の設定で検索機能を使用します。
-
の使用 TCP ストリームに従う 作業中のストリームを分離するためのツールです。
ポップアップする赤／青のテキストウィンドウは、SMPP とは関係のないテキストプロトコルににのみ有用なので、閉じてください。
-
SMPPProtocol
このプロトコルは、TCP 上で動作し、完全なバイナリなので、ストリームのコンテンツを復号化するには、Wireshark （または 16 進エディター）のような特別なツールが必要です。
ストリームは、独立した PDU で構成されており、各 PDU は、コマンド、ステータス、シーケンス番号およびコマンドに基づくその他の情報を含むメッセージです。
ストリームプロトコルとしての TCP の性質上、TCP パケットには複数の PDU が含まれることがあり、PDU は 2 つ以上の TCP パケットにまたがることがあります。Wireshark は PDU を正しく再アセンブルするので、Wireshark ユーザーにとっては、ほとんど透過的です。
次に、MT を送信してから SR を受信する際に、ネットワークを通過する PDU の例を示します。
注：標準コマンドのリストは、SMPP 仕様 5.1.2.1 節（SMPP コマンドセット）に記載されています。
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 操作）で説明されています。
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 s 明確（多くの場合、 esm_class は単に 0）になります。
この 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 節に記載）は、この特定の MT に対して SR がリクエストされているかどうかを 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 バイトに制限されます（最上位ビットは単に廃棄されます）。
エンコードの問題が発生した場合は、次の点を確認してください。
- 最初に、どの文字がどのエンコーディングに属するのかを把握しておくようにします。GSM7 は、発音区別符号（アクセント）を部分的にサポートしていることで悪名高いです。フランス語の場合、é と è が GSM7 に含まれますが、ê、â、ï は含まれません。スペイン語に関しても、状況は良くありません。
- セディーユ付きの C（ç）は、GSM7 アルファベットでは大文字のみ存在しますが、一部の機種では小文字または「スマート」文字で表示されます。一般的なレコメンデーションは、これを完全に避けてセディーユを削除する（フランス語ではそれでも非常に読みやすい）か、UCS-2 に切り替えることです。
- SMS-C パートナーから明示的にリクエストされない限り、SMS で ASCII を使用しないでください。このエンコーディングは、8 ビット文字で、GSM7 よりカバー範囲が狭いので、容量を浪費します。
- Latin-1 は、常にサポートされているわけではありません。Latin-1 の使用を試みる前に、SMS-C パートナーに互換性を確認してください。
- 各国語シフトテーブルは、Adobe Campaign Classic コネクタではサポートされていません。代わりに UCS-2 を使用する必要があります。
- UCS-2 と UTF-16 は、多くの場合、携帯電話で混在します。これは、絵文字や UCS-2 には存在しない、めったに使われない文字を送信するユーザーにとっては問題です。
- GSM7 エンコーディングは、Wireshark ではサポートされていません。間違って特殊文字が表示されます。 GSM7 文字列が適切にエンコードされているかどうかを確認する必要がある場合は、16 進コードと GSM7 テーブルを比較する必要があります。
この data_coding フィールドは、使用されるエンコーディングを示します。 唯一の問題は、値 0 は、仕様ではデフォルト SMS-C エンコーディングを意味しますが、一般的には GSM7 を意味することです。SMS-C での確認 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 ビット文字のみが入る十分なスペースが残ります。
ウィキペディアには、ユーザーデータヘッダーおよび連結された SMS に関する優れた記事があります（英語）。
short_message に UDH が含まれているかどうかを把握するには、esm_class の 6 ビットと 7 ビットを確認します（仕様の 5.2.12 節を参照）。Wireshark は、インターフェイスの UDH を解析して、正確な情報を提供します。
上のスクリーンショットでは、メッセージフィールドのユーザーデータヘッダー（1）、UDH に含まれる情報（2）、およびパケットに属さないが Wireshark によって計算されたいくつかの追加情報（3）を確認できます。ショートメッセージ本文フィールドは、Wireshark によって再構築された完全なメッセージを含むので、特に興味深いものです。
SR を受信中
レシーバーがバインドされている場合、SMS-C はいつでも SR を送信できます。 SR は、ビット 2 ～ 5 の DELIVER_SM PDU を使用して送信されます esm_class を設定。
この 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:........
次に、上記の行の読み方の一般的なガイドラインを示します。
- ID は、で送信したものと同じです SUBMIT_SM_RESP 一致する MT の
- テキストフィールドの問題は、無視できます。このフィールドは、SMS が純粋な英数字の ASCII とは別のエンコーディングを使用して送信された場合、役に立たない、信頼できない、さらには完全に読めない可能性があるので、Campaign では無視されます。 これは正常な動作です。
- フィールド名では、大文字と小文字が区別されません（例えば、id: sub: Text：は、ID: SUB: text：を記述することもできます）。
- この dlvrd sms-C パートナーによってドキュメント化されていない限り、フィールドは通常、信頼性がありません。
- 日付は、どのタイムゾーンにも属す可能性があり、実質的に役に立たないか、またはリモートサーバーの時計がオフになっているので、単純に間違っている可能性があります。
- この 統計 フィールドには、付録 B で定義されている以外の値が含まれる場合があります。常識的な判断と SMSC パートナーのドキュメントを参照して、その意味を理解します。
- この err フィールドは、完全に SMS-C に依存し、ほとんどの場合、SMS-C パートナーによってドキュメント化されます。 多くの場合、コード 000 は成功を意味し、それ以外のコードはエラーを示します。このフィールドは、多くの場合、数値ですが、16 進数であることもあります。
同じ MT に対する複数の SR
一部の SMS-C は、同じ MT に対して複数の SR を送信し、ネットワークでの MT の進行を追跡します。 大抵の場合、クライアントは、いつメッセージを受け取ったかのみを把握したい（これは、通常、最後の SR）ので、これは、ほとんど役に立ちません。
疑わしい場合は、SMS-C から受信した最新の SR のみを処理してメッセージの状態を確認します。
SMPP ウィンドウ
操作と応答は非同期なので、応答を待機する前に複数の操作 PDU を送信することで、転送レートを最適化できます。 返信がないメッセージの数は、ウィンドウと呼ばれます。
最大ウィンドウが 4 の送信の例：
現在の実装では、ウィンドウを制御せず、MT を処理するのに十分な速度をリモート SMS-C が持っていることが期待されています。