モデムトレースを利用したさくらのセキュアモバイルコネクトのLTE通信デバッグ方法（5）

送出ATコマンドの説明

まずトレースを見る前に、ここでは接続と試験に使用した各ATコマンドの詳細を説明します。

AT%HWVERSION

nRF9160DKボードに搭載されているnRF9160モジュールのハードウェアバージョンを念のために確認し、記録としてUARTログに残るようにします。

■コマンド詳細

AT+CGMR

nRF9160DKボードに搭載されているnRF9160モジュールのモデムファームウェアバージョンを念のために確認し、記録としてUARTログに残るようにします。

■コマンド詳細

AT+CFUN=0

モデムのRF回路やLTE機能一式を停止します。
今回わかりやすさのために使用しますが下記のATコマンドのドキュメントにある通り、NVMの寿命に影響しますので実用途でのモデムの利用の際は不必要な使用を避けた方がよいです。

■コマンド詳細

AT+CGDCONT=0,"IP","sakura"

LTE接続に使用するPDP_TypeとAPNを指定します。

■コマンド詳細
■マニュアル：SIMのデバイス接続と設定/APN（アクセスポイント名）

AT+CEREG=5

モデムに発生したイベントをできるだけUART上へ通知するよう設定します。
最も多くの情報が通知されるよう設定しています。

■コマンド詳細

AT%XSYSTEMMODE=1,0,0,0

モデムの持つLTE機能やGNSS機能の有効無効を設定します。ここでは、各キャリアでサービスしているLTE-Mのみ有効とします。

■コマンド詳細

AT+COPS=1,2,"44020

接続に利用するキャリアを、手動設定でPLMN番号を用いて設定します。ここでは、選択方法を手動、指定方法をPLMN番号、利用キャリアをSoftbank(44020)と設定しています。

■コマンド詳細
■マニュアル：さくらのセキュアモバイルコネクト特有の設定/使用するキャリアを明示的に指定する

AT+CFUN=1

モデムのRF回路とLTE機能一式を起動し、接続処理等を開始します。機能有効後のOK応答後も、自律的に接続処理等を継続します。そのため、OK応答時点では接続が完了しているとは限らず、別途ATコマンド等で状況を確認する必要があります。

本ドキュメントでは、接続処理完了を前提に、次のコマンドまで数十秒待っています。接続処理が成功すると、SIMのコントロールパネル上のログにステータスが追加されます。

■コマンド詳細
■マニュアル：その他の機能/ログ

AT+COPS?

現在接続に使用しているモバイルネットワークを表示します。

■コマンド詳細

AT+CGATT?

Packet Domain servicesへの接続状態を表示します。データ通信のためのセッションができているかの確認になります。

■コマンド詳細

AT%XCBAND

現在使用しているバンドを表示します。

■コマンド詳細

AT%XCBAND

現在の信号品質を表示します。
■コマンド詳細

AT%NBRGRSRP

付近の基地局からの受信電力値を表示します。
■コマンド詳細

AT#XPING="192.168.0.2",45,5000,5,1000

モデムからサーバに対して、ICMP pingパケットを送信しその応答を確認します。
■コマンド詳細

このデータ転送によって、SIMのコントロールパネル上のアクテビティモニタにトラフィックグラフが表示されます。集計間隔の都合上、反映までは数～十数分かかるのにご注意ください。
■マニュアル：その他の機能/アクティビティモニタ

AT+CGATT=0

Packet Domain servicesから切断をリクエストします。データ通信のためのセッションの削除を要求しています。
■コマンド詳細

切断処理が成功するとSIMのコントロールパネル上のログにステータスが追加されます。
■マニュアル：その他の機能/ログ

AT

ATコマンド応答の確認です。

モデムトレースデータ

前項で取得したnRF9160_modem_trace_test.pcapngを使った場合の説明をします。
nRF9160_modem_trace_test.pcapngをWiresharkで開きます。

列項目は「No,、Time、Protocol、Info」が表示されていれば、おおよその状況把握を行うことができると思います。また、表示ウインドウは「パケット一覧、パケット詳細」があるとよいです。
その他、好みに応じて必要な列項目を追加削除してご利用ください。

LTE接続時のログフレームについて

