30-Oct-2019
[ありゃ]

23-Oct-2019の補足で書こうと思っていたけど長くなってしまったのでこちらに。

BM_Japan_4401、「BM 4401はBrandmesiterリフレクターにアクセスするために日本国内に設置された接続サーバーでしたが、2019年9月30日を持ちまして運用停止致します。ご利用を頂きまして、有難うごさいました。」とのアナウンスが出ていますね。

運営おつかれさまでした、ではあるのですが…ちょっと引っかかることがあります。一体どなたが運営していたのかということと、誰かに引き継ぐようなことはしなかったのかなということ。

とはいえ、XLXサーバのように誰にも断らずにサーバを立てることができて多少のトラブルがあってもあまり問題ないようなシステムに対し、BrandMeisterの基本的に一国一接続サーバという、利用者側からは中央集権的に見えるシステムでは運営側の負担は大きいものがあります。

周波数を巡っての争いとか結構アレなことをする人達が少なくないので、サーバの運用者を伏せていてもアレなことが起こってしまったとしたらかなり嫌ですね…単に資金が尽きたとか飽きただけという可能性もありますし、真相は分かりませんが。

試しにBrandMeisterのサーバを立てるとどれくらいの資源が必要になるのかなと思ってJoining BrandMeister with your own serverにあるHardware specificationsを見てみましたが、推奨環境は

ということで、潤沢なメモリが使えるVPSでないと厳しそうです。BM_Japan_4401の動いていたIPアドレス(150.66.42.231)をドメイン名・IPアドレス検索 (ANSI Whois)に食わせるABLENETのVPSを使っていたようで、ここのV3(4vCPU, RAM4GB, \3315+税/月)になるのでしょうか。さくらのVPSだと4Gプランが同じようなスペックで一ヶ月\3960+税。

いやこれフツーに運用コストがツラいでしょ。

とりあえず接続先のサーバをBM_Japan_4401から他のサーバに切り替えれば良いだけなので、それ以外については今までと何も変わらなかったりします。どこかおすすめの接続先はありますかね?DMRPlusも使ったことが無いので、こちらを試してみても良いのでしょうが…58.65kg(14:10)

23-Oct-2019
[わかんねえなあ…]

DAPNETGatewayで使ったIPv6対応のUDPSocket.{cpp,h}をDMRGatewayに入れてみたのは良いのですが、DMRGatewayの使い方が分からないのでメモ。

とりあえずDMRGateway.iniの[General]セクションが以下の状態(デフォルト)で、

MMDVMHost.iniの[DMR Network]セクションを以下のように設定するとMMDVMHost←→DMRGatewayとのリンクが確立します。

Localの設定が必要、というのがBrandMeister/XLXに直接接続する際との違いです。単に一つのサーバに接続するだけならDMRGateway.iniの[DMR Network 1]セクションをこんな感じに書けば繋がりますが、

実際に運用するならPassAllTGの設定を外し、サンプルのDMRGateway.iniのようにTGRewrite, PCRewrite, TypeRewrite, SrcRewrite, PassAllPCの内容を適切に設定する必要があるでしょう。Location=0で[Info]セクションの設定をサボっていますが、この場合はMMDVM.iniの内容が引き継がれるようです。

なお、以下の点につまづきました。

XLXサーバに繋ぐ場合、Address=<XLXサーバのアドレス>, Port=62030, Password=<なんでも良いが省略は不可>で良く、トークグループの設定も(PassAllTGを設定していれば)4000〜4026で問題ありません。

そもそもDMRGatewayは複数のDMRネットワークをトークグループの設定に応じて切り替えて運用するのが目的なので、今回のように単一のネットワークに繋ぐなら不要なんですけどね…59.45kg(20:20)

30-Oct-2019補足:BM_Japan_4401は運用を停止しています。

20-Oct-2019
[こうかなあ…]

