今年もハムフェア 2018

今年も暑い中で行ってきました。

最近外国のハムクラブの展示が年々増えているように感じます。今回特に買いたくなるものも無かったけど、SDR的なものが円熟期に入ったような気がしました。なぜかCW関係が元気です。
　昨年留守番が一人だけで閑散としていたPRUGのブースには今年は数名の方が詰めてあって、AX.25を拡張したFX.25のプロトタイプTNCを作っているみたいなポスターと実物らしき物が展示してありました。X.25由来のAX.25は元々品質の良い回線を相手にしているので１ビットでもエラーがあるとフレームを捨ててしまいます。そこで回線品質が悪いと途端にリトライが始まり、特に回線遅延が大きい場合に疎通が極端に悪くなるんですが、FX.25では衛星通信で使うような Forward Error Correction（前方誤り訂正）をやるのでそれが改善されるようです。またAX.25を内包していて、AX.25でも通信できます。今後の成り行きをフォローしたいものです。
　CQ出版のブースで再免許の書類を買ってきましたが、電波法のスプリアスの規定が変更になりH34年でJARLの補償が無効になるような記載が・・・。

やってくれますMicrosoft

　仕事で60台ほどのPCを管理しているが、Windows10 1803 の8月定期更新（KB4343909）を適用してから動きが変わった。
　多くのPCを管理するため1台のPCでバッチファイルを組み、その中でPsExec.exeを使って他のPCで遠隔コマンドを実行させているが、やってみると7月までうまく行っていたのに、今月はエラーメッセージのオンパレードだ。

　Make sure that the default admin$ share is enabled on xxxxx.
  xxxxx:
　Could't access xxxxx:
  ネットワークパスが見つかりません。

ときた。default admin$ shareって何だ？　
　ネットで検索するとnet share コマンドで確認できるらしいが、実物を見ても問題は無さそう(というかビールスの感染ルートなので用が無ければ塞ぐべきか)。そのほかUACだ何だと出るが、書いてあることを試しても効果が無い。そこでネットワークパスに着目した。要するに「ネット上でPCが見つからない」って事だろう。すでに動いていたカラクリなのでユーザとしては名前以外は手の出しようがない。Windowsのコンピュータ名は大文字と小文字を区別しない仕様だった筈なので、これまでこの違いを放置していた。
　試しにコンピュータ名を正確に打ち直してみると状況が変わった。エラーにはなるがPCにはアクセスできている。要するにPCの名前の大文字と小文字を（勝手に）区別するようになってPCの名前が解決できなくなったようだ。そこで大文字小文字を合わせてアクセスできるようにした。
　しかし、今度はログインを拒否される。 PsExecのパラメータで指定したユーザ名/パスワードが受け入れてもらえないようだ。試しに、ローカルアカウントであることを表すためにユーザ名の頭に付けている「.\」を外してみた。すると何事も無かったように動くようになった。

　これらを踏まえると、8月15日の更新でコンピュータ名やユーザ名に関する扱いが変わってるようだ。これが意図されたものかバグかは分からないが影響は相当なものだと考えられる。クラッカー対策かもしれないが、我々みたいに他に困っている人は大勢いると思うのだが。
　まあ PsExecなんて普通の人は使わないか。

LT-R6のカラクリ（その１）

　最後にLT-R6を公開してから数年が過ぎた。その間にいくつかのバグレポートをいただき、修正も済んでいるがリリースする気になれないまま月日が経った。時間が経つと、それに見合った機能追加をしないと格好がつかない、と考えたまま今日に至っている。アイデアはあるが気力が続かない。

　そんなこともあり、とりあえずここでLT-R6についてこれまで書かなかった中身を少し公開しよう。CI-Vは1本の線を共用して双方向の通信を行うため、CI-V上を流れる個々のデータからはそれが何かは判別できない。通信の内容を解析するには先ずCI-Vの調歩同期信号を受信・UARTで再生し（ここまではクローニングケーブルの仕事）、その後バイト単位で受信したデータからフレーム（以下、CI-Vの基本フォーマットのプリアンブル (0xFE)からEOM (0xFD)までをこう表現する）を再構成し、その中身を解析することで誰が何の目的で送信したフレームかを判別する。このときIC-R6とLT-R6の双方がランダムにデータを送信することで起きる信号の衝突や、衝突を検出した場合に送出される連続したJammer(0xFC)、及びその後のフレームの再送に対応した処理を行う必要がある。実際にCI-VをモニターしているとJammerはよく見られる。
　フレームの再構成にはステートマシンを使う。LT-R6には3つのステートマシンを内蔵している。通信用、メモリーデータ受信用、及びCI-Vプロトコル解析用だ。通信用は通常のLT-R6の動作に使う。この場合正常にフレームを受信した時だけ結果を上位ソフトに上げればよいが、ただし自分が送信したデータをモニターし、もし潰れていた時は衝突が起きているのでJammerを送出してアボート（中断）処理を行い双方の状態を整合させるようにしている。メモリーデータ受信用も同様だが制御に使うコードが違う。通信用、メモリーデータ受信用は送信部との連携がある分だけややこしい。
　一方プロトコル解析用はCI-Vの全てのデータを抜けなくキャプチャーするのみで単純である。解析用ステートマシンの状態遷移表を抜き出すと次のようになっている（作者独自の書式）。

     * STATE MACHINE
     *  State        OUTFR        SYNC        INFR         ABT
     *   /Input(event)
     *  SYN(FE)     +/SYNC         +/SYNC    x]+/SYNC    x]+/SYNC
     *  EOM(FD)     +/OUTFR      x]+/OUTFR   +]]/OUTFR   x]+/OUTFR 
     *  JAM(FC)   x]+/ABT        x]+/ABT     x]+/ABT       +/ABT   
     *  ELSE        +/OUTFR        +/INFR      +/INFR    x]+/OUTFR   
     *  TM-OUT     x]/OUTFR       x]/OUTFR    x]/OUTFR    x]/OUTFR
     * 
     *  SYMBOLS:
     *   -: abandon data
     *   +: accept data
     *   ]]: complete with success
     *   x]: complete with error

　 ステートマシンは状態を持ち、通信に伴って発生するイベントに対しアクション/次の状態を記述する。 OUTFR,SYNC,INFR,ABTが状態であり、SYN,EOM,JAM,ELSE,TM-OUTがイベントである。例えばフレーム受信中(INFR)にフレーム開始(SYN)を受信すると、受信は異常終了し（x]）データ(SYN)は取り込み(+)、次の状態をプリアンブル部(SYNC)とする。
　TM-OUTはフレーム受信中の一定時間内にフレームが完結しない場合の処理である。

　 ステートマシンは通信ライブラリから渡されるCI-V受信データを処理する。通信ライブラリはCI-Vデータを受信するとそれを受信バッファに積み、次にデータが入ったというイベントを発生する。このイベントを受けてスレッド（イベントディスパッチングスレッド）が実行され、その中でステートマシンを実行することになる（少し専門的ですがご勘弁）。スレッドを実行中に通信ライブラリは次のデータを受信する可能性があり、1バイト受信する度にイベントが発生する訳ではない事を含めてロジックを組む必要がる。リアルタイム処理ではここら辺りがややこしくていまだに理解不十分な点があるかもしれないが結果オーライで実装している。

　リアルタイム処理のデバッグは処理を止めて解析できないので厄介である。とくに以前ci-vの受信に使っていたrxtxライブラリーには受信したデータがライブラリーの中に詰まるような現象を起こす問題があり、それを発見し対処するのには長期間を要した。現在のjSSCライブラリーに変えてからはこれまでそのような問題はない。

続く