PATHpilotのブログ

NTT ONU+ホームゲートウエイ一体型ボックスの初期化について備忘録。

このボックスの管理WEBの操作が必要になったがパスワードが不明。最終手段として初期化を行った。

1. 電源を切る（ACアダプターコネクタを本体から抜く）
2. 初期化ボタン（初期化と書かれた小さな穴）にセムクリップ等のピンを挿入しスイッチを押す
3. 初期化ボタンを押したまま電源を入れる（ACアダプターコネクターを本体に差し込む）
4. 本体の初期化インジケーターがオレンジ色に点灯するまで初期化ボタンを押したままにする（10秒以上かかった。気長に待つ）
5. 初期化インジケーターがオレンジ色に点灯したら初期化ボタン穴からピンを抜く

以上で初期化が完了。管理WEBには初期ユーザー名（user）と初期パスワード（user）でログオンが出来る。パスワード変更を求められるが初期パスワードのuserを入力しても受け付けられる。

初期化によって接続設定のユーザー名とパスワードの再設定等が必要になるが、それは仕方ない。。。。

以上

ECHOLINKのLINKノードがDTMFで9999を受信すると、自動でECHOTESTサーバーに接続する。知らなかったというか、WIRES-XからDTMFで9999が送られてきて（送ってきた局がいる）ECHOLINKがECHOTESTに接続してしまったので驚いた。

実際のECHOLINKのDTMFのドキュメントでもそう書いてある。

Examples

(These examples assume that the default DTMF codes are configured.)

• To connect to node number 9999:

Enter:  9 9 9 9

EchoLink responds with:

"CONNECTING TO CONFERENCE E-C-H-O-T-E-S-T"

followed by

"CONNECTED"

because 9999 is the node number of conference server "*ECHOTEST*".

つまりDefaultではそうなってるみたい。でも、このDefault設定を変える方法が見つからなかった。

一旦接続すると接続したままになってしまう（TIMEOUTはあるのかも）ので要注意だ。

友人からWindows11にログオン出来なくなったという救援依頼が来た。

友人曰く、ログオンするときにいつもパスワード”1234”を入力するけれどもパスワードエラーになるということだ。実機のノートパソコンを持ってきてもらって自分でやってみてもその通りだ。パスワードが違うって怒られる。

いろいろ悩んだ。何回か間違ったパスワードを打ち込むとパスワードロックされましたって表示されて、暫く（10分程？）ログオンが禁止されちゃうし。でも、ちょっと待てよ、、、パスワードが4桁数字って変じゃないか？？これって本当はPINなんじゃないのか？？

つまり、PINが無効になっちゃってパスワードを要求してるんだけれど、普段パスワードを使ってないから記憶に無いってパターンじゃないのかなぁ。なぜPINが無効になったかは不明だけれど。

で、いろいろ調べて見て役に立つ情報にめぐりあった。でも、それなりに怖い作業なので、自分なりに解釈して実行してみた。

まずはShiftキーを押しながら再起動を実行する。トラブルシューティングが起動する。詳細オプションに入ってコマンドプロンプトを実行する。但し、機種によっては詳細オプションの中にコマンドプロンプトが出てこない場合があるみたい（別のWindows11マシーンでやってみたらコマンドプロンプトが出なかった。なぜ？？）。

で、コマンドプロンプトでの作業になる。

①　大抵はWindows 11はCドライブに入ってるはず。以下でファイルが見つかるはず。

dir c:\windows\system32\utilman.exe 

②　パスが正しい事を確認してから以下を実行する。まずutilman.exeをcmd.exeで上書きするのでバックアップを取っておく（後で戻すから）。

copy c:\windows\system32\utilman.exe c:\windows\system32\utilman.exe.bak

③　utilman.exeをcmd.exeで上書きする。

copy c:\sindows\system32\cmd.exe c:\windows\system32\utilman.exe　　
上書き確認は勇気を出して「はい」を実行する。

なんでこんな事をするかというと、ログイン画面の右下に表れる人形アイコンをクリックしたときの動作を変えるためのようだ。この人形をクリックすると通常はutilman.exeが実行されるようだけれど、それはコマンドプロンプトをメニューに含んでいないみたい。これをcmd.exeに変えてやる（cmd.exeをutilman.exeにスワップする）とメニューにコマンドプロンプトを含むようになる。つまり、このメニューは動的に設定されるみたいで、utilman.exeが実行できる内容で変化するみたい。見方を変えれば、utilman.exeはcmd.exeのサブセットみたいなもので、cmd.exeの機能を制限したものだと判断できる。この制限を取っ払う作業を上でしたわけだね、きっと。

