martin-ger/esp_wifi_repeaterフル機能のWiFi NATルーター（そして現在はWiFiリピーターでもある）
フル機能のWiFi NATルーター（そして今ではWiFiリピーター、別名L2ブリッジでもあります）
NEW 2026: 初回リリースから10年を経て、それはついに、ずっとそうであろうとしていたものになりました：真のWiFiリピーター。既存のドキュメントやリンクを壊さないために、標準エディションは依然として、すべての高度な機能を備えた有名なNATルーターバージョンのままです。しかし、本格的なL2ブリッジの簡素化されたバージョンに興味があるなら、以下のセクション ESP8266 WiFi Repeater - L2 bridge をご覧ください。
これは、esp8266 および esp8285 上での WiFi NAT ルーターの実装です。また、ACL を備えたパケットフィルタリングファイアウォール、ポートマッピング、トラフィックシェーピング、リモートモニタリング（またはパケットスニッフィング）用のフック、MQTT 管理インターフェース、簡単な GPIO 操作、および電力管理のサポートも含まれています。より広いエリアをカバーするためにメッシュ構成で複数のルーターをセットアップするための新しいモード「Automesh」も含まれています。
NAT 機能を Arduino プロジェクトに統合する方法をお探しなら - こちら をご覧ください。
EPS32 NAT Router は ESP32 向けの高度なプロジェクトです。
典型的な使用シナリオは次のとおりです。
デフォルトでは、ESP は STA およびソフトAPとして動作し、あらゆる IP トラフィックを透過的に転送します。NAT を使用しているため、ネットワーク側にも接続ステーション側にもルーティングエントリは必要ありません。ステーションはデフォルトで DHCP により 192.168.4.0/24 ネットワーク内で設定され、既存の WiFi ネットワークから DNS レスポンダアドレスを受け取ります。
測定結果によると、双方向で約 5 Mbps を達成できるため、ストリーミングも可能です。
いくつかの詳細はこの ビデオ で説明されています。
デバイスへの直接フラッシュには Web-Installer を使用してください。
esp_wifi_repeater は次のデフォルト設定で起動します。
初回起動（またはファクトリーリセット）後、ESP はオープンAPと ssid "MyAP" を持つ WiFi ネットワークを提供します。有効な ssid やパスワードを知らないため、まだアップリンクAPへの自動再接続は試みません。
この WiFi ネットワークに接続し、シンプルな Web インターフェースまたはコンソール経由の全オプションを含む完全な設定のいずれかで基本設定を行ってください。
Web インターフェースでは、基本的な転送機能に必要なすべてのパラメータを設定できます。この主要な作業については rubfi に感謝します: https://github.com/rubfi/esp_wifi_repeater/ 。ブラウザで "http://192.168.4.1" を開いてください。次のページが表示されます。
まず、アップリンク WiFi ネットワークの適切な値、つまり "STA Settings" を入力します。オープンネットワークの場合はパスワード "none" を使用します。本当に automesh モードを使用したい場合にのみ "Automesh" ボックスにチェックを入れます。"Connect" をクリックします。ESP は再起動し、あなたの WiFi ルーターに接続します。数秒後、ステータス LED が点滅するはずです。
automesh を選択した場合、設定は完了です。"Soft AP Settings" の設定は必要ありません。automesh モードではこれらの設定は "STA Settings" と同じだからです。接続されたすべての ESP リピーターによって同じ ssid が提供されます。
automesh を使用しない場合は、ページを再読み込みして "Soft AP Settings" を変更できます。"Set" をクリックすると、再び ESP が再起動します。これで、新しく設定された Soft AP を介してトラフィックを転送する準備が整います。これらの変更は設定インターフェースにも影響することに注意してください。つまり、さらに設定を行うには、新しく設定された WiFi ネットワークのいずれかを介して ESP に接続してください。Soft AP 経由でアクセスする場合は、変更した場合に備えて Soft AP ネットワークのアドレスを覚えておいてください（ESP はこのネットワーク内では常にアドレス x.x.x.1 を持ちます）。
必要に応じて、"lock" チェックボックスをオンにして "Lock" をクリックできます。これで、アップリンク WiFi ネットワークのパスワードでロックを解除しない限り、設定を変更できなくなります（ネットワークがオープンでもパスワードを定義してください）。
Web インターフェースで非 ASCII 文字や特殊文字を入力する場合は、"My%20AccessPoint" のような HTTP スタイルの 16 進エンコーディングを使用する必要があります。これにより、文字列 "My AccessPoint" が生成されます。この 16 進エンコーディングを使用すると、0 を除く任意のバイト値を入力できます（C 内部の理由による）。
間違えて ESP との接続をすべて失った場合でも、シリアルコンソールを使用して回復できます（"reset factory"、以下を参照）。
高度な設定は、コンソールインターフェースのコマンドラインから行う必要があります。このコンソールは、115200 ボーのシリアルポートまたは tcp ポート 7777（例: 接続された STA からの "telnet 192.168.4.1 7777"）を介して利用できます。
初期設定には次のコマンドを使用します:
繰り返しますが、非 ASCII 文字や特殊文字を入力したい場合は、HTTP スタイルの 16 進エンコーディング（例: "My%20AccessPoint"）を使用するか、CLI のみのショートカットとしてバックスラッシュ付きの C スタイル引用符（例: "My\ AccessPoint"）を使用できます。どちらの方法でも文字列 "My AccessPoint" になります。
コマンドラインはさらに多くのコマンドを理解します:
ほぼすべての環境で動作させるのに十分です。
ほとんどの set コマンドは、save と reset の後にのみ有効になります。
コマンドライン入力の "単一の #" 以降、行末まではコメントとして扱われ、無視されます。
デフォルト設定では、GPIO2 がステータス LED（GND に接続）を駆動するように設定されており、次の表示が行われます:
"set status_led GPIOno" で GPIO ピンを変更できます（16 より大きい任意の値、例: "set status_led 255" でステータス LED を完全に無効化）。GPIO1 に設定すると、ESP-01 ボードの内蔵青 LED で動作します。ただし、GPIO1 は UART-TX ピンでもあるため、シリアルコンソールが機能しなくなります。その場合、設定はネットワークアクセスのみに制限されます。
選択した GPIO を 3 秒以上 Low にすると、リピーターはファクトリーリセットを実行し、デフォルト設定で再起動します。"set hw_reset GPIOno" で GPIO ピンを変更できます（16 より大きい任意の値、例: "set hw_reset 255" で HW ファクトリーリセット機能を無効化）。
ESP-01s や NodeMCU を含む多くのモジュールでは、GPIO 0 はすでに使用されているため、それを使用するのがおそらく良い考えです。ただし、フラッシュ中に Low に引っ張ることと干渉する可能性があるため、デフォルトのピンではありません。したがって、GPIO 0 の既存のプッシュボタンを HW ファクトリーリセットに使用したい場合は、フラッシュ後に "set hw_reset 0" と "save" で設定してください。HW ピンによってトリガーされたファクトリーリセットは、設定された hw_reset GPIO 番号をリセットしません（コンソールからの "reset factory" はリセットします）。
外部ネットワークのクライアントが内部ネットワークのサーバーポートに接続できるようにするには、ポートをマッピングする必要があります。外部ポートは、特定の内部 IP アドレスの内部ポートにマッピングされます。これには "portmap add" コマンドを使用します。ポートマッピングは "show" コマンドで一覧表示でき、現在の設定とともに保存されます。
ただし、期待するデバイスが特定の IP アドレスで待ち受けていることを確認するには、そのデバイスまたは ESP が再起動されたときに、そのデバイスが同じ IP アドレスを持つことを保証する必要があります。これを実現するには、デバイスに固定 IP アドレスを設定するか、ESP が DHCP リースを記憶する必要があります。これは "save dhcp" コマンドで実現できます。現在の状態とすべての DHCP リースを保存するため、再起動後に復元されます。DHCP リースは "show stats" コマンドで一覧表示できます。
WPA2 Enterprise (PEAP) サポートがプロジェクトに含まれました。これにより、PEAP 認証を使用する WPA2 Enterprise ネットワークを WPA2-PSK ネットワークに変換する「コンバーター」が可能になります。これは特に大学環境でよくある問題を解決します: ローカル WiFi ネットワークが PEAP-MSCHAPv2 認証を使用する WPA2 Enterprise ネットワークである場合です。非常に顕著な例は、世界中の多くの大学で利用可能な "eduroam" ネットワークです。問題は、多くの IoT デバイスが WPA2 Enterprise 認証を処理できないことです。そのため、開発やデモが困難です。非常に役立つのは、WPA2 Enterprise ネットワークにログインし、クライアントにより単純な WPA-PSK ネットワークを提供する「コンバーター」です。
使用するには、次の設定パラメータを設定してください: ssid、use_peap、peap_identity、peap_username、peap_password（通常の password パラメータは不要です）。この設定は CLI を介して行う（および保存する）必要があり、Web インターフェースでは利用できません。
現在のコードは RADIUS サーバーの証明書をチェックしません。誰かが不正な AP と RADIUS サーバーを設置した場合、MITM 攻撃に対して脆弱です。パスワードは平文で送信されませんが、使用される MSCHAPv2 は破られていることが知られています。また、ESP8266 には現在、あなたの Enterprise ネットワークパスワードが含まれていることに注意してください。ESP8266 によって転送されるすべてのトラフィックは、ネットワーク管理者によってあなたのアカウントに関連付けられる可能性があります。悪用したり、信頼できない他人に提供したりしないでください（例: オープンネットワークを設定すること）。また、デバイスがロックされていても、Enterprise ネットワークパスワードはシリアルポートを介して ESP のフラッシュから平文で抽出できます。
より長い距離や広いエリアをカバーするために、複数の esp_wifi_repeater を直列またはメッシュ構成で使用したい場合があるかもしれません。一般に、これは NAT ルーターで問題なく実行できます。実際には複数の NAT レイヤーが存在することになります。しかし、これは接続性が制限されることを意味します: すべてのノードはインターネットと通信できますが、一般にノード間の直接 IP 接続はありません。そしてもちろん、ホップ数が増えるほど利用可能な帯域幅は低下します。しかし、5 台の esp_wifi_repeater を直列にしても十分に動作するというユーザーレポートがあります。
このようなセットアップでは、設定は非常に時間がかかり、エラーが発生しやすい作業です。それを簡素化するために、esp_wifi_repeater に新しいモード「Automesh」が追加されました。SSID とパスワードを設定し、"automesh" をオンにするだけです（CLI で "set automesh 1" を使用するか、Web インターフェースでチェックボックスを選択するだけです）。これにより、次のことが行われます:このように設定された各esp_wifi_repeaterは、接続先と同じSSID/パスワードを持つWiFiネットワークをAP上で自動的に提供します。クライアントは、元のネットワークとリピートされたネットワークの両方で同じWiFi設定を使用できます。"automesh"で設定された各esp_wifi_repeaterは、まず接続先として最適な他のAPを探します。それは、元のWiFiネットワークに最も近く、信号強度（RSSI）が最も良いAPです。
信号強度はスキャンで簡単に測定できますが、同じSSIDを持つAPが複数見える場合、どれが元のWiFiネットワークに最も近いのでしょうか？そのため、このプロトコルはやや汚いトリックを使用します："automesh"モードのesp_wifi_repeaterは、自身のBSSID（実際にはIEEE 802.11規格によればAPであるためこれは"ESSID"ですが、SDKはこれを"BSSID"と呼びます）、つまりAPインターフェースのMACアドレスを操作します。これは、毎秒約10回送信されるすべてのビーコンフレームに含まれます。この形式は、24:24:mm:rr:rr:rr です。"24:24"はリピーターの一意の識別子にすぎません（これが実際のAPのMACと衝突する可能性はわずかにありますが、本当に必要な場合はこのプレフィックスを変更できるため無視できます）。"mm"は"メッシュレベル"、つまり元のWiFiネットワークまでのホップ数を意味します。最後の3つの"rr:rr:rr"は、さまざまなESPを区別するための単なるランダムな数字です。元のAPは自身のBSSIDを維持します。つまり、"24:24"というプレフィックスがないものがルートとして認識され、メッシュレベル0と呼ばれます。
これで、各esp_wifi_repeaterは、どの他のesp_wifi_repeaterが元のWiFiネットワークに最も近いかを学習し、それに接続して、自身のBSSIDをそれに応じて選択できます。また、内部ネットワークのIPアドレスもメッシュレベルに合わせて調整されます：10.24.m.0。これにより、元のWiFi APをルートとし、複数のメッシュレベルでリピートノードを持つツリー（非常に特殊なメッシュ）が作成されます（実際には、リンク層のスパニングツリープロトコル（STP）や、ネットワーク層の距離ベクトルプロトコルを使用したルーティングと似た動作をします）。アップリンクのリンク損失が検出されるとすぐに、設定が再起動されます。これにより、ループを回避できます。（再）設定中は、BSSIDを含むビーコンも送信されないためです。
利便性のため、"automesh"設定後のesp_wifi_repeaterは、最初にアップリンクAPに接続できるかどうかを確認します。これが失敗した場合、正しいSSIDのAPが見つかったとしても、ユーザーがパスワードを間違えたと判断し、工場出荷時設定にリセットします。一度接続に成功した後は、設定が正しいと見なし、接続が失われたりリセットされたりした後も、接続できるまで試行し続けます（誤って設定されたAPによるDoS攻撃を回避するためです）。
範囲内に複数のESPがある場合、短い"悪い"パスと長い"良い"パス（リンク品質の点での良し悪し）の間にトレードオフが存在する可能性があります。パラメータ am_threshold は、どのような接続が悪いかを決定します：スキャンでのRSSIがこのしきい値未満の場合、その接続は悪く、1ホップ多いパスが優先されます。つまり、am_threshold が85で、スキャンで2つのautomeshノードが検出されたとします：レベル1でRSSI -88 dBのAと、レベル2でRSSI -60 dBのBです。この場合、Aへのリンクはあまりに悪い（-88 dB < -am_threshold）と見なされ、Bが優先されます。新しいノードは、Bを経由するアップリンクを持つレベル3ノードになります。am_threshold は正の値で指定されますが、負のdBを意味します。値が小さいほど良好です。
automeshネットワークのトポロジーをより詳しく知りたい場合は、すべてのノードをMQTTブローカーに接続し、"Topology"トピックをパブリッシュさせることを検討するとよいでしょう（下記参照）。ここで "/WiFi/+/system/Topology" を購読すると、メッシュ内の弱いリンクを検出し、完全なグラフを再構築するために必要な、すべてのノードとリンク情報（接続されたESPのRSSIを含む）を取得できます。TopologyInfoトピックには、次のJSON構造が含まれており、automeshネットワークの完全なグラフを再構築するために使用できます：``` { "nodeinfo" { "id":"ESP_07e37e", "ap_mac":"24:24:01:72:c7:f9", "sta_mac":"60:01:bc:07:e3:7e", "uplink_bssid":"00:1a:54:93:23:0a", "ap_ip":"10.24.1.1", "sta_ip":"192.168.178.33", "rssi":"-66", "mesh_level":"1", "no_stas":"2" }, "stas":[ {"mac":"5c:cf:45:11:7f:13","ip":"10.24.1.2"}, {"mac":"00:14:22:76:99:c5","ip":"10.24.1.3"} ] }
_am_scan_time_ と _am_sleep_time_ の2つのパラメータを使用することで、GPIO16をRSTに接続している場合、automeshモードで電源管理を実装できます。起動後、esp_wifi_repeater は _am_scan_time_ 秒間、利用可能なアップリンクAPをスキャンします。見つからない場合は _am_sleep_time_ 秒間ディープスリープし、再起動後に再試行します（デフォルトは0 = 両パラメータ無効）。
# モニタリング
コンソールからモニタサービスを開始できます（"monitor on [portno]"）。このサービスは内部ネットワークのトラフィックをpcap形式でTCPストリームにミラーリングします。例えば、外部ネットワークのコンピュータから "netcat [external_ip_of_the_repeater] [portno] | sudo wireshark -k -S -i -" を使用すると、内部ネットワークのトラフィックをリアルタイムで観測できます。例えば、内部クライアントがどのインターネットサイトと通信しているかを観測するために使用します。これによりESPとWiFiネットワークにかかる負荷が少なくとも2倍になることに注意してください。高負荷時には、モニタセッションで一部のパケットが途中で切れたり、ドロップされたりする可能性があります。注意: このポートを開いたままにすることは潜在的なセキュリティ問題です。ローカルネットワーク内の誰でも接続してトラフィックを観測できます。
# ファイアウォール
ESPルーターには基本的なファイアウォールが統合されています。ACL（アクセス制御リスト）をSoftAPインターフェースに適用できます。これは、ルーターを使用して他のIoTデバイスをインターネットに接続する場合、IoTセキュリティの要となります。例えば、サードパーティのIoTデバイスが "calling home" を行ったり、マルウェアボットとして悪用されたりするのを防ぎ、PC、タブレット、スマートフォンを含むホームネットワークをホームオートメーションデバイスから見えないように保護するために使用できます。
4つのACLリストは、"from_sta"、"to_sta"、"from_ap"、"to_ap" と名付けられており、両方のインターフェースの受信パケットと送信パケットを対象としています（"sta" は接続されたクライアントへのインターフェース、"ap" はアップリンクAPへのインターフェースを意味します）。ACLは "CISCO IOS スタイル" で定義されます。
次の例はゲストサブネットに役立ちます。インターネットへのアクセスを許可しますが、他のローカルアドレスへのアクセスは許可しません（xx.xx.xx.xx アドレスにはご自身のローカルネットワーク範囲を使用してください）。このルールセットは、送信ローカルブロードキャスト（DHCP用）とUDP 53（DNS）を許可し、上流ルーターのサブネット宛ての他のパケットはすべてブロックし、その他のパケットはすべてインターネットに通過させます:```
acl from_sta clear
acl from_sta IP any 255.255.255.255 allow
acl from_sta UDP any any any 53 allow
acl from_sta IP any xx.xx.xx.xx/24 deny
acl from_sta IP any any allow
次の例はより制限的で、ESPのAPでアクセスが非常に制限されたIoTサブネットを計画する場合に役立ちます。また、送信方向のローカルブロードキャスト（DHCP用）、UDP 53（DNS）、およびローカルブローカーへのTCP 1883（MQTT）を許可しますが、その他のパケットはすべてブロックされ、任意のインターネットアクセスも含まれます（必要に応じて4番目のステートメントを調整して、他のホストを有効にすることができます）：``` acl from_sta clear acl from_sta IP any 255.255.255.255 allow acl from_sta UDP any any any 53 allow acl from_sta TCP any any 192.168.0.0/16 1883 allow acl from_sta IP any any deny
"to_sta" 方向の ACL も定義できますが、通常は不要です。逆方向は NAT 変換によって、要求されていないトラフィックから十分に保護されているためです。
ACL は、各パケットに対して処理されるフィルタリングルールで構成されます。各ルールは、プロトコル（IP、TCP、または UDP）、送信元アドレス/ポート、宛先アドレス/ポート、およびアクション "allow" または "deny" で構成されます。プレーン IP の場合はポートはなく、アドレスのみが指定されます。IP ルールには TCP パケットと UDP パケットが含まれます。アドレスは "/" 表記のサブネットアドレスとして指定できます（例: 192.168.178.0/24）。また、"any" をワイルドカードとして使用でき、任意のアドレスまたはポート番号に一致します。ルールは "acl" コマンドで定義されます:
- acl [from_sta|to_sta|from_ap|to_ap] [TCP|UDP|IP] _src-ip_ [_src_port_] _desr-ip_ [_dest_port_] [allow|deny|allow_monitor|deny_monitor]
ルールは、リストに現れる順序で上から下へ処理されます。パケットに一致する最初のルールが適用され、そのパケットが許可（転送）されるか、拒否（ドロップ）されるかが決定されます。つまり、特殊なケースを先に、一般的なルールを最後に置きます。ACL にルールがある場合、どのルールにも一致しないすべてのパケットはデフォルトで拒否されます。したがって、上記の例の最後のルール "from_sta IP any any deny" は、そもそもデフォルトであるため、実際には必要ありません。ACL が空の場合、すべてのパケットが許可されます。
ACL ルールの定義も上から下への順序で行われます。新しいルールは常にリストの最後に追加されます。ACL を変更するには、まず完全にクリアして (acl from_sta clear) から再構築する必要があります。ACL は設定と共に保存されます。"show acl" を実行すると、各ルールのヒット数と、許可および拒否されたパケットの総数の統計とともに ACL が表示されます。
"set acl_debug 1" コマンドを使用すると、拒否されたすべてのパケットのサマリーがコンソールに出力されます。また、MQTT トピックでこのサマリーを公開することもできます。これはファイアウォール構成に使用でき、接続されたデバイスを機能させるために必要なルールを判断するのに役立ちます。また、予期しないトラフィックが発生した場合（そして拒否された場合）の手がかりにもなります。
より深い分析には、モニタリングサービスを使用できます（拒否されたパケットも、ドロップされる前にモニタに報告されます）。"monitor acl _port_" コマンドでモニタを開始すると、ACL をオンラインフィルタとして使用できます。"allow" の代わりに "allow_monitor"、および "deny" の代わりに "deny_monitor" として定義されたすべてのルールは、
通常どおり処理され、パケットの転送を許可しますが、パケットをモニタにも送信します。したがって、基本的にすべてのパケットを "allow" または "allow_monitor" するルールのリストも意味があります。キャプチャ時にどのパケットを記録するかを選択するために使用できるからです。例: リスト:```
acl from_sta clear
acl from_sta IP 192.168.0.0/16 any allow_monitor
acl from_sta IP any any allow
acl to_sta clear
acl to_sta IP any 192.168.0.0/16 allow_monitor
cl to_sta IP any any allow
すべてのパケットを許可し、またステーションから192.168.0.0/16（ローカル）サブネットへ、および192.168.0.0/16からステーションへ向かうすべてのパケットを監視用に選択します。もちろん、このようなフィルタはキャプチャ後に完全なモニタリングトレースに対しても適用できますが、何を探しているのかがすでにわかっている場合、これらのオンラインフィルタは監視オーバーヘッドを大幅に削減するのに役立ちます。また、"deny" の代わりに "deny_monitor" を使用するだけで、すべてのdenyファイアウォールルールをデバッグするためにも使用できます。
デフォルトでは、APインターフェースはNATされているため、APに接続されたノードはESPのSTAインターフェースを介して透過的に外部世界にアクセスできます。したがって、本格的なネットワークマニアでない限り、追加の操作は必要ありません。
さらにネットワーク設定に本当に興味がある方のために: このプロジェクトではESPのlwip IPv4スタックが拡張され、静的ルートをサポートしています。"show route" は、接続されたネットワークインターフェース（APおよびSTAインターフェース）へのリンクを含む、既知のすべてのルートをルーティングテーブルに表示します。これら2つのインターフェース間のルーティングは、追加設定なしで動作します。他のネットワークへの追加ルートは、Linuxボックスやルーターで知られている "route add network gateway" コマンドで設定できます。"save" コマンドは、ルーティングテーブルの現在の状態をフラッシュ設定に書き込みます。
静的ルートで何ができるかの簡単な例を次に示します。中央のホームルーターを介してSTAインターフェースで接続された2つのESPというネットワーク構成を考えます:``` | 10.0.1.1 AP-ESP1-STA 192.168.1.10 | <-> |Home Router| <-> | 192.168.1.20 STA-ESP2-AP 10.0.2.1|
各ESPは、そのAPの背後に、異なるネットワークアドレス（10.0.1.0/24 と 10.0.2.0/24）を持つ第2のネットワークを有しています。ESP1 は 192.168.1.20 の ESP2 に ping を送信できますが、10.0.2.1 には ping を送信できません。192.168.1.20 を介して到達できることを知らないためです。これは、2つの静的ルートを追加すると変わります。ESP1 では:```
route add 10.0.2.0/24 192.168.1.20
そしてESP2では:``` route add 10.0.1.0/24 192.168.1.10
これで、ESP1 上の "ping 10.0.2.1" は成功します。これは 192.168.1.20 に送信され、ESP2 によって応答されます。
次に、各ネットワークで追加のクライアントが接続します（アドレス 10.0.1.2 と 10.0.2.2）:```
| STA1 10.0.1.2 | <-> | 10.0.1.1 ESP1 192.168.1.10 | <-> |Home Router| <-> | 192.168.1.20 ESP2 10.0.2.1| <-> | STA2 10.0.2.2 |
Now even client STA1 with the local address 10.0.1.2 can ping to STA2 with 10.0.2.2 as it send its request first to its default router ESP1 and this knows, that all packets to a 10.0.2.0/24 address have to be forwarded to 192.168.1.20. There the ESP2 knows how to send it to STA2. Tthe same applies for the reply in the other direction.
これで、ローカルアドレス 10.0.1.2 のクライアント STA1 も、まずデフォルトルーターである ESP1 にリクエストを送信することで、10.0.2.2 の STA2 に ping を送信できます。ESP1 は、10.0.2.0/24 アドレスへのすべてのパケットを 192.168.1.20 に転送する必要があることを認識しています。そこで ESP2 が STA2 への送信方法を把握しています。逆方向の応答についても同様です。
これにより、各 ESP とその STA クライアントが（ポートマップを一切必要とせずに）互いに直接到達できる、ESP のマルチスター型トポロジーを構成できます。必要なルートの設定は多少面倒かもしれませんが、ネットワーキングの良い練習になります。次のステップは、RIP のような動的ルーティングプロトコルを ESP に移植することでしょう...
upstream_kbps と downstream_kbps を 0 以外の値に設定すると（デフォルトは 0）、ESP の AP の最大ビットレートを制限できます。この値は、接続されているすべてのクライアントのトラフィックに適用される制限です。定義されたビットレートを超えるパケットはドロップされます。トラフィックシェイパーは「トークンバケット」アルゴリズムを使用しており、バケットサイズは現在、1秒あたりのビットレートの4倍に設定されているため、それまでトラフィックがなかった場合にはバーストが許可されます。
バージョン 1.3 以降、ルーターには MQTT クライアントが組み込まれています（彼のライブラリ https://github.com/tuanpmt/esp_mqtt に対する Tuan PM に感謝します）。これにより、ルーター/リピーターを IoT に統合しやすくなります。ホームオートメーションシステムは、例えば、現在関連付けられているステーションの情報に基づいて判断を下したり、リピーターをオン/オフしたり（例えば、時間スケジュールに基づいて）、単に負荷を監視するために使用したりできます。ルーターは、ローカルの MQTT ブローカーまたはクラウド内の公開ブローカーのいずれかに接続できます。ただし、現在 TLS 暗号化には対応していません。
デフォルトでは、MQTT クライアントは無効になっています。設定パラメータ "mqtt_host" を "none" 以外のホスト名に設定することで有効にできます。MQTT を構成するには、次のパラメータを設定できます。
MQTT パラメータは "show mqtt" コマンドで表示できます。
ルーターは次のステータストピックを定期的に（mqtt_interval ごとに）公開できます。
さらに、リピーターはイベントベースで公開できます。
LWT およびステータスレポートとして、リピーターは次を公開します。
ルーターは次のトピックを使用して構成できます。
ルーターに例えば Vdd、その IP、およびコマンドライン出力のみを公開させたい場合は、mqtt_mask を 0x0001 | 0x0002 | 0x0040（= "set mqtt_mask 0043"）に設定します。
esp_wifi_repeater は、SPI 経由で接続された ENC28J60 イーサネット NIC のサポートを追加しました（これを正しく動作させるための素晴らしい仕事をしてくれた Andrew Kroll https://github.com/xxxajk に感謝します）。これは、"user_config.h" で HAVE_ENC28J60 コンパイルオプションを有効にした場合です。イーサネットインターフェースは、ESP が 160 MHz で動作している場合、約 1 Mbps をサポートします。AP インターフェースを有効にしてイーサネットをアップリンクとして使用すると、esp_wifi_repeater は WiFi デバイス（例: 他の ESP）向けの安価な AP になります。
SPI 経由の接続は次のようになります。``` NodeMCU/Wemos ESP8266 ENC28J60
D6 GPIO12 <---> MISO
D7 GPIO13 <---> MOSI
D5 GPIO14 <---> SCLK
D8 GPIO15 <---> CS
D1 GPIO5 <---> INT
D2 GPIO4 <---> RESET
Q3/V33 <---> 3.3V
GND <---> GND
短くてはんだ付けされた配線が最適です。さらに、GPIO15をデカップリングするためのトランジスタが必要です。そうしないとESPが起動しなくなります。参照: https://esp8266hints.wordpress.com/category/ethernet/ 。また、良質な電源が重要です: ENC28j60は動作時に約160mAを必要とします。ESPボードの3.3Vを使用しようとすると、私の環境では失敗します。
これで新しいイーサネットインターフェースを設定できます:
- set eth_enable [0|1]: SPIバス上のENC28J60イーサネットNICを有効/無効にします (デフォルト: 0 - 無効)
- set eth_ip _ip-addr_: ETHインターフェースに静的IPアドレスを設定します
- set eth_netmask _netmask_: ETHインターフェースに静的ネットマスクを設定します
- set eth_gw _gw-addr_: ETHインターフェースに静的ゲートウェイアドレスを設定します
- set eth_dhcpd [0|1]: ETHインターフェース上で動的IPアドレス用のDHCPサーバーを起動します (デフォルト: 0 - 無効)
# 電源管理
リピーターは現在の供給電圧を監視します("show stats"コマンドで表示されます)。これは、esp_init_data_default.binの107番目のバイト(vdd33_constという名前)が255(0xFF)に設定されている場合にのみ機能します。これを実現する最も簡単な方法は、esp_init_data_default_v08_vdd33.binをフラッシュに書き込むことです(下記参照)。
_vmin_ (mV単位、デフォルト0)が0より大きい値に設定され、供給電圧がこの値を下回ると、_vmin_sleep_ 秒間ディープスリープモードに入ります。GPIO16をRSTに接続している場合(ESP-01でははんだ付けが困難です)、この間隔の後に再起動し、再接続を試みて、測定を継続します。_vmin_ が設定とともに保存されている場合、供給電圧がしきい値を上回るまで、繰り返しスリープします。これらの設定は、過放電保護なしの(リチウム)バッテリーでESPに電源を供給している場合に特に(唯一?)役立ちます。その場合、2900mV-3000mVの値がおそらく有用で、ESPの消費電力を最小限に抑え、損傷する前にバッテリーを再充電または交換する時間を大幅に確保できます。これは、ESPをバッテリーに直接接続している場合にのみ意味があります。追加のロジックがある場合、それでもバッテリーは消耗します。
"sleep"コマンドを使用して、ESPを手動で一度スリープさせることができます。
注意: 最大供給電圧より高い _vmin_ 値をフラッシュに保存すると、リピーターは再起動のたびに即座にシャットダウンします。その場合は、blank.bin(または他の任意のファイル)を0x0c000にフラッシュして、設定全体を消去する必要があります。
# WiFiリピーター - L2ブリッジ
このプロジェクトは現在、**NATルーター**と**レイヤー2ブリッジ**("リピーターモード"と呼ばれる)という2つの異なる動作モードを提供しています。両方のモードがネットワークカバレッジを拡張しますが、トラフィックとデバイスIDの処理方法が根本的に異なります。
### NATルーターモード(標準)
このモードでは、上記で説明したように、デバイスは標準ゲートウェイとして動作します。新しいサブネットを作成し、そのアクセスポイント(AP)に接続されたすべてのデバイスに対してネットワークアドレス変換(NAT)を実行します。
* **サブネットの分離**: 接続されたクライアントはプライベートサブネット(例: 192.168.4.x)上にあり、プライマリネットワークから隔離されます。
* **トラフィックの識別情報**: クライアントからのすべてのトラフィックは、ESP8266自身のIP/MACアドレスから発信されているようにメインルーターに認識されます。
* **シンプルさ**: 上流ルーターに特別な設定は不要で、事実上すべての標準Wi-Fiネットワークと互換性があります。
* **制限事項**: NATバリアのため、ポートマッピングを使用しない限り、プライマリネットワーク上のデバイスはリピーターの背後にあるデバイスへの接続を簡単に開始できません。
### レイヤー2ブリッジモード("リピーター"バリアント)
このモードは、透過的なレイヤー2(データリンク層)ブリッジを実装します。ESP8266は、セカンダリサブネットを作成するのではなく、既存のプライマリネットワークを拡張します。
* **透過的ブリッジング**: ESP8266はイーサネットフレームレベルでトラフィックをブリッジします。接続されたクライアントは、プライマリネットワークのDHCPサーバーから直接IPアドレスを受け取ります(DHCPスヌーピング/リレー経由)。
* **統一ネットワーク**: すべてのデバイス(リピーターとメインルーターの両方)は、同じL2ブロードキャストドメイン上に存在します。
* **デバイスの可視性**: リピーターの背後にあるデバイスは、メインネットワーク上で元のMACおよびIP識別情報を保持します。これにより、ローカル検出プロトコル(mDNS/Bonjour、UPnP、ネットワーク探索など)がネットワーク全体でシームレスに機能します。
* **複雑さ**: 上流ネットワークがリピーター経由で接続された「隠れた」クライアントにトラフィックを正しくルーティングし返すように、プロキシARPやDHCPスヌーピングなどの高度な処理が必要です。
* **ユースケース**: ネットワーク全体でのデバイス検出(例: スマホアプリを介したプリンターやスマートホームデバイスの制御)が必要な場合に最適です。
リピーターモードには機能が少なくなっています: ルーティング、ポートマッピング、DHCPは不要で、ACLとAutomeshもあまり意味がなく、pcapによるネットワーク監視も同様です。したがって、これらの機能はすべてリピーターモードでは利用できません。MQTTも削除されています。残りの機能は、コンソールまたはリモートコンソールから引き続き利用できます。
プリコンパイル済みバイナリは "firmware-repeater" フォルダにあります。
リピーターモード版の初回設定は、基本的にNATルーターと同じくらい簡単です。シリアルコンソールからssid、password、ap_ssid、ap_passwordを設定し、保存してリセットするだけです。Webインターフェース経由で行いたい場合も簡単ですが、正しい順序に従う必要があります:
- クライアントで"MyAP" WiFiに接続します
- ブラウザで "http://192.168.4.1" を開きます
- **最初に** AP設定のssidとパスワードを入力し、設定して再起動します
- その後、新しく定義したAPのssidに接続し、ブラウザで再度 "http://192.168.4.1" を開きます
- 次にSTA設定のssidとパスワードを入力して接続します
STAのssidが定義されると、リピーターは独自のDHCPサーバーを実行しなくなり、上流のDHCPからIPアドレスを受け取ります(192.168.4.1ではなくなります)。Webページまたはリモートコンソールに接続するには、クライアントがmDNSをサポートしている場合は "esp-wifi-repeater.local" という名前を使用するか、上流ルーターで割り当てられたアドレスを調べる必要があります(またはシリアルコンソールで "show stats" を使用します)。ESPはコンソールと "reset factory" でいつでもリセットできます。
### 主な相違点のまとめ
| 機能 | NATルーター | レイヤー2ブリッジ |
| :--- | :--- | :--- |
| **ネットワークアーキテクチャ** | 新しい独立したサブネットを作成 | 既存のブロードキャストドメインを拡張 |
| **IPアドレス割り当て** | クライアントはセカンダリプールを使用 | クライアントは上流のDHCPサーバーを使用 |
| **検出 (mDNS/UPnP)** | ブロックまたは困難なことが多い | 完全サポート (透過的) |
| **上流からの可視性** | クライアントIDが隠される (NAT) | クライアントIDが保持される |
| **実装** | 標準的なネットワーキング | 高度なプロキシ処理 (Proxy ARP/スヌーピング) |
# ビルドとフラッシュ
プリコンパイル済みバイナリをデバイスに直接フラッシュするには、[Web-Installer](https://martin-ger.github.io/esp_wifi_repeater/) を使用してください。
Dockerがインストールされている場合、完全なビルド環境にアクセスする最も簡単な方法は、ESP8266を /dev/ttyUSB0 に接続し、イメージを次のコマンドで実行することです:```
git clone https://github.com/martin-ger/esp_wifi_repeater.git
docker run -it --rm --device=/dev/ttyUSB0 -v $(pwd)/esp_wifi_repeater:/home/esp/esp_wifi_repeater martinfger/iot_devel:1.0
cd esp_wifi_repeater
make
make flash
L2 WiFi リピータ バージョンをビルドするには、make コマンドで VARIANT=bridge オプションを使用するだけです:``` git clone https://github.com/martin-ger/esp_wifi_repeater.git docker run -it --rm --device=/dev/ttyUSB0 -v $(pwd)/esp_wifi_repeater:/home/esp/esp_wifi_repeater martinfger/iot_devel:1.0 cd esp_wifi_repeater make VARIANT=bridge make flash
ビルド環境をゼロから構築し、このバイナリをビルドするには、esp-open-sdk をダウンロードしてインストールしてください（ベースの NONOS SDK 2.2 を同梱したこのバージョンを推奨します: https://github.com/xxxajk/esp-open-sdk）。同梱されている "blinky" サンプルをコンパイルして書き込めることを確認してください。
次に、このソースツリーを別のディレクトリにダウンロードし、Makefile 内の BUILD_AREA 変数と、user/user_config.h 内の任意のオプションを調整します。デフォルト構成の変更は user/config_flash.c で行えます。"make" で esp_wifi_repeater ファームウェアをビルドします。"make flash" で esp8266 に書き込みます。
ソースツリーには、liblwip_open のバイナリ版と、esp-open-lwip の私のフォークから必要な追加インクルード、および rboot ツールのバイナリが含まれています。*そのために追加のインストール作業は不要です。* プリコンパイル済みライブラリを使いたくない場合にのみ、https://github.com/martin-ger/esp-open-lwip からソースをチェックアウトしてください。それを使って esp-open-sdk ツリー内の "esp-open-lwip" ディレクトリを置き換えます。esp_open_lwip ディレクトリで "make clean" を実行し、その上の esp_open_sdk ディレクトリで再度 "make" を実行します。これにより、NAT 機能を含む liblwip_open.a がコンパイルされます。そのバイナリで liblwip_open_napt.a を置き換えてください。また、https://github.com/raburton/rboot から "rboot.bin" バイナリをビルドし、プロジェクトのルートディレクトリに置き換えても構いません。
*更新*: ウェブ上のインストール手順で "0x10000.bin" を使うと書かれているのを読んだ場合 - OTA のため、これは現在 "0x02000.bin" に変更されました。
完全なプリコンパイル済みファームウェアバイナリを使用したい場合は、"esptool.py --port /dev/ttyUSB0 write_flash -fs 4MB -ff 80m -fm dio 0x00000 firmware/0x00000.bin 0x02000 firmware/0x02000.bin" でフラッシュできます（ESP-01 の場合は -fs 1MB を使用）。esp8285 の場合は、-fs 1MB と -fm dout を使用する必要があります。
Windows では、https://espressif.com/en/support/download/other-tools で入手できる "ESP8266 Download Tool" を使用してフラッシュできます。ファームウェアディレクトリから 0x00000.bin と 0x02000.bin の 2 つのファイルをダウンロードします。一般的な ESP12、NodeMCU、Wemos D1 の場合、次の設定を使用します（ESP-01 の場合は FLASH SIZE を "8Mbit" に変更します）:
<img src="https://raw.githubusercontent.com/martin-ger/esp_wifi_repeater/master/FlashRepeaterWindows.jpg">
お使いのデバイスで "QIO" モードが失敗する場合は、代わりに "DIO" を試してください。また、"Detected Info" を確認して、フラッシュチップのサイズとモードを確認してください。ダウンロードしたファームウェアがまだ正しく起動しない場合は、同梱のチェックサムでバイナリファイルが破損していないか確認してください。ファームウェアバイナリの破損が疑われる場合は、リポジトリ全体を zip としてダウンロードし、その zip からバイナリを展開してください。これにより、HTTP ダウンロードの問題（CR-LF 変換など）を回避できます。
# OTA（Over the air）アップデート対応
rboot ライブラリを使用した実装に基づいています: https://github.com/raburton/rboot 。christianchristensen の貢献に感謝します。
ビルドプロセスでは、esp_wifi_repeater バイナリのコピーが 2 つ、ファームウェアディレクトリに作成されます: 0x02000.bin と 0x82000.bin です。初期インストールでは、0x00000.bin（rboot ブートローダ）と 0x02000.bin（プログラムの 1 コピー）をフラッシュするだけで問題ありません。esp_wifi_repeater は動作します。
少なくとも 1MB のフラッシュがあれば、別のバージョンで OTA（Over the air）アップデートを行うことができます。つまり、CLI から対話的に新しいバイナリをロードし、それに切り替えることができます。もう一方のバイナリは、現在非アクティブなメモリ位置（0x02000（rom0）または 0x82000（rom1）のどちらか）にロードされ、成功すると起動されます。インストール済みの 2 つのバイナリを対話的に切り替えることもできます。現在の設定は、フォーマットが変更されていない限り、両方のバイナリで使用されます。
OTA 機能は次のコマンドで制御できます:
- show ota: 現在アクティブなバイナリと次のアップデートの URL を表示します
- set ota_host _hostname_: OTA サーバーのホスト名または IP アドレスを設定します（デフォルト: "none"）
- set ota_port _portno_: OTA サーバーのポート番号を設定します（デフォルト: 80）
- ota update: ota_host:ota_port から HTTP 経由で新しいバイナリ（0x02000.bin または 0x82000.bin）のダウンロードを試行し、起動します
- ota switch: もう一方のバイナリに切り替えます（インストールされている場合）
OTA 機能をテストするには、ESP を（STA または AP として）アップデートサーバーと同じネットワークに接続するよう設定します。そこで、ファームウェアディレクトリ内で簡単な Web サーバーを起動します。例:```
cd firmware
python -m SimpleHTTPServer 8080
パラメータ hostname をコンピュータのホスト名またはIPアドレスに設定し、portno を8080に設定して、「保存」します。次にCLIで次のように入力してください:``` ota update
If configured correctly, the update will start and the ESP will reboot with the new binary.
正しく設定されていれば、アップデートが開始され、ESPは新しいバイナリで再起動します。
# Known Issues
# 既知の問題
- Due to the limitations of the ESP's SoftAP implementation, there is a maximum of 8 simultaniously connected stations.
- ESPのSoftAP実装の制限により、同時に接続できるステーションは最大8台です。
- The ESP8266 requires a good power supply as it produces current spikes of up to 170 mA during transmit (typical average consumption is around 70 mA when WiFi is on). Check the power supply first, if your ESP runs unstable and reboots from time to time. A large capacitor between Vdd and Gnd can help if you experience problems here.
- ESP8266は送信中に最大170 mAの電流スパイクを発生させるため、良質な電源が必要です（WiFiがオンのときの典型的な平均消費電流は約70 mAです）。ESPが不安定に動作したり、時々再起動する場合は、まず電源を確認してください。ここで問題が発生する場合は、VddとGndの間に大きなコンデンサを追加すると効果的です。
# Licenses
# ライセンス
The software is open source. Third party source files have their own license header. For all other files the MIT license applies.
本ソフトウェアはオープンソースです。サードパーティのソースファイルにはそれぞれ独自のライセンスヘッダーがあります。その他のファイルにはMITライセンスが適用されます。