広告ブロック機能を使っている閲覧者には読めない記事を送信するアンチ広告ブロック

チラシおことわり
©いらすとや.

この記事は、嫌儲の方(自身の行為によりアカの他人が1円でも利益を得ることが許せない方)には到底納得できないであろう内容となっています。別のページまたは他所のサイトに移動されることをオススメします。

ウェブの広告は、「がとらぼ」の中の人が閲覧者であれば「まぁ見たくないけどどうでもいい。」程度。しつこく同じのが表示されたりセクシャルな画像だったり健康関係の広告の不快な画像、全ページ広告とかは「できれば見たくはない」そんな感じ。広告内容云々以前にハラの立つ行儀の悪い表示の広告もある。
でも、ウェブサイトを作って提供し続けるとなると、サーバのイニシャルコスト+月々の維持費さらにコンテンツを作るコストも。これが1ヶ月に1000円,2000円程度であれば全部自腹でも良いけど、維持費だけでも毎月万単位だといくら趣味でも全額自腹はツラい。たとえ微々たる額でも広告収入があれば助かるというか広告収入がないとやっていけないというもの。
そうなると、コンテンツを提供する側としては広告を見ることすら拒否してタダ読みをされるというのは困る。(コンテンツの有益性を棚上げしてスミマセン)
そこで広告ブロックアプリや広告をブロックするブラウザ拡張機能を使用している閲覧者にはコンテンツを表示しない、或いはもう少しソフトに「警告」を表示するという手段を講じることが必要になる(かもしれない)。

まぁ本来なら、「もしもこの糞下僕の拙い駄文でお目汚ししましたら誠に申し訳ございません。こんなコンテンツでも僅かでもお役に立てましたら恐悦至極に存じます。」という気持ちは持ち続けたいところではあるけど、現実にはそれどころじゃない。

閲覧者には「広告を見ない権利」はあるけどコンテンツ提供側にも「タダ読みを防ぐ権利」があると。

アンチ広告ブロックの記事とサンプル

↑のリストの最後の2つが新しく作ってみたもの。その内の上側「文字コードシフト式アンチ広告ブロック」はウェブサイト側は特に何かすることはなくて簡単なJavascriptを出力するだけ。閲覧者のブラウザでJavascriptが実行され、広告ブロックを判定して(広告ブロックしているなら)コンテンツの文字(漢字)を正常なものではなくす(読めなくする)というもの。「がとらぼ」でも7月末〜8月頭まで1週間ほど実際に試してみた。特に問題はなかったようだが、サーバからブラウザに正しいコンテンツを送信してブラウザ上で読めなくするというものなのでHTMLソースを読むなりJavascriptを無効にするなりコンテンツを異常にする処理を壊すなりすれば全く問題なく読めてしまうという問題がある。つまり「毒にも薬にもならない」程度の効果しかない。

「逆・文字コードシフト式アンチ広告ブロック」がこの記事の本題。これは、ウェブサイト側で「文字をずらす」という処理を施して送信し、閲覧者のブラウザ側で「広告ブロックが無効」ならJavascriptで(逆に文字をずらして)正しいコンテンツを表示するというもの。これはJavascriptを正常に実行しなければ正しく読めないので「広告すら表示しないでタダ読みする閲覧者の為すがままを許さない」というウェブサイト提供者側には一定の満足感が出るもの。
ただし、これを採用したからといって、閲覧者が「広告ブロック機能を無効にして正常にコンテンツを読もうとする」とか「広告をクリックしてくれるようになる」かというとそれは不明。むしろ最近は理不尽な人が増えてるので反感を買うことがあるかも

ここで言う「文字をずらす」(シフトする)というのは文字コード表で文字○個(指定分)プラス或いはマイナスした文字を表示するというもの。例えばアルファベットで「マイナス1シフト」するとB→Aのようにアルファベットの1つ前の文字になるのでIBMはHALになる。「プラス1シフト」するとB→CのようになるのでIBMはJCNになる。ひらがなだと「マイナス1シフト」すると「い」→「あ」のようになるし「プラス1シフト」すると「い」→「う」になる。漢字なども同様にシフトさせると別の文字になる。
なお、このページのサンプルではUTF-8で漢字の最初の「亜」という文字以降のコードポイントをシフトさせるようにしているので半角英数字や「かな」「カナ」などは文字が変わらない。漢字のコードポイントを1つだけシフトさせると異体字などの似た字になることが多いので頑張ればなんとか読めるか読めないか程度に書き換わる。あと、半角英数字をシフトさせるとHTMLタグなどが壊れてしまうので文章の体裁が崩れたり画像が表示されなかったりという点で困る。