Wireshark上ではモデムに対する無線通信の送受やATコマンドの送受が個別に細かく各行にフレームとして表示されています。
多岐にわたる全データを全て解析することはできませんが、LTEを利用する機器の設計/運用において、状況把握に役立つ「ログのフレーム」についてコメントしていきます。

また下記情報を把握しておくと理解しやすくなります。
LTE接続時の処理では、モデムはさくらインターネット側の設備に直接アクセスするのではなく、SIM内の情報やユーザが設定した情報をキャリアの設備に伝え、キャリアの設備が代行してさくら側の設備に対し各種の手続きを行う形になります。
■参考：モバイルネットワーク通信の仕組み

そのため、モデムとキャリアの設備間の通信状況は、さくらインターネット側では把握することができません。ユーザー側の操作で、キャリアの設備との確実な通信確立が必要です。
このモデムとキャリアの設備間の状況を把握し、対策を講じるために、モデムトレースが有効です。ここでは、nRF9160のトレース取得機能で取得可能な範囲の情報について解説します。

実際には、これ以外にも本トレースデータに含まれない/本手法では取得できない多くのやり取りがモデムとモバイル網の間で行われていますが、多くの問題は取得可能範囲で対処できることと、今回の手法では取得できない情報であるため、一旦省略させていただきます。

ATコマンドでの情報取得と設定のモデムへの送出

No.1～15フレームでは、モデムの情報取得と設定を行うATコマンドがモデムに送られ、コマンドの応答やOKが受信されていることが確認できます。

注意点

ここに表示されるATコマンドは、nRF9160モデム内部で対応しているもののみです。SerialLTEModemアプリケーションが独自に持つATコマンドは表示されません。

独自ATコマンドを含む詳細なログを確認するには、別途取得したターミナルのUARTログと併せて確認することを推奨します。

以降に出てくるATコマンドについても同様です。
この範囲の各送出ATコマンドごとの詳細は「送出ATコマンドの詳細」と同様ですので省略します。

LTEへの接続

ATコマンドによる接続指示

モデムに対して、RF回路やLTE機能一式を起動し接続処理等の開始を指示しています。

モデムによる接続処理開始

モデムはRF機能をONにし、設定されたパラメータに基づいて接続可能なキャリア基地局を探索します。
基地局は、SystemInformationBlockType1と呼ばれる情報を定期的に報知しているので、モデムはしばらく受信状態を維持し、この情報の到着を待ちます。情報を受信後、モデムは接続可能な基地局と、その接続に必要な情報取得を試みます。

nRF9160_modem_trace_test.pcapngでは、運よく一発目のSystemInformationBlockType1で接続できるキャリア基地局を見つけておりますが、見つかりにくい場合は、下図のように他の基地局のSystemInformationBlockType1が並んだりします。

Attach requestの直前のSystemInformationBlockType1が最終的にモデムが選択した基地局になるイメージです。

詳細を確認したいフレームの行をダブルクリックすると詳細を確認できます。
SystemInformationBlockType1のフレームの詳細ビューでツリーを展開すると、基地局がSystemInformationBlockType1で報知している情報を確認できます。

非常に多くの情報が含まれるため、すべての確認は困難ですが、以下の点を確認することで、大体の場合は意図通りの接続ができているかどうかを確認することができます

• ATコマンドで設定したPLMN番号と一致しているか
• モデムで対応しているバンドや、利用設定しているバンドが一致しているか

接続要求の用意、RFでのキャリア基地局への接続と、モバイル網への接続要求

接続要求用意

モデムは基地局を決めると「attach request」というNASメッセージを用意します。実際には、このタイミングでは送信しておらず、後述の基地局とのコネクション確立後にInformation tranferに乗せて送信されます。

すべてのパラメータを紹介することはできませんが、リクエスト内で確認が必要になりやすい項目をいくつか選定して紹介します。
このリクエストでは、SIMの持つ情報のうち、IMSIがモバイルネットワーク設備に対して送信されています。

利用しているSIMのコントロールパネル上で確認できるIMSIが送られているのが確認できます。

