Rspamdを使って送信ドメイン認証の認証済み受信チェーン Authenticated Received Chain (ARC)を導入する

メールを届ける
©いらすとや.

お仕事でメールサーバを管理・運用するような人には「がとらぼ」は用無しで、メールサーバを管理・運用しない人には全く興味がないかもしれないけど、送信ドメイン認証関連でARCのこと。

  • SPF: メールの送信元MTAのIPアドレスとDNSのSPFレコードに書かれたIPアドレスを比較検証
  • DKIM: 送信側MTAで電子署名を付け、受信側はDNSの公開鍵を取得して検証
  • DMARC: 送信者ドメイン認証に失敗(正当ではない送信者)の場合にメールの破棄等をリクエスト+レポート
  • ARC: 認証の連鎖でメールヘッダを投稿者まで辿る

それぞれ役割が異なるのでどれを導入すれば良いとかじゃなくて全部入れたいところ。SPFだけ、DKIMだけ或いはSPF + DKIMだけというのはできるけど、DMARCだけとかARCだけというのは無い。
で、SPFやDKIMは、メーリングリストや代理送信等では認証がFailする。DMARCのポリシーがRejectだとそのメールが受信側MTAで破棄される可能性がある。(でも、DMARCのポリシーは「何もしない」ではなく厳しく「Reject」にしたいところ。でないと導入の意味が半減だと思う。)

今回のARCは経路のMTA(メーリングリストのような中間・再送信サーバ等も)で検証を行い検証の数珠つなぎを行う。送信・再送信・受信サーバの全てがARC対応ならだけど。
そして、ARCでの認証がPassならDKIM認証がFailでも送信認証PassとすることでSPF, DKIMの中間・再送信サーバ問題も解決できる(かもしれない)。
「がとらぼ」の中の人が運用しているMTAではすでにDMARCをRejectポリシーで運用しているのでARCには対応したいところ。

大手でも既にGmailは(受信側は)ARC対応している。
送信側で対応しているところを知らないが。

簡単にやりたいので迷惑メール対策ツールのRspamdのarcモジュールを使用する。

https://rspamd.com/doc/modules/arc.html と modules.d/arc.conf を参考に設定する。ウェブの設定例は複数の書き方が混ざってるので不慣れだと混乱させられる。

設定するファイルは local.d/arc.conf (無ければ新規作成)。modules.d/arc.confは変更しないこと。
基本的には上のリンクのページの真似で良いんだけど、秘密鍵のpathを既に設定している筈のDKIMのものと同じにする又はコピー又はシンボリックリンクにするとラク。この方法では、ARCとDKIMで同じ秘密鍵を使うけど、ちゃんとDKIM署名とは別のARC用の署名になる。
設定項目の秘密鍵の path の書き方は複数ある。(既にある)DKIMの設定(local.d/dkim_signing.conf)を真似ると簡単。
これだと(DKIM用の秘密鍵をARCでも使うなら)、DNSに新たに公開鍵のTXTレコードの追加が不要。

もちろん、ARC用にDKIMと同じ方法で別の鍵のペアを作ってそれをARC専用として登録することもできる。筋としてもこちらが正当?ただし、先にDNSにARC用の公開鍵を登録してDNSを再起動し、REFRESH時間(できれば2倍)を待ってからMTAでARCを有効な状態にしてやらないと送信したメールがひどい目に合うかも。

管理者の世界ではセカンダリDNSまたは更に他所のDNSの古いキャツシュ消えるまで庚申待の宴を夜を明かして行うことになっています。

今回は一応DKIM用とは別にARC用の鍵のペアを用意することにする。(オススメはARC用を別途作らずDKIM用の流用の方)
DKIMの鍵の作り方は前回も書いたけど、下のようなの。(鍵ファイルを置くディレクトリはARC用に /var/db/rspamd/arc とする)

# mkdir /var/db/rspamd/arc
# rspamadm dkim_keygen -d example.com -s セレクタ -b 2048 -k /var/db/rspamd/arc/example.com.セレクタ.key > /var/db/rspamd/arc/example.com.セレクタ.pub

