こんにちは、KATA_KANと申します。
2年前、以下のリンク先でRX72M RSKを使用したM3S-T4-Tinyでのping疎通について問い合わせさせて頂いておりました。https://community-ja.renesas.com/cafe_rene/forums-groups/beginners/f/002-2095199602/7950/rx72m-rsk-tcp-ip-m3s-t4-tiny-ping
今回もM3S-T4-Tinyに関する質問となります。
現在、RX72M 176pin（R5F572MNDDFC） を使用したオリジナルボードの開発をしており、RSKで試した情報を流用しつつ、M3S-T4-Tinyを使用したEtherポートへのping導通や、DHCPでのIPアドレス自動割り当て等の動作確認をしています。その作業の中で、起動済みのDHCPサーバからのIPアドレスの取得は上手くいくのですが、DHCPサーバをオリジナルボードより後から起動した場合、DHCPによるIPアドレス取得が動作しないことがわかりました。
オリジナルボードのEtherモジュールからパケットキャプチャをして、DHCP Discoverをどのように送っているか確認したところ、最初のDHCP Discoverの後、4秒、4秒、8秒、16秒後にそれぞれ再送した後は、DHCP Discoverを再送していないようでした。
恐らく、M3S-T4-TinyのDHCPクライアントの動作仕様として、APIのlan_open()等を呼んだ直後にだけDHCP DISCOVERを送信し、DHCPサーバからの応答が必要回数タイムアウトした場合、以降何もしない、という動作となっていると推測しているのですが、実際の動作はどのようになっていますでしょうか？また、DHCPサーバが起動し、IPアドレスが割り当てるまでクライアント側からDHCP DISCOVERを繰り返し送るようなロジックとしたい場合、どのように修正すればよいでしょうか？
現在使用しているM3S-T4-TinyのバージョンはV2.10です。
よろしくお願いいたします。
大変申し訳ございません。Content Under Reviewとなった同様の投稿が連続でされてしまっているようです。ひとつを残し、他を削除したいのですが、どうすればよいでしょうか？
TAKA_KANさん、フォーラム管理人です。
投稿された内容がUnder Reviewになってしまい、申し訳ありません。同じ内容が複数回投稿されていましたので、他の投稿は削除させて頂きました。
なお、書込みされた内容に問題があったわけではなく、システムの自動判定でレビュー要と判断されたようです。ご迷惑をお掛けして、申し訳ありません。
以上、よろしくお願いします。
KATA_KANさん
シェルティです、こんにちは。T4の設計担当者です。
回答が遅くなりました。すみません。
>>実際の動作はどのようになっていますでしょうか？
DHCPが失敗するとAPIPA(Automatic Private IP Addressing)というIPアドレスを用いてTCP/IPを起動します。往々にしてこの状態ですと通信は出来ないです。
T4のソースコードは以下から入手可能です。
https://github.com/renesas/rx-driver-package/blob/master/source/r_t4_rx/r_t4_rx_vx.xx/r_t4_rx/make_lib/make_lib.zip
dhcp.cが実装体です。イベント(要因)×現在の状態=次の状態、となるような状態遷移モデルで実装しています。
>>また、DHCPサーバが起動し、IPアドレスが割り当てるまでクライアント側からDHCP DISCOVERを繰り返し送るようなロジックとしたい場合、どのように修正すればよいでしょうか？
tcpudp_close()でいったんTCP/IP自体をクローズし、tcpudp_open()を実行しなおすことでDHCP処理が再開されます。
以上です
シェルティさん
回答ありがとうございます。
>DHCPが失敗するとAPIPA(Automatic Private IP Addressing)というIPアドレスを用いてTCP/IPを起動します。>往々にしてこの状態ですと通信は出来ないです。これは、DHCPクライアントのDHCP Discover発行がタイムアウトした場合、仮のIPアドレス(ソースコード(dhcp.c dhcp_apipa())を見ると、169.254.1.1～169.254.254.255？)の範囲で設定されてTCP/IPが起動するという理解でよいでしょうか？
>tcpudp_close()でいったんTCP/IP自体をクローズし、>tcpudp_open()を実行しなおすことでDHCP処理が再開されます。このTCP/IPの再オープン処理を行う場合、DHCPサーバからIPアドレスの払い出しを受けているかどうかをM3S-T4-Tiny外で判定する必要があると思うのですが、どのように行うのが適切でしょうか？思いついたのは、T4_CFG_SYSTEM_CALLBACK_FUNCTION_NAME_TMPで指定するコールバック関数(T4サンプルプログラムだとsystem_callback)内で、DHCP_EV_LEASE_IPのイベントが来た際にフラグを立てるようにしておき、tcpudp_open()をした後、一定時間後(40秒後？)にそのフラグをチェックし、フラグが立っていなければ、tcpudp_close()→tcpudp_open()を行うのを繰り返す。というロジックなのですが、これでいけるかどうか試してみようと思います。
こんにちは、シェルティです。
返信が遅くなりました。下記回答します。
KATA_KAN said:これは、DHCPクライアントのDHCP Discover発行がタイムアウトした場合、仮のIPアドレス(ソースコード(dhcp.c dhcp_apipa())を見ると、169.254.1.1～169.254.254.255？)の範囲で設定されてTCP/IPが起動するという理解でよいでしょうか？
はい、ご認識の通りです。
KATA_KAN said:>tcpudp_close()でいったんTCP/IP自体をクローズし、>tcpudp_open()を実行しなおすことでDHCP処理が再開されます。このTCP/IPの再オープン処理を行う場合、DHCPサーバからIPアドレスの払い出しを受けているかどうかをM3S-T4-Tiny外で判定する必要があると思うのですが、どのように行うのが適切でしょうか？
T4からのsystem_callback()でイベント通知を確認する方法が適切です。
KATA_KAN said:思いついたのは、T4_CFG_SYSTEM_CALLBACK_FUNCTION_NAME_TMPで指定するコールバック関数(T4サンプルプログラムだとsystem_callback)内で、DHCP_EV_LEASE_IPのイベントが来た際にフラグを立てるようにしておき、tcpudp_open()をした後、一定時間後(40秒後？)にそのフラグをチェックし、フラグが立っていなければ、tcpudp_close()→tcpudp_open()を行うのを繰り返す。というロジックなのですが、これでいけるかどうか試してみようと思います。
はい、この方法が適切です。種々ご検討ありがとうございます。
返信が遅くなり申し訳ございません。（かふぇルネからのメールによる更新連絡が届いていないようでした）
KATA_KAN said: これは、DHCPクライアントのDHCP Discover発行がタイムアウトした場合、仮のIPアドレス(ソースコード(dhcp.c dhcp_apipa())を見ると、169.254.1.1～169.254.254.255？)の範囲で設定されてTCP/IPが起動するという理解でよいでしょうか？