このIMSIが意図したものではない場合、刺しているSIMが違うものである、などの状態になっている可能性があり確認が必要になります。
↑↓別パラメータの話なので切り離す。
またこのリクエスト内ではモデムからモバイルネットワーク設備に対して送信するESM Information(APN名など)が存在することを通知しています。
ESM Informationがない場合は、ATコマンドでAPN設定がうまくできていない可能性があります。
このフラグは必要な情報を取得するようにキャリア設備に対して知らせています。

RFでのキャリア基地局への接続と、AttachRequestの送信

上記のAttach Requestでの接続要求を開始するにあたり、まず先にモデムは基地局へのRFでの接続を確保します。モデムはRRCConnectionRequestを発行し基地局に対して接続の要求を行います。
要求を受け取った基地局は、モデムに対してどのような設定で接続を確立するかのRRCConnectionSetupを応答します。

RRCConnectionSetupにはRFでの接続のための基地局から指定されたパラメータが含まれており、これを受け取ったモデムはその指示に従いRFでの接続を確保します。

その後モデムは基地局に対してRRCConnectionSetupCompleteを返すとともに、NASメッセージとして先に用意されたAttach Requestを基地局を通してモバイルネットワーク設備(MNOのMME)に対し送信します。

フレーム27のRRCConnectionSetupCompleteの行の詳細を確認すると、Attach RequestがNASメッセージとして送られているのを見れます。

認証情報の要求と送信

続いて、基地局に接続してきたモデム＋SIMに対して、このモバイルネットワークに接続してよいかを判定するAuthenticationの処理が行われます。

フレーム28で、モバイルネットワーク設備(MNOのMME)から基地局を通してDLInformationTranferに乗せて、Authentication requestという接続のための認証情報の要求がモデムに対して送られます。
その下のフレーム29にはDLInformationTranferから取り出されたAuthentication requestが単体で表示されています。

詳細を確認すると、MMEがHSSから取得した認証に必要なランダム値や認証用データが送られてきているのが確認できます。

モデムは自動的に送られてきた情報と、SIMの機能を利用して演算を行い、MMEへの応答用の認証用データを生成します。

生成が終わると、モデムはAuthentication responseのNASメッセージを作成し、ULInformationTranferに乗せて基地局へ送信します。MME側で接続してよいかの判定が行われ、以降の処理が継続されます。

なお、再接続時の方式によっては、Authentication request自体が基地局側から来ない場合があります。この点については、別途解説予定です。

NASメッセージの送受の暗号化設定のコマンドとその応答

Information transferにのせるNASメッセージの暗号化方式を取り決めるやり取りが行われます。このやり取りにより、以降のNASメッセージは暗号化されます。この暗号化方式決定も、ユーザ側で変更できる設定はありませんので、パラメータを深く検討する必要はあまりありません。

以降、モデムと基地局のやり取りでは、しばらくはいくつかのNASメッセージをInformation transferに乗せて送受が行われます。同様の説明になりますのでInformation transfer部での実送受は省略し、NASメッセージでのみ説明を記載します。

キャリアモバイル設備からのデータ接続のためのパラメータ情報問い合わせとそれに対する応答

モバイル網側からモデムに対してデータ接続のための情報を送信するよう要求がESM　information requestとして送られてきます。それに対してESM information responseでAPN名などの情報をモデムは送信します。

ESM information responseの詳細を確認すると、ATコマンドで設定したAPN名が送られているのが確認できます。ここで送られているAPN名が間違っていると接続できませんので設定値のチェックポイントの一つになります。

無線区間の暗号化設定のコマンドとその応答

無線区間の暗号化方式を取り決めるやり取りが行われます。このやり取りにより、以降の無線区間通信は暗号化されます。この暗号化方式決定も、ユーザ側で変更できる設定はありません。そのため、パラメータを深く検討する必要はあまりありません。

キャリアモバイル設備からのUE機能の問い合わせとそれに対する応答

モデムがサポートしている機能のリストをモバイル設備が要求しています。モデムの持つ機能により自動で応答され、モバイルネットワーク設備側はその中から適切な機能を選択して利用します。こちらもユーザ側で変更できる設定はないため、パラメータを深く検討する必要はあまりないでしょう。

キャリアモバイル設備からの接続許可

