zoomがどんどん遅くなる?

長時間のzoomセミナーをしているとネットワークが遅くなって回線品質が低下とか表示されるようになってしまうという話がありました。しかし別のPCではそんなに遅い気はしないし、該当のPCを再起動すると直るという。
RTX830、フレッツ光v6プラス、IPoE、MAP-Eの環境。

調査しながら適当にネットサーフィンしていたら、途中で名前解決に時間がかかりはじめたところで思いつく。
MAP-EによるIPv4 over IPv6は複数の接続元からIPv4を共有する都合上、利用できるポートが限られています。これが足りてない感じかも。
状況は
# show nat descriptor address
で確認。

RTX830は、TCPに関してはポートセービングIPマスカレードという動作でセッションを詰め込めているのですが、UDPは1ポート占有してしまう上に、タイムアウトが900秒になっているとのこと。あとTCPはセッション終了が明示的だけどUDPは放置なのでタイムアウトまで待ちっぱなしが続く。

とりあえずこれを300秒に設定してみました。これで様子見。60秒でも良かったかもしれないが、VoIP関連だと150秒欲しいみたいな話もあったので、とりあえず。
# nat descriptor timer 1 protocol=udp 300

sshに入れなくなった?鍵ファイルの最後の改行

しばらくぶりにsshで繋ごうとしたら入れないサーバーがあるというので見てみました。
認証はRSAまたはED25519の鍵ファイル。
windows10上のpowershellからsshで試します。
私の鍵では入れたが、たしかにその人(useraaaとします)の鍵では入れない。

サーバー上でuseraaaがssh localhostとすると、入れる。鍵ペアとauthorized_keysは問題なさそう。
で、ググってみたら

ssh – Windows 10 OpenSSH key invalid format – Stack Overflow
>I got this working.. believe it or not by adding a single LF at the end of your private key file.

秘密鍵ファイルの最後に改行を足せと。
ええーそんなばかなーと思って足したら、通ったよ…

サーバー側 OpenSSH_8.7p1, OpenSSL 3.0.1
クライアント側 OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
でした。
クライアント側FileZilla 3.62.2(Windows)の場合は改行なくても通りました。
Windowsのsshと特定の組み合わせの問題なのか?

古いサーバーにsshで繋げられない(ssh-dssを今さら使う)

古いLinuxサーバー(CentOS4か5か)がLAN内にあって、そちらにsshアクセスしようとしましたが、ssh鍵がdsaって書いてある。
最近windowsからのsshはpowershellから起動して使うようになりまして(便利になったね!)。

とりあえず
ssh -i id_dsa IP_ADDRESS
としてみましたが
sign_and_send_pubkey: no mutual signature supported
とエラーでアクセスできず。

一時的にssh-dssを許可しないといけないので
ssh -i id_dsa -o ‘PubkeyAcceptedKeyTypes +ssh-dss’ IP_ADDRESS
これで使うことができました。

古いサーバーはリプレースしていかないとね…

中古車サンバー、冬タイヤ、オイル漏れ、オーバーヒート

相変わらず乗っていた中古車サンバーですが、エンジンオイルの交換をお願いしたところ、「どこかオイルが漏れているね?」と言われました。コンクリート地で見えやすいところにしばらく停めていたら、確かに。

サンバーのエンジンは後ろのバンパーのところにありますからね。
その後ディーラーで冬タイヤを付けてもらいながら見てもらったところ、確かに漏れていると。ただし原因が直接わからないので、少しずつ見ないといけないので、いずれまた見ましょうということに。

冬になって雪が積もるとこんな感じに。ルーフキャリアの雪下ろしが手間ですね。
スタッドレスはヤフオクで未使用品ホイール付きを買いました。ホイールを安く買うのが目的だったので、タイヤはあんまり期待してない。
それにしてもRRのサンバーは凍結路面で緊張の連続です。フリフリ。

そんな中、雪で見えない段差を踏んでしまい、ちょっとショックが入った翌日、水温計が異常に上がってしまいました。数秒で元に戻ったりしたんですが、こりゃおかしい。