ウェブページを1つずつHTMLコード手書きで作るならそこに記載するコンテンツ本文自体を文字シフトしてやらなくてはならないのでこれは後の修正が面倒だしシフトさせるのも何か用意してやる必要がある。でも、最近は1ページずつHTMLコード書いてなんてやってる人はほぼ居ないだろうと思うのでこの記事では対象外。
殆どは何らかのCMSを使ってるだろうし、中でもWordPress使ってる人が結構多いと思う。そこでWordPress用に文字シフト出力用のコードを書いた。WordPressの管理画面では正常な内容で記事の作成・編集が出来て正常な内容でデータを保存する。ページを出力するときに文字シフトして読めなくして閲覧者のブラウザに送る。

/WORDPRESSのPATH/wp-content/themes/使用しているテーマ/functions.php (次のコードをファイル最後に追記)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
add_filter('the_content', 'shift_content');
function shift_content($content) {
    $arrCont = mb_str_split($content);
    $arrCont = array_map('utf8_zenkaku_codePointShift', $arrCont);
    return implode($arrCont);
}

function utf8_zenkaku_codePointShift($str){
    $cP = mb_ord($str, "utf8");
    if ($cP > 0x4e9b) {
        $cP = $cP - 1;
        $str = mb_chr($cP, "utf8");
    }
    return $str;
}

PHP77.?以降で且つmbstringモジュールが有効でないと機能しない関数を使っています。

WordPressのテーマでthe_content()関数が使われている部分が書き換わります。つまりWordPressのコンテンツ(本文)部分を書き換えるフィルタです。記事のタイトルやページのヘッダ・フッタ・ウィジェットなどは書き換わりません。
shift_content()関数はWordPressのコンテンツ本文に書かれている全ての文字を1文字ずつ配列にしてarray_map関数で配列の要素それぞれ(つまり1文字ずつ)にutf8_zenkaku_codePointShift()関数の処理を実行しimplodeで配列内の全要素を再接続。つまり個々の文字をつないで文字列に戻す。それを出力として返す。
utf8_zenkaku_codePointShift()関数は受けた1文字のコードポイントが0x4e9c(UTF-8で「亜」という漢字)以降であればコードポイントを1つマイナス方向にシフトさせて返すだけの単純な内容。
結構面倒そうなことだけどPHPだとド素人でも超簡単にできる。

投稿記事だけ(WordPressでは普通の記事1つだけを表示する)に適用したい場合は、 shift_content() 関数内で is_singular() を使って分岐させる。このような分岐は何かしらした方が良さげ。

functions.phpはWordPressのテーマの核心部分で、これの変更をとんでもなく間違えるとウェブサイト全体が正常に表示されなくなるなど重大な問題が発生するかもしれません。十分にご注意ください。

シフトした文字を戻すJavascriptをページのフッタに挿入する。
/WORDPRESSのPATH/wp-content/themes/使用しているテーマ/footer.php (以下を最後の方の</body>の直前に挿入する)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
<script>
  const adspace = document.querySelector('#adwidget');
  const mCont = document.getElementById('mainContent').innerHTML;
  var mAfter = [];
  var afCont = '';
  if( adspace.clientHeight === 0 ){
    arrCont = mCont.split('');
    for(var i = 0; i < arrCont.length; i++){
      if (arrCont[i].charCodeAt(0) >= 0x4e9c) {
        mAfter[i] = String.fromCharCode(arrCont[i].charCodeAt() + 1);
      } else {
       mAfter[i] = arrCont[i];
      }
    }
    afCont = mAfter.join('');
    document.getElementById('mainContent').innerHTML = afCont;
  }
</script>

このJavascriptの中で、#adwidgetというのが広告のあるブロックを想定。必要に応じて変更。

