DVDFabに続いて、MakeMKVとXrevealでUHDメディアのRIPを試す。
まず、MakeMKV。念の為、MakeMKVフォーラムで公開されているレジストキーを登録する。



PCを再起動して、MakeMKVを起動。ディスクバックアップを選択する。
ビデオファイルを複合、のチェックボックスにチェックを入れる。

バックアップを開始すると、プログレスバーが伸びていく。

しかし、読込のScsiエラーが多発して、ファイル検証で全然プログレスバーが進まない。
仕方なく、バックアップを断念する。

続いてXrevealでUHDメディアをISO保存。

こちらは順調にプログレスバーが進み、50分ほどで保存が完了した。

保存されたISOファイルはDVDFabで保存したものと同様、中身のtsファイルをVLCで再生することもできた。
DVDFabとXreveal、二つのアプリで保存したISOファイルのプロペディを確認すると、容量に大きな差がある。

DVDFabで保存したものは44.3GB、Xrevealで保存したものは54.5GBとなっている。
DVDFabも、保存前のオリジナルが54.5GBだったので、Xrevealの方が忠実に保存しているように思える。
4K BDレコーダーのデータ吸い出しはうまくいったので、続いて市販のUDHメディアのRIPを試してみる。
HLDSの外付けドライブに、MARVELのUHDメディアを挿入。早速ドライブアクセスが始まり、分析される。

オリジナルはBD66/54.5GBで、保存したISOはBD50/45GBとなっている。圧縮か、不要なファイルを削除しているのだろうか?
保存したISOは2層のBDメディアにも保存できそうだ。
どちらもDolby Visionと表記されている。

開始ボタンを押すと分析処理が走り、ディスクコピーが開始された。
ビデオの再エンコードのビットレート、24Mbpsとなっている。

吸い出しされたISOファイルをエクスプローラで開き、中身のtsファイルをVLCに読み込ませると問題なく再生できた。

素晴らしい。
LibreDrive対応のドライブが準備できたので、BDメディアのRipにトライする。
MakeMKVを使ってみたいが、まずはSONYの4K BDレコーダーで録画したBDAVメディアのRipを試してみたい。
5chの情報で、AnyDVDの流れを汲むXrevealというソフトがSONYレコにも対応しているとのことなので、ダウンロードしてインストールする。

Xrevealは全ての機能を使うにはPro版へのレジストが必要。
永続版でも$45と、この手のソフトとしては安いので、PayPal決済ですぐに購入してしまう。

インストールしたXrevealはタスクトレイに常駐して、メニューから登録を選ぶと、レジストコードを入力できる。
Pro版への登録が完了し、以前録画してムーブした、プロジェクトXレストア版のBD-R DLメディアを試してみることにする。

メディアを挿入して、ディスクを認識。

Xrevealメニューから、ISOにリッピングを選択。

ソースと保存先を確認して、開始ボタンを押す。


数分でリッピングが完了。

出力されたISOファイルをExplorerでマウントして、中を開くと、m2tファイルが二つ確認できる。
ファイルのプロパティを確認すると、26Mbpsの動画ファイルとなっている。


VLCに喰わせると、再生できた!

素晴らしい。4K番組のRipも、これでようやく実現できるようになった。
もう一台、中古のBuffaloのUSB外付けドライブを入手したので、FW更新にトライする。
製品型式はBRXL-16U3Vで、搭載ドライブはHLDSのBH16NS58。ファームウェアは1.03となっている。
MakeMKVのStatusは、Possible, not yet enabledだ。

DVDFab UHDドライブツールを起動すると、ファームウェアのダウングレードのボタンがアクティブ化されているではないか!
FW1.00にダウングレードできる。

これは試してみるしかないか・・と、ボタンを押してみる。

ダウングレードのプログレスバーが進み、途中何度かドライブのトレイが開閉する。

2-3分でダウングレードが完了した。

PCを再起動してMakeMKVで確認すると、StatusはEnableに変わった。

これでこのドライブもLibreDrive対応ドライブとなった。
いよいよ、MakeMKVをインストールする。
MakeMKVはDVDやBlu-rayを無劣化のままMKV形式の動画ファイルへリッピングするソフトウェアで、AACSやBD+などのコピーガードにも対応する。
ただし、ブルーレイレコーダーで録画したBDAVディスクには対応していない。
生データのままバックアップする機能も有しているが、不要なファイルも含まれていて、扱いが厄介なので、PCでの再生を主眼とするならMKV形式に変換したほうが良いようだ。
ベータ版として30日間全機能を利用でき、公式フォーラムの[News and Announcements]の[MakeMKV is free while in beta]というスレッドの[Beta Key]をコピーして、アプリの[Register]メニューから登録すれば継続して使用できるようだ。

ちなみに、永続版にレジストするには10,602円(この日の為替レート)を支払う必要がある。


まずはインストール。特に問題なく完了する。




起動すると、ドライブのステータス画面が表示され、プルダウンで対象ドライブを切り替えることができる。
まず、前日にダウングレードしたHLDSのドライブ、BH16NS48を確認する。
LibreDrive Informationの箇所は、StatusがEnabledとなっており、対応していることが分かる。
BD raw date readなどもYesとなっている。

続いてPioneerのバルクドライブ、BDR-212Mだ。
これは、StatusがPossible, not yet enabledとなっている。
ファームウェアを更新等すれば、対応可能ということだろうか?

続いて同じく Pioneerのハイエンドドライブ、BDR-S13JX。
こちらはStatusがEnabledでBD raw date readなどもYes。
BDR-212MもBDR-S13JXも、同様の公式ファームウェアなのだが、何故違いが出てしまうのか?

最後に、Logitecブランドのポータブルドライブ。こちらはPioneerのBD-TD05が採用されている。
このドライブもEnbledでLibreDriveに対応している。

BDR-212M以外のドライブは全てLibreDriveに対応していることになる。
MakeMKVのフォーラムで調べると、BDR-212Mの対応FWは、1.01と1.02となっており、自分の持っている212MのFWは1.01で一致している。
BDR-S13JXの方は同一の型番はないが、BDR-S13UとS13JXの1.01と1.02がフォーラムのリストに掲載されている。一方で自分の持っている個体は1.05だ。
BDR-TD05は、リスト掲載が1.00と1.02、手持ちドライブは1.01。
何だか解せないのだが、対応FWとして掲載されているドライブはNGとなって、掲載されていないFWのドライブがEnableとなるようだ・・。
さらに、フォーラムの投稿を読むと、Drive PlatformがRS8xxx、RS9xxxのものはファームウェア更新不要でサポートされるべき、と書かれている。自分のPioneerドライブは全てRS8xxxかRS9xxxの新しいPlatformとなっている。また、SDF.binにドライブ情報が記載されていれば、動作するとのこと。ただ、SDF.binファイルはバイナリエディタで開いても、中身は確認ができなかった。
まあ、意地になって全てのPioneerドライブをEnableにする必要もないのだが・・。
一番当たり障りのない、中古のIODATAドライブ(中身はBH16NS48)を用いて、DVDFabのUHDドライブツールでDEファームウェアへのダウングレードを試してみることにする。
まず、更新前のファームウェアのリビジョンをB's Recorderのドライブ設定で確認する。リビジョンは1.03だった。
また、この外付けドライブはSATA-USB変換チップで余計なInquiryコマンドに対する応答はしないようで、内蔵ドライブのベンダー、型式を返してくれるようだ。


