Lycolog

R86S U1のファンはいかにも貧弱でいつ壊れても不思議がなかったので、壊れる前にもうちょいマシにしようと試行錯誤したログ。

やろうとしたこと

既存のケースを外し、ラズパイ用の大型クーラーをつけて適当なケースを作って冷やせるようにしようとした。

R86S U1の分解像

外観

裏ブタを開けたところ

本体を開けたところ

手前からCPUボード、NIC、NICの裏板の三層構造になっている。

各ボードを繋ぐケーブルが邪魔なので、作業するときは外すとやりやすい。

FPC（フレキシブル基板、フレキシブルケーブル）は以下の手順で外せる。左右についている爪を触ると折れるので触らない方がいい。但し折れても支障はない。

CPUボードを開けたところ

グリスが酷い。閉じ直すときは、ここまで塗る必要はなく、注射器から1mmほど出しておけばよい。

CPUヒートシンク？

蓋側にはケースに熱を伝えるための銅の板がついており、やはりグリスがたっぷりついている。

CPUファン

銅板やヒートシンクを冷やしているというよりはケース表面のヒートシンク形状を浸すための装置に見える。40 x 40 x 7mmの2pin形式なら互換性があるものと思われる。

ピンの形状は検証していないが、調べた限りJST SH1.0MMらしい。ハウジングはこの手の製品が使えると思われる。

耐久性が心配になるサイズだが、この方式であれば上に60mmファンを雑に置いておいても成立しそうな気はした。

CPUボード単体

CPUにはヒートスプレッダが二つ付いており、ノートPCによくあるタイプに見えた。

NIC側を開けたところ

NIC本体と裏板は特殊なコネクタで繋がっており、上に引っ張ると抜ける。調べた感じOCP2.0という規格らしい。

OCPはOpen Compute Projectの略で、ラックサーバー用の規格のようだ。一般的にOCP2.0メザニンカードと呼ばれているらしい？

このコネクタを備えた変換PCIeカードも流通しており、普通のPCに繋ぐこともできるようだ。

R86S U1の寸法記録

CPUボード

Autodesk Fusionで描いたもののスクショ。誤差+-0.50mm程度と思われる。

CPU本体

Autodesk Fusionで描いたもののスクショ。誤差+-1.00mm程度と思われる。

Rが付いて盛り上がった形をしているヒートスプレッダのサイズが上手く取れなかったので、大まかな図。特に上下のスプレッダの間隔は怪しい。

NIC

手描きのスケッチ。ネジ穴の直径を書いているが、実際はすべて3.00mmと思われる。

「チ」とあるのはNICのチップ。「チ」2.44mmはチップの高さ。

NICの裏板

NICがのっかってる板。NVMeSSDを挿すやつが載ってるやつ。ケース固定用のネジ穴とヒートシンク固定用のネジ穴で直径が異なる。

左にある凸型の図はNICを支えるスペーサーと、それが載った基板の寸法。

下にある「内側のネジがヒートシンク用」「ファンのネジ」とあるのはネジの寸法。

ラズパイクーラーの足回りの寸法

GeeekPi ICE Tower Plus クーラー Raspberry Pi 5、Raspberry Pi 5 4GB/8GB 用冷却ファン付き Pi 5 アルミニウム アクティブクーラーの寸法。

luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。

• 確認環境
• セットアップ
• Collectdのプラグイン設定
• Collectdのプラグイン
  • collectd-mod-cpu：CPU使用率
  • collectd-mod-interface：ネットワーク転送量
  • collectd-mod-load：負荷(Load Average)
  • collectd-mod-memory
  • collectd-mod-thermal
  • collectd-mod-uptime
  • collectd-mod-rrdtool
• トラブルシューティング
  • Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される
• 参考

確認環境

セットアップ

1. LuCIを開く
2. System→Software
3. luci-app-statisticsを入れる
4. 画面リロード
5. Statics→Graphからグラフが見れることを確認

この時点で幾つかのプラグインが導入されたが、消したり入れたりして、結果として以下のものを導入した。

• collectd-mod-cpu
• collectd-mod-interface
• collectd-mod-load
• collectd-mod-memory
• collectd-mod-thermal
• collectd-mod-uptime
• collectd-mod-rrdtool

Collectdのプラグイン設定

/etc/collectd.confをいじると変更できる。

基本的にはLoadPlugin hogeでhogeプラグインを読み込み、以下の書式で設定するようだ。設定がなければLoadPlugin hogeだけでよい。

<Plugin hoge>
        Foo true
        Bar 1
        Baz "fuga"
</Plugin>

Collectdのプラグイン