上の例の「セレクタ」の部分は共通の任意の文字列(半角英数字)を指定する。ARC専用に作るならDKIM用とは違うセレクタを指定する。 これで、 /var/db/rspamd/arc に example.com.セレクタ.pub (公開鍵)と example.com.セレクタ.key (秘密鍵)の2つのファイルが作成される。
Rspamdに登録するのは example.com.セレクタ.key (秘密鍵)の方。
example.com.セレクタ.pub (公開鍵)の内容(セレクタを含むドメインキー)をDNSの example.com 用ゾーンファイルに書く。

RSAで鍵長に2048bitなどを指定すると公開鍵が255文字を超える。rspamadm dkim_keygen が出力する公開鍵は予めDNSのTXTレコード用に行分割形式になってるが、それでも古いシステムのMTAを相手にすると問題になることもあるようなので注意。まぁそんな古いシステムを動かしているようなところならそもそもARC非対応だと思うのでおそらく何も考えずにコピペでOK

公開鍵は先のコマンドで出力した /var/db/rspamd/arc/example.com.セレクタ.pub のファイルの中身すべてをそのままDNSのゾーンファイルにコピペする。
arc._domainkey IN TXT ( "v=DKIM1; k=rsa; "
        "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqcOxgk+SkMRDo5Tj6e5HfVINHBRfEm6eaTDJp8L8aa+u15ueLEqyA3SBmWdistFVSAdSL8/MjBuogwpBvEJoQ23IhcITVIcwAsbYLMzFq6N1pJlQ3JqKF/127vjd13FFqAH9kbiasNOr1VIyt2namokz2CeM4js+IIk/yqF4Y2z6kSdHTofjzOhilsMpMAGNTa5Fh4OVEzDSL9sI7"
        "zH4YqxmGrqPVxDMUF4MF6XvR9HYlB1KApxsB4oAjcTGj3FwTzwroKG0QHCDETBEknuDJR51Ctpkrf3qO605TEWQlfe+c+2C3pNGh8IGDz5GkE4HqFKnr1jJX0R213adJAGe7QIDAQAB"
) ;

こんなの。この例ではセレクタを arc にしている。
DNSのTXTレコードは一応255文字までということになっているけど、括弧を使った複数行記述により255文字超えに対応している。DNSがBINDならDNSのゾーンファイルにそのままコピペ。BIND以外なら修正が必用かも。シリアルを増やすのを忘れずに。
rndc reload とか何かやってDNSの設定変更を反映させる。

ちなみにDKIMと同じようにRSAの他にEd25519で鍵を作って同じように配置してみたが、(少なくともRspamdの)ARCでは複数署名には対応していないっぽい。試した限りではRSAの署名しか使われなかった。まぁ経路内のMTAがEd25519非対応で検証のチェーンが切れてFailでは話にならないのでRSAだけで良いかもしれないが、これから普及させようというならいっそEdDSAな署名で統一すれば良かったのに。ARCの仕様でこのあたりどうなっているのか調べてないのでスミマセン。

今回はRspamdのサービス再起動ではなく、設定リロードを行う。

# service rspamd reload

これだけで、メール受信時のARC認証と、メール送信時のARC署名の両方を行ってくれる。postfixなどMTAには特に設定変更は不要なのがありがたい。

メールを送信して確認

自分宛に送ってみたメールのメールヘッダを見てみた。
確認するのは ARC-Message-Signature と ARC-Seal と ARC-Authentication-Results の3つと、最終的な送信認証結果であるAuthentication-Results (Rspamdの場合)の計4つのレコード。

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=intaa.net;
	s=arc202010; t=1603108555;
	h=from:from:sender:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=6VsBFBqz1cYAm4jEi75leHazQTFMa4BrcqUiEhaBfiE=;
	b=F0Ua28oi7jvsxqxxxe5dxEjL3Q8Dc8y5RqDHeqB0LxPnUL9OT3Qrk2vXYKuq+Zvi3pbXA1
	Y4sXM0i8JnLPlNhFfRkhiOOTh1b5a9UXxiH/nmqj0VopWWZ3H2Jc/v75N5Cp7U3PILiuOu
	2xp8biheXaTqj81FRyFeASQrEw+qBsazbkakfmYMuj0ESwEaIv/qCovalPbuDDQQEk3q3O
	PTH8AGTzv3NJf8eK+bA3fjMyAetV9gFr8S92SHc7Fy76sfzWF0pPBxu+lLTJani9cC68NP
	7Xk1fs7GtscR8+RBi/B5ZceCvvPgz4UbDYiTO3fb74YUxS3TninspYn38E+/fw==