公式のドライブツールの一部の使用方法を見ると、SATAのBIOS設定をAHCIからIDEに変更、と書かれている。今時IDEモードなんてないだろう・・と、この解説は無視することにする。
DVDFabのメイン画面を起動して、ユーティリティを選択、UHDドライブツールをここから起動する。

ドライブのプルダウンメニューで、BH16NS48が選択されていることを確認して、[ファームウェアをダウングレード]のボタンを押す。
すぐに赤字で、『お選択のドライブのダウングレードに対応しません』、の警告が表示され先に進めない。『お選択』とい和訳が微笑ましいけど・・。

ちなみに、Pioneerのドライブを選択すると、『お選択のドライブがUHDドライブではありません』の警告となり、UHD互換性の部分もN/Aとなっているので、そもそもPioneerのドライブには対応が困難ということになる。

BH16NS48の古いファームウェアはないかな・・とWebを検索したら、すぐに見つかった。しかも、lg.comのWebサイトに。
純正のリテールパッケージのサポートページで、N1.01とN1.02の二種類のFWが公開されていた。

まあ、中古のドライブなので、文鎮化したらしたでいいか・・とダウンロードしたアップデータ(アップではなく、ダウンだが・・)でファームウェアを適用する。



適用はあっさり完了。PCの再移動を促され、再起動後にB's Recorderでドライブ設定画面を開いたら、キチンと1.01のリビジョンに変わっていた。

取り敢えず、今日のところはここまでにしておく。
昨年、LGやASUSのドライブと、DVDFab AIOを購入して、UHDドライブツールも入手した。
これで、UHD Blu-rayをバックアップできる環境構築の準備が整った。
あらためて、備忘の意味も込めて、関連情報を整理する。
まずはややこしい用語。
UHD Official Drive、UHD Friendy Drive、LibreDriveという言葉が入り乱れている。
以下、整理。
■ UHD Official Drive
正規仕様通りにUHD再生するためのドライブ
AACS2.0を完全実装しているが、再生には環境制限あり(SGX、HDCPなど)
ディスクの中身は保護された形でしか扱えない
■ UHD Friendly Drive
UHD対応を謳っていない通常のBDXL対応ドライブ、ただし、特定FWによりUHDディスクを読める
AACS2.0を実装していない/回避できる、基本的にAACS1.0として扱われる
MakeMKVなどでデータ読み出し、リッピング可能
■ LibreDrive
MakeMKVが持っているドライブ制御モードのこと
低レベルで直接データを読み出すことによりドライブの制限を無効化
Official Driveでも使える場合がある
続いてファームウェア。
UHDをリップイングするためには通常、MakeMKV(SDFtool Flasher)やDVDFab UHDドライブツールを用いてドライブのファームウェアを書き換える必要があるのだが、書き換え用のファームウェアには以下の二種類が存在する。
■ DE firmware
オフィシャルFWの旧バージョン
UHD制限が緩い状態
LibreDriveは条件付きで有効
■ MK firmware
MKVファームラムの有志が最新の公式FWをカスタマイズしたもの
ドライブ制御をかなり書き換え、LibreDrive前提で設計されている
制限はほぼ無し
このようにMKファームウェアはMakeMKVでの利用を前提にカスタマイズされているため、汎用的に使用するのであれば、DEファームウェアを使用する方が無難か。書き換え操作自体もDVDFabのツールを使用した方が安全だ。

https://how-to-it.com/uhd-friendly-drive/
次に、ドライブの対応状況。
Pioneer以外のHLDS系のBDドライブとして、以下が手元にある。
・ASUS BW-16D1HT
・HLDS BH14NS58
・HLDS WH16NS58(計測用FW搭載)
・IODATA BRD-UT16WX(BH-14NS48)
中古で入手したBRD-UT16WX以外は全て内蔵ベアドライブだ。
DVDfabのドライブ対応状況は以下。

https://dvdfab.org/4k-uhd-drives.htm?af=fqywrSW849LJYBHp
公式ドライブとしては、HLDSのWH16NS60、BU40N、BU50Nと唯一の外付け、BuffaloのBRUHD-PU3が挙げられている。
これらは一つも手元にはなく、UHDフレンドリードライブとして、自分が保有しているドライブとしてはBW-16D1HTが掲載されている。
さらにフレンドリードライブ(おすすめ)として掲載されている中には、自分の持っている、BH14NS58とWH16NS58が存在する。
IODATA外付けの中のドライブ、BH-14NS48はリストのどこにも掲載されていない。
続いてMKVフォーラムでのレコメンド。

https://forum.makemkv.com/forum/viewtopic.php?f=16&t=19634
同サイトにUpされているファームウェアパックをダウンロードして、MKファームウェアのモデルを確認すると、ASUSのBW-16D1HT、HLDSのBH14NS58、WH16NS58は含まれていて、BH-14NS48のファームウェアは存在しない。
ちなみに、BH14NS58用のファームウェアのファイル名は、
HL-DT-ST-BD-RE_BH16NS58-1.02-NM01101-211901041359.bin
となっているので、BH16NS58用のもののようだが、BH16NS58用としては、
HL-DT-ST-BD-RE_BH16NS58-1.01-NM00500-211711161545.bin
という一つレビジョンの古いファームウェアがパックされている。
また、MakeMKVのForumでは、パイオニアのドライブもLibreDriveモードで動作するようになった、と書かれている。
これはFWの改造なしに、MakeMKV側で対応した、ということだろうか?
余談だが、Buffalo BRUHD-PU3-BKというUSB外付けスリムドライブが両方のリストにレコメンドドライブとして掲載されているが、現在は入手不可だ。
BuffaloのドライブだとBRXL-PTV6U3-BKBが現在入手可能だが、これはどちらのリストにも無い。