ちなみに、この後人形アイコンから入るコマンドプロンプトで実行するnet userコマンドは、上記のトラブルシューティングのコマンドプロンプトでは実行できない（エラーになる）。だからコマンドプロンプトの渡り歩きみたいなことをしないといけないのだね。

④　スタートアップ画面が表示されたら人形アイコンをクリックしてコマンドプロンプトを表示して、以下を実行する。

net user "username" password

もちろんusernameは実際に使うユーザー名、passwordも実際に使うパスワード。このコマンドでusernameのパスワードを設定し直すわけだ。実行したらコマンドプロンプト画面を閉じて、ログオン画面で今セットしたパスワードをセットする。なお、このnet userコマンドは現在のパスワードを聞いてくることなしに、新しいパスワードが設定できる。ちょっと（かなり）ヤバいコマンドだ。

じゃじゃーん！でログオンが出来る。

⑤　ログオンができたらutilman.exeを元に戻しておく。元に戻すと人形アイコンをクリックしてもコマンドプロンプトは選択肢には入らなくなる。それ以外にどういう影響があるかは不明。案外もどさなくてもいいのかもね。

copy c:\windows\system32\utilman.exe.bak c:\windows\system32\utilman.exe

⑥　この後、スタートメニュー -> 設定 -> アカウント -> サインインオプション -> PIN でPINを設定する。この時インターネット接続してないとPIN設定が出来なかったけど、そういう物だったっけ？？？でも、一旦PIN設定するとインターネット接続はとくに関係ない感じでPINが使えるけどね。。。

この後再起動するとログイン画面でPIN入力が求められるようになる。更にPIN入力の下にサインインオプションが現れて、パスワードとPINのどちらを使うか選択ができるようになる。

めでたし、めでたし。

しかし、、、、こんなことが出来ちゃまずいんじゃないかなぁ、セキュリティ的に、と思ったりもする。この方法に助けられて言うのもなんだけど。。。。

HRI-200を使ったWIRESのノード局をFTM-100で構成した場合の留意点備忘録。

FTM-100のノード局（仮にJA0XYZとする）がWIRESのPC画面の「接続局ID表示」で変な挙動をする。VoIPでルームにWIRES参加している他局（仮にJH0CDEとする）が送信中はJH0CDEがグリーンアイコンで接続局ID表示に表示される。送信が終わればこのグリーンアイコンは消える。しかし、JA0XYZ局が参加している場合、JA0XYZの操作とは無関係にJH0CDE局のグリーンアイコン消滅後に一瞬（1秒未満）JA0XYZ局のグリーンアイコンが表示され消滅する。

VoIPでルームに接続しているJH0CDE局が送信中はJA0XYZ局のFTM-100は設定された周波数で送信状態になっている。つまり、VoIPで送られてきたJH0CDEの音声をJA0XYZはFTM-100で中継しているわけだ。JH0CDEの送信が終わればこのFTM-100は受信状態になる。どうもこの時にスケルチが一瞬開いてしまうような感じだ。

実は類似の減少がEchoLinkとFTM-100との間でも発生していた。詳細はこちらを参照のこと。

FTM-100はDATA SQUELCHを供えている。これはデータ信号送出中のスケルチを制御するものだ。DATA SQUELCH にてTX:ONだとData送出中はスケルチをONにする。TX:OFFだとスケルチ制御をしない。どうやら、TX:ONだとData送出後にスケルチオンからオフになるときに信号が入ってきていないのにスケルチが開いてしまうようだ。

HRI-200はスケルチが開くとPTTをオンにする。入力信号をWIRESに送り出すにはこのスケルチ信号が頼りなので当然なのだけれど、上記不安定状態でもPTTがオンになるようだ。

FTM-100のSETUPメニューから　9. DATA -> 3. DATA SQUELCH -> 2. TX:OFF を設定すると、Data送出時にスケルチ制御をしなくなるので、結果としてこの不安定状態が発生しなくなる。

めでたし、めでたし。

幾つかあるブログの中で特に「クロール済み - インデックス未登録」の件数が多いブログがある。

なんでだろう？？って思って調べてみた。

幾つかのネット情報によると、どうやらインデックスするに値しないと判断されたようだ。