collectd-mod-cpu：CPU使用率

collectd-mod-cpu

設定はデフォルトのままで良さそう。

collectd-mod-interface：ネットワーク転送量

collectd-mod-interface

Network→Interfaces→Deviceにあるものが見れる。

br-lanとMAP-E、PPPoEが見たいので以下のようにした。

LoadPlugin interface
<Plugin interface>
        Interface "br-lan"
        Interface "map-wanmap"
        Interface "pppoe-wanppp"
</Plugin>

collectd-mod-load：負荷(Load Average)

• collectd-mod-load

uptimeコマンドで出てくる内容と思われる。1を超えていれば過負荷、割っていれば余裕がある。

Wikipediaによると、1ならその時間平均で全てのプロセスが実行され、1.73なら73%のプロセスが実行待ちになったと言う事のようだ。これを1分、5分、15分の平均で出しているとのこと。

設定項目がない。

collectd-mod-memory

• collectd-mod-memory

メモリの使用量を取れる。

設定はデフォルトのままで良さそう。

collectd-mod-thermal

• collectd-mod-thermal

デバイスの温度を取れる。

R86S U1の場合、thermal_zone1以外無価値に見えたので、thermal_zone1のみとした。thermal_zone0はマザーボードの温度のようだが、固定値しか出てこない。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

これだけだと余計なグラフが出てくるため、設定後に余計なグラフデータを削除する。

collectd-mod-uptime

公式にマニュアルはなさそうだが、起動時間を見れる。

LoadPlugin uptime

collectd-mod-rrdtool

• collectd-mod-rrdtool

collectdが取得したメトリクスを保存したり、メトリクスのグラフを書くのに使われている模様。特に設定せずとも勝手に設定されるため設定を気にする必要性はなさそう。

ログは標準では/tmp/rrd/OpenWrt/に保存されているようなのでストレージの摩耗は気にしなくていい。（/tmp/はオンメモリストレージ）

トラブルシューティング

Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される

上図の青枠のように壊れて表示されていない画像や、集計対象外のものが表示されている場合、/tmp/rrd/OpenWrt/配下にある不要なメトリクスを削除することで非表示にできる。

例えば上図にあるthermal-cooling_device*にはまともにデータが入っていないため、画像が壊れて表示されている。rm -Rf thermal-cooling_device*で消すと出てこなくなる。

上図の状態になると、下図のように不要なグラフが表示されなくなる。

但しcollectd.confで以下のようにデバイスを絞っていないと、再び出てくると思われるので、設定で表示したいものだけに絞ってから消した方がよい。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

参考

• [OpenWrt Wiki] Performance and logging

Amazonや公式サイトにある情報が本当に正しいとは限らないので実地検分。

• やり方
• 調査ログ
  • CPU
  • メモリ
  • NIC(RJ45)
  • NIC(SPF+)
  • ストレージ(eMMC)
• まとめ

やり方

# これでCPUの情報が取れる
cat /proc/cpuinfo

# これでメモリの情報が取れる
opkg install dmidecode
dmidecode -t 17

# これでCPU, NICの情報が取れる
opkg install hwinfo
hwinfo

# これでeMMCのベンダ情報が取れる
cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid

調査ログ

CPU

cat /proc/cpuinfoの結果から取得した情報。

model name : Intel(R) Celeron(R) N5105 @ 2.00GHz

メモリ

dmidecode -t 17の結果から取得した情報。

MicronのLPDDR4でDDR4-3200相当であるとわかる。

Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 8 GB
Error Information Handle: Not Provided
Number Of Devices: 2

Memory Device
Array Handle: 0x003A
Size: 4 GB
Form Factor: Row Of Chips
Locator: Controller0-ChannelA
Type: LPDDR4
Speed: 3200 MT/s
Manufacturer: Micron Technology

NIC(RJ45)

hwinfoの結果から取得した情報。

pci 0x125cはI226-VなのでIntel Ethernet controller I226-V

Hardware Class: network
Model: "Intel Ethernet controller"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x125c
SubVendor: pci 0x8086 "Intel Corporation"
SubDevice: pci 0x0000
Revision: 0x04
Driver: "igc"
Driver Modules: "igc"
Device File: eth2

NIC(SPF+)

以前分解したときのラベルと、hwinfoの結果から取得した以下の情報と突き合わせるとMellanox ConnectX-3 En10*2 Gigabit Ethernet CX341Aであることが分かる。