どちらのドライブもHLDS BU40Nを使用していると思われるが、使えないのだろうか?
MKVのフォーラムでは、Mac環境でBRXL-PTV6U3のFW更新が紆余曲折の上うまくいった・・という書き込みがあるので、SDFtoolなら書き換えができるのかもしれない。
BRXL-PTV6U3ではないが、BU40NのFW書き換えには殻割不要、とのブログもある。
https://milkchoco.info/archives/13024
ちなみに、SDFtoolを使用する際は、MakeMKVのインストールも必要だそうなので、注意が必要だ。
取り急ぎ手軽なところで、まずは中古のIODATAのドライブを使って、DVDfabでFW更新を試してみよう。
2年半前に購入したSONYのワイヤレスイヤホン、WF-1000XM5がイマイチだ。
購入当初からそうなのだが、渋谷や品川などの繁華街を歩いていると、ブチブチと激しく音が途切れる。
当時使っていたAppleやBeats、B&OなどのTWSでも多少は音切れはあったのだが、WF-1000XM5はそれらと比べて激しかった。
発売直後からそのようなレビューが多く、正直諦めていたのだが、翌春リリースされたファームウェアで大分改善されたとのレビューが紹介された。
https://av.watch.impress.co.jp/docs/review/minireview/1582789.html
しかし、自分環境はほとんど改善の効果が見られない。
その後Technicsのイヤホンを買ったり、AirPodsを買い増したりと、利用頻度が減っていたのであまり気にしなくなったのだが、少し前に、後継機のXM6を購入して再考するようになった。
XM6の音切れが凄く少ないのだ。
確かに、発売前後の開発者インタビューなどでも、アンテナを増やすなど、音切れ対策に苦心した、との話が掲載されていて、その効果なのだろう。
しかし、それに比べて、旧機種とは言え、XM5はあまりに酷くないか?
5chなどで書き込んでみても、それほど激しく音切れする人あまりいないよう、オマ環扱いされてしまう。
それなら・・と、3年の長期保証が切れる前に、SONYのサポートに問い合わせをしてみることにした。
まずは問い合わせ。公式のチャットによるサポートで問い合わせ。
初め、設定の確認、FWの確認、本体の初期化、など、色々指示をされ、試してみたが改善されず。
結局、本体の点検を勧められた。
それなら、と公式のサポートリンクから、修理の申し込みを行う。
修理は、認定修理店に持ち込むか、指定場所ピックアップのどちらかのようで、認定修理店が思った以上に少なく、近隣になかったのでピックアップでお願いすることにした。
指定日の指定時間帯に、佐川急便がピックアップに訪れる。回収用の箱も用意しており、本体を渡すだけ。
4/12にピックアップされ、何か連絡が来るのかな・・と待っていたが音沙汰がなく、気が付いたら1週間後にプチプチに包まれた(多分、ピックアップ時に入れてたプチプチ)現物が自宅に届いていた。
修理伝票もついていて、中を見ると、修理交換・最新FW更新、と書かれていて、価格は26,***円と記載されているが、最終的に長期保証対象で0円となっている。
26,***円ということは、本体交換なのだろうか?
中を見ると、充電ケースは使用感があり、元のままと思われる。
イヤホン本体も、元々傷もなかったので新品なのか修理なのかよく分からない。でも、分解して修理するとも思えないし、金額もそれなりなので交換なのだろうか?
このまま中古売却しようとも考えていたが、やはり改善効果があるか気になるところ。
1週間経過して、実際の街に付けた状態で繰り出してみた。
結果は・・改善効果有り。
渋谷や品川でも、これまでのように激しくブチブチ切れることはない。
AirPodsと同じくらいのような感じだ。これなら不満はない。
ということで、何で2年半もの間この状態で使い続けたのだ・・と多少の後悔の念はあるが、保証が切れる前に交換しておいて良かった・・とちょっと安堵するのだった。
その後、帰りの電車では、朝よりも少々音切れが増えたようだ。この日は早朝出社だったので、混雑が少なめだったのかもしれない。でもまあ、許容範囲内ではあるけど。
この日のセールで、通常2,950円のソースネクストのB's ディスクセーフが0円でダウンロードできるというので試してみる。
非ソースネクストユーザーなら警戒するが、既にB'sレコーダーを使用しているのでそんな必要もない。
インストールして起動。メディアをドライブに挿入すると、何故か認識してくれない。
原因は不明だが、この時偶然アップデートのために起動していたSAMSUNG Magicianを終了したら認識するようになった。
書き込み済みのBD-R SLメディアをチェックする。

特にエラーもなく、淡々と進捗と読み取りスピードでグラフ表示される。
あまり、意味のないチェック機能だ。これなら、フリーウェアのVSO Inspectorの方が良さげだ。
修復バックアップ機能はそのようなメディアが手近にないので試せていない。
BD-R DLメディアも試してみる。

ついでに、普段使った事のない、Opti Drive Speedもインストールしてみる。

旧Neroのソフトで、フリーウェアだ。ディスクの読み取りスピードを制限できるソフトだ。
ドライブのアクセス音がうるさい場合や、SHM-CDのような粉砕のリスクのあるディスクを再生するときに活用できる。
DVDビデオを挿入した状態で起動したが、MAXのx16から変更することができない。何故だろうか・・。

今一つ使い方が分からないまま終了となった。
BD-Rドライブが軒並み終売で、市場に暗雲が立ち込めている。
ストックのドライブは十分だが、このまま一生使い続けられるのか、一抹の不安も残る。
特に気になるのは、SONY/Panasonicが撤退した後のメディアの品質だ。
今現在、VerbatimのM-Disc BD-R XLを使用していて、30枚くらい使って焼きミスは一枚あったか、無かったか。
エラー率としては問題ないが、実際に焼き品質はどうなのか?
今現在市場に流通するSL/DLメディアも含めて、久々に品質チェックを行ってみる。


まずは、現行使用しているVerbatimのXL。
XLメディアを検証できるのはPlexUtilitiesだけなので、それを使用してチェックを行う。
ちなみに今現在はVictorブランドのパッケージの品を買っているが、メディアIDを見ても、Verbatimブランドと同じCMC製造だと分かる。
書き込みにはPioneer BDR-212を使用。

速度指定なしと、x2倍速で計測したが、x2指定の方が若干数値は悪くなってしまった。この辺りは誤差なのだろうか?


LDCはMAXで3000前後、BISはMAXで80前後と、一般的な数値から見ると非常に悪い。
ChatGPTに結果の画像を喰わせると、長期保存は危険、という厳しめの回答が返ってきた。
前回2023年に計測した結果と比べても良くないようだ。
ただし、その他のメディアでも厳しめの結果が出るので、値そのものの信憑性が疑わしいところがある。
同じ環境で相対的に評価するしかないのかもしれない。
続いて、BD-R DLメディア。こちらはOpti Drive Controlを使用する。今現在入手できるものは、製造元としてはCMCとRiTEKしか存在しない。
VerbatimはCMCの子会社なので、CMCのメディアを指定で入手するのは容易い。
一方でRiTEKは自社ブランドのRiDATAがあり、amazonなどでは入手可能だが、Verbatimと比べると少し入手性が悪いように思える。OEM先としてはBuffaloなどがあるようだが、確実か、と言われると保証はない。
で、そのVerbatimとRiDATAのDLメディアの検証結果。
書き込みはPioneer BDR-212と検証ドライブでもあるHLDS WH16NS58で行う。



結果、Verbatimの数値は非常に悪い。
Layer Breakの中間地点でのエラー率が非常に高い。
5インチ型とは別にHLDSとPioneerのOEMスリムドライブでも書き込みを行ってみたが、どちらもLayer Breakの場所でエラーが出て失敗に終わる。
RiDATAの方がずっと数値が良いが、HLDS WH16NS58では、7%書き込みでエラーで失敗してしまった。
どちらもあまり信用できないのかもしれない。
最後にVerbatimのSLメディア。こちらはHLDSのスリムドライブでも検証を行う。