サンバーにはクーラントのリザーブタンクがあって、そこをのぞき込んでみると、カラッカラ。

ペットボトルの頭を切って逆さまにして漏斗にして入れてみます。2Lまるまる入りました。

これでちょっと走ってみましたが、あいかわらず水温計は瞬間上昇したりして不安定。
寒い時期だから助かってるだけで、本当はダメかもしれません。
ということでディーラーに修理依頼。
クーラントを運ぶパイプが折れて漏れていたそうです。
段差を踏んだぐらいでそこまでいくか?とも思いましたが、元々老朽化してたらそんなもんだろうという気もします。
部品取り寄せで2週間ほど預けました。

無事に仕上がりまして、再び乗ることができるようになりましたが、オイル漏れの原因究明のために来月また預ける予約をしました。
webで色々見ていると、オイル漏れはサンバーの持病みたいなものらしく、いろんな方が対策をしている様子が読めますが、私はそこまで自分で手を出せないので、ディーラーにお願いしました。
なにはともあれ快調に走れるようになってほしい…

英語配列キーボードの右AltをIME起動キーにする

Windows PCにHappy Hacking Keyboard (HHKB Professional)を合わせて使っておりますが、全角/半角キーの無いUS配列なのでIMEの起動切替がAlt+`という知らないと想像もできない組み合わせ。HHKBだとバッククォートが右上なので余計に面倒な感じに。

これに対し、USキーボード愛好の日本人には割とお馴染みの方法としてキーボードドライバをAXキーボードにするという方法があります。AXって何ですの?と言われると、DOS/VだとかIBM PC/AT互換機だのという歴史を紐解くことに…。私も昔はNECのPC-9801や9821、EPSONの国民機(互換機)ユーザーでしたから、スペースバーの右にXFERがあってそれで変換とかしていたわけです。こうなるとIMEじゃなくて日本語入力FEPね。(話がそれた)

ということでスペースの右のキー、右AltキーがIMEの起動キーになることはとても相性が良いわけです。
このAXキーボード指定のやり方、検索すると同じ方法を掲載しているサイトがたくさんあるのですが、私が最も参照していた@ITの「Windowsで右Altキーに[漢字]キーを割り当てる方法(AXキーボード設定を利用する方法)」というページが最近隠れて出てこなくなったので、自分のサイトにも残しておこうというわけで記します。

レジストリエディタで HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters を開いて下記の値を編集。

LayerDriver JPNREG_SZkbdax2.dll
OverrideKeyboardIdentifierREG_SZAX_105KEY
OverrideKeyboardSubtypeREG_DWORD1
OverrideKeyboardTypeREG_DWORD7

一応Windowsシステムkbdax2.dllが存在するかチェックしてからやれということになっていますが、無かったことがないので気にしてません。もしかすると非x86のARM版とかには存在しない可能性も?(見たことないので知りません)
また過去にはOverrideKeyboardSubtypeかOverrideKeyboardTypeのキーが見つからなかったことがあるので(Windows2000だったかな…)そのときはキーを作成して値を設定しました。

これで再起動すると右Altだった部分がAXキーボードの「漢字」キーになっており、IMEの切り替えができるようになります。

ちなみにHHKBは最下段が「Alt、◇、スペース、◇、Alt」という並びになっていますが、私はディップスイッチの切り替えでAltと◇を入れ替えてあり、実際にWindows上では「Win、Alt、スペース、漢字、Win」として機能します。
ここにされにキーマップの変更を行い、右Winをアプリメニューキーとして割り当てておけば、Windowsでは困ることはないかと思います。実際私が便利に使っている。

キーマップの変更は未だにChange Key(ChgKey)というフリーソフトで行っていますが、配布形態が.lzhなので、Windows10だとそのままでは開けません。なので7-zipもインストールするという、一通りの環境整備の流れになっております。

設定後は再起動して反映を確認します。