ARC-Seal: i=1; s=arc202010; d=intaa.net; t=1603108555; a=rsa-sha256;
	cv=none;
	b=EYgwd/GZVS5StCJt007Srx9ivY4nIeL7Q6NV5nYt3JOYJF3UeAc81i0RIqbHCYfzLrcJQn
	YaKOswyF0dnTnkOnB0wEidrcR8tlWemIpFKN/pCnYXcZg+X+2K/HjMyNdVRWzVibR58rQm
	s/q4lXZL+wx82iw6BApKQJ7DYY0xm9z663gZR5kIn4AnVtKMTcziTrek1seCsIXbrimd6h
	hTvQmFa4abYIw4qdMLRMYNozu8bG4pUA4oqCIk3c92sMCbW2PGJSrzufbl5gz5doxjXLZK
	Zopcw6UcyQLHupOBvWP3ioylFF+e1yzD08oVsqm8sNHHN80LtOqHqmEnqTIy2g==
ARC-Authentication-Results: i=1;
	mail.intaa.net;
	auth=pass smtp.auth=gato@intaa.net smtp.mailfrom=gato@intaa.net
Authentication-Results: mail.intaa.net;
	auth=pass smtp.auth=gato@intaa.net smtp.mailfrom=gato@intaa.net
Gmailにメールを送ってみた (変更前)
Authentication-Results: mx.google.com;
	dkim=pass header.i=@intaa.net header.s=dkim header.b="P5dq/EPh";
	dkim=neutral (no key) header.i=@intaa.net header.s=eddsa header.b=s4PatVO3;
	arc=fail (DNS record missing);
	spf=pass (google.com: domain of gato@intaa.net designates 2001:2c0:d800:6701::2000 as permitted sender) smtp.mailfrom=gato@intaa.net;
	dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=intaa.net

中途半端な設定だったので、arc=fail で検証失敗しDNSに適切な公開鍵が無いと書かれている。
ARC-Authentication-Resultsも当然無い。
ちなみにdkimがpassとneutralの2つがあるのはDKIM用にRSAとEd25519の2種類の署名を用意しているから。GmailはEd25519非対応のようなのでそれがneutral (no key)になっている。(DKIM検証結果は次も同じ)

Gmailにメールを送ってみた (ARC設定後)
ARC-Authentication-Results: i=2; mx.google.com;
       dkim=pass header.i=@intaa.net header.s=dkim header.b="P5dq/EPh";
       dkim=neutral (no key) header.i=@intaa.net header.s=eddsa header.b=s4PatVO3;
       arc=pass (i=1);
       spf=pass (google.com: domain of gato@intaa.net designates 2001:2c0:d800:6701::2000 as permitted sender) smtp.mailfrom=gato@intaa.net;
       dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=intaa.net
Authentication-Results: mx.google.com;
       dkim=pass header.i=@intaa.net header.s=dkim header.b="P5dq/EPh";
       dkim=neutral (no key) header.i=@intaa.net header.s=eddsa header.b=s4PatVO3;
       arc=pass (i=1);
       spf=pass (google.com: domain of gato@intaa.net designates 2001:2c0:d800:6701::2000 as permitted sender) smtp.mailfrom=gato@intaa.net;
       dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=intaa.net

このレコードはメールの受信側であるGmailのmx.google.comが付けたもの。(ARCでは同じようなヘッダが並ぶので見るところを間違えないように)
arc=pass になって(受信側の)ARCによる検証成功。
このとき、 i=1 と i=2 でそれぞれ ARC-Seal, ARC-Message-Signature, ARC-Authentication-Resultsが存在する。中間サーバがあればさらに?

あとは、外部からARC付きメールを受信したときの動作確認をしたいところだけど、ARC付きでメールを送ってくれるところを知らないという・・