結果は一般的な数値(ChatGPTやGeminiによる指標となる数値)よりは悪いが、DLやXLに比べたらずっと低い(最外周部まで書き込みしていないが)。ヒゲのようなエラーの突出もほとんどない。
やはり、安全・長期保存ならSL、と言う認識は間違いないようだ。しかし、25GBのSLメディアは使い勝手が圧倒的に悪い・・。
4種類のディスクをPioneerのBDR-212で書き込み、WH16NS58で計測した結果を比較したのが以下。
上から、バーベSL、RiDATA DL、バーベDL、Victor XLで、バーベDLの数値が突出して悪い。
Victor XLも良くはないが、3層はこんなものなのか。

ということで、BD-Rのバックアップ運用は、品質面においても疑問を感じてしまう結果となってしまった。
しかし代替はないし、困ったものだ・・。
Cloud GatewayとU7 Pro/UAC-Proのファームウェアが更新されたので、改めて更新の手順を確認して実践する。
Cloud GatewayはSSHを用いてローカルでファームウェアをアップロードして更新する。
はじめにSSH接続が有効になっていることを確認する。

・SSHでCGUへ接続
ssh root@192.168.1.250

・FWバージョンの確認
ubnt-device-info firmware

・binファイルをCGUへ転送(SSHログイン状態ではなく、PowerShellプロンプトから行う)
scp d:\a6aa-UDRULT-5.0.12-*******.bin root@192.168.1.250:/root/fw.bin

・FWアップデート実行(SSHログイン状態で実行)
ubnt-systool fwupdate /root/fw.bin

・更新の確認
ubnt-device-info firmware

以上の手順で、ファームウェアが4.4.9から5.0.12に更新できた。
続いてAPのファームウェア更新。
こちらは以前も実践しているが、念の為再確認。こちらはずっと簡単だ。
・UniFiのソフトウェアダウンロードページから対象のファームウェアを探す
・該当のファームウェアのダウンロードを右クリック→リンクのコピーを行う
・左ペインからUniFi Devicesを選択
・対象のAPを選択し、Settingsタブを開く
・タブを下にスクロールし、Manual Firmware Updateを選択

・先ほどリンクをペーストして、Updateを実行


U7 Pro XG、UAC Pro全てを最新ファームウェアに更新した。
サブPC用のNanoKVMの電源が入らなくなり、代品を手配した。
時間がようやく取れたので、入れ替えを行う。


microSDカードは、以前購入した個体はKIOXIAのカードだったが、今回の個体はDMと書かれた謎のブランド。
Aliexpressでは販売されているが、メーカーは不詳で、OEM向けの製品のようだ。


既存のNanoKVMを取り外し、元あった配線と同じように接続。
起動すると、OLEDパネルが点灯しNanoKVMのログイン画面にはアクセスできるが、サブPCそのものが起動しない。

POST画面で、
USB Device Over Current Status Detected !!
というメッセージが表示され、15秒後に強制シャットダウンする。

このメッセージで調べると、ASUSマザーで出るメッセージで、USB給電周りが問題の場合があるようだ。
問題箇所切り分けのため、接続を最低限にして試す。
結果、USBの内部配線を外すと起動することが分かった。
接続ケーブルのピンアサインを確認したが、ぱっと見問題なさそうだ。



仕方ないので、内部USB配線を止めて、USBケーブルを外回しにして試してみる。
が、それでも起動しない。
おかしいな・・とピンアサインを改めて確認していたら、問題点が判明した。
同梱のUSBフラットケーブルだが、コネクタに極性を示す三角マークが付いている。
片側の三角マークは反対側の三角マークと結線されている・・と普通に思っていたら誤りだった・・。
逆になっているのだ・・。片側の三角マークをプラス5Vに繋ぐと反対側の三角マークはグランドになる。

原因がわかれば対策は容易。USBは内部結線に戻し、極性マークには惑わされずに正しい向きでUSBケーブルを挿す。
そうしたところ、問題なくPCは起動し、KVM操作もWebブラウザから行うことができた。
何て人騒がせな・・。
余談だが、調子の悪かった1年前に買ったNanoKVM。取り外して直接USB給電も試してみたが、起動しない。
LEDの類が全く光らない。これは壊れている・・と考えるのが正しそうだ・・。時間を見てもう少し弄ってみようとは思うが。
余ったAC Proを電波の届き難い2Fのトイレに設置することにした。
当初、壁面に取り付けようと思ったが、壁が硬すぎてビスが打ち込めない。そのため天井取り付けに変更。


ベースプレートを木ねじで天井石膏ボードに固定して、LANケーブルを取り付けたAC Proを捻ってはめ込む。LANケーブルはPoEインジェクターに接続。給電だけを行う接続だ。
Cloud GatewayもYAMAHAルータの上にきちんと設置。ケーブルはCloud Gateway付属の極短ケーブルを使用した。

コントローラからきちんとAC Proが認識されるか・・と確認したら、Offlineになっている。

ChatGPTに聞くと、メッシュで接続する場合は、その個体を初期化して再度Adoptする必要があるようだ。
説明によると、LANケーブルを接続しない状態でリセットする必要があり、本体のWireless Uplinkを有効にする必要があるそうだ。
設定を確認すると、Wireless Uplinkという項目はないが、Meshは有効になっているので、恐らく問題ないだろう。

仕方なく一旦AC Proを天井から取り外して、今一度リセットする。
リセットすると、コントローラの画面にAC Proが表示され、そのままAdoptできるので、先に進める。Adoptingになり、うまくいくと思いきや、暫くすると再びオフラインに・・。

色々試行錯誤していると、各APの設定でParent APかClient APかの設定がある。LAN接続している2台のAPはParent APにして、今回のメッシュ接続するAPはClient APに設定する。
それでも当初うまくいかなかったのだが、何度か初期化、再Adoptを繰り返しているうちに、気がついたらきちんとOnlineになっていた・・。
何だったのか・・原因が分からないのが嫌だなぁ・・。

続けてメッシュ接続したAC ProのFWが少し古いので、コントローラのWeb UIからUpdateできるか確認してみる。残念ながら、うまくいかない。コントローラがInternetと通信できるだけではダメなのか?
仕方ないので、URLを直接入力して、ローカルでUpdateする。この方法なら問題ない。
最後に再びAC Proをトイレの天井に固定。念のためコントローラでの認識を確認するが問題無さそうだ。
ここまで長い道のりだったな・・。
U7がCGUに登録されたので、既設のAC Proを登録する。
その前に、SSIDの設定をCGU上で行う。
この作業も、旅行中の福井の電車移動中に行った。