モバイルネットワークからモデムに対して接続の許可がAttach acceptというメッセージで通知されます。このAttach acceptで接続が許可されデータ経路が用意されIP通信ができるようになります。

詳細を確認すると、端末に割り当てられたIPアドレスやDNSサーバー、MTUサイズ、接続に使用されたAPN,細かいネットワークのパラメータなどが確認できます。
IPアドレスやDNSサーバーは、セキュアモバイルコネクトのコントロールパネルのSIM設定/モバイルゲートウェイの設定で設定した値と一致していることを確認します。

細かいネットワークパラメータの一部は、ユーザ側でも変更可能なところがありますが、変更方法は後の連載記事に問題時の実例として別途の資料にて説明したいと思います。

接続許可への応答

モデムはモバイルネットワークからのattach acceptに対して、Attach Completeを応答します。

接続のATコマンド通知

AT+CEREGコマンドで設定したモデムに発生したイベント通知がモデムから送られてきているのが確認できます。

内容としてはstatが「Registered, roaming」という通知となり、端末がモバイル網に登録/接続され利用可能になった旨と

いくつかの接続パラメータが通知されています。この通知はUARTにも流れ、ATコマンドを利用するアプリケーションから確認できるようになっています。通知の詳細は下記を参照してください。

■コマンド詳細1
■コマンド詳細2

接続の追加情報の受信

MNO設備からモデムに対して、EMM informationという情報が追加で送られます。これには時刻情報など追加のオプションの情報が含まれています。オプションのため接続に利用したキャリアによって応答内容が異なることがあります。

ここまでで一通りの接続の処理が完了したことになり、以降IP通信が可能となります。

無線区間の一時切断

接続後、一定時間情報の送受がない場合、基地局より無線区間の接続のみ切断の指示が来て一旦無線接続を切断します。LTEとしての接続は維持されており、通信が必要となった際に無線区間の接続のみの回復処理で通信可能になる状態です。

ATコマンドでのステータス確認

接続指示のATコマンド以降では、主に現在のモデムの接続状態の取得を行っています。コマンドのモデムへの送信と結果のモデムからの受信が確認できます。コマンドごとの詳細は「送出ATコマンドの詳細」と同様ですので省略します。

PINGでの疎通確認

PINGのATコマンドによるIPパケットの送受そのものを確認することができます。
PINGのATコマンドそのものはSerialLTEModemのアプリケーションとして持っている独自ATコマンドのため、こちらのモデムのトレースデータには表示されていない点に注意してください。
別途取得したターミナルのUARTログのタイムスタンプと突き合わせての確認が確実です。

無線区間接続回復

現在LTEのattach完了後、しばらく通信が無かったためRFの接続が基地局から一旦切られています。
PINGのATコマンドを受け取ったモデムは、IPデータ送信のために、RF区間のコネクションの接続を基地局に対して要求します。Frame69～76でその様子が確認できます。

ping送信と応答の確認

RF区間のコネクションが確立されると、モデムからPINGのICMPパケットが送信されます。Frame77～86で、送信されたICMPパケットを確認できます。
送信したICMPパケットに対する応答が指定したサーバーから返ってきていることを確認します。SIMに設定したIPアドレスから、指定した対抗サーバのIPアドレスに対して通信しているのを確認してください。

この辺りは、通常のIP通信のパケットキャプチャと同様にデータを確認するできます。また、この通信は、対抗サーバー側のパケットダンプでも観測でき、ping応答が成り立っていない場合は、合わせて確認することで、どこまで通信が成り立ったのかを特定できます。

無線区間の一時切断

前回同様に、接続後一定時間情報の送受がないため、基地局より無線区間の接続のみ切断の指示が来て一旦無線接続を切断しています。
LTEとしての接続は維持されており、通信の必要が発生した際に無線区間の接続のみの回復処理で通信可能になる状態です。

LTEからの切断

ATコマンド送信

モデム側からの回線の切断を行うように、ATコマンドでモデムに対して指示されているのが確認できます。

無線区間の接続回復と切断要求の送信

ATコマンドを受け取ったモデムは、切断要求のDetach requestというメッセージを用意し、このメッセージを送る通信のために、RF区間のコネクションの接続を基地局に対して要求します。（基地局からRF区間のコネクションが一旦切られているため）