ARC署名付きのメールを送って下さった方がいたので署名を基に判断するという動作の確認ができました。チェーンの部分は(「がとらぼ」の人が理解できてないので)よく解らなかったけど。

針金4箇所曲げるだけの高利得な謎アンテナを建て直した

針金4箇所曲げるだけの高利得な謎アンテナを建て直した

前回アンテナを建てたときは軽量だからという理由でアンテナポール本体を樹脂パイプにしたのだが、建てたその日に既にアンテナポールが揺れすぎという問題が判明していた。直径25mmの樹脂パイプは想像以上にフニャフニャでちょっとの風でビョンビョン横揺れするのね。アンテナポールを固定するための金具もサイズが合ってなくて滑り止め系のゴム素材で隙間を埋めて使ってたからガッチリ固定でないので、尚更風が吹くとパイプが揺れやすかった。

今回は直径はほぼ同じ直径25.4mmだけど金属製の単管なのでフニャフニャではなくなった。また、単管の直径に合う金具を用意したのでしっかり固定できた。
ただし、アンテナポール周り全てが金属製の単管なのでだいぶ重い。建物から水平方向にズドンと突き出した46mmのパイプを軸として直径32mmと直径25.4mmの単管を垂直に留めたが、全て上方向に生やそうとすると重すぎて軸が回せないためアンテナを上にできない。そこで、32mmの単管はほぼ半分(少し下方向が長め)、25.4mmの単管(アンテナポール本体)はほぼそれと同じだけ下側に下げて生やすようにする。これで、完全バランスではないが、アンテナポールの単管の約1m分とアンテナ部材の重量分だけがバランスが取れない程度。これくらいなら軸を回すことができるのでアンテナを上にできる。
このように、軸より下方向にカウンターバランスウェイトとしてポールを下げたため、前回よりも屋根の上に出る高さが50cmほど低い。

取り付け方としては(重い方の)アンテナが下向けになる状態で軸に取り付けて直交クランプ(2つ)のネジを締めて軸に固定。で、軸を180度回してアンテナが真上が向く状態で(建物内で)軸を完全に固定。書くのは簡単だけど大仕事なので何度もやりたくない作業。
金具は全て1mm厚のゴムシートを挟んで滑らないようにしてネジを締めている。

アンテナ本体の高さ調整が難しいのでハイトパターンに合わせて最適な高さにするというのはちょっと無理。やるとしたらアンテナを留めているグラスファイバーの細い2本のポールを交換する感じ?ADS-Bだと1週間くらい測定して調整前と比較というのをかなりの回数繰り返すことになるのだろうけど現実的じゃない。

これで、普通の風程度では大きく揺れることはなくなった。アンテナが揺れまくらなくなるとADS-Bの受信も安定しそうな感じ。(と、期待している)
実際には建て直して1週間ほど経つが、建て直し前より結果が悪いということはない。むしろ受信状況は改善しているが、これは建て直しと同時にdump1090-faの受信設定を見直したからからと思われる。

dump1090-faとPiAwareをVersion 4.0に更新

dump1090-faのWeb-UI SkyAware

FlightAwareのフィーダーさんたちが使っている多数がdump1090-faとPiAwareだと思われるが、そのdump1090-faとPiAwareが2020年9月末にバージョン4.0になった。そこで、アンテナ建て替えの停止ついでに3.8から4.0に半年ぶりに更新することに。3月下旬リリースの3.8.1はスキップ。

dump1090-fa 4.0への更新

2020年10月9日時点でArmbainのarm64のシングルボードコンピュータで利用可能なパッケージではすでにdump1090-faの4.0が提供されている。なので、この記事のように自分でビルドしなくてもapt install dump1090-faでインストールするなりapt upgrade dump1090-faで更新するなりで終わりといえば終わり。
しかし、今回はレシーバの種類をRTL-SDRに限定してビルドした。

基本的なdump1090-faのビルド方法は以前のdump1090-faの記事と同じ。 ただ、RTL-SDRに限るオプションとして dpkg-buildpackage -b --no-sign の代わりに

$ dpkg-buildpackage -b --no-sign --build-profiles=custom,rtlsdr
ビルドしてできたパッケージをインストール。