UAP-PRO-5G、UAP-PRO-2G、UAP-HOME-2Gの従来のSSIDに加えて、UAP-PRO-6Gを追加で設定する。
その後、東京に戻り、居間のAC Proと2Fの仮接続中のAC Proをリセットピンで初期化して、CGUからAdoptする。
無事Adoptが完了して、3つのAPがリスト表示されるようになった。

早速、iPhoneを6GのSSIDに接続する。
続いてWindows用inSSIDerで電波状態を確認する。
6Gの電波が表示されなかったが、メニューから表示を切り替えることで、6G Onlyの電波状況を確認できた。
当初制限付き、という表示が付記されていたが、それも接続し直しなど色々試していたら解消された。


ちょっと調べると、Appleのサイトに

と記載されている。
そうなんだ。取り敢えず今はこのままにして、今後再検討か?
ただ、2.4Gも含めて一つのSSIDに変更するとなると、監視カメラなどの機器も全て設定変更する必要があり、相当面倒だ。
やるなら、5Gと6Gのみ統合か?
継続検討としたい。
マニュアル操作によるFW運用でも構わないが、やはりオートで更新された方が便利なので、強制的にデフォゲを既設ルータに向ける方法を探る。
Geminiに聞いてみると、以前同様sshで変更する手順が紹介される。
一度本体を初期化しているので、改めてCGUのSSHを有効にする。
ファームウェアを更新したためか、前回あったOS setingsというタブが見当たらない。
またまたGeminiに聞いて、どこにあるか調べる。
Control Panelページの中に隠れていた。


sshを有効にしてログイン。Geminiの提案に従って、ルーティングテーブルを確認して。

その後、デフォゲを削除するコマンドを打つが、エラーが返ってくる。

さらにGeminiに聞いて、WAN側接続がない状態でLAN側のデフォ結束を割り当てる方法を教えてもらう。