Hardware Class: network
Model: "Mellanox MT27500 Family [ConnectX-3]"
Vendor: pci 0x15b3 "Mellanox Technologies"
Device: pci 0x1003 "MT27500 Family [ConnectX-3]"
SubVendor: pci 0x15b3 "Mellanox Technologies"
SubDevice: pci 0x0113
Driver: "mlx4_core"
Driver Modules: "mlx4_core"
Device File: eth3

ストレージ(eMMC)

以下の結果から、name: SCA128, manfid: 0x0000dfであることから、メーカー不詳のSCA128という製品であることが分かる。ググってもメーカー情報は不明だった。

cat /sys/class/mmc_host/mmc0/mmc0:0001/name
cat /sys/class/mmc_host/mmc0/mmc0:0001/manfid

まとめ

公式サイト？の情報やAmazonの情報と比べると微妙に差異があり、また、書いてない情報も取れたので調べてよかったなと思った。

前回2024/01/25に更新したサーバー機（サブマシン）だったが、今回サーバーとして運用することになったのと、将来的に10GbEを導入した時の投資としてネットワークスペックを上げるなどを目的とし、更新を実施した。

• 更新前後の構成
• 主な更新理由
• 開封の儀
  • マザボ
  • CPU
  • CPUクーラー
• 組み立て後
• あとがき

更新前後の構成

POST時にメモリエラーが出るので近日中にメモリは交換予定だ。幸い相性保険に入っていたので追加費用は出ない見込み。

主な更新理由

• マザボ更新によるNICの高速化
  • 1Gbpsを2.5Gbpsに上げることにより将来の高速化に備える
  • メインマシンが2.5GbpsなのでLAN内速度の向上
• SocketAM5への移行
  • 今後新たにCPUを買うときに発生するコストの痛みを余裕のある今のうちに吸収
• DDR5への移行
  • もうDDR4とかオワコンですしお寿司…

開封の儀

買ったもの。全部神戸市内で購入。というかメインマシン更新時と同じくソフマップで買ってきた。ここにしかITXマザーがなさそうだったのが理由だ。

メモリがやけにゲーミングだが、他が売り切れていたので仕方がなくこれにした。

この時はまだCPUクーラーが適合しないとは夢にも思っていなかった。何故ならAM4とAM5はCPUブラケットに互換性があるとされていたからだ。

マザボ

箱の中身。WiFiのアンテナや、温度センサ、M2SSDネジ、ケーブルバンド、SATAケーブル辺りがあった。写真には写っていないがASRockのデカいシールも入っていた。

表面。CPUソケットの主張が激しい。

AM5からはLGAに変わっているためマザボ側にトゲが生えている。ピン折れリスクの観点からPGAの方が好きだったので残念だ。

とはいえ、PGAは面積当たりのピン数の制約が強いのでスペックアップのためには仕方ないだろう。面積当たりのピン数はLGAの方が有利だろうし。

裏面。裏面NVMeスロットが復活していた。これはA320M-ITXにはあったけどA520M-ITX/acではなくなっていた要素だ。

恐らくNVMeスロットを2つにする上で仕方がなかったのだろう。確かASUSも裏面に実装していたと思う。

CPUバックプレートを差し込もうとしたところ、なんと入らなかった。寸法は同じだったが穴のサイズが合っていなかった。

更に言うとバックプレートが剥がせなくなっていた。マザーボードに完全に貼り付けてあった。

側面。2.5Gの文字がまぶしい。今回最大の目的はこれである。

CPU

右が今回買った方で、左が今まで使ってた方。なんか見た目がかっこよくなっていた。

PGAからLGAに変わった関係で背が低くなっている。ソケットアサイン用の窪みが出来た関係もあると思うが、接点の密度は左程増えていないようにも見える。むしろ減っていても不思議がない。

CPUクーラー

まさか手持ちのが使えないとは思ってなかったので、組み立て作業はこれが届くまで一時停止する。

こちらは入手困難であったため、Amazonで調達した。17時ごろに見たら翌朝配送と書かれており、私はこの時、映画を見るスケジュールで埋まっていて当日中に手に入れる手立てがなかったからだ。

翌日12時半に到着して、無事パーツを組むことが出来るようになった。エアフローをサイドフロー型向けに最適化しておきたいので、このパーツは外せなかった。なんか微妙な奴ならソフマップにもあったのだが、微妙なのは使いたくなかった。こういうものには納得が必要だ。

付属品はファンとヒートシンクにIntel用のバックパネルとリテンションキット、CPUグリス、マニュアルなどだった。

AMDのバックパネルがないのが気になったが、そのまま挿すことが出来た。これは賢いなぁと思ったが、メーカーごとに自由なバックプレートを作れないのは差別化要素を失わさせる要因にもなるため、Intelの方が多様性に資するなとは思った。

