Wifi中継機の呪い

わが家では,Wi-Fiルーターの置き場所の制約のため,一部の部屋では,電波が十分な強さで届きません.そこで今回、Wi-Fi中継器を買って,改善できるものか,試してみました.しかし結果は惨憺たるものでした.

昔アマチュア無線のパケット通信で,同じ周波数を使った中継でうまくいった例はなかったので,今回も100%の期待はしていませんでした.

せめて,ないよりマシ位ならよかったんですが,ないほうがマシと言う状況になってしまいました.

適切なネットにうまくつながってくれるどころか,不適切なネットに繋がることが頻発した上,中継器と上流のWi-Fiルーターの接続がしばしば途切れるので,本来中継器がなくても十分接続できた場所でも,通信速度の低下や,切断が頻発しました.

設定をいろいろ変えたり,置き場所もいろいろ替えましたが,一番良いと思われる状態でも,中継器がないときより総合的によくならないどころ,悪化しました.

ということで,一週間ほどで,中継器の使用は止めることにしました.

やめても,1台のAndroidスマホは,これまでつながっていたネットにつながらなくなってしまいました.呪いまで残してくれました😓

これはアマチュア無線のバケット通信の,NET-ROMという中継機能でしばしば経験しました.
距離や環境的には十分な信号強度で通信しているはずなのに.

Google GroupsのWeb UI

グーグルグループ(Google Groups以下 “GG” )のWeb UIを使っている人ってたぶんほとんどいないと思われますが,MLのメールが全部メールアドレスに届くのもうっとうしいので,せっかくWeb UIがあるGGで運営されているMLについては,メールを受け取らず,Web UIで見に行くことにしています.

確かひとつだけ参加している米YahooのMLも同様の設定にしています.ほんの少しだけ関心があるのに,メールがやたらと来るMLに参加するのに適したやり方だと思っています.

ようするに,普通のMLの参加方法としては,MLの運営側からメールアドレスにプッシュされるのですが,こちらが見たいときだけプルで参加するということです.

プルなので,緊急連絡があっても,自分で見に行かなければ気がつきませんので,そういう連絡があるMLについてはしない方がいい参加方法です.

たぶん,GGの参加者のうちでもWeb UIのみ利用という人はほんの数パーセントと思います.

長らくそんなに使い良いとも悪いとも言えないUIでしたが,最近大幅に切り替わりました.

全般として良い悪いはともかく,大きな欠点というか,欠陥があります.それは,ホームページに該当する”My Groups”に表示される参加MLリストに,新規投稿数が表示されなくなったことです.

このため,参加している各MLをいちいちのぞいてみないといけないのです.

さすがにこの欠陥は重大なので,多くのユーザーからフィードバックがあると思うので,次のリリースで改善されることを期待しています.

仮想マシンの使い道

そう言えば,現在個人で管理している公開サーバーはRaspberry Pi 4 Model Bで動いていますが,Raspberry Pi (以下 “RPi”)にする前はIntel Core i7のデスクトップ機で動かしていました.

切り替えるときに旧サーバーのハードディスクをイメージ化して残しておきました(qcow2型式).当初このイメージからブートできるように設定していたと思います.

まあ,他の人のなんの役に立つわけではありませんが,自分で昔に書いた文章がときどき自分で必要になることがあります.たいていは,MacのSpotlightや,RPiのサーバーでlocateコマンドを実行することで,ワークステーション内やサーバー内に探し出せることが多いですが,今回のは見つからず,The Wayback Machineを久しぶりにアクセスしてみました.

その文章に該当する記事の目次のページはあったんですが,The Wayback Machineが,PukiWikiのサイトのクロールをちゃんとできていなくて,残念ながら記事本文はサルベージできませんでした.

それで思いついたのは,Core i7のサーバーに残っている可能性です.仮想マシンを起動してみましたが,起動はしませんでした.ここで気がついたのは,仮想マシンを起動しなくても,ディスクイメージをマウントすれば,データにアクセスできるということです.

たぶん,旧サーバーのディスクイメージを仮想マシン用にとっておいたのも,仮想マシンとして動かすよりも,データのサルベージ用だったんじゃないかと,自分の過去の思いを推測しています😓

さいわいなことに,qcow2をマウントしたら,目的の文章があっさり見つかりました.

Debianの仮想マシンを破壊

現在,メインのWSであるMac mini,唯一のノートであるMacbook,サブのWSであるSlackwareの動くデスクトップ,それぞれに仮想環境があり,それぞれにDebianがインストールしてあります.