特に気になっているブログの状況はこんな感じになっている。一旦インデックスる登録されたページも未登録にされているようだ。

全体の85パーセント程度が未登録で、そのほとんどが「クロール済み - インデックス未登録」だ。

つまり、クロールしてページは認識したけれどインデックス登録しなかったってことだ。そしてその数は増えている。

一方、ここのブログの状況はこんな感じになっている。

明らかに差がある。ここのブログもインデックス未登録数の絶対数は大きいけれどおよそ全体の25％程度だ。

これら二つのブログの違いは、ブログスタイルの違いと考察した。前者のブログは写真多様で説明文が少ない。写真や動画で伝える事を意図しているので文章も出来るだけ軽量にしている。一方、後者のこのブログは解説や備忘録を目的としているので文章を充実させたいと思いながら書いている。クローラーが文章内容を解釈しているかは不明（特定単語やその出現頻度はみてる？）だけれど、それなりの重量感をもった文章を書けばインデックス登録される可能性が高くなる印象を持った。

以前からGoogle検索でヒットさせたいページは「しっかり書きましょう」ってアドバイスを頂くことが多いが、ブログのスタイルからもその意味がわかる（ような気がする）。

しかしこれはブログのスタイルの問題なので、まっいいか、って事なんだろうと思うけれど、各ブログ項目はさておきブログのメインページには訪れてもらいたいと思いえば、それなりのメリハリのあるブログ構成作りが必要なんだろうなぁって思う。

Sharp AQUOSをTP-Link Archer AX23Vでインターネット接続した際、ちょっと手間取ったのでその備忘録。

TP-Link Archer AX23Vを現在使っているルーター（NTTホームゲートウエイ XG-100NE）にケーブル接続して、AQUOS 4KTVJ22-2からTP-Link経由でインターネットアクセスする構成にした。

AQUOSからYouTubeやAmazon Primeがアクセスできることを確認したが、どうもネットアクセスが一部おかしい。NHK地上波デジタルのデータ放送で、レーダー拡大[ネット]をクリックしてもタイムアウトとなり、インターネットに接続してないとのエラーメッセージが出た。

ひとつ気になっていたことはTP-Linkのルーターを箱から出してそのまま使っていたこと。出荷状態だとルーターモードになっているんだろうなぁって思いながら、とりあえずそのままでインターネットアクセスできるから「ま、いいか」で使っていた。やはりブリッジモード（アクセスポイントモード）にしないといけないんだろうか。

ということで、マニュアルに従ってTetherというスマホアプリをダウンロードした。

起動するとアカウント登録から始まる。有効なメールアドレスをユーザーIDとする。このメールアドレスにアカウント・アクティベーションリンクが送られてくる。

その後ルーター管理者パスワードを設定してから、インターネット接続タイプの選択になる。DefaultでIPV6が選ばれたいた。ホームゲートウエイはIPV6接続なのでそのように設定した。なのでプロバイダー情報は聞いてこない（IPV6はMACアドレスで管理されているからPPPoEで必要となる接続先設定は不要）。設定が一通り終わると、ルーターは再起動される。この再起動でTP-LinkにWifi接続していたデバイスはそれ以外のWifiアクセスポイントに接続しなおしてしまうので、再起動後にスマホもTP-Linkに再接続する必要がある。

この後スマホからTetherに再ログインする。画面下のメニューからツールを選び、動作モードをクリックする。

動作モードでアクセスポイントモードを選ぶ（下の写真はセットが完了した後に開いた画面）。

これでアクセスポイントモード（ブリッジモード）に変更ができた。

で、早速NHK地上波デジタルのデータ放送からレーダー拡大をクリックすると速攻でレーダー画像が出てきた。

やっぱりルーターにカスケードで接続するルーターはブリッジモードじゃないとダメなのね。

Niftyからドメイン@niftyサービス終了のメールが2月7日に来た。このブログのドメイン pathpilot.jpが残すところわずか一ヵ月足らずで使用停止になる。

実はこのメールは2回目だった。1回目は12月13日に届いていたが、読み飛ばしていた（自分のミス）。だが、こんな重要な事、メール一発で済ませてしまうのはちょっと厳しいんじゃないかなぁ。

2月7日に届いたメールには以下が書かれている。

　　【重要】ドメイン@nifty終了に伴うドメイン移管お手続きのお願い

