Raspberry Pi (Linux)

長らく実家にて運用しているVPNクライアントルーターについて、一部改善した。

Linux の NAT 環境では、デフォルト設定のままではマジックパケットなどの ブロードキャストパケットが転送されない。
そのため、VPN＋NAT を介した Wake on LAN（WoL）は通常そのままでは利用できない。

これは iptables の NAT 機能そのものというより、Linux の IPv4 スタックがブロードキャストパケットのフォワーディングを抑制している仕様によるものだ。

●bc_forwarding によるブロードキャスト転送の有効化

Linux では /proc/sys/net/ipv4/conf/ 配下に、ネットワークデバイスごとの IPv4 動作を制御するパラメータが用意されている。
この中にある bc_forwarding を 1 に設定することで、ブロードキャストパケットの転送を許可できる。

これを利用して、NAT 越しの WoL を可能にする。

マジックパケット（ブロードキャスト）の転送を有効化
sysctl -w net.ipv4.conf.all.bc_forwarding=1
sysctl -w net.ipv4.conf.wlan0.bc_forwarding=1
sysctl -w net.ipv4.conf.vpn_vpn.bc_forwarding=1

all
→ 今後生成されるインタフェースに対してもデフォルト値として適用

wlan0
→ 無線 LAN 側

vpn_vpn
→ VPN トンネルインタフェース

関連するすべてのインタフェースについて bc_forwarding=1 を設定する必要がある。

●VPN デバイスは動的生成される点に注意

注意すべき点として、vpn_vpn デバイスは VPN クライアント起動時に動的に生成される。
そのため、起動直後に sysctl を実行すると、デバイスが存在せず設定に失敗する。

この問題を回避するため、起動プロセスの最終段階（default.target 到達後）で設定を行う仕組みを用意した。

実家に設置してある VPN クライアントルーターを無線化。

「can’t add wlan0 to bridge」 の記事にある通り、当初はリモート側をブリッジ構成にして、無線 LAN と有線 LAN を同一セグメントにぶら下げる構想だった。
しかし、RTL8188EU を搭載した USB 無線 LAN ドングルを STA（クライアント）モードで使用する場合、L2 ブリッジが成立せず、この構成は断念することになった。

これは wpa_supplicant 自体の問題というより、RTL8188EU を含む多くの USB 無線 NIC が STA モードでのブリッジ（4addr / WDS）をサポートしていないことによる制約である。

その後の検証で、ブリッジを使用せず wlan0 を L3 インターフェースとして直接利用するルーティング構成で目途が立ったため、朝一番で無線構成へ移行した。

LAN ケーブルが不要になり、設置場所の自由度が大幅に向上した。

リモート側 VPN クライアントルーターの経路情報
pi@gw2:~ $ ip ro
default via 192.168.0.1 dev wlan0 onlink
192.168.0.0/22 dev wlan0 proto kernel scope link src 192.168.7.252
192.168.1.0/24 dev vpn_vpn proto kernel scope link src 192.168.1.251 metric 204

思い立って、高齢の実父見守りの為に実家に設置してある、自宅LAN―リモートLAN間のラズパイVPNルーターを弄ることにした。

RTL8188EU チップの USB 無線LANドングル（TL-WN725L）をラズパイ本体に追加し、有線NICとの共存を図れないか、と考える。

とりあえず、ブリッジに wlan0 と eth0 をぶら下げる構成を試してみることにした。

しかし、よく考えてみると、リモート側を無線にする明確な理由が見当たらない……。

まあ、LANケーブルが接続されていない方が設置場所に困らない、という利点は確かにある。

ところが、、、
wpa_supplicant で接続する場合、無線LAN（STA モード）では bridge mode が使えないことが判明し、少し驚いた。

brctl addif br0 wlan0 とすると、
can’t add wlan0 to bridge br0: Operation not supported
と表示される。

調べてみると、これは wpa_supplicant の問題というより、無線LAN（802.11）の仕様とドライバ実装上の制約によるものらしい。