なぜDebianかというと,Ubuntuみたいに独自性に突っ走ることのないオーソドックスなLinux distroであり,デスクトップがSlackwareと共通で気に入っているKDEであるからです.

で,何に使ってるのといわれると,特に具体的な用途はないんです😓 まあ,Slackwareに自力でGNU Radioをインストールするのに疲れたので,パッケージングソフトで簡単にGNU Radioをインストール&アップトゥデートできるということが唯一の具体的な用途かも知れません.

しかし,GNU Radioに対する関心もかなり低下して,GNU Radioで何をやるのと言われると明確に回答できません😓 逆に明確な目標・目的がないからこそ3つもの仮想マシンを維持しているわけです.

その,3つの無駄にディスク容量を食う仮想マシンのうち,一番実用性が高いと思われるSlackware下のKVMで動かしているDebianを壊してしまいました.

どのように壊してしまったかというと,よく思い出せないのです.いつもと違う古いKernelで,Slackwareを起動してしまい,その状態でディスクエラーが出る(なぜ?)のに,仮想マシンを起動してしまったような気がします.しかし,Kernelのバージョンが古いから問題だったのか,このWS自体久しぶりに起動し,ハードウェアに何か不具合が生じていた為なのか,その辺り解りません.

たしかなことは,当該の仮想マシンであるDebianを起動しても正常に起動せず,ブート時にfsckをマニュアルでかけろとメッセージが出て止まってしまうようになったことです.そのインストラクション通りにfsckをかけてから再起動したらログイン画面は出るようになったのですが,そこでパスワードを入れても,またログイン画面に戻ってしまいます.Xか何か肝心なところが壊れているのかも知れません.

どのように直そうか迷いましたが,結局,昔,「別所」のWSで動かしていたDebianの仮想マシンをコピーして済ませました.古いけど,Debian 9 (Buster)なので,update & upgradeで最新の状態にできました.

今回は,upgradeした状態のスナップショットをとっておきました.仮想マシンはバックアップをとらないので,安定した状況のスナップショットをひとつ残しておくのは重要ですね.

さて,復活したDebianで何をしますかね😓

logデータの突き合わせプログラムを書けという自分への指令(5・終)

ログの原簿であるLog200のデータにある交信レコードをup-to-dateにしているメインのデータベースであるMariaDB (MySQLコンパチブル)のデータと照合して,MariaDBに欠落しているレコードがないか,を確認するプロジェクトですが,照合スクリプトの最終形が吐き出したエラー分について手で確認をしました.

MariaDBとの照合は,日付,時刻(±5分のマージン)とコールサインで検索しました.参考の為に,モードの違いについても,検索してヒットしたレコードと原簿のレコードについて照合して,違う場合はwarningとしました.

原簿にある7万9千レコード全部について照合するのに,190分ほどかかりました.そのうちほとんどがMariaDBが占めていて,PerlのCPU占有は30秒余りです.

その結果,モードの違いまでも含めると,540ありました.検索条件が違うので(4)の293件より多くなっています.

このうちwarning扱いのモードの違いをのぞいたエラーは,128件で,手作業で照合しました.

ほとんどが,コールサインの間違いです.もらったQSLカードで修正したものがほとんどです.また,時刻の違いも何件かありました.時刻は,PCの時計データを取り込むようにしていますが,そのPCが仮想マシンのため,仮想マシンが再起動した直後に時刻データが不正確であった可能性があります(これは仮想マシンの特定のバージョンにより含まれているバグです).可能性は低いとはいえ,自分が間違っている可能性もあり,間違っているのは自分か相手か断定できません.しかし,もらったQSLカードに返信の形で発行するQSLカードは相手の時刻に合わせた方が無難なので,ほとんどのケースで相手に合わせて修正してます

完全な漏れは,先に判明したUR2FEO局の2交信分の他は,8N2SEA/2局との1交信のみでした.いずれも追加済です.思っていたよりうんと少ないレベルなので,安心しました.

これで,少なくとも原簿であるLog200に記録されている交信は全てメインの交信データベースにあるという状態にできました.

ただし,多くはない思いますが,原簿に漏れている交信もあるはずです.それらについてはどうしようもないです.QSLカードが届いて,該当する交信レコードがないときはこっそり追加するしかありません😓

ただし,あり得ない時間や明らかにJST/UTCの計算違いの場合は,こちらの時間にしています.