上の手順だけでは更新の場合はおそらくウェブUIが動かない・dump1090が機能していない?という状態になる。

$ lighty-enable-mod dump1090-fa
これで更新前と同様に動作するようになる。

dump1090-fa 4.0の起動オプションの見直し

ネットの記事をちょろっと見てチャチャっとインストール〜動作させたようなフィーダーだと起動オプションが不適切なことがある。
今回は見直すことにした。
まずは、使用できるオプションを確認する。

$ dump1090-fa --help
前略
--device-type <type>     Select SDR type (default: rtlsdr)

      rtlsdr-specific options (use with --device-type rtlsdr)

--device <index|serial>  select device by index or serial number
--enable-agc             enable digital AGC (not tuner AGC!)
--ppm <correction>       set oscillator frequency correction in PPM
--direct <0|1|2>         set direct sampling mode

      ifile-specific options (use with --ifile)

--ifile <path>           read samples from given file ('-' for stdin)
--iformat <type>         set sample format (UC8, SC16, SC16Q11)
--throttle               process samples at the original capture speed

      Common options

--gain <db>              Set gain (default: max gain. Use -10 for auto-gain)
--freq <hz>              Set frequency (default: 1090 Mhz)
--interactive            Interactive mode refreshing data on screen. Implies --throttle
--interactive-ttl <sec>  Remove from list if idle for <sec> (default: 60)
--raw                    Show only messages hex values
--net                    Enable networking with default ports unless overridden
--modeac                 Enable decoding of SSR Modes 3/A & 3/C
--no-modeac-auto         Don't enable Mode A/C if requested by a Beast connection
--net-only               Enable just networking, no RTL device or file used
--net-bind-address <ip>  IP address to bind to (default: Any; Use 127.0.0.1 for private)
--net-ri-port <ports>    TCP raw input listen ports  (default: 30001)
--net-ro-port <ports>    TCP raw output listen ports (default: 30002)
--net-sbs-port <ports>   TCP BaseStation output listen ports (default: 30003)
--net-bi-port <ports>    TCP Beast input listen ports  (default: 30004,30104)
--net-bo-port <ports>    TCP Beast output listen ports (default: 30005)
--net-stratux-port <ports>   TCP Stratux output listen ports (default: disabled)
--net-ro-size <size>     TCP output minimum size (default: 0)
--net-ro-interval <rate> TCP output memory flush rate in seconds (default: 0)
--net-heartbeat <rate>   TCP heartbeat rate in seconds (default: 60 sec; 0 to disable)
--net-buffer <n>         TCP buffer size 64Kb * (2^n) (default: n=0, 64Kb)
--net-verbatim           Make Beast-format output connections default to verbatim mode
                         (forward all messages, without applying CRC corrections)
--forward-mlat           Allow forwarding of received mlat results to output ports
--lat <latitude>         Reference/receiver latitude for surface posn (opt)
--lon <longitude>        Reference/receiver longitude for surface posn (opt)
--max-range <distance>   Absolute maximum range for position decoding (in nm, default: 300)
--fix                    Enable single-bit error correction using CRC
--fix-2bit               Enable two-bit error correction using CRC (use with caution)
--no-fix                 Disable error correction using CRC
--no-crc-check           Disable messages with broken CRC (discouraged)
--mlat                   display raw messages in Beast ascii mode
--stats                  With --ifile print stats at exit. No other output
--stats-range            Collect/show range histogram
--stats-every <seconds>  Show and reset stats every <seconds> seconds
--onlyaddr               Show only ICAO addresses (testing purposes)
--metric                 Use metric units (meters, km/h, ...)
--gnss                   Show altitudes as HAE/GNSS (with H suffix) when available
--snip <level>           Strip IQ file removing samples < level
--quiet                  Disable output to stdout. Use for daemon applications
--show-only <addr>       Show only messages from the given ICAO on stdout
--write-json <dir>       Periodically write json output to <dir> (for serving by a separate webserver)
--write-json-every <t>   Write json output every t seconds (default 1)
--json-location-accuracy <n>  Accuracy of receiver location in json metadata: 0=no location, 1=approximate, 2=exact
--dcfilter               Apply a 1Hz DC filter to input data (requires more CPU)
--version                Show version and build options
--help                   Show this help