このJavascriptの中で、mainContent(2箇所)というのがコンテンツ本文のブロックを想定。必要に応じて変更。

このJavascriptをどのように出力するかという処理を入れるのは当然考慮すべきこと。WordPressの「投稿記事」(ようするに普通の記事を1つだけ表示)のときだけこのJavascriptを出力するというような処理はあった方が良いが、好みで。もちろん、コンテンツ書き換え側もセットで。(読めないように書き換えたにも関わらずJavascriptが無かったら読めないままだし、本文を書き換えていないのにこのJavascriptを出力すると正常なコンテンツを異常にしてしまうので)

広告コードの部分 (Adsenseなら自動広告ではなくレクタングルのユニットなど)
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<div id="adwidget">
<!--ここから広告コード -->
<script async src="//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js"></script>
<ins class="adsbygoogle"
	style="display:block; text-align:center;"
	data-ad-layout="in-article"
	data-ad-format="fluid"
	data-ad-client="ca-pub-0000000000000000"
	data-ad-slot="0000000000"></ins>
<script>
	(adsbygoogle = window.adsbygoogle || []).push({});
</script>
<!--ここまで広告コード -->
</div>

広告コードを1行目の<div id="adwidget">と14行目の</div>で囲んでやることが重要。その id="adwidget" というのがJavascript内の#adwidgetのこと。この#adwidgetブロックの高さが0になったら広告が表示されていないという判断にする(Javascriptの方に書いてる)

コンテンツ本文は上のサンプルでは#mainContentであるということになっている。つまり書き換えられるブロックは<div id="mainContent">書き換えられる記事本文部分</div>という風になることを想定している。投稿記事(ようするに普通の記事を1つだけ)を表示するのであればテーマのファイルは /WORDPRESSのPATH/wp-content/themes/使用しているテーマ/template-parts/content/content-single.php (このPathは最近のWordpress標準添付のテーマの流儀と同じ場合) の中のthe_content();の周囲でid指定できそうなdivタグを見つけてid="mainContent"を指定する。(例: <div class="entry-content" id="mainContent">)

最近のGoogleさんはとても賢いのでこのようなコンテンツの書き換えが行われても表示完了時に正常な表示になるのであれば正常にクロールしてくれる筈だけど絶対とはいえないので自己責任で。

Fail2Banの再インストールと設定の見直し

コンピューターに不正にアクセス
©いらすとや.

メールサーバやウェブサーバをインターネットに公開していると、どうしても迷惑さん達がたくさんやってくる。
メールサーバやウェブサーバでログを録って、Fail2Banでそのログをリアルタイムで監視する。
ログインに失敗したとか何か悪さしようとしているログが記録されしだい、FailBanはただちにそのログを検知して指定された動作をする。多くの場合はそのログに記録されたIPアドレスをパケットフィルタに登録して、その後しばらく(指定した期間)はそのIPアドレスからの通信を受け付けないようにする。なお、Fail2Banという名前だからといってかならず「ログイン失敗」→「Banする(ハブる)」という用途にしか使ってはいけないということはない。

「がとらぼ」の中の人はずいぶん長くFail2Banを利用している(でも詳しくはない)が、突然1台のホストのFail2Banが調子が悪くなった。ログにどんどん認証失敗のログが溜まっているのに殆ど反応しない。完全に反応しないというのではなく中途半端が一番困る。で、自分でFail2Banのフィルタールールを作って登録して動作テストを行ったのだが、やはり全く反応しないわけではないが「問題発生のログ」に殆ど反応しない。Fail2Banのログに何か異常が出ていれば対応のしようもあるのだが問題なし。Fail2Banを再起動しても変わらず。