設定は出来たようで、8.8.8.8にpingを打つとレスポンスがある。
google.comにpingを打ってもかえってきて、名前解決も出来ているようだ。
Auto Updateがキチンと動作するかは新しいファームウェアがリリースされてからでないと確認できないが、設定は一応完了した。
この作業は、旅行中の福井の電車移動中に行った。
Cloud Gateway UltraのローカルFW更新手順をCopilotに聞く。今度機会があったら試してみよう。
以下は Ubiquiti Cloud Gateway Ultra(CGU)を、インターネットに出さずに SSH 経由でローカル FW(UniFi OS)をアップデートする標準的な手順です。
※UniFi Network アプリ経由ではなく CGU 本体(UniFi OS) の更新手順です。
【前提条件】
管理用PCから CGU への SSH 接続が可能
CGU の IPアドレス が分かっている
アップデートに使う UniFi OS 用 .bin ファイル を入手済み
(例:unifi-cloud-gateway-ultra-
SSH は通常 root ユーザーで実施
1. 現在の UniFi OS バージョン確認
ssh root@
ログイン後:
>> ubnt-device-info
または:
>> cat /etc/version
2. UniFi OS ファームウェアをローカルPCに準備
Ubiquiti公式のダウンロードページから CGU 対応の UniFi OS を取得します。
ファイル例:
unifi-cloud-gateway-ultra-3.2.7.bin
3. ファームウェアを CGU に転送(scp)
>> scp unifi-cloud-gateway-ultra-3.2.7.bin root@
※ /tmp はアップデート時によく使われます
4. SSHでCGUに再ログイン
>> ssh root@
5. ローカルファームウェアでアップデート実行
以下のコマンドを実行:
>> ubnt-upgrade /tmp/unifi-cloud-gateway-ultra-3.2.7.bin
実行時の挙動
自動で検証(checksum)
展開
書き込み
完了後 自動再起動
途中で SSH が切断されても 問題ありません。
6. 再起動後の確認(約3-5分後)
>> ssh root@
>> ubnt-device-info
期待するバージョンになっていれば成功です。
7. UniFi Network アプリ側の確認
ブラウザで:
https://
UniFi OS バージョン
Network アプリの状態
Adopted / Provisioned 状態
を確認してください。
いまだにCGUがU7をAdoptしてくれない。
ChatGPTとGeminiに解決策を聞くが、違う方法を紹介される。
一つはWAN側に既存ルーターを繋ぐ、所謂多段ルーターの構成。
もう一つはWANは繋がずにLAN側にだけ繋ぐ構成。
後者は当初からやっていてうまくいかないので、前者を試してみる。
確かに、WAN側がActiveでInternetに繋がってないと、アプリケーションやFWの最新版のダウンロードも出来ない訳だから、コントローラとして運用する場合制約が生じるな・・。
まずLAN側のIPを変更して、その後WAN側を宅内メインLANのIPに設定する。

だが、何故かWANからもLANからもCGUにアクセス出来なくなる。pingも返らない。
何か違うIPに変わってしまったのか?
仕方ないので本体リセットをする事にしたのだが、これが失敗。
リセット操作自体は背面のリセットホールにピンを挿し込みながら、電源を接続すれば良い。
失敗したのは、2代の既設APがAdoptされているまま設定ごと消してしまった事。
また今の壁付けのAPを外してリセットしなければならない。
余談だが、初期化して起動するとリカバリーモードと言う状態で立ち上がる。この状態でローカルでFWの更新ができたるので、折角なので適用する。


その後再度起動して、WAN側にローカルなLANを接続してどうなるか・・。

結果はダメだった。
AP一覧に何も表示されない。

余談だが、Network頁を参照すると、何故だかWAN側が、au one net、と表示されている。
よくよく考えると、ルーターのWAN側にAPを繋いでも、それがAdoptの対象になるとはちょっと思えない。
多段ルーター構成にしてWAN側とLAN側を別のネットワークにすればいけるような気もするが、今更アドレス体系を一新する気はさらさら無い。
ちなみにAIに聞くと、WAN未接続でのコントローラ運用はあまり推奨できないようで、Cloud keyかSWコントローラの使用を勧められる。
Windowsのコントローラを改めて起動してみるが、こちらもやはりAP一覧に何も表示されない。しかも、動作もモッサリだ。
CGUの構成に戻り、WAN接続は諦めて、LANのみ接続し、IPアドレスも元に戻す。
そして改めてCGUのWebコンソールにログイン・・。
すると、なんと、AP一覧にU7がAdopt待ちで表示されているではないか!
元の接続設定に戻しただけなのに何故認識されるようになったのかは、???。
だが、結果オーライ。すぐにAdoptする。

ついでにU7のファームウェア更新も行う。CGUのWAN側は未接続なので、自動更新は出来ない。
Auto Updateを無効にして、Ubiquiti公式のFirmware公開ページのURLをコピペしてLocal Updateのダイアログに貼り付けると更新が始まり、無事完了した!




ちょっと手間だが、アップデータやファームウェアはこの方法でマニュアル更新すれば運用できるかもしれない。
昨日、U7にSSHでアクセスして設定変更していたら、U7を初期化したり、Cloud Gatewayを再起動したりしたせいか、sshでログインができなくなってしまった・・。

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
という警告が出る。
Unifi Communityで検索したら、以下の解決策が紹介された。
https://blog.future.ad.jp/remote-host-identification-has-changed
以前記録したホストキーの情報と、今回接続しようとしているホストキーの情報が違う際に、警告として表示されるようだ。
今回の場合だと、known_hostsファイルの2行目に問題があります。という内容になる。
SSHクライアントに保持されている、known_hostsファイルを修正してあげれば良いようだ。
手っ取り早くやるなら、SSHクライアント端末のターミナルで、以下を実行すれば良い。

ssh-keygen -R 192.168.1.171(U7のアドレス)
実行後、無事にsshでアクセスできるようになった。

一方、Cloud GatewayでどうしてもAdoptできない問題だが、思い当たるとしたら、Cloud GatewayがInternetに出れる状態になっていないから・・だろうか?
本来Cloud Gatewayはルータなので、WAN側も設定しなければならないが、今回ルータとしては使用していないので、WAN側には何も接続していない。
Copilotに聞いてみると、sshでログインして、Gateway IPを変更する方法が紹介された。
sshでCloud Gatewayに接続しようとすると、拒否られる。
設定を見直すと、SSH周りの設定が二箇所あって、その内の一箇所が無効になっていた。

この設定は元々有効になっていた。



こちらは無効だったので、有効にしてパスワードを設定する。
有効にすると、sshでログインできるようになった。
ただ、Copilotから紹介された、デフォゲを削除して、新しいアドレスを設定しようとしたがうまくいかず。
しかしよくよく考えると、この方法はあまり宜しくないように思えたきた。
他の方法を試してみることにする。
昨日U7をセットアップしたが、HWコントローラのCloud GatewayがU7のAdopt候補リストに一向に上がってこない。
ChatGPTで調べると、
・DHCPのOption 43の設定でコントローラのIPを設定
・DNSでunifiをコントローラのIPになるように名前解決
・SSHでアクセスして、強制的にAdopt先を切り替える
等の解決案を紹介してくれた。
最近のAIは相変わらず凄いよな・・。
ということで、まずはDHCPのOption 43設定を試すことにした。
より接続の可能性を高めるために、自宅内ネットークからCloud GatewayとU7を切り離し、直結に近い環境で接続。
その上で、Cloud GatewayのDHCPサーバ機能を有効にして、Option 43として、自身のIP、192.168.1.250を設定した。

この状態で、Cloud GatewayもU7も再起動したが・・結果はNG。
続いて、SSHで強制的にAdopt先を変えるやり方。
まず、ターミナル(PowerShell)を起動する。
ssh ubnt@192.168.1.250
set-inform http://192.168.1.250:8080/inform
を設定する。

念のため、ターミナルでinfoコマンドを打って、inform設定が正しいことを確認。
この状態で試したが、やはりダメ。
理論的に、この状態なら完璧な筈なのに、なぜダメなのだろうか・・。
Unifi APのデフォルトのinformアドレスは、
http://unifi:8080/inform
となっている。
ChatGPTの解決案の1番目はunifiを192.168.1.250に名前解決する・・という内容で、その他の解決先とやっていることは同等だ。
この日は疲れてしまったので、ここから先は明日以降検討してみよう。
さあ、続いてはコントローラ側でのU7のAdoptだ。
ごく簡単な作業かと思ったが、ここで大きく躓く。
まず、MacのSWコントローラではU7が認識され、Click to Adoptボタンが表示される。

しかし、HWコントローラのcloud gatewayには一向に表示されない。
iOS用のアプリには一瞬、Pending Adoptionの表示とともにU7が出現するのだが、すぐに消えてしまう。
表示させた瞬間を狙ってU7の表示をタップするが、APに接続、と表示され、そのまま×ボタンしか押せない。
たまに、×ボタンを押した後次の画面が表示され、UniFiなしで設定、の画面に進める事があるが、この状態で進めて良いのか悩ましい。


もしまた本体のリセットをしなければならない状況に陥ったら、あの苦行のセキュリティホールへの結束バンド差し込みが待っている・・。
と言う事で一旦Mac上のSWコントローラでAdoptを進めると、これは問題なく完了する。
IPアドレスの変更もできる。
と言うことはU7本体に問題は無さそうだ。


その後、一旦初期化、再度Adoptなども試したが状況は改善しない。

Mac用SWコントローラを落とした状態(Macそのものをシャットダウン)で数時間放置して再トライしたが、やはりダメだ。
と言う事でこの日は一旦作業を中止する事にした。
いよいよU7 Pro XGの天井取り付けに取り掛かる。
まずは、取り外し済みのAC Proを移行期間中動作できるように、PoEインジェクターで動作するようにする。

ちなみに、メッシュ機能を利用して、この取り外したAPも別の場所に取り付けし、運用することを検討する。
使用するPoEインジェクターは元々AC Proに付属していたもの。最近の機種には同梱されていないようだ。
PoEインジェクターを介して電源とLANを接続すると、AC Proが起動して、機能するようになった。これで移行の準備は整った。
まずはLANケーブルの交換。あらかじめ購入してあったUbiquiti純正のCAT6Aケーブルを使用。凄く細身でしなやかで、編み構造なので扱いしやすい。モールを外しつつ、このケーブルに取り替える。2mで丁度良い感じだ。


続いてU7 Pro XGの取り付け用のベース金具を天井に取り付ける。

いくつかの補助金具もあったが、天井ボード裏やスタットに取り付けるもので、自分の場合は使用できない。
直接、ベース金具を木ねじで石膏ボードに固定することにした。


U7の取り付け前に、LANポートとリセットボタンの位置を確認。AC Prpにはあったカスケード接続用のLANポートは無い。


抜け落ち防止のため、少し多めに木ねじを打ち込み、金具の固定は完了。
ここで痛恨のミス。本体の取り付けを急ぎ、LANケーブルを繋げないまま固定してしまった。

失敗に気づいたが、既に本体はロックされていて、取り外すにはセキュリティスロットに結束バンドを差し入れるしかない。
しかしこのU7、セキュリティスロットが天井取り付けした状態だと位置を判別するのが難しい。
AC Proは外装カバーの縁にあって分かりやすかったが、U7は背面が内側に階段状に絞り込まれていて、その一番奥にセキュリティスロットがある。
結束バンドの先端をこの孔に挿入するのは至難の技だ。なんでこんな構造に改悪したのだろうか?


30分くらい試行錯誤して、ようやくロックを外すことができ、何とか本体を外す事ができた。
今後の参考に、背面から、結束バンドの先をセキュリティスロットに差し込んだ状態で写真を撮っておく。

そして、LANケーブルの先端をはめ込み、再び天井金具に固定する。


LANケーブルのもう片端をPoEハブに差し込み、U7が起動する。


白いLEDがゆっくり明滅する。
次は設定だ。
U7への移行の一環で、いよいよ居間のアクセスポイントにメスを入れる。
このAP Proも、以前のMac用コントローラに登録されていて、新しいコントローラと紐づけるにはハードウェアリセットが必要となる。
前回、自室のAPを取り外した実績があるので、作業は簡単。結束バンドの端をセキュリティスロットに差し込み、本体を回して外す。
電源が入っている状態で、LANポート脇のリセット用孔にピンを挿し込み、数秒押し続けると初期化される。


Cloud GatewayのWeb管理画面を開くと、Adopt待ちのAPが表示される。

Adoptを選択して、居間のAP Proを登録。その後、IPアドレスの設定、Wireless Networkの登録を行う。


そして家庭用のVLAN201を設定して、そのVLANに家庭用Wireless Networkを紐付け登録する。


設定後、Wi-Fi Explorerで電波状態を確認するが、謎の状態に。
5GのSSIDが、2.4GHzで表示される。
うーん・・Wi-Fi Explorerがおかしいのか?
続きは翌日に持ち越すことにする。
cloud gateway ultraが思ったより早く、1/8に到着した。
金曜日の夜に早速セットアップ。




まずは開梱。Appleライクだが少しチープな、Ankerのようなパッケージだ。同梱物はUSB-CのACアダプタとLAKケーブル。
2.5GのWANと1GのLANが4つ並ぶ。

事前に情報を仕入れると、cloud gatewayはBluetoothでセットアップができるという。
電源を入れてiPhoneでUniFiのアプリを起動すると、確かに認識してした。


タップして接続、を選択して接続。
ルータなので通常はWAN側をONUなどに接続して設定をするようなのだが、今回はルータ機能は使用しないので、オフラインでのセットアップを選択する。



デバイスの名前はデフォルトのまま進める。
ローカル管理資格情報、という画面が表示されるが、日本語も微妙におかしくて、どうしたら良いか分からない。

取り敢えず、下に表示されるパスワード要件を全てクリアするパスワードを入力して、設定を進める。


セットアップは完了したようだが、最後の画面の日本語がやはり理解できない。

その後、iOSアプリのデバイス一覧からcloud gatewayを選択するが、ユーザー名とパスワードの認証画面が表示される。
ユーザー名は何も設定してないので、???だ。UniFiのアカウントや、admin+先程設定した複雑なパスワード、Webで調べたUniFiデバイスの一般的なアカウントである、ubnt/ubntとか、色々試すがダメ。
先程のセットアップ完了画面では、

UCGUltraをオフラインで設定することを選択しました。管理するには、コンソールと同じローカルネットワークに接続されたデスクトップでunifi/を開く必要があります。
と書かれているので、LAN側ポートをハブに繋いでPCからWebブラウザでアクセスしてみる事にする。
ただ、割り当てられてるIPアドレスが分からない。
DHCPサーバからリースされてるアドレスなのかな・・と調べるが、cloud gatewayのMACアドレスが見つからない。
Webで調べると初期IPは192.168.1.1とあるが、これはどドメインコントローラとダダ被りだ。
ハブ接続は止めて、サブPCと直結して、ブラウザアクセスしてみた。
そうしたところ、アクセスできた!

ログイン画面にはパスワードの入力箇所しかないので、初期セットアップで設定したパスワードを入れてみると、ログインできた!

取り敢えずIPアドレスを他と被らないものに変えようと、と設定箇所を探すが、何だか凄く分かりづらい。
何とか探し出して、192.168.1.250に設定して、Applyボタンを押して変更ができた。

上部のNetworkアイコンをクリック
左ペインの歯車アイコン(Settings)
その右列のNetworkをクリック
Name=Defaultをクリック
Host Addressを修正する
Apply Changesをクリック
ハブに接続して、ようやく家庭内ドメインネットワーク上で他の端末からアクセスできるようになった。
今日は遅くなったので、ここまで。
2か月ほど前から、趣味で撮影に使っているE10MK2が20分ほどで録画停止するようになった。
購入した直後のテストでは40分ほどランニングしても問題なかった。撮影設定はその頃から変えておらず、4K@60p、100Mbpsのままだ。
以前テストしたのは夏場で、1年以上経過して、冬に差し掛かってから発生・・。腑に落ちない。
設定を見直しても特に問題なく、動作テストではやはり、20分ちょいで停止する。
新しいFWがリリースされていたので、それに更新してみても変化はなかった。
Webで検索しても5chで質問しても有益な情報は無く、仕方なくSONYのサポートに連絡。
翌日にはメールで返信が来て、
1.自動電源OFF温度が高になっているか
2.液晶パネルを横に展開して撮影
3.USB給電している場合は9V/3AのPD機器を使用
4.Wi-Fi機能をOFFにする
5.SDカードをフルフォーマットする
6.他のSDカードを使用する
を試して欲しいとの内容だった。
結構しっかりしたレスでびっくりした。
1-4は実施済みなので、5を試してみる。
フルフォーマットについては気になっていたのだが、本体でできることは知らなかった。
フルフォーマット後のメディアを使用して録画してみたが、結果は25分ほどで停止。若干改善したようにも思えるが、ほとんど変わらない。
6の別のSDカード・・も、年末にNAND高騰の状況を踏まえてLexarの少しスペックの高いカードを購入しているので、試すこともできる。
ただ、熱に起因しているような気がするので、カメラ購入時に準備して、不要なのでお蔵入りしていたクーリングファンを試してみることにした。



Ulanziのクーリングファンは未開封のままで、開けてみると小型でバッテリー内蔵、スプリングで固定する仕組みで、E10にもフィットする。

装着による傷とかも付きそうもないし、脱落も心配ない。
気になるのはファンの風切り音で、まあまあ静かなので大丈夫そうではあるが、マイクで拾わないか少し心配だ。
装着した状態でランニングテストしてみたら、40分は余裕で録画継続できたので、ここでテスト終了とした。
これだけ保てば、クーリングファンのバッテリーも含めて、一回の撮影は乗り切れそうだ。
今週末にでも実戦投入してみる。
Windows用のinSSIDerを久々に使う。
自分のアカウントでサインインしたら、以前の購入ライセンスでインストールできた。
何故かMac用のWi-Fi Explorerと2.4G帯の電波の反応が違っている。
また、Wi-Fi Explorerもそうだったのだけど、2FのAPのSSIDの表記に、[HIDDEN]と書かれている。

これは何故なんだ?と調べたら、Mesh機能がonになってるためのようだ。FWを上げたらMesh対応になって、デフォルトがonのようだ。

Mac用コントローラの設定ミスが発覚。
リセットして追加したAC Proの管理画面を見ると、接続しているクライアントが、家庭用のVLANに紐づけたSSIDにしかぶら下がっていない。
5GのSSIDには何も繋がっていない。
調べると凡ミスで、SSIDの記述を間違えていた。UAPのところ、UACにしていた。
これで5GのSSIDに手持ちのiPhoneが接続するようになったが、もう一つおかしな点が。
Mac用のサーベイアプリ、Wi-Fi Explorerで、登録したAC Proの5G帯の電波が表示されない。
色々試して、AC Proのチャンネルを手動設定で低い周波数帯に移動したら表示された。

Wi-Fi Explorerを動作させているMac Studioが高い周波数帯の5Gに対応してないのか?
そんな事はないと思うのだが・・。
後日、Windows用のinSSIDerも用いて、もう少し調べてみよう。
Uniquiti Cloud Gateway Ultra 18,800円@Ubiquitiストア

U7 Pro XGをセットアップするために、一旦見送っていたCloud Gatewayを発注。
SW型のコントローラは、やはり長期運用には向かない。うっかり環境をクリアしてシステム更新する事もあるので・・。
Cloud Gatewayははっきり言ってUTM機能付きのルーターなので、コントローラ用途で買うのは勿体無いのだが、現状これが一番安いのだから、致し方無い。
購入したのはUltraで、これでもWAN側は2.5Gbpsのスペックだ。
上位機種のMax(Apple製品とMaxとUltraの上下関係が逆なのでややこしい・・)はLAN側4ポートも全て2.5G。さらに上位のFiberは、WAN側がSFP+の2ポートと、10GBase-Tも備えている。

ただ、前者は35,900円、後者は50,300円と少々お高い。
それでもYAMAHAのルータなどと比べたら破格だが。
昨今のメモリ高騰で、これらの製品も何らかのDRAMは載っているだろうから、値上げの可能性も高い。
今このタイミングで注文したのは吉だったと思いたい。
翌日になり、改めてWindows環境でのControllerのセットアップに再トライしてみることにする。
Wslがセットアップされると、エクスプローラのLinuxドライブの下にUbuntuという共有が出現するようだが、空だ。
セットアップが上手くいっていないことは間違いない。
前回のwslのインストールのエラーメッセージに、解決のヒントがあった。
BIOSで仮想化を有効化にするように書かれていて、コマンドも記載されている。
Webでも調べると、Windows環境での入れ子の仮想化設定方法が紹介されている。
Get-VM | Get-VMProcessor | Select-Object VMName, ExposeVirtualizationExtensions
仮想基盤上でこのコマンドを打つと、現在のVMの仮想化設定が確認できる。
デフォルトはFalseとなっている。

Set-VMProcessor -VMName unifi_server -ExposeVirtualizationExtensions $true
このコマンドで指定したVMの仮想化を有効にする。

Linux-Ubuntu共有にも、ファイルが格納された。

仮想化を有効にした後、UniFi Controllerを立ち上げたら、ようやくエラーなく起動するようになった。
ただ、起動に結構時間を要する。

また、起動後にUniFiデバイスを検索するも、何も見つからない。

VM上からAC ProのIPアドレスにpingを打つと返ってくるので、ネットワーク設定は間違ってないと思う。
UniFi Controller上でUniFiサーバのアドレスを確認すると、ループバックアドレスになっているのが気になるが、原因不明。

リセットしたAC Proも、リセット前のAC Proもどちらも表示されない。
試行錯誤も面倒なので、HWのコントローラを買おうかな・・やっぱり。
夜になり、改めてUniFiをどうしようか思案する。
ハードウェアのコントローラを購入しようか・・と心が傾いているが、取り敢えず取り外したUAP-AC Proのリセットを行うことにした。
まず、以前インストールしたMacのControllerを起動する。
こちらは難なく動作する。
ただ、既存のAC Proは古いMac環境で登録されていて、リセットしないと新しいMac環境では登録できない。

Mac用コントローラの画面指示に従い、まずは取り外したAC Proのリセットを行う。
スマホのSIMを外す際に使用するリセットピンを側面のリセット孔に挿しこみ、数秒押し続ける。
AC ProのLEDが点滅を開始し、リセット動作が始まったようだ。

暫くすると、Mac用コントローラに新しいUniFiデバイスが表示される。

IPアドレスはDHCPサーバからリースれたものになっている。どうも、設定は全てクリアされたようだ。

仕方ないので、一からセットアップを行う。
IPアドレスを固定設定して、2.4Gと5GのWLAN設定を新規作成する。

さらに、家庭用VLAN201を追加設定して、家庭用2.4GのWLAN設定をVLAN201と紐付けて作成する。



これで取り敢えず、取り外したAC Proも使えるようになった。
さて、この先どうしようか・・。
昨年購入して、そのまま放置していたUbiquitiのWi-Fi7アクセスポイントをそろそろ設置しよう・・と重い腰を上げる。
まずは既設のAPの取り外しと、リセット操作だ。
古いMacのUniFi Controllerでアクティベーションしているので、リセットが必要になる。
既設は同じUbiquitiのUAP-AC Proで、取り外し方法をWebで確認する。

固定用のラッチがあって、これをペーパークリップで押し下げた状態で本体を回転させる必要があるようだ。
ペーパークリップが見当たらなかったので、代用品として結束バンドを使用。
ラッチの位置をマニュアルで確認して挿入。上下に振るとラッチが外れた感触が伝わる。

その状態で本体に回転すると、簡単に外す事ができた。
ちょっと残念だったのは、筐体全体が加水分解を起こしていてベトベトで、汚れや埃が付いてしまった点。
APの表面をラバー加工する必要なんてないのに、余計だよな・・高級感出したかったのか?
新規購入したU7 Pro XGがどうなのかも気になるところだ。

続いて、UniFi Controllerのセットアップだ。少し前のBFセールでHWタイプの管理アプライアンスが安かったので購入を検討したが、結局、無駄なコストは掛けず、ソフトウェアのコントローラをVMで構築する事にした。
VM自体はセットアップ済みなので、管理サーバのソフトウェアインストールから始める。

しかし、ここで問題発生。
インストール後、UniFi OS Serverを起動すると、コマンドプロンプトで、

続行するには、Linux用Windowsサブシステムを最新バージョンに更新する必要があります。
とメッセージが表示される。
どうも、Windows用のUniFi Controllerは、Windowsネイティブで動作するのではなく、Windows Subsystem for Linuxという、Windows上のLinux環境で動作するようだ。
メッセージの通り、
Wsl.exe ―update
を実行する。

Linux用Windowsサブシステムは正常にインストールされたようだが、今一度UniFi OS Serverを起動すると、
Application Initialization Failedの警告が表示される。

Linux用Windowsサブシステムが本当にインストールされているか、役割と機能の追加で確認すると、確かにチェックマークが付いている。

Webで調べた情報をもとに、手動で、
Wsl ―install
を実行すると、ubuntuがダウンロードされて、インストールされる。
しかし、

WSL2は現在のマシン構成ではサポートされていません。
のメッセージが表示されて、動作しない。
最新のWindows Subsystem for Linux、WSL2は、Windows上で仮想マシンを構築すいて、その上でUbuntuをインストールして動作させるもののようだ。
今試しているWindows Server環境はそもそもVMなので、VMにVMをさらに構築できるのか?という疑問が生じる。
よく分からないので、一旦ここで止めることにする。
記録・歴史
常時接続の日々
Designed by CDS
Copyright © tc-engine.com / TOKYO CLUB / 頭狂倶楽部. All Rights Reserved.