xlxd、IPv4/IPv6デュアルスタック化してみました。IPv4/v6のソケットを用意して、それぞれにbind()して、データの来たソケットからrecvfrom()して、相手のIPアドレスに応じて適切なソケットからsendto()するようにしただけなのですが。

とりあえずIPv4/IPv6の各xlxdに同時にインターリンクできたので、XLX765もこのコードで試しています。実際にここへIPv6で繋いでくるケースがどの程度あるかは分かりませんし(というか無いんじゃないかなあ)、dashboard(2)の修正も今後必要です。58.40kg(06:50)

21-Oct-2019補足:dashboard2、IPv6対応入れてみました。PHPいじるの初めてなんですけど…

16-Oct-2019
[うーむ…]

IPv6対応化改造をしたxlxd、手元で動かして試しているのですが

という状況です。IPv4/IPv6どちらでもインターリンクをすることはできたので改造した通信部分は動いているように見えますが、IPv4←→IPv6の相互運用はできないことを再確認しただけとも言えます。

とりあえず動かしてみる、から先を目指すにはデュアルスタック化は避けられない感じですね…58.70kg(16:05)

14-Oct-2019
[うーむ]

IPv6対応化改造をしたxlxd、以下の問題があります。

それくらいできるでしょ、と考えていたのですが…xlxdの起動時に指定したIPアドレスからsocket()のAF_INET/AF_INET6を決定してしまうので、現状ではどうにもならないという。対処するにしても、お手軽に改造して対応する、の範疇を越える気がします。

とりあえずは従来のコードと同様にIPv4上で安定して動くかどうかを確認したいので、そちらをまずはどうにかしたいのですが。58.70kg(21:05)

09-Oct-2019
[XLXサーバにホットスポットをつなげる際は]

XLXサーバにMMDVMHostを(DMRGatewayを使用せずに)直接つなげる場合、28-Aug-2019にあるようにMMDVM.iniの[DMR Network]セクションの設定を

としますが、これに加えてDMR無線機のトークグループの設定を4000〜4026にする必要があります。4000で切断、4001がmodule A〜4026がmodule Zとなります。

XLX765のxlxd、IPv6対応化改造を行ってみました。MMDVMHost側のIPv6対応はまだ行われていないため、まずはIPv4で従来どおりに動くかどうかをテストします。UDPによるパケット転送部分のみIPv6に対応していますが、他(xlxapi.rlx.luからのDMR IDデータベース読み出し、ambed/ambedtest)については今のところ対応は不要と考えています。簡単に試した範囲ではなんとなく動いているようですが、不具合を見つけたら遠慮なくお知らせください。

…とはいえ、OpenBSD対応を追加したというpull requestが半年経っても未だにマージされないので、多分この改造も放置されるのでしょうね。

ハムフェア2019のSAGAMI-NETブースで頒布したDVD-ROMに収録されているDMR始めました(PDF)、置いておきます。28-Jul-2019TeXでごにょごにょはこの伏線だったりするのですが。ソースコードもGitHubに上げておきます。58.90kg(16:30)

06-Oct-2019
[実験中]

試しにDAPNETGatewayのIPv6対応(と言ってもgetaddrinfo()使った形に書き直すだけ)をやってみたのですが、そんなに難しくなかったのでちょっとGitHubに転がしておきます本家のIssuesも立てていますので、万一コードがマージされるような事態になったら自分のリポジトリは消します。

この手の作業に慣れた人ならおそらく半日(数時間?)もあれば終わるのでしょうけど、三つの問題にハマりました。

IPv4←→IPv6フォールバックについては、現時点では考慮していません。webブラウザのような不特定のサイトに繋げるようなアプリケーションでは必須かもしれませんが、特定のサーバに(場合によってはIPアドレス直打ちで)繋げるようなものなので。58.75kg(16:50)

22-Oct-2019補足:IPv6ブランチにマージされちゃいました。少し細かい部分の見直しも必要そうなので、こちらの作業用リポジトリはしばらくの間残ります。