Fail2Ban関係で変わったといえば、Fail2Banの最新版の0.11.2が出たのが昨年2020年11月。これは半年以上前なので関係なさそう。
FreeBSDのPortsでFail2Banの最新版が出たのが2021年6月15日、問題の発生しているホストでPorts/PKGを最新版に更新したのが7月前半。これっぽい。
FreeBSDのPortsのFail2Banの最新版0.11.2_1の変更点の注意書きは、「PKG/PortsでイントールしたFail2Banを稼働させるためにディレクトリが足りなくてもユーザーの責任でなんとかしろ云々」(意味不明)
まぁ、ports/PKGで何か足りなくてもユーザーでどうにかしてねっていうのはFail2Banに限らずports/PKG全般そうじゃないかとは思うけど、何か問題が発生してるのかな?
とりあえず、FreeBSDのports/PKGでインストールしたFail2Banは多くのファイルがports/PKGの削除時に自動的に削除される。更新時も殆どのファイルが一時的に削除されて新しい版のファイルが置き直される。ユーザーが作成した設定ファイル・フィルタファイル・アクションファイルはFail2Banのディレクトリに残る。
ただし、/var/db/fail2Banに作成されるsqlite3のデータベースファイルはports/PKGを削除・更新しても消されずに残る。Fail2Banで大きな変更があってデータの構成が変わった際は注意。「がとらぼ」の人は大きな変更があったらFail2Banを停止してsqlite3ファイルを削除してfail2Banを改めて立ち上げるようにしている。

今回の動作異常は

  1. Fail2Banを停止
  2. Fail2Banを削除
  3. Pythonを再ビルド&再インストール
  4. Fail2Banの設定ディレクトリ/usr/local/etc/fail2banを退避
  5. /var/db/fail2ban ディレクトリを削除
  6. Fail2Banをビルド&インストール
  7. Fail2Banの再設定
  8. Fail2Banの起動
以上で結果的に直ってしまった。(Fail2Banの再インストールだけではダメだった)
ただ、Fail2Banはバージョン更新で意外と多くが変わるようなので設定ファイルも1から見直すべき。

FreeBSDのPorts/PKGではFreeBSD用にパッチの当たった状態でFail2Banがインストールされるため/usr/local/etc/fail2banのfail2ban.confはFreeBSD向けのPath設定になっている。メインの初期設定のjail.confもFreeBSDでよく使われるアプリのログのPathが記載されたpaths-freebsd.confを読み込む設定が最初から入っている。

[INCLUDES]

#before = paths-distro.conf
before = paths-freebsd.conf

fail2ban.confとjail.confを含め/usr/local/etc/fail2banにある設定ファイルはports/PKGを更新すると一旦削除されて新しいファイルに置き換えられるためユーザーが編集してはいけない。
jail.confの設定を変更したいなら同じディレクトリにjail.localというファイルを新規で作成して、その中に変更したい(または追加したい)内容だけを書くとその設定が優先で使用される。(オーバーライド)
そして、jail.confには初期値があるだけでなく設定の書き方の参考にもなるのでしっかり見る。

たとえは、Postfixであればjail.confの[Postfix]セクション(Jail)に設定が書かれているがこの設定は有効化されていない状態。 なので /usr/local/etc/fail2ban/jail.local (無ければ作成)には
[postfix]
enabled  = true

と書いてやればjail.confの[postfix]セクションに書かれた設定でそのルールが有効化される。(ただし、アクションなど他の設定が未指定だと機能するか不明)

また、Fail2Banの0.10まではではPostfix用の設定は分かれていなかったような記憶があるが、少なくともFail2Ban 0.11系ではPostfixの設定は複数存在する。 Postfix用のフィルターファイルは /usr/local/etc/fail2ban/filter.d/postfix.conf の1つなのでそこにいろいろ書かれている。また、セクションが複数あるだけでなく 0.10からはmodeもあるのでさらに細分化されている。 jail.localには使用するセクションをenabled = trueにするだけでなく使用するモードも書く。例: mode = more
たとえばPostfixでSMTP認証を実装するのにSASLを使っているとすると、fail2Banには[postfix-sasl]というセクションが用意されているので有効化する。fail2ban 0.9系まではPostfixのSASL関係のログを検知するフィルタは存在せず、0.10で[postfix]の中にSASL関係のログを検知するフィルタが入り、0.11で[postfix]からSASL関係のログを検知するフィルタが外れて[postfix-sasl]に入った。バージョン毎に違うため要確認。

