D-STARシステムについて
D-STARは平成10年に当時の郵政省からJARLが「アマチュア無線の周波数の有効利用を図るためのデジタル化」技術の
調査検討について委託を受けたことから始まりました。そのため、調査検討の課程で総務省の当時の考え方などもふまえた
システムとなっており、ネットワーク接続が日本では管理サーバー方式となっているのもそのような理由からです。
JARLがD-STARの運用を始めて20年になりますが、当初のゲートウェイサーバーはレピータのみを接続するもので
ルーター --- dsgwd --- レピータコントローラー
という接続のみでした。郵政省(総務省)からの委託ですのでレピータ装置等はJAIAに要請して入札にて行い、
応札してくれたのはアイコムのみでしたので、上記のdsgwd、レピータコントローラーはアイコムの製品となりました。
皆様ご存じのとおり、当初のシステムはゲート越え先の交信を聞くことはできず、レピータから返るRPT?、UR?で
あいてるかな？使ってるかな？と判断するしかありませんでした。
これをなんとかならないかと考えましたが、JARLのD-STARであり、メーカーに依頼すると莫大な費用もかかります。
レピータは製品として出ているものですので、今から変更もままなりませんので委員会で現状のシステムに追加する方法を
開発することとし、5年前に
ルーター --- dsgwd --- xchange --- レピータコントローラー
|
--- multi_forward --- ユーザープログラム
という構成にすることとし、管理サーバーにはhole_punchdを追加する等のプログラム開発、試験を進めてきました。
ただし、D-STARはアマチュア無線ですからユーザーから利用料等を徴収していませんので、携帯電話のように
潤沢な資金はありませんから、別に同等のシステムを用意して行うということはできませんので、現行のシステムで
現行の交信に対する支障を最小限に抑えて行うことしかできません。このmulti_forwardは開発当初は試験プログラム
という位置づけで、その検証をするためさらにユーザープログラムの試験として開発したのがdmonitorです。
そのため、dmonitorはあくまで試験プログラムですので、使用していただくのはかまいませんが、一切のサポートは
できませんとしています。
以上のようないきさつから、5年前から試験を始めましたが時間を要し、概ねの目処がついた一昨年7月に上記の
multi_forward及びhole_punchdサーバーへのユーザーからの接続を解禁しました。それに呼応してアイコムが自社製品に
DVレピータモニター機能を搭載してくれました。
現在、このような構成で運用していますが、上記のxchangeもまだ完成したプログラムではありません。
皆様お気づきと思いますがxchangeを導入後、ゲート越え交信中に他のレピータ等から割り込みがあった際に交信が途切れてしまう
現象が出ているはずです。これについては、当初のdsgwd、レピータコントローラーだけではおこらない現象です。
なぜ、こうなるかというと新たに挟んだxchangeで必要な信号がやりとりできておらず、その原因は仕様書に記載された
パケット転送の方式をきちんと守らないといけないことが判明し、現在も修正中です。
D-STARは管理サーバー方式をとっていますので、仕様書にしたがった運用をしていただかないと大多数のユーザーが運用している、
DRモードによる運用に支障を来すこととなります。すぐに、海外ではどうのと言われる方がおられますが、ここは日本ですので
国内の電波法令に従い運用しなければなりませんので、ご理解いただければと思います。
以前よりユーザープログラムが動いていることは認知していましたが、管理サーバーに顕著な障害はありませんでしたので、
黙認していました。しかし、最近になり上記のxchangeの修正をしたところ動かなくなったと、申し入れがありましたが、
特定のプログラムをブロックしているのではなく、これまでにもご案内してきておりますが、仕様書に合致した状態にすれば動作
するものです。
D-STARの運用ガイドラインではD-STAR運用当初から
4-2-5 D-STARに関するその他の規定
（1) デジタル無線機および周辺機器を自作するときであって、D-STARを利用する場合は、
JARLが公表している仕様に準拠させること。
－以下略－
4-3 利用の停止
次の場合、JARLは利用者および管理者に対しシステムの利用を停止させることができる。このとき利用者および管理者に
発生した損害等についてはJARLは責任を負わない。
（1) 利用者および管理者と連絡がとれなくなった場合。
（2) 利用者および管理者が本指針から逸脱した場合。
（3) 利用者および管理者がネットワークの運営に支障を与えた場合。
（4) 申込みおよび届け出の内容に虚偽の記載、あるいは不十分な記載が判明した場合。
（5) 利用者および管理者の死亡や解散等でネットワークの利用ができなくなったとJARLが判断した場合。
（6) その他、JARLが必要と判断した場合。
と定められており、日本国内での運用にはこのガイドラインを遵守していただく必要があります。
先に黙認と書きましたが、仕様書には
5.1 有線通信パケット
(2) インターネット上の局より GW を通して端末無線局へのアクセス
－前略－
既存のJARLのD-STARネットワークに接続する場合は、既存のネットワークとの整合性を保証するため、JARLの検証・承認を得ること。
また、JARLから割り当てられた問合わせIDを使用すること。
8.4 ポート番号
転送用ポート番号の使用状況は次の通りです。
50000 DPRS
50001 dstatus
50002 multi_forward
50003–50099 予約
50100-50999 ユーザー定義
51000 multi_forward で使用
51001- 未使用
ユーザー独自に開発したプログラムで使用する場合は、JARLに届け出を行い、割り当てを受けるものとする。
と定められていますが、これは、ポート番号の競合を避けるためです。
当該ソフトウェアは、ポート番号の指定を受けることなく(届出なく)、50100を使用していました。
これは、ガイドラインに抵触することとなり、接続を解禁していない時期から勝手に接続し、
正常な動作を確保するためシステム改修をしたら、自分たちのやりたいことが出来ないので動くようにしてくれ
と言われても対処できないということは自明の理です。
さらに、動かなくなったという声があったため対処方法を下記に掲載しましたが、申し入れ書によると、開発者から
「インターネットを使用しているので遅延は避けられないので対処できないと言われた」とありますが、
このパケット転送の仕様は、dsgwdとxchange、multi_forward、アプリ間のものであり、
dsgwd、xchange、レピータコントローラー間もこの仕様に従っています。そのような理論になると、
通常のゲート越え交信でもインターネットを経由するものですのでできなくなるはずですが、そのようなことはありません。
以上のとおり、一般ユーザーの方にはあまり関係しませんが、独自のアプリや接続で運用したい場合は、D-STARシステムは仕様に
従った運用をしていただかないと、他のユーザーの方に迷惑をかけることとなります。アマチュア無線家は短波の有効性の発見から始め、
メーカーを超える能力を持っていると思っています。研鑽に努め所定の手続きをしてさらなる向上にご協力いただきたいと思います。
また、現在公開されている仕様書は、英文に翻訳され全世界に公開されています。このため、D-STARの基本的な要件を変更することは、
上位互換を除いてできません。（仕様書に準拠しているシステムの変更を伴わないことが条件です。）
当初掲載の記事
すでにD-STAR技術情報でもご案内させていただいておりますとおり、前月末からタイムアウト対策として、
xchange、multi_forward、dstatus、dprsのアップデートを実施しましたが、一部のレピータで、
これら全てのプログラムでなく、一部のプログラムだけアップデートされているレピータが見受けられます。
このためプログラム間での情報交換の異常で、管理サーバーが正常に稼働していません。
今後、このような状態が続くようであれば、管理サーバーの正常な稼働を確保するため、対策を
実施することになりますので、至急アップデートしていただくようお願いします。
また、JARLのD-STAR委員会が提供しているプログラム以外を接続されている方は、その接続手順を確認
していただくようお願いします。
（正常な接続手順であれば、ブロックされることはありません。）
なお、今回のxchangeのアップデートは、xchangeに接続しているプログラムとの間でタイムアウトが
発生する事象に対応するためのものです。D-STARの音声パケットは、20ミリ秒ごとに12バイトの音声情報
が遅滞なく継続的に受け取れることが必要です。この条件を明示的に確認する方法を、強化しました。
xchangeと接続プログラムの間では、ハンドシェークの手法を導入して、これらを確認していましたが、
タイムアウトが多発することから、これまで、正規の手順以外でも受け付けていましたが、
正規の手順以外は、ブロックするように変更しました。
（特定のプログラムで転送が確認できない場合、次のパケットの処理に移れないため、他のプログラムも
転送できない事象が発生し、タイムアウトになります。）
特定のプログラムがブロックされているのは、このためですのでプログラムの
開発者に連絡の上、至急変更して頂くよう連絡してください。
なお、確認事項は
1．ハンドシェークが手順に則っていない（ハンドシェークが成立しないため、パケットの転送できない）
2．応答パケットが20ミリ秒以内に戻ってこない（次のパケットが処理できない）
3．自動検出ではないのですが、バッファオーバーフローに該当するパケットの送信
の3点です。
下記に実際に確認している1．と3．の不適切な実際の例を示しておきます。
生存確認の要求側のパケットの例
07:46:45.668636 IP xx.x.x.xxx.60005 > xxx.xxx.xxx.xxx.50100: UDP, length 10
0x0000: 4500 0026 0fee 4000 4011 66d3 xxxx xxxx E..&..@.@.f.....
0x0010: xxxx xxxx ea65 c3b4 0012 c429 4453 5452 .....e.....)DSTR
0x0020: 0000 7312 0000 ..s...
に対する応答パケットが、本来であれば上記の要求に対しては赤字で示したマジックナンバーが
仕様書で示された手順（パケット毎に異なる任意の数値で、ゾーンレピータとＧＷとの通信で送られた
パケットの識別として使われ、この数値を返送して届いたことを認識する。）に準拠していない例です。（実際の返答パケットです。）
07:46:45.723745 IP xxx.xxx.xxx.xxx.50100 > xx.x.x.xxx.60005: UDP, length 10
0x0000: 4500 0026 888f 0000 3e11 3032 xxxx xxxx E..&....>.02....
0x0010: xxxx xxxx c3b4 ea65 0012 825a 4453 5452 .......e...ZDSTR
0x0020: 0097 7212 0000 0000 0000 0000 0000 ..r...........
この応答例では、仕様書によれば0000を返す必要があるのですが、0097を返しています。
この値が仕様書に準拠していないため、届いた確認が取れず、次の処理に進めません。
このため、全てのxchangeの転送が出来ないことになります。また、この応答例では、これ以外にも
問題があり、本来10バイトで返答しているにもかかわらず。18バイト送ってきています。
（最後に赤で示した8バイトです。）
この手法は、バッファオーバーフローと呼ばれる典型的なハッキングの手法の
一つです。
また、2．の場合は、仮に応答パケットが正常に受け取れたとしても、20ミリ秒間隔で相手に
届かなければ、音声として復調できないことになります。
D-STAR技術情報のブログ
https://dstar.seesaa.net
にも詳細が掲載されています。あわせてご覧ください。
D-STAR委員会
※ 当分の間、本記事がトップに表示されるようにします。
その他の記事は3段目以降を確認していただくようお願いします。
D-STARは平成10年に当時の郵政省からJARLが「アマチュア無線の周波数の有効利用を図るためのデジタル化」技術の
調査検討について委託を受けたことから始まりました。そのため、調査検討の課程で総務省の当時の考え方などもふまえた
システムとなっており、ネットワーク接続が日本では管理サーバー方式となっているのもそのような理由からです。
JARLがD-STARの運用を始めて20年になりますが、当初のゲートウェイサーバーはレピータのみを接続するもので
ルーター --- dsgwd --- レピータコントローラー
という接続のみでした。郵政省(総務省)からの委託ですのでレピータ装置等はJAIAに要請して入札にて行い、
応札してくれたのはアイコムのみでしたので、上記のdsgwd、レピータコントローラーはアイコムの製品となりました。
皆様ご存じのとおり、当初のシステムはゲート越え先の交信を聞くことはできず、レピータから返るRPT?、UR?で
あいてるかな？使ってるかな？と判断するしかありませんでした。
これをなんとかならないかと考えましたが、JARLのD-STARであり、メーカーに依頼すると莫大な費用もかかります。
レピータは製品として出ているものですので、今から変更もままなりませんので委員会で現状のシステムに追加する方法を
開発することとし、5年前に
ルーター --- dsgwd --- xchange --- レピータコントローラー
|
--- multi_forward --- ユーザープログラム
という構成にすることとし、管理サーバーにはhole_punchdを追加する等のプログラム開発、試験を進めてきました。
ただし、D-STARはアマチュア無線ですからユーザーから利用料等を徴収していませんので、携帯電話のように
潤沢な資金はありませんから、別に同等のシステムを用意して行うということはできませんので、現行のシステムで
現行の交信に対する支障を最小限に抑えて行うことしかできません。このmulti_forwardは開発当初は試験プログラム
という位置づけで、その検証をするためさらにユーザープログラムの試験として開発したのがdmonitorです。
そのため、dmonitorはあくまで試験プログラムですので、使用していただくのはかまいませんが、一切のサポートは
できませんとしています。
以上のようないきさつから、5年前から試験を始めましたが時間を要し、概ねの目処がついた一昨年7月に上記の
multi_forward及びhole_punchdサーバーへのユーザーからの接続を解禁しました。それに呼応してアイコムが自社製品に
DVレピータモニター機能を搭載してくれました。
現在、このような構成で運用していますが、上記のxchangeもまだ完成したプログラムではありません。
皆様お気づきと思いますがxchangeを導入後、ゲート越え交信中に他のレピータ等から割り込みがあった際に交信が途切れてしまう
現象が出ているはずです。これについては、当初のdsgwd、レピータコントローラーだけではおこらない現象です。
なぜ、こうなるかというと新たに挟んだxchangeで必要な信号がやりとりできておらず、その原因は仕様書に記載された
パケット転送の方式をきちんと守らないといけないことが判明し、現在も修正中です。
D-STARは管理サーバー方式をとっていますので、仕様書にしたがった運用をしていただかないと大多数のユーザーが運用している、
DRモードによる運用に支障を来すこととなります。すぐに、海外ではどうのと言われる方がおられますが、ここは日本ですので
国内の電波法令に従い運用しなければなりませんので、ご理解いただければと思います。
以前よりユーザープログラムが動いていることは認知していましたが、管理サーバーに顕著な障害はありませんでしたので、
黙認していました。しかし、最近になり上記のxchangeの修正をしたところ動かなくなったと、申し入れがありましたが、
特定のプログラムをブロックしているのではなく、これまでにもご案内してきておりますが、仕様書に合致した状態にすれば動作
するものです。
D-STARの運用ガイドラインではD-STAR運用当初から
4-2-5 D-STARに関するその他の規定
（1) デジタル無線機および周辺機器を自作するときであって、D-STARを利用する場合は、
JARLが公表している仕様に準拠させること。
－以下略－
4-3 利用の停止
次の場合、JARLは利用者および管理者に対しシステムの利用を停止させることができる。このとき利用者および管理者に
発生した損害等についてはJARLは責任を負わない。
（1) 利用者および管理者と連絡がとれなくなった場合。
（2) 利用者および管理者が本指針から逸脱した場合。
（3) 利用者および管理者がネットワークの運営に支障を与えた場合。
（4) 申込みおよび届け出の内容に虚偽の記載、あるいは不十分な記載が判明した場合。
（5) 利用者および管理者の死亡や解散等でネットワークの利用ができなくなったとJARLが判断した場合。
（6) その他、JARLが必要と判断した場合。
と定められており、日本国内での運用にはこのガイドラインを遵守していただく必要があります。
先に黙認と書きましたが、仕様書には
5.1 有線通信パケット
(2) インターネット上の局より GW を通して端末無線局へのアクセス
－前略－
既存のJARLのD-STARネットワークに接続する場合は、既存のネットワークとの整合性を保証するため、JARLの検証・承認を得ること。
また、JARLから割り当てられた問合わせIDを使用すること。
8.4 ポート番号
転送用ポート番号の使用状況は次の通りです。
50000 DPRS
50001 dstatus
50002 multi_forward
50003–50099 予約
50100-50999 ユーザー定義
51000 multi_forward で使用
51001- 未使用
ユーザー独自に開発したプログラムで使用する場合は、JARLに届け出を行い、割り当てを受けるものとする。
と定められていますが、これは、ポート番号の競合を避けるためです。
当該ソフトウェアは、ポート番号の指定を受けることなく(届出なく)、50100を使用していました。
これは、ガイドラインに抵触することとなり、接続を解禁していない時期から勝手に接続し、
正常な動作を確保するためシステム改修をしたら、自分たちのやりたいことが出来ないので動くようにしてくれ
と言われても対処できないということは自明の理です。
さらに、動かなくなったという声があったため対処方法を下記に掲載しましたが、申し入れ書によると、開発者から
「インターネットを使用しているので遅延は避けられないので対処できないと言われた」とありますが、
このパケット転送の仕様は、dsgwdとxchange、multi_forward、アプリ間のものであり、
dsgwd、xchange、レピータコントローラー間もこの仕様に従っています。そのような理論になると、
通常のゲート越え交信でもインターネットを経由するものですのでできなくなるはずですが、そのようなことはありません。
以上のとおり、一般ユーザーの方にはあまり関係しませんが、独自のアプリや接続で運用したい場合は、D-STARシステムは仕様に
従った運用をしていただかないと、他のユーザーの方に迷惑をかけることとなります。アマチュア無線家は短波の有効性の発見から始め、
メーカーを超える能力を持っていると思っています。研鑽に努め所定の手続きをしてさらなる向上にご協力いただきたいと思います。
また、現在公開されている仕様書は、英文に翻訳され全世界に公開されています。このため、D-STARの基本的な要件を変更することは、
上位互換を除いてできません。（仕様書に準拠しているシステムの変更を伴わないことが条件です。）
当初掲載の記事
すでにD-STAR技術情報でもご案内させていただいておりますとおり、前月末からタイムアウト対策として、
xchange、multi_forward、dstatus、dprsのアップデートを実施しましたが、一部のレピータで、
これら全てのプログラムでなく、一部のプログラムだけアップデートされているレピータが見受けられます。
このためプログラム間での情報交換の異常で、管理サーバーが正常に稼働していません。
今後、このような状態が続くようであれば、管理サーバーの正常な稼働を確保するため、対策を
実施することになりますので、至急アップデートしていただくようお願いします。
また、JARLのD-STAR委員会が提供しているプログラム以外を接続されている方は、その接続手順を確認
していただくようお願いします。
（正常な接続手順であれば、ブロックされることはありません。）
なお、今回のxchangeのアップデートは、xchangeに接続しているプログラムとの間でタイムアウトが
発生する事象に対応するためのものです。D-STARの音声パケットは、20ミリ秒ごとに12バイトの音声情報
が遅滞なく継続的に受け取れることが必要です。この条件を明示的に確認する方法を、強化しました。
xchangeと接続プログラムの間では、ハンドシェークの手法を導入して、これらを確認していましたが、
タイムアウトが多発することから、これまで、正規の手順以外でも受け付けていましたが、
正規の手順以外は、ブロックするように変更しました。
（特定のプログラムで転送が確認できない場合、次のパケットの処理に移れないため、他のプログラムも
転送できない事象が発生し、タイムアウトになります。）
特定のプログラムがブロックされているのは、このためですのでプログラムの
開発者に連絡の上、至急変更して頂くよう連絡してください。
なお、確認事項は
1．ハンドシェークが手順に則っていない（ハンドシェークが成立しないため、パケットの転送できない）
2．応答パケットが20ミリ秒以内に戻ってこない（次のパケットが処理できない）
3．自動検出ではないのですが、バッファオーバーフローに該当するパケットの送信
の3点です。
下記に実際に確認している1．と3．の不適切な実際の例を示しておきます。
生存確認の要求側のパケットの例
07:46:45.668636 IP xx.x.x.xxx.60005 > xxx.xxx.xxx.xxx.50100: UDP, length 10
0x0000: 4500 0026 0fee 4000 4011 66d3 xxxx xxxx E..&..@.@.f.....
0x0010: xxxx xxxx ea65 c3b4 0012 c429 4453 5452 .....e.....)DSTR
0x0020: 0000 7312 0000 ..s...
に対する応答パケットが、本来であれば上記の要求に対しては赤字で示したマジックナンバーが
仕様書で示された手順（パケット毎に異なる任意の数値で、ゾーンレピータとＧＷとの通信で送られた
パケットの識別として使われ、この数値を返送して届いたことを認識する。）に準拠していない例です。（実際の返答パケットです。）
07:46:45.723745 IP xxx.xxx.xxx.xxx.50100 > xx.x.x.xxx.60005: UDP, length 10
0x0000: 4500 0026 888f 0000 3e11 3032 xxxx xxxx E..&....>.02....
0x0010: xxxx xxxx c3b4 ea65 0012 825a 4453 5452 .......e...ZDSTR
0x0020: 0097 7212 0000 0000 0000 0000 0000 ..r...........
この応答例では、仕様書によれば0000を返す必要があるのですが、0097を返しています。
この値が仕様書に準拠していないため、届いた確認が取れず、次の処理に進めません。
このため、全てのxchangeの転送が出来ないことになります。また、この応答例では、これ以外にも
問題があり、本来10バイトで返答しているにもかかわらず。18バイト送ってきています。
（最後に赤で示した8バイトです。）
この手法は、バッファオーバーフローと呼ばれる典型的なハッキングの手法の
一つです。
また、2．の場合は、仮に応答パケットが正常に受け取れたとしても、20ミリ秒間隔で相手に
届かなければ、音声として復調できないことになります。
D-STAR技術情報のブログ
https://dstar.seesaa.net
にも詳細が掲載されています。あわせてご覧ください。
D-STAR委員会
※ 当分の間、本記事がトップに表示されるようにします。
その他の記事は3段目以降を確認していただくようお願いします。