多くの無線LANドライバ、とりわけ RTL8188EU 系では、
クライアント（STA）モードの wlan0 を Linux ブリッジに追加すること自体がサポートされていない。

何をやってもダメで、結局VPNルーターは安定の有線構成のままに戻すことにした。

wpa_supplicant は未完成というより、セキュリティや設計思想の観点から、クライアント用途に特化した作りになっている、というのが正確なところだろう。

実際、無線＋ブリッジ構成は、うっかり L2 ループを起こしやすいのも事実だし、VPNルーター用途としてはリスクが高い。

というわけで、無理に無線化せず、有線で安定運用するのが正解、という結論。

まあ、とりあえず、ほぼ丸一日時間を潰すことができたので、結果オーライということで（笑）

bullseyeでブリッジの仕様が変わったようで、ホスト間でMACアドレスが重複してしまう問題が判明。

192.168.1.254 dev br0 lladdr d2:b3:88:52:b1:18 STALE
192.168.1.2 dev br0 lladdr d2:b3:88:52:b1:18 STALE
192.168.1.1 dev br0 lladdr d2:b3:88:52:b1:18 REACHABLE

以前は最初にブリッジ接続したNICのMACアドレスがブリッジのMACアドレスになっていたので重複することは無かった。

なんでこんな仕様にした？

bridge name bridge id STP enabled interfaces
br0 8000.d2b38852b118 no enxb827ebb9d8d1

まあ、思えば妥当な仕様か・・・

/etc/machine-idを元にブリッジのMACアドレスを生成する模様で、ディスククローンから異なるシステムをセットアップしてそのまま使用するとmachine-idが重複し、その結果MACアドレスも重複するという話だった・・・

こうやってmachine-idを再生成すれば良い模様。

rm -f /etc/machine-id
dbus-uuidgen --ensure=/etc/machine-id
dbus-uuidgen --ensure

参考資料
MachineId - Debian Wiki
File: NEWS| Debian Sources/sources/bridge-utils/1.7-1/debian news

machine-idについては今まで気にも留めていなかったが、今回の問題で初めて存在を認識した。

ユーザーは振り回されるのみ(笑)

SEASKY.BLUE は登録日が2016/06/04で早くも５年。

毎年ドメインの更新で１６８０円掛かっていて、こんなサイトに金を掛けるのがバカバカしくなってきた・・・

という訳で、

SEASKY.BLUE ドメインは更新期限の５月一杯で返却し、MyDNS.JP様のおかげで無償で維持できるドメインに変更することにした。

SEASKY.BLUE を即座に無効にして新ドメインへのリダイレクトも一切なしでゼロスタートとしたが、全くアクセスが無くなってしまった(笑)

清々するなあ！

USBメモリーでhostapdを起動する案・・・「hostapd USBスイッチ追加」の続き。

Wi-Fiアダプタが外付けでUSBハブの個別スイッチにてON-OFFできる場合は、USBメモリーの検出・非検出でワンクッション置く必要もなく、Wi-Fiアダプタの検出・非検出をトリガーにhostapdを起動・停止すれば良く、新たに常駐スクリプトを設置。

次の様に起動して常駐しておく。
/usr/local/bin/hostap_auto_sw.sh wlx9cefd5fb7b50 2>&1 | logger -t hostap_auto_sw.sh &

hostapdを停止する前にデバイスを外すことになり、やや強引だがシステム上の問題は皆無。

これで、USBメモリーの無駄な電力を節約できる。
ケースの中にあるオンボードのデバイスではこれは使えず、わざわざ個別スイッチ付きのUSBハブを買った甲斐があった。

いずれにせよ、そこまでしてhostapdに拘る価値があるかは別問題(笑)

----------------------------------------
パンダ、当日届いて早速使用。

目論見通り、USBメモリーとは無関係に個別スイッチONでhostapdがバッチリ起動。
性能的にもRTL8192EUとほぼ同じで問題無し。

USBハブの個別スイッチに付属のLED表示で、hostapdが起動中であることが判り、視認性もプラス。