RF区間のコネクションに成功するとDetach requestをRRCConnectionSetupCompleteとともに送信します。

切断の完了

Detach requestを受け取ったモバイル網の設備からDetach acceptが届きます。

切断のATコマンド通知

AT+CEREGコマンドで設定したモデムに発生したイベント通知がモデムから送られてきているのが確認できます。
内容としてはstatが「Not registered」という通知となり、端末がモバイル網に登録/接続されていないことが通知されています。
この通知はUARTにも流れ、ATコマンドを利用するアプリケーションから確認できるようになっています。
通知の詳細は下記を参照してください。

■コマンド詳細1
■コマンド詳細2

以上で正常系のトレースデータの一通りの動作を確認できたことになります。

ATコマンドUARTログデータ

前項で取得したnRF9160_modem_trace_ATcommand.logでの場合を説明します。
まず、nRF9160_modem_trace_ATcommand.logをテキストエディタなどで開きます。
モデムに指示したATコマンドとその応答や、モデムからの通知が記録されています。

モデムトレース側の時間が多少ずれていることがあるため、適宜送ったコマンドとのタイミングを見つつ対応関係をとる必要があることがあります。
基本的にモデムトレース側にWireshak上で時刻調整をかければ大体合うことが多いですが、間にリセットが入るようなログの場合調整しきれないときがあるのでそのときは目視で対応確認します。

以下、主なところのコマンドのリターン値や通知についてコメントしていきます。
コマンドでの設定値については「送出ATコマンドの説明」を参照してください。
nRF9160_modem_trace_ATcommand.logをテキストエディタで開きます。

▼ボード情報取得

[2024-01-26 11:51:25.139] AT%HWVERSION
[2024-01-26 11:51:27.094]
[2024-01-26 11:51:27.094] %HWVERSION: nRF9160 SICA B1A
[2024-01-26 11:51:27.097]
[2024-01-26 11:51:27.098] OK
[2024-01-26 11:51:32.989] AT+CGMR
[2024-01-26 11:51:34.325]
[2024-01-26 11:51:34.325] mfw_nrf9160_1.3.5
[2024-01-26 11:51:34.331]
[2024-01-26 11:51:34.331] OK

nRF9160DKボードのHWやFWの情報を取得しています。
事前に取得しておくことで後のデータの見直しや比較の際に検証条件違いによる問題の切り分けの助けになるかと思います。
指定の情報とOKの文字列の応答が確認できます。

▼接続のための設定と、状態通知設定の適用

[2024-01-26 11:51:38.982] AT+CFUN=0
[2024-01-26 11:51:40.170]
[2024-01-26 11:51:40.174] OK
[2024-01-26 11:51:50.340] AT+CGDCONT=0,"IP","sakura"
[2024-01-26 11:51:51.399]
[2024-01-26 11:51:51.399] OK
[2024-01-26 11:51:56.187] AT+CEREG=5
[2024-01-26 11:51:56.874]
[2024-01-26 11:51:56.874] OK
[2024-01-26 11:52:02.106] AT%XSYSTEMMODE=1,0,0,0
[2024-01-26 11:52:02.799]
[2024-01-26 11:52:02.799] OK
[2024-01-26 11:52:07.121] AT+COPS=1,2,"44020"
[2024-01-26 11:52:08.121]
[2024-01-26 11:52:08.121] OK

すべてのコマンドにOKが返り正常に設定できていることが確認できます。

▼接続開始

[2024-01-26 11:52:12.764] AT+CFUN=1
[2024-01-26 11:52:14.023]
[2024-01-26 11:52:14.023] OK

モデムのRF回路やLTE機能一式を起動し、接続処理等を開始します。OKはコマンドを正常に受け取り処理開始ができたことを表しており、接続が完了したわけでない点に注意が必要です。

[2024-01-26 11:52:14.088]
[2024-01-26 11:52:14.092] +CEREG: 0
[2024-01-26 11:52:14.612]
[2024-01-26 11:52:14.612] +CEREG: 2,"1810","01835B02",7
[2024-01-26 11:52:15.951]
[2024-01-26 11:52:14.612] +CEREG: 5,"1810","01835B02",7,,,"11100000","11100000"