ファンの新旧比較。左が新しい方、右が古い方。新しい方が風量があり、やや五月蠅かった。古い方は風量がやや少ない代わりに静かだった。

ヒートシンクの新旧比較。銀色が古い方、黒色が新しい方。

違いとしては、まず色が違うほか、台座のヒートシンクが小さくなっているのと、台座の高さも減っていた。

また、若干ヒートシンクの角が削れており、これはドライバーでネジを占めるときのクリアランスとして便利だった。以前はヒートシンクが削れていたのでイマイチだった。

グリスはCoolerMasterのコーポレートカラーだったが、なんかキモいので拭き取って忘れることにした。実際にはNoctuaのグリスを塗った。

組み立て後

中身。ヒートシンク付きのごついゲーミングメモリが目立つが、以前と比べ黒くなった。大体CPUクーラーのせい。

外観。ぶっちゃけ変わる要素がないので、ほぼ変わっていない。変化としてはシールが増えているところだ。しかし今回はRADEONのシールがなかったので、Ryzenのシールのみとなり、シールの枚数が奇数になってしまった。

左から右にシールを増やしているが、Athlonのシールがあるマシンもそうそうなさそうなので、結構独特な存在だと思っている。

あとがき

今回の更新作業は予期せぬトラブルで自宅サーバーが予想外長時間止まってしまった。本来は16時開始17時終了でサーバーを再開する予定が、CPUクーラー手配の関係などで翌日15時まで、ずれ込んでしまった。まぁ、こういうのも、また自宅サーバーの醍醐味だろうという気はするので、特に気にしてはいないし、むしろ停止中にメンテ画面に切り替えるためのDNS変更スクリプトとかは作っておいた方がいいだろうなという気付きを得られたりもした。

ひとまず本質的なスペックとしてはさして上がっていないと思われるが、拡張性で言えばマザボのスペックが最新鋭になり、ストレージスロットがやや増えているのもあり、将来的な拡張には耐えてくれるだろうし、この規模の更新は当面しなくて済むだろう。このベーススペックで5年、あるいはそれ以上持つことを期待したいところだ。

ただ、このマザーボードを使ってCPU(Ryzen 7 9800X3D)が壊れたとか、不具合系の話もまことしやかに聞くのでやや心配だが、そこは見守っていきたい。

OCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことを派生させて更にIPv4にも対応させるプラン。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けないが、PPPoEを使って取得したIPv4であれば開けるので、これとIPoE側のIPv6の併用でデュアルスタックでWell-known portsの開放を行い、サーバーを運用できるようにするのが目的だ。

• 確認環境
• 今回の要件
• やり方
  • サーバー側の準備
  • PPPoEインターフェースの作成
  • ファイアーウォールの作成
  • サーバーだけをPPPoEのIPv4通信の対象にする
  • NATを設定する
  • 疎通確認
  • IP変動対策にDDNSを設定する
• トラブルシュート
  • curlで「Connection refused」や「接続が拒絶されました」と出る
  • 同一LANにぶら下がっている端末でDNS解決に失敗する
• 雑感：かなり苦しい

確認環境

今回の要件

• OCNバーチャルコネクト環境でIPv6サーバーを公開した時にやったことに追加でIPv4も開通させる
• IPv4はPPPoEで取得できるものを使う
• サーバーマシン以外の端末に影響を与えない

やり方

サーバー側の準備

ufwではv4にも穴が開いている状態とする

1. nginxの設定を開きIPv4向けにlisten 443 ssl;を追記して保存する
2. nginxを再起動する

PPPoEインターフェースの作成

1. SSHでOpenWrtに入る
2. /etc/iproute2/rt_tablesを開き次のようにpppoeの行を追加、保存

   #
   # reserved values
   #
   128     prelocal
   255     local
   254     main
   253     default
   300     pppoe
   0       unspec
   #
   # local
   #
   #1      inr.ruhep
   

3. 反映する
   • service network restart
4. LuCIに入る
5. Network→Interfacesを開く
6. Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する
   

   

7. General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる
   

   

8. Advanced Settingsタブを開き、Use DNS servers advertised by peerのチェックを外し、Use gateway metricを10、Override IPv4 routing tableをpppoe (300)にする
   

   

9. Saveボタンを押して保存する
10. wanインターフェースのEditを押す
11. Advanced Settingsタブを開き、Use gateway metricを1にする
12. Saveボタンを押して保存する

ファイアーウォールの作成

1. 引き続きLuCI上で作業する
2. Network→Firewallを開く
3. ZonesのAddボタンを押す
4. Nameをwan_pppoeにし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanpppを選択し保存する
   

   