ただ、このデバイスは電界強度が高い分消費電力が高めで、ピーク500mA程度まで上がる。
ハブ経由で供給している５Vが瞬間的に4.5Vを下回ることがある・・・当面誤動作は起きてないけど・・・

以下、USBハブの個別スイッチONによるhostapdの起動から、USBハブの個別スイッチOFFによるhostapdの停止までに関係するログ。

＊個別スイッチON
Dec 3 19:49:16 gw0 kernel: [1499954.012399] usb 1-4.4: new high-speed USB device number 59 using xhci_hcd
Dec 3 19:49:17 gw0 kernel: [1499954.131537] usb 1-4.4: New USB device found, idVendor=148f, idProduct=5372, bcdDevice= 1.01
Dec 3 19:49:17 gw0 kernel: [1499954.131545] usb 1-4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 3 19:49:17 gw0 kernel: [1499954.131550] usb 1-4.4: Product: 802.11 n WLAN
Dec 3 19:49:17 gw0 kernel: [1499954.131554] usb 1-4.4: Manufacturer: Ralink
Dec 3 19:49:17 gw0 kernel: [1499954.220767] usb 1-4.4: reset high-speed USB device number 59 using xhci_hcd
Dec 3 19:49:17 gw0 kernel: [1499954.332542] ieee80211 phy13: rt2x00_set_rt: Info - RT chipset 5392, rev 0223 detected
Dec 3 19:49:17 gw0 kernel: [1499954.345220] ieee80211 phy13: rt2x00_set_rf: Info - RF chipset 5372 detected
Dec 3 19:49:17 gw0 kernel: [1499954.368527] rt2800usb 1-4.4:1.0 wlx9cefd5fb7b50: renamed from wlan0
Dec 3 19:49:18 gw0 kernel: [1499955.757615] ieee80211 phy13: rt2x00lib_request_firmware: Info - Loading firmware file ‘rt2870.bin’
Dec 3 19:49:18 gw0 kernel: [1499955.757668] rt2800usb 1-4.4:1.0: firmware: direct-loading firmware rt2870.bin
Dec 3 19:49:18 gw0 kernel: [1499955.757674] ieee80211 phy13: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
Dec 3 19:49:18 gw0 kernel: [1499955.945277] IPv6: ADDRCONF(NETDEV_UP): wlx9cefd5fb7b50: link is not ready
Dec 3 19:49:18 gw0 kernel: [1499955.946274] br0: port 3(wlx9cefd5fb7b50) entered blocking state
Dec 3 19:49:18 gw0 kernel: [1499955.946279] br0: port 3(wlx9cefd5fb7b50) entered disabled state
Dec 3 19:49:18 gw0 kernel: [1499955.946510] device wlx9cefd5fb7b50 entered promiscuous mode
Dec 3 19:49:18 gw0 hostap_auto_sw.sh: hostAP manually srarted 2020年 12月 3日 木曜日 19:49:18 JST
Dec 3 19:49:20 gw0 kernel: [1499957.302902] IPv6: ADDRCONF(NETDEV_CHANGE): wlx9cefd5fb7b50: link becomes ready
Dec 3 19:49:20 gw0 kernel: [1499957.302977] br0: port 3(wlx9cefd5fb7b50) entered blocking state
Dec 3 19:49:20 gw0 kernel: [1499957.302980] br0: port 3(wlx9cefd5fb7b50) entered forwarding state

LIVA Zルーターのhostapdにてパンダを導入する前に、ラズパイルーターで使っていたRTL8192EU（Tp-Link TL-WN823N）で試してみた。

Intelワイヤレス・アダプター用のドライバであるiwlwifiは処理が重く、UP時はCPU温度が４℃ほどもあがるぐらいだが、こうすると本体のCPU温度は変わらず。
更に、802.11nのHT40チャンネルボンディングもしっかり効いて、上下70Mbps近く出る。

また、ハブでLIVA Z本体から離して設置するのでUSB3.1のノイズ干渉も受けず、安定する。
あと、Wi-Fiアダプタは結構消費電力が高く、通信時には最大２W程度消費するんで、冷却効率の面でもこの形が良い。