モデムが自動的に接続処理を行っています。
進捗に応じてAT+CEREGコマンドで設定した現在の状態のイベント通知が表示されています。

最後の「+CEREG: 5,"1810","01835B02",7,,,"11100000","11100000"」のところで接続が完了しています。この通知はAT+CEREGコマンドでの設定により行われており、モデムに発生したイベントが通知されています。

内容としてはstatが「Registered, roaming」という通知となり、端末がモバイル網に登録/接続され利用可能になった旨といくつかの接続パラメータが通知されています。

通知の詳細は下記を参照してください。
■コマンド詳細1
■コマンド詳細2

▼状態確認

接続が完了したので現在の状態を取得しています。
あらためて接続ができていることの確認と、その接続品質などの情報を問題があった際の参考情報となるよう押さえておきます。

[2024-01-26 11:53:36.922] AT+COPS?
[2024-01-26 11:53:37.796]
[2024-01-26 11:53:37.796] +COPS: 1,2,"44020",7
[2024-01-26 11:53:37.806]
[2024-01-26 11:53:37.806] OK

現在接続しているモバイルネットワークを確認しています。接続開始前にAT+COPSコマンドで指定した44020に手動選択で接続されているのが確認できます。
■コマンド詳細

[2024-01-26 11:53:44.093] AT+CGATT?
[2024-01-26 11:53:44.951]
[2024-01-26 11:53:44.951] +CGATT: 1
[2024-01-26 11:53:44.957]
[2024-01-26 11:53:44.957] OK

現在の接続状態を確認しています。Attachedの1を確認できます。
■コマンド詳細

[2024-01-26 11:53:49.343] AT%XCBAND
[2024-01-26 11:53:49.972]
[2024-01-26 11:53:49.975] %XCBAND: 1
[2024-01-26 11:53:49.975]
[2024-01-26 11:53:49.975] OK

現在の接続に使用している無線のバンドを確認しています。いまはバンド１での接続を行っていることが確認できます。
■コマンド詳細

[2024-01-26 11:53:54.234] AT+CESQ
[2024-01-26 11:53:55.010]
[2024-01-26 11:53:55.010] +CESQ: 99,99,255,255,14,44
[2024-01-26 11:53:55.014]
[2024-01-26 11:53:55.014] OK

現在の接続に使用している無線の信号品質を確認しています。応答値より受信品質と受信電力をdBm値で確認できます。
■コマンド詳細

[2024-01-26 11:54:00.133] AT%NBRGRSRP
[2024-01-26 11:54:00.851]
[2024-01-26 11:54:00.851] %NBRGRSRP: 174,475,49,325,475,49,113,475,37
[2024-01-26 11:54:00.858]
[2024-01-26 11:54:00.858] OK

隣接した基地局のIDと受信電力を確認しています。応答値より基地局のIDとその受信電力をdBm値で確認できます。
■コマンド詳細

▼PING送信テスト

実際にIP通信を行い、疎通を確認します。ここではpingを使って確認しています。

[2024-01-26 11:54:06.123] AT#XPING="192.168.0.2",45,5000,5,1000
[2024-01-26 11:54:07.259]
[2024-01-26 11:54:07.263] OK
[2024-01-26 11:54:07.500] #XPING: 0.236 seconds
[2024-01-26 11:54:08.644] #XPING: 0.145 seconds
[2024-01-26 11:54:09.827] #XPING: 0.173 seconds
[2024-01-26 11:54:11.014] #XPING: 0.172 seconds
[2024-01-26 11:54:12.135] #XPING: 0.120 seconds
[2024-01-26 11:54:13.139] #XPING: average 0.169 seconds

192.168.0.2のサーバーに対してpingを送信し、その応答が返ってきていることが確認できます。
■コマンド詳細

▼切断

接続を切る際には電源OFFなどでの強制断ではなく、コマンドを送って明示的に接続を切る処理を推奨しています。

[2024-01-26 11:54:31.891] AT+CGATT=0
[2024-01-26 11:54:33.590]
[2024-01-26 11:54:33.590] OK
[2024-01-26 11:54:33.590]
[2024-01-26 11:54:33.590] +CEREG: 0