いつも＠nifty（アット・ニフティ）をご利用いただき誠にありがとうございます。
昨年よりご案内しております通り、2005年より提供してまいりました
「ドメイン@nifty」を2024年3月をもって終了することとなりました。

ご利用中のお客様には大変お手数をお掛けしますが、終了日までにお持ちの
ドメイン名を、他社ドメイン管理事業者に移管のお手続きをお願いいたします。
　

ドメイン@niftyサービス終了日：2024年3月
※詳細な日付についてはホームページに掲載いたします。

...中略...

 ＜重要＞
・ドメイン名の移管手続き完了後は、ネームサーバーを必ず変更してください。
　PDNS1.NIFTY.AD.JPなど、ドメイン@niftyで提供していたネームサーバーは切断され
　利用できなくなります。

おいおいどうするんだ、というかどうしたらいいんだ？？？

ガイドされたWebページを読むと移管先を自分で決めて移管先に移管申請をしろ、ってことだ。移管先を自分で決めろって言われても困っちゃうよね。自分はたまたまムームードメインにドメインを幾つか持っているのでそこで移管手続きが出来るが、ドメイン@niftyでしかドメインを持っていなければ業者探しから始めることになる。これはかなりハードルが高いと思う。

ムームードメインへの引っ越しに先立って、ドメイン@niftyに自分のドメインのAuthCodeを申請しないといけない。この申請はWhois情報公開代行サービスを使っていると却下されるとの事だ。そこでガイドに従ってnifty上で自分のドメインのWhois情報公開代行サービス利用を停止した。ちなみに情報公開代行サービスを使用しないと、自分のプライベート情報が公開されることになる。

AuthCode申請を7日16時20分に行ったら翌8日9時02分にメールで届いた。しかし、ここに至るには大きな問題があった。それはドメイン登録者番号をドメイン@niftyが公開していないことだ。7日夕方にniftyにメールで自分のドメインの登録者番号の取得方法を問い合わせたが8日中には届いていない。nifty自身はQ＆Aで以下を掲載しているのに。。。おたくもドメイン管理事業者でしょうが。。。
（追記:2月14日14時14分に@niftyカスタマサポートデスクから返事が届いた。既に他社にドメイン管理を移しているからそちらに問い合わせるように、との内容だった。自分はムームードメインのサービスを使って登録者番号の取得が出来たが、そうでない移管が制限される。改善を強く望むところ）

APRSISCE/32のScrollerのウインドウが左上隅にコンパクトにまとめられてしまった。これをスクリーン上下幅まで拡大させた時の備忘録。

APRSISCE/32をインストールした直後はScrollerウインドウはスクリーン上下幅まで拡大されていたけど、ある日なぜだか左上隅にコンパクトにまとめられてしまった。Scrollerとは受信したステーションのパケットを表示するウインドウで、見ていて楽しい。自分の場合はIGate/Digipeteaterも表示するようにしている。楽しいのでScrollerウインドウサイズを元にもどしたい。

コンパクトになってしまったScrollerウインドウ：

APRSISCE/32はオプションが沢山あって、どこをどう設定すれば良いかなかなかわからなかった。いろいろ放浪した結果、以下をつきとめた。設定前はAutoになっていたけれど、これをNarrowにしたらScrollerが大きくなった。まとめると、Configure -> Screen -> Orientation -> Narrow 。方法が分かっても、これでScrollerが大きくなるのが納得いかない（直感的にたどり着かない）。

Scrollerウインドウサイズを元にもどす方法：

ちなみにIGate/Digipeater表示を加えるにはConfiguration -> Scrollerで設定する。

ScrollerにIGate/Digipeater表示を加える方法：

やっぱり、APRSっておもしろい。

NEC WiFiルーター WX4200D5でWIRES-X HRI-200ノード構成が出来なかった件の備忘録というか疑問の記録

Aterm WG1800経由で構成済み・運用中のWIRES-Xノード（HRI-200の先にはYaesuモービル機、430帯でノード運用中）のWG1800をWX4200D5に取り換えたが、運用できなかった。

WIRES-XアプリはHRI-200に接続されているモービルトランシーバーの受信信号を確認し、自分自身のノードアイコンを緑色（ノードからルームへの送信）にするが、音声データをルームに送出しない（ルームが音声データを受信しない）。

手順