5. lan⇒wanのゾーン設定のEditボタンを押す
6. Allow forward to destination zones:にwan_pppoeを追加し、保存する
   

   

7. Network→Interfacesを開く
8. wanpppインターフェースのEditボタンを押す
9. Firewall Settingsタブを開き、Create / Assign firewall-zoneにwan_pppoeが設定されていることを確認する。設定されていなかったら設定する
   

   

サーバーだけをPPPoEのIPv4通信の対象にする

1. 引き続きLuCI上で作業する
2. Network→Routingを開き、IPv4 Rulesタブを開く
3. General SettingsタブのIncoming interfaceをlanに、SourceをサーバーのIPにする（例：192.168.1.5/32）
   

   

4. Advanced Settingsタブを開く
5. Tableにpppoe (300)を設定し、保存する
   

   

NATを設定する

1. 引き続きLuCI上で作業する
2. Network→Firewallを開き、Port Forwardsタブを開く
3. Addボタンを押す
4. Nameに適当な名前を付け、Restrict to address familyをIPv4 only、Source zoneをwan_pppoe、External portを443、Internal IP addressを転送先のサーバーIP、Internal portを443にして、保存する
   

   

5. 最後にこれまでの内容をSave & Applyする

疎通確認

1. Network→Interfacesを開き、wanpppのIPv4を拾う
2. ドメインレジストラの設定でAレコードにこれを登録
3. 適当な外部サーバーからcurlを投げて中身が返ってきたらOK

   curl -4 -v https://example.com
   

IP変動対策にDDNSを設定する

/etc/hotplug.d/ifaceに40-pppoeというファイルを755で作り、以下の内容を記述する。

#!/bin/sh

[ -n "$DEVICE" ] || exit 0
[ "$ACTION" = ifup ] || exit 0
[ "$INTERFACE" = wanppp ] || exit 0

vdpw=ここにDDNS更新用のパスワード
pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
logger -t "DDNS - PPPoE IP" $pppoeaddr
# hoge.example.comに対して更新リクエストを飛ばす例
logger -t "DDNS - DOMAIN: hoge" $(wget -O - "https://dyn.value-domain.com/cgi-bin/dyn.fcg?d=example.com&p=$vdpw$&h=hoge&i=$pppoeaddr")

# When making requests for multiple domains, wait 60 seconds between each request

このスクリプトはhotplugイベントが発生したときにファイルパス順に呼ばれるスクリプトらしい。

ひとまずデバイスでなく、インターフェイスが起動したときで、かつインターフェース名がwanpppの時に実行されるように組んである。

注意点として、このエンドポイントはレートリミットがシビアで、60秒以内に送ると503を返してくるようなので、複数回投げる場合はsleep 61とかして間隔をあけると良さそうだ。数が増えてきたらバリュードメインAPIのDNS設定APIを利用した方が早いだろう。

ただしこのAPIはTTLの制御に難があり、処理方法によっては3600秒に固定される罠が潜んでいるので注意が必要だ。

トラブルシュート

curlで「Connection refused」や「接続が拒絶されました」と出る

• /var/log/ufw.logにログがあればufwで穴をあける（まずこれはない）
• ファイアーウォールかルーティングかNATの設定のどこかがおかしいので見直す。

同一LANにぶら下がっている端末でDNS解決に失敗する

PPPoEインターフェース（wanppp）の設定を開き、Advanced SettingsからUse DNS servers advertised by peerのチェックを外すと直る。

雑感：かなり苦しい

IPv4, v6のデュアルスタックに出来たのはいいが、幾つかの端末で繋いだところIPv4側に流れるケースがあった。メインのv6でなく、オプションのv4に行くという状況はやや残念だ。

構成的にもマルチセッションという微妙な形態で、v4とv6でインターフェースが二系統あり、セキュリティもNATとFWがあり、なかなか複雑な状態になってしまった。

Mastodonにおいてはv4IPのインスタンス（兵庫丼）との疎通はTLレベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。

Misskey.ioからは疎通できず、こちらからはユーザープロフィールまではアクセスできるがフォローを押しても音沙汰がない。

結論としてはリッチなアプリケーション通信を伴う用途において、この方式は向かない気がした。恐れくこれはルーターより外側がIPoEとPPPoEで別系統になっている関係で、通信が混乱して上手くいかないパターンがあるのではないかと感じている。

DDNSも制約が厳しいし、Value DomainのAPIはあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。

まぁいい勉強にはなったので、そのうち何かに活かせるだろう、きっと。