ISDNの全銀手順 解決？

ISDNの標準標本が存在していないため、何をどうすれば正常な状態に戻るかわからない。
なので、考えられることは全部やった。
全部やっても、結局直らなかったのだが、偶然繋がりそうな環境になった。

まず、こちらが持っているリソースを紹介。

・ISDNモデム AtermIT42 破損疑い
・ISDNモデム V30Slimオレンジ(現行は薄青)
・WindowsXP 32bit ノートPC
・Windows7 64bit ノートPC

最終的に、ISDNモデム V30SlimオレンジとWindowsXPの組み合わせになった。

IPアドレスを編集する際に、DNSサーバーを未指定にすれば、
ドメインからIPアドレスを引くことができなくなるため、セキュリティが少し上がる。
ルーターのNAT越しならば、攻撃されないだろう。
ただし、内部の攻撃からは脆いので、特定のIPアドレス以外弾く指定にすればだいぶ固くなる。
アンチウイルス入れる場合は、内部LANにプロキシを入れてそいつをIPアドレスで指定してやれば、定義ファイルの更新ができる。ESETで確認済み。
================================================
================================================

当初、Windowsサーバーが壊れているとは想定していなかった。
なぜなら、SQLサーバーは普通に稼働しているからだ。
AtermIT42では、ER信号の状態が分からなかったが、
V30Slimだと、USBを接続しただけでER信号が点灯するため、この状態はオカシイと思った。
現に、発信と着信接続が出来ない、また、TA内設定が確認出来ないなど、普通じゃない動きをしていた。
うちの環境だと、着信接続からモデムのチェックを外せば、ER信号は消えるのだが、
こいつは出しっぱなしである。
ここから、新しいPCで環境作りを行うことをやり始めた。

なお、業務に関しては、VPNから受信するファイルをゲットできることが判明したため、
私が手動で取り込みを行っていた。
この段階である程度の稼働状態を維持できている。
ソフトウェアの情報は、作成元からもらっていないため、解析だけでここまでたどり着いている。オカシイと思う。
================================================

全銀のソフトウェアはCD-ROMが紛失状態になっていたため、サーバーからフォルダ毎コピーした。
ソフト起動時に、毎度コピー防止の警告が表示されるが、スキップしても動作には問題ないらしい。
これを解除するには、CD-ROMにあるプログラムを使って数値計算をする必要がある模様。見つかるのか？
まぁ再起動しなければ問題ないだろう。
================================================

その後、全銀ソフトがVPNを作るのではなく、Windows標準の着信接続(PPTP)でVPNを作って、TCP/IPで接続要求していることが判明した。
当初、他社の接続専門会社から、うちのネットワーク内のIPアドレスに接続要求を飛ばしていると言っていたため、
別セグメントでルーティングも組んでないのにどうやって、アクセス出来るの！？
と驚いて試行錯誤をしていたが、その後、台帳が古いと判明した。
正確なIPアドレスは着信接続時に振っているアドレスだった。
それが解決したことで、着信接続と指定されていたポートが空いていれば、
受信できるだろうという確信が持てた。
でも台帳が古いと言ったのはけっこう根に持っている。
判明したきっかけは、私がVPN超え出来ないから、
着信接続で振っているIPアドレスに指定を変えてくれと行ったところ、もうその数値になっている、という返事が帰ってきた。
はぁ・・・・・・、といいながら電話を切ってたような気がする。許さないぞ。
================================================

着信が確認できたあと、全銀ソフトウェアに接続要求が来るようになった。
しかし、接続異常で切断される。
開始要求は来て、返答をしているようだが、どうにもデータが送られてきているようには見えない。
もしかしたら、ISDNの中間経路で微妙な断線が発生しているのか？ということで、MDFから線を伸ばして、最短経路を作った。
このとき、モデムのUSBを抜いたり、無線を接続したり、有線LANを抜いたりしていた。

今思えば、これがいけなかった。

これの偶然の組み合わせで、Windows7の構成で、受信できるようになった。
微妙に断線しているか、ノイズが乗ったせいで局地的にドロップが発生していると予想つける。
このあと、リモートできるようにしたり、配線を丁寧にしたりしてたところ、再度繋がらなくなった。

昼間はつながったのだが、繋がらなかったのは夕方以降ということで、NTT基地局内で交換器トラブルでも起こっているのか？と仮設を立てた。

早急な解決のため、NTTも巻き込む。標準が分からないので、出来る手段は何でもやる。
=================================================

このへんで、別の会社で使っている別の建物のISDN回線を使って、pingテストをする。
これを行うことで、ドロップ率を確認することが出来た。
Winodws7構成の場合、普通のpingでも、ドロップしているのが確認出来た。
１０秒間ぐらい普通にやりとりしたあと、２回分のpingがドロップしている。
MTU設定の通り抜け不可能の症状に似ているが、MTU578にしても直ることはなかった。
パケットキャプチャのWireSharkで見る限りでも、ちゃんと578でやり取りしているが、
一部のフラグメントパケットが途中でやり取りできなくなっている。