1. 変更前、ノードPCはHRI-200経由でモービルトランシーバー（430MHz帯）に接続しており、ハンディ―トランシーバーからそのモービルトランシーバから電波を送ることで、ノードPC経由でルーム接続している。今回はWiFiルーターの入れ替えなのでノードPC、HRI-200、モービルトランシーバの接続は一切触っていない。
2. 使用中のWG1800をWX4200D5に置き換える。
3. 光ケーブル収容のネットワークモデムもリセットする。
4. WX4200D5にて、ノードPC上のDHCPでのインターネット接続を確認。
5. PC上のIPアドレス(192.168.10.10)等を固定IPに変更。
6. PC上で上記固定アドレスでインターネットアクセスできることを確認（Chromeでインターネット上のWebをアクセス）。
7. WX4200D5のWebコンソールにて、上記固定IPアドレスに対してWIRES-Xのポートを開放する（ポートマッピング）。
8. WIRES-Xアプリでポートチェックを実行し、全てがOKとなることを確認。
9. WIRES-Xアプリでいつも接続しているルームに接続
10. ルームに接続されている他のノードからの音声は、上記モービルトランシーバから電波として送信されハンディ―トランシーバーで受信できることを確認。つまりこのノードPCはルームからの音声を受信することができる。
11. 上記ハンディ―トランシーバーからモービルトランシーバーに送信した場合、ルームに音声が送られない。つまりノードPCからルームに音声が届かない。ただし、このノードは緑色アイコンとして表示される。つまり、モービルトランシーバーはハンディートランシーバーの信号を受信し、ルームに対して送信操作をするのだが、音声がルームに送られない。ハンディ―トランシーバーから音声を送っている間、ノードPCのサウンド画面ではHRI-200 A（CH1）Audio Codecのレベルは変動するので、音声はPCに入ってきている。そもそも、PC周りはWiFiルーター以外は取り換えていないし、PC上の設定も変わっていなので、音声がPCに入ってくるのは当然だと思う
12. ノードPCを再起動しても状況は変わらない。
13. この状態でWX4200D5をWG1800に戻すと、WIRES-Xアプリ上の表示（緑色）の仕方は同じでルームに対して音声が送られる。つまり、この現象はWX4200D5についてまわっている。

まとめると、WG1800をWX4200D5に入れ替えるだけで（ポート開放設定済み）、音声のみがルームに対して送られなくなるのだ。

これは一体どういうことだろう。。。

そもそもトランシーバーの受信信号をWIRES-Xアプリがルームに送出するには、スケルチが開いて音声データが入力される必要がある。しかし、スケルチさえ開けば音声は無変調でも送り出されるはずだ。つまりこの場合、スケルチは自ノードから送信PTTとして働くわけだ。それで音声データがルームに送られないというのは音声データパケットがルームに届かないということか。

アプリで受信したデジタル音声をデコードする作業を考えてみると、まずはデータバッファにある程度データが溜まってからDMAでデコーダーに送るんだと思う。音声が出てこないということはデータバッファにデータが溜まらないってことだ。

ポート開放と関係があるのか？送信はノードPCからデータを送り出す方向だからポート開放とは逆方向。そもそもポート開放（ポートマッピング）はインターネットから自IPアドレス/ポートに送られてきたパケットをポートマッピングしたPCにリレーする手段だ。だからポート開放とは無関係だろう。WX4200D5にすると、音声データパケットが送りだせないのか？？？

うぅ～ん、わからん。

Lenovo Mini Towerのスリープ状態でACラインをOFFした場合の状態とリモートアクセスについて備忘録

Case-1

1. スリープ状態に入る
2. 電源スイッチランプはブリンクする（スリープ状態を表示）
3. マウス操作
4. 覚醒せず
5. キーボード操作
6. 覚醒

Case-2

1. スリープ状態に入る
2. 電源スイッチランプはブリンクする
3. ACラインオフ
4. ACラインオン
5. 電源スイッチランプは消えたまま、ブリンクしない
6. キーボード操作
7. 覚醒せず
8. 電源スイッチ操作
9. 起動
10. スリープした時の状態に戻る。PORでのクリーンスタートアップとは違う。

Case-3

1. スリープ状態に入る
2. 電源スイッチはブリンクする
3. リモートアクセス（Google Remote Desktop）
4. リモートアクセスはタイムアウト、ネット通信できない
5. キーボード操作
6. 覚醒

まとめ

リモートアクセスする場合も想定する場合は、絶対にスリープしてはいけない。物理的に電源スイッチの操作、または物理的に接続されたキーボード操作しないと覚醒できなくなる。