USBのバスパワー（５V）の電圧がハブまでの配線でドロップするが、4.95Vぐらいは出ているので問題無し。

RTL8192EUはカーネルソースツリーにマージされていないので、ロードすると「カーネルを汚染する」とのメッセージが出るため正式導入は見送り、パンダに期待。

LIVA ZのインテルCPU、案外処理能力が低くて丁度いいな(笑)

その点、ラズパイ２Ｂは小さくて低消費電力な割には優秀な印象。
やはり時代はARMか・・・

LIVA Zルーターの機能追加・・・

ディスクラベルを引数とし、そのディスクラベルを設定したUSBメモリー等をUSBポートに取り付けるとWi-Fiアクセスポイントが起動し、そのUSBメモリーを取り外すとWi-Fiアクセスポイントが停止するという機能の常駐スクリプトを書いて運用中。

こんな風に起動して常駐させる。
/usr/local/bin/hostap_usb_sw.sh APSW 2>&1 | logger -t hostap_usb_sw.sh &

crondのタイマーで１９：００～２２：３０までは自動でWi-Fiアクセスポイントが立ち上がるようにしてあるが、それ以外の時間帯に使用する目的で用意。

USBメモリーをスイッチ代わりとしたオリジナルなアイデア。
スイッチ付きのHUBと組み合わせるとGood！

しかし、その間にUSBメモリーを本来の目的で活用しないと、その消費電力約０．２Ｗ程度が無駄に(笑)

------------------------------------------

後日、バカみたいにわざわざUSBハブまで買って設置。
画像のUSBハブ最上段に付いているUSBフラッシュメモリー、LABELを"APSW"としてあり、ハブの個別スイッチにて hostapd がON-OFFする。

5秒以内にON-OFFできるので利便性も高く、これは思っていた以上に便利だ。

しかし、そこまでしてhostapdに拘る価値があるか否かは別問題（笑）

早朝覚醒で時間を持て余し、朝からラズパイサーバーをPi2Bから眠っていたPi3B+に変更したが、やはり消費電力が・・・

いい加減アンダークロックしても、Pi2BよりCPU温度が10℃以上高くなり、アルミケースの温度も明らかに高く触ると湯たんぽ状態(笑)

ファンレスに拘りたいので、常時オンラインな用途でPi4Bを使うなんてあり得ないな・・・

・アンダークロック状況
arm_freq_min=300
core_freq_min=200
gpu_freq_min=200
temp_limit=65

・CPU温度
pi@pacific ~ $ vcgencmd measure_temp
temp=47.8’C

夏場は60℃付近で常用か・・・

Pi3B+はイーサネットがUSB2.0の帯域をフルに使えるようになっており、理論上最大４８０Ｍｂｐｓで、実際のＳＭＢファイル転送は２００Ｍｂｐｓ程度出るようで、Pi2Bよりはかなり快速に。
処理能力もPi2Bの倍近く、phpブログの処理時間がほぼ１／２になる。

ストレージの同期をやってみたが、やはりPi2Bよりはかなり快速。
消費電力据え置きだと最高だが、、、

やはり、どうしても消費電力が気になる・・・

temp_limit=65 では気に入らないので、temp_limit=50 まで下げてみたところ、ちょっとした負荷ですぐに50℃に達するので、phpブログの処理時間はPi2Bと大差ないレベルまで伸びてしまった・・・

これでは意味無いじゃないか(笑)

temp_limit=60 ぐらいで妥協するか・・・間をとって、temp_limit=55 だな。

否、4月～9月 temp_limit=60，10月～3月 temp_limit=50 ぐらいが適当か。

--------------------------------------
しかし・・・当日帰宅後

結局Pi2Bに戻した。

Pi3B以降と比較して消費電力がかなり低く、ケースも冷たい状態なのにその割に性能が良い。

やはり、Pi3B以降は使う気にならない。

この事実に納得いかないのか、同じことを繰り返している(笑)

・2017/01/22 Pi3Bを試した際の記事
　結局　Pi2

・2018/07/01 Pi3B+を試した際の記事
　やはり消費電力が・・・