うーん？50msの状態でこの状態だと、100msの環境だとブツブツなんだよなぁ。

よくわからないので、この間にNTTの施工を行ってたが、結局判明しなかった。
ちなみに、ER信号出した状態で、接続試験テストをしていたのだが、これはだめだ。
必ず試験が失敗するようになっているので、確実な試験は、TAからUSBを抜いてテストするのが必須となる。
NTTの人もノウハウが薄れているため、何が正常な状態なのか把握していない模様。

このへんで、ISDNの危険性を感じてきた。
================================================

テストを繰り返したあと、WindowsXPで無線LANとISDNモデム V30Slimオレンジの組み合わせで、全銀ソフトウェアのファイル受信が成立した。
信号品質は良くなっているため、受信速度は上がっている模様。

あーもうこれ維持する形で行くぞ！っということで、何も触らず、リモートデスクトップで状態確認しながら、維持することにした。
================================================

しかし、無線LAN接続のため、いつリモートできなくなるかがわからない。
ので、有線接続にして安定化させた。

しかし、その後、再度ファイル受信が失敗するようになった。

嫌だ。もう逃げたい。何が正しいのかわからない。
================================================
================================================

でも、こんな状況でも、心当たりがある。
きっかけは有線LANが認識された途端にpingのドロップ現象が発生する。
Windowsは当時、モデム・64K ISDNから、1.5MbitADSLになったり、
一部、ギガ化していることもあって、Win98SE→Win2000の間で、
RWINの初期値が変更されていることを知っている。
RWINはReceive WINdow sizeという。

まず、MTUの1500バイトを受信するたびに、サーバーから、受信したよ信号(ACK)を出すと、受信-送信のやりとりが増えるため、実際のデータのやり取り以上に、通信しているため、スループットが落ちる。
これを解決するために、8000バイトまでまとめて送信、受信側がそのキャッシュをためたら、またデータ送ってと信号を出すと、やり取りが減るため、スループットが増える。

Win98SEは8192バイト、Win2000/WinXP初期は16384バイト、しかし、WinXP後期だと、65535バイトと言ってるやつもいる。
この数値は、高速なネットワークになる分には問題ない。
ただ、速度が遅いだけだ。
しかし、速いネットワークから、遅いネットワークにした状態で、このセッティングだとどうなるか？

送信側はScalingを8192バイト、受信側が65535バイトだった場合、
送信側は8192バイト送るが、それで止まる。受信側のACKを待つからだ。
受信側は65535バイトまで待つが、送られてこない。送信側が送ってないからだ。
一定時間待った後、遅いんじゃ再送しろ信号を出すまで、送信側は通信を停止している。

つまり、この設定を適切に行わないと、リプレースした瞬間にISDNが正常に受信できなくなるのだ。
過去の話だと、RWIN値で信号がドロップするという話はなかった。
しかし、遅くなった場合、これが顕現するのだ。

実際は、RWINだけでなく、MTUによって、断片化したフラグメントの受信状況もよるのだが、フラグメントがあった場合は、再送してっていう信号を出すのだ。
今回はそれっぽい気配がなかったため、RWINだと思っている。
=================================================

Windows7では、この辺を考えないように、RWINの自動チューニング機能がある。
だから、Win7だと、上手くいかないこともあるだろう、と思っていた。
だが、WinXPでも実際発生した。

どっちのPCでも、有線LANを指した途端に、RWIN値の拡大が行われたと思われる。
レジストリには記載されてなかったが、別にnetshでもいぢれるため、
勝手にLAN向けにRWINをいじられた挙げ句にその設定値をISDNでも適用されるというデスコンボが発生している可能性がある。
本当にわからない。共通点は、上手く言ってる環境のLANはBroadCom。
だめな環境はIntelであることだ。もしかしたらドライバで制御している可能性がある。
=================================================

とりあえず、この環境は触らないことにした。
無線LANは怖いが、有線LAN刺すと、また受信不能になる可能性が高い。
なんで、Win7環境に、破損疑いだったISDNモデム AtermIT42を使って、
色々試行錯誤しようと考えています。
USB経由だと64bitは対応しないらしいので、USBシリアルポートを使ってシリアル接続でやってみます。

で、レジストリやnetshを使って、色々無効化したり、WireShackでパケットキャプチャしたり、色々試す予定です。
ちゃんとリプレースしたいから、色々やる予定です。

でも、最終的にはISDN接続は撲滅させます。
技術情報がない技術なんて、ただのブラックボックス。
俺みたいな犠牲者をこれ以上だしてはいけない。
俺は運が良い方で、中学生のころに、ADSL研究してたから、変にRWINを知ってただけだ。
MTUは今でも、VPNの通信ドロップに関わっているからなんとかなるのだが、
RWINはもうわかんねぇ。ISDNもだめだ。何が正常なのか分からん。
ちゃんと、歴史通りにブロードバンド化するべきだ。