バージョンによって使用できるオプションが変わることがあるのでバージョンを更新した場合は設定変更するつもりがなくても確認しておくのが良さそう。 今回4.0では3.8で追加された --fix --fix の2ビット訂正が --fix-2bit に変更になっている。

また、ようやく --version でバージョン表示ができるようになった。
$ dump1090-fa --version
-----------------------------------------------------------------------------
| dump1090 ModeS Receiver                                   dump1090-fa 4.0 |
| build options: ENABLE_RTLSDR                                              |
-----------------------------------------------------------------------------

ところで、dump1090-faでゲインの設定ってどうしているだろうか。

https://discussions.flightaware.com/t/rtl-dongle-gain-question/15588
obj FlightAware Staffの発言の引用

librtlsdrには2つの異なるゲイン設定があり、これらのオプションが制御します
–enable-agc は、RTL2832U内のデジタルAGCを有効にします。実際には、これはあまり役に立ちません(デジタルステージ内でデータをスケーリングするだけなので、追加情報が抽出されることはありません)
–gain -10 は、チューナーチップでアナログAGCを有効にします。これは、有用である可能性が高くなります。
–gain(何か他のもの)はアナログAGCを無効にし、チューナーゲインをdB単位のその値(または近くにあるチューナーがサポートするもの)に直接設定します。
R820Tチューナーでは、チューナーのゲイン設定が実際にはLNA(RF)ゲインとミキサーゲインの両方を制御します。 librtlsdrを介してそれらを個別に制御することはできません。
アナログAGCは、信号が特定の強度にしばらく留まる場合に最適に機能し、フィードバックループを調整するための時間を与えます。これは、バーストが非常に短いため(1090MHz信号では実際には当てはまりません)、ほとんど)そしてあなたは広範囲の信号強度を得るでしょう。
個人的には、R820Tの最大ゲインから1ノッチ下の-ゲイン48で実行します。最大ゲイン(デフォルト)は、不均衡な量のノイズを追加するようです。強い/近い信号の場合、または増幅されたアンテナを使用する場合は、ADCステージでのクリッピングを回避するためにゲインを低くする必要があります。

ゲインは固定なら30〜48程度で設定 (--gain 48 など)、または、AGCを使うなら (--gain -10 AGCはこれ一択)だけど、ADS-BではAGCオンはあまりオススメではないらしい。他の人の意見でも。受信範囲を殆ど航空機が通らなくて1機だけを暫く追跡するような場合には有用らしいが。–enable-agcは問題外ということで。
そこで、「がとらぼ」ではAGC不使用に変更。ただし、固定の場合は環境に合わせた調整は面倒。次のdump1090-exporterのSignal Strengthのグラフを見ながら値を調整したところ、「かとらぼ」の環境(過剰に増幅する怪しいLNA使用)では --gain 30 くらいが一番良さそうな感じということになった。

https://discussions.flightaware.com/t/dump1090-mutability-dcfilter/30584
david.bakerの発言の引用

DCフィルターは、エンコードが振幅エンコードされているため、ADSBには役立ちません。 他の無線システムでは、非常に便利です。
RTLドングルとプロスティックは実際にはソフトウェア無線であり、他の周波数(数MHzから1.8GHz)を聞くために使用できます。 RTLドングルで使用されるテクノロジーは、低IFおよびゼロIF無線変換と呼ばれます。 ゼロIF変換は、ソフトウェアでフィルターで除去できるDC成分を出力に追加します。 一部の無線エンコーディングでは、DCオフセットを削除することが重要です。 ADSBではそれは問題ではありません。
DCフィルターをオフのままにしてください。

前回のdump1090-faの記事でCPUの使用率として少し触れたDC FilterはADS-Bでは役に立たないらしいので使用しない (--dcfilter は付けない)

2ビット訂正 (--fix --fix)オプションは4.0で --fix-2bit に変更になった。
ただし、2ビット訂正はFR24にフィードするなら使わない方が良いみたい。1ビット訂正 (--fix 1回指定)に留めるのが良さそう。

1ビット訂正 --fix について

https://discussions.flightaware.com/t/fix-parameter-in-dump1090-fa/65791
obj FlightAware Staffの発言の引用