切断の指示を送信し、その結果として切断されたことがCEREGで通知されています。
■コマンド詳細1
■コマンド詳細2

サーバパケットダンプデータ

前項で取得したmodem_trace_test.pcapには、サーバーのネットワークインターフェースのうち、プライベートインターフェイスのネットワークへ接続している方のネットワークインターフェースを流れる送受データが記録されています。

サーバー自体の動作状況はもちろん、ある程度のモバイルゲートウェイの状況も観察できます。
モバイルゲートウェイそのものの挙動をすべて見ることはできませんが、サーバーが宛先のものやブロードキャストのパケットは記録されているためある程度状況を把握することができます。

前項で取得したmodem_trace_test.pcapでの場合を説明します。
modem_trace_test.pcapをWiresharkで開きます。

モバイルゲートウェイによるARPのサーバーへの到着と応答

モデムからPINGにより送られたICMPパケット(172.16.0.1 → 192.168.0.2宛て)はモバイル網を通じてまずモバイルゲートウェイへ到着します。
モバイルゲートウェイは、192.168.0.1のプライベートインターフェイスが設定されているため、192.168.0.0/24宛てのパケットをプライベートインターフェイスのネットワークへ転送します。

プライベートインターフェイスのネットワークはL2のネットワークのため、パケット送出のためにサーバーのMACアドレスが必要になります。しかしこの段階ではモバイルゲートウェイはサーバー(IPアドレス 192.168.0.2)のMACアドレスを把握していないため、ARPにより192.168.0.2のMACアドレス特定を行っています。
その様子がFrame1,2となり、ARPの問い合わせのブロードキャストに対して、192.168.0.2のサーバーが応答を返しているのを確認できます。

応答の詳細を確認すると、モバイルゲートウェイのネットワークインターフェースのMACアドレスが9c:a3:ba:30:4a:5f、サーバーのネットワークインターフェースのMACアドレスが9c:a3:ba:30:0b:54であることが確認できます。

PINGの受信と応答

モバイルゲートウェイはARPでMACアドレスの把握が終わると、サーバーに対してモデムから受信したICMPパケットを転送します。
その様子がframe3になります。

詳細を確認すると、モデムから発信されたPINGのICMPパケットがモバイルゲートウェイのMACアドレスから送信されているのが確認できます。

サーバーはこのパケットに対してFrame4で応答を返します。このとき単純に返しているように見えますが、サーバー内では少し複雑な判断をして応答しています。
PINGのICMPはあくまでのIPレイヤでの通信ですので、IPヘッダ内の送信元であるモデムの172.16.0.1へ応答する必要があります。

サーバーは設定されたroute情報に従い、172.16.0.0/16宛ての通信は、固定で192.168.0.1への転送を行います。
このとき192.168.0.0/24のネットワークに接続している現在のネットワークインターフェースを利用して192.168.0.1への応答を行います。

また、この際に192.168.0.1のMACアドレスを知る必要がありますが、今回はARPを発行するまでもなくモバイルゲートウェイからのARPリクエストにより、サーバ側のARPキャッシュに192.168.0.1のMACアドレスが格納されているためこの情報を用いて192.168.0.1へ、モデムの172.16.0.1へ応答するICMPパケットが送信されます。そのため192.168.0.1についてのARPは存在していません。

そのときのICMPパケットパケットがframe4の詳細で確認できます。
モデムの172.16.0.1宛てのICMPパケットが、モバイルゲートウェイのMACアドレスへ送信されているのが確認できます。このパケットを受け取ったモバイルゲートウェイが実際にモデムの172.16.0.1宛てへの送信を担当します。
同様の処理がframe5～12も含め、合計5回行われているのが確認できます。基本的にここまででモデムとの通信は完了となります。

最後のARP

サーバーのLinux側でのARP情報のキャッシュの管理都合による自動問い合わせになります。LTE通信とは関係なくサーバー側で管理上必要なタイミングで発生したもので、LTE通信には直接影響しませんのであまり気にする必要はありません。

終わりに

以上で、正常に接続できたときのトレースやログの確認方法について、大まかな理解をいただけたかと思います。次回以降は、具体的なトラブル事例とトレースを用いて、より詳細な解説を進めていきます。