jail.localの例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 192.168.0.0/24 fd00::/16
bantime  = 6h
findtime  = 12h
maxretry = 3
destemail = foobar@example.com
action = pf[name=%(__name__)s, bantime="%(bantime)s", actiontype=<allports>]    #←パケットフィルタpfでBanする
         %(mta)s-whois[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s"] #←IPアドレスの素性をwhoisで引いてメールする
         webhook[]    #←この行はpfのフィルタリングを実行すると共にwebhookで通知する (新規にwebhookアクションを作った場合)
         #アクションは必要に応じて複数設定可、それぞれ1行で書く


[postfix]
enabled  = true

[postfix-sasl]
enabled  = true
bantime = 12h
maxretry = 1

本来はセクション別にでも監視対象のログファイルを指定してやるところだが、メジャーなアプリケーションは必要無い場合がある。
postfixのログの場合、jail.confで before = paths-freebsd.conf が指定されていて、そのpaths-freebsd.confの中でさらに before = paths-common.conf が指定されていて paths-common.conf の中で postfix_log = %(syslog_mail_warn)s と指定されている。戻って、 paths-freebsd.conf の中で postfix_log = %(syslog_mail_warn)s と指定されているため、jail.confの[postfix]セクションで指定されている logpath = %(postfix_log)s は logpath = /var/log/maillog ということになる。これが初期値なので jail.local でログファイルを指定する必要はないということになる。
postfixのログの出力先を変更しているということであれば、logpath = hoge という設定をjail.localの[postfix]セクションに追加する。

Webhook用のアクションを作る

/usr/local/etc/fail2ban/action.d/webhook.conf (新規)
1
2
3
4
5
[Definition]

actionban = /usr/local/bin/curl -X POST \
            -d '{"name":"fail2ban-<name>", "server":"<fq-hostname>", "address":"<ip>"}' \
            https://example.com/webhook/listener.php

この例では https://example.com/webhook/listener.php がwebhookの受け手。(この記事では省略)
<name>, <fq-hostname>, <ip> はfail2banで使われる変数。

# service fail2ban start    #Fail2Banの起動  

動作確認

# fail2ban-client status
Status
|- Number of jail:      5
`- Jail list:   dovecot, postfix, postfix-sasl, rainloop, recidive

fail2ban-clientコマンドに引数 status を付けると稼働中のセクション(Jail=牢獄)のリストが表示される。設定で有効にしたセクション名が全て表示されていて不足・過剰がないこと。
この例ではdovecot, postfix, postfix-sasl, rainloop, recidiveの5つのセクションが有効であることが判る。

# fail2ban-client status postfix-sasl
Status for the jail: postfix-sasl
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/maillog
`- Actions
   |- Currently banned: 2
   |- Total banned:     2
   `- Banned IP list:   192.168.59.101 192.168.59.142

statusの後にセクション名を追加するとそのセクションの状態が表示される。
この例ではpostfix-sasl (SMTP認証)では/var/log/maillogを監視していて、現在は2つのIPアドレスをBanした状態で、そのBan済みのIPアドレスは192.168.59.101, 192.168.59.142であることが判る。ここで表示されるIPアドレスはFail2Banで管理しているIPリストなので別途パケットフィルタの設定が正しく行われていなければこの通りに「弾く」ことはできない。パケットフィルタ側でも現在BanしているIPアドレスリストを表示してFail2Ban側と同じIPアドレスがBanされていることを確認する。

最近のfail2ban-clientコマンドではかなり多くのことができる。 --help を付けて実行すると使い方が表示される。

ADS-B用アンテナをさらに改修した話

レーダー
©いらすとや.

この記事の話は昨年末にADS-Bの受信機セットが壊れて以降の長期間にアンテナ関係で行ったことが時系列マゼマゼで書かれています。

謎の針金アンテナを作り直しと再設置
以前作った針金アンテナの記事の写真。
スタブの部分が少し広く、そしてそのスタブ部分を直接グラスファイバーのポールに留める方式にしていた。これでもまぁまぁ受信できていたのだが、なんか気に入らなかったのも確か。今回アンテナケーブルを変更するついでにアンテナ自体も作り直すことにした。ただし、基本的には「針金4箇所曲げるだけの高利得な謎アンテナを作る」のダブルツェップアンテナと同じもの。

謎の針金アンテナを作り直しと再設置 1
回収した針金アンテナのスタブの幅。アンテナの計算ではスタブの間隔は8mmということになっていたのでどうするか迷ったあげくこの時は間隔そのものを8mmで作った。この針金は直径3mmなので針金の中心からだと間隔が11mmということになる。

謎の針金アンテナを作り直しと再設置 2
前回も針金にアンテナケーブルを仮留めするのに使った圧着端子。給電点の位置を決めるのに圧着する側ではなく丸い穴(上の写真では中心より左下側に見えている穴)を針金に通して位置を探った。前回は最終的には圧着端子は使わずケーブルの端はハンダでアンテナ針金に直付けになった。
今回は圧着端子の圧着する側(上の写真では中心より右寄りの筒部分)を針金に通して位置を調整してからかしめることに。

謎の針金アンテナを作り直しと再設置 3
かしめる筒部分の穴の直径と針金の直径が近いものを選択したが案の定針金をスムーズに通ってくれないので切断した。また、アンテナケーブルと接続する部分は少し表面を削った。

謎の針金アンテナを作り直しと再設置 4
今回は針金の中心の長さでアンテナの設計どおりに作るということでスタブの間隔が変わる。つまり針金の直径が3mmなので針金と針金の間の幅は5mmになる。
針金を曲げる前に圧着端子を通しておいてスタブ部分にそれぞれ1つずつ圧着端子を配置した。圧着端子とアンテナケーブルを接続し、VNAでSWRの値を見ながら位置をずらして調整する。前も書いたが、最適位置を探すと位置はケーブルの芯線側と網線側でちょっとズレた状態になる。(1090MHzのSWRが1.0だとスミスチャートで1090MHzがちょうど中心の50Ωを通る曲線)

謎の針金アンテナを作り直しと再設置 5
写真では既に自己融着テープを巻いてしまっているが、芯線の先、網線の先をそれぞれ圧着端子にハンダ付けして自己融着テープを巻き、その上からビニールテープなどで養生する。自己融着テープもビニールテープも導電性はないということになっているが、芯線側と網線側を一緒には包まないようにした。

謎の針金アンテナを作り直しと再設置 6
この写真は今回修理を行った過程で撮影した再現用。
暫く前に、新しく作った針金アンテナを写真の赤い輪の部分にタイバンドを巻いて固定した状態で一度「完成」として屋根の上に設置したのだが、しばらくしてタイバンドが取られて壊されてしまった。聞いた話では、カラスが屋根に集まっていたらしいのでカラスにイタズラされたかな?

謎の針金アンテナを作り直しと再設置 7
壊れた状態を撮ったもの。光学望遠のないスマホで撮ったのでこれで等倍。アンテナを固定していた細めのタイバンドが無くなったのでアンテナが外れて立ってる筈のエレメントが倒れた状態に。これでも受信自体はできるけど無指向アンテナのハズが傘を横にしてさしているようなもので本来の性能は発揮できない。
金属製のマストとケーブルを留めていた細いタイバンドも取られていてアンテナケーブルがマストからだいぶ離れている。

謎の針金アンテナを作り直しと再設置 8
見た目は醜くてヤバいがエポキシパテでアンテナケーブルを固めた。パテとアンテナの針金は触れていない。マストとアンテナケーブルを留めるタイバンドは全て太いものに取り替えた。
ついでにグラスファイバーの2本の延長マストも長さを倍にしてアンテナの位置を少し高くした。

謎の針金アンテナを作り直しと再設置 9
細い単管のアンテナポールの先にグラスファイバー2本で継いで高さを稼いでいる。こうすれば上部が軽くなる。アンテナポールが金属製なのでグラスファイバーで遠くに離すことでアンテナへの影響を弱めようということもある。
アンテナマストの先端に取り付けられた針金アンテナは ┫ になっているが、上の写真だと背景に溶け込んでいて殆ど見えていない。(特にスマホ画面だと見えないかも)
一応、これで完成のつもり。

問題はカラスのイタズラが本当だとしたら、これで壊されないとは限らないのよね。昨年H2には全く問題無かったけど。

2021年8月7日追記:
カラスが数羽集まって針金アンテナを突きまくって騒いでいるらしい。曲がり始めているとも。アルミ棒が銀色で太陽光が当たってピカピカ光るからかしら?

昨年末まではアンテナからその直下60cm以内までRG58を使い、塩ビパイプに格納したBPF+LNA+RTL-SDRドングル+シングルボードコンピュータとそこから室内までLANケーブルと電源用としてのUSBケーブルを伸ばした。しかし、屋外の塩ビパイプに熱源を入れて稼働させるとどうしても結露と湯気が発生して基板類がサビてしまう。 そこで、「アンテナ直下に機器類を置いてアンテナケーブルによる信号ロスを避ける」というのは諦めてアンテナから室内まで4〜5m長のアンテナケーブルを伸ばすことにした。ただし、針金アンテナから50cmほどのところでNコネクタでケーブルをつないでいる。いつかアンテナが壊れたり新しいアンテナを作ったらそこから先だけを取り替えるというつもり。また、バイアスTのLNAを購入したらそこに挟むというのもアリかもしれない。
で、安価なRG58ケーブルを幾つかAliExpressで購入したのだが、結構ヒドくて内1本に至っては3mのケーブルで信号がほぼ届かないほど。端子を取り替えたら直るかなと思って端子を外したら網線がボロボロボロボロ崩れたのが次々出てきてこれはダメだと思った。というか、RG58はさすがに1m以上は良くないかなと思ったのでもう少しだけマシそうなのを購入。今回アンテナケーブルには5D-FBを使用した。5Dなので太さ7.5mmで50Ω、家庭の衛星放送のアンテナケーブルに使われる5C-FBが75Ωで似たようなやつ。
FlightAwareのFAQを見ると「アンテナから受信機までのケーブルは、高品質の50オーム同軸ケーブルが15 m以下である必要があります(Ecoflex 10、Ecoflex 15、Westflex W103、H100、LDF250、LDF450、またはLMR600を推奨)」と書かれている。LMR400でも高くて手が出ないのにそれが推奨にすらなってなくてLMR600とかいう個人的には見たこともない直径15mmの太くて硬い高価なケーブルが推奨とかちょっとヒドい。でも、裸銅のソリッドケーブルだとケーブル曲げるのが大変な代わりに形作られたケーブルを変形させるのも大変なので今回のようなカラスに留めバンド取られて壊されるというようなのは無くなるかな?

謎の針金アンテナを作り直しと再設置 10
dump1090-faの5.0あたりから入っているウェブUIの新版SkyAwareによる昨日午後の様子。日中は100NM(海里)=185km以内で認識されることが殆どだったが、新しく作ったアンテナでは日中でも100NMを超えて遠くの航空機も捉えることが増えた。また、「がとらぼ」の中の人の環境では北西の若狭湾方向に限られるが夜も含めて180NM(330km)程度まで見えることが増えた。高度4万フィートくらいで巡航している旅客機だと海抜0mで周りに障害物が無いとして地球が丸い関係で見えるのは理論上では230NM(420km)が限度。高度2万4千フィート(7400m)の航空機だと計算上の最大距離は170NM(320km)ということになる。ADS-Bの1090MHzは光に近い特性で曲がったり反射したりしないためこれを超えるとなんかオカシイということになる。(ただし、稀に320NM=600km超えとかいうアヤシイのを検知することがあるけど)

以下2021年7月29日追記:

謎の600km超え 1
この画像はdump1090-faの出力する値をPrometheus + Grafanaで監視しているもの。(dump1090 Prometheus ExporterでADS-B受信状況を監視する参照)
頻発するわけではないけど、ときどき600kmを超える何かを検知しているというのが画像中の赤丸のように記録されている。このグラフは48時間分を表示しているので1瞬だけ飛び出たようなのは表示されず、数十秒〜数分検知されていなければこのようには表示されない。でも地球の丸さと航空機の高度を考えると600kmというのはありえない。何かの誤りやADS-Bの誤情報、エラー訂正の失敗だとは思うけど謎だった。

謎の600km超え 2
自衛隊F-15?と思われる航空機が能登半島の西、若狭湾の北方をうろついていたので眺めていたら、九州の宮崎県の海岸近くに突然ワープした。しかも暫くが2回。受信した値を間違えてエラー訂正してプロットしてるんだろうとは思うけど、こんなに変な風になるのね。しかも600km超えの時は毎回測ったように600km少しの同じ値なので毎回この場所(能登半島の西)に現れた航空機が間違って宮崎県沖に瞬間移動してるように検知してるのかな?