転送中のノイズによって損傷した一部のメッセージに対してエラー訂正を行います。そうでない場合は破棄されます。 これの欠点は、ひどく損傷したメッセージが誤って「修正」され、悪いデータが生成される可能性が高くなることです。 通常、これらの不良メッセージは、後続の処理によって除外されます(これが「シングルトラック」統計の取得元です)

dump1090exporterの更新

dump1090exporterの更新はpipで行う。
$ pip3 install --update dump1090exporter
環境によってはpip3ではなくpip。

更新自体は簡単だが、オプションが変わっていて、動作が怪しいためdump1090 Prometheus ExporterでADS-B受信状況を監視するのようにデータの在り処のURLを未指定にするとaircraft.jsonが取得できなくなってる。他のjsonファイルは/dataに取りに行くのでdump1090exporterのバグ?
そして、データの在り処の指定オプションが変わっているっぽい。
--url=在り処のURL だったのが --resource-path=在り処のURL になった。どのバージョンで変わったかは調べてない。

dump1090-faのWebUIのURLがhttp://127.0.0.1:8080だとすると、データは(初期値では)その/dataにあるので http://127.0.0.1:8080/dataになる。

起動コマンドの例
$ /usr/local/bin/dump1090exporter --resource-path=http://127.0.0.1:8080/data --latitude=-35.xxxxxxxx --longitude=139xxxxxxxx

dump1090exporterのグラフ
Grafanaでチャートを表示してSignal Strengthの折れ線グラフ(下から2番め)を見る。dump1090-faで--gain 30を指定するとこれくらい。(あくまでも「がとらぼ」の中の人の環境で怪しいLNAを使用しての30指定でこれくらい。)
--gain の数値を増やすと3つのグラフが上方向に上がる。「がとらぼ」の環境だと40指定のようにむやみに高い数値を指定すると水色のnoiseが-5 dbFSあたりまで上がる。その結果はとても悪くなる。LNA無しだと先の引用のように48くらいを指定するのも良さそう。

PiAwareの更新

PiAwareもすでに4.0のパッケージが提供されているようなので面倒がイヤなら素直にパッケージを利用する方が簡単。
しかし、「がとらぼ」では前回に引き続きビルドする。
ビルドの基本はFlightAwareにフィードすると変わっていない。ただし、4.0では3.8より依存関係を満たすのが面倒になっている。

足りない
piaware depends on tclx8.4; however:
  Package tclx8.4 is not installed.
 piaware depends on tcllib; however:
  Package tcllib is not installed.
 piaware depends on tcl-tls (>= 1.7.16-1+fa1); however:
  Package tcl-tls is not installed.
 piaware depends on itcl3; however:
  Package itcl3 is not installed.

tclx8.4, tcllib, itcl3は普通に apt install hoge のようにインストールする。(嫌がられる場合は apt install -f hoge

のように-fを付けて強制する)

上の4つの内、piaware 4.0ではtcl-tlsは専用版が要るみたい PiAwareビルド時には要らないけどインストール以降で必要。
そこで、扱いやすいようにパッケージとしてビルドしてインストールする。

$ sudo apt install tcl-dev chrpath
$ cd ~/      (ホームディレクトリで)
$ git clone http://github.com/flightaware/tcltls-rebuild.git
$ cd tcltls-rebuild
$ ./prepare-build.sh buster     (Armbian, Debianのバージョンがbusterの場合)
$ cd package-buster
$ sudo dpkg-buildpackage -b --no-sign
$ cd ../
$ sudo dpkg -i tcl-tls_1.7.16-1+fa1_arm64.deb

PiAwareの更新は /etc/piaware.conf と /var/cache/piaware の中のファイルを消したりしなければ基本的にはトラブらない筈。

dump1090-faやPiAwareのバージョンを最新にしないとFlightAwareからフィードをブロックされるとかはないようなので、最新に保つ必要があるかと問われると「まぁ必要はない」けど、半年放置したので新しくしたい気持ちがあった。今回はアンテナの建て替えついでだからちょうど良かった。そういう機会がないとダウンタイムがそれなりに発生するから更新なんかしたくないしね。