ここではほんとの数字を使ったり、名称を使うと生めかし過ぎるので、控えることに しました。ボカシを入れることにしました。
よくこういうときに、たとえば、パ○ソニックとか書いて、公表はしてないぞと みせかける人もいますが、これはおかしい。これならだれだってパナソニックと 想像できてしまう。こういうのはボカシとは言わない。 かえって、なにかな？と興味を引かせるのだから こういうのは「強調」というと思う。だから私はやらない。 ○○○○○ク、くらいならやるかもしれないが。(^_~;
匿名でなくてもかまわなそうと判断した部分はそのままにしてあります。
マスター
サンヨー
IIJ4U
サンヨーとはメイルでは拉致があかないと思い電話をした。
（案の定、DDI-Pocketとサンヨーではタライ回しされた）
IIJ4UのＨＰにはつぎのようなことが書いてありました。

■ SANYO RZ-J700をご利用のお客様へ SANYO RZ-J700を32kパケット方式でご利用の場合、当社AirH"用アクセスポイントでは正常に接続できない場合があることを確認しております。詳しくは、DDIポケットにお問い合わせください。 ※RZ-J700はフレックスチェンジ方式、128kパケット方式には対応しておりません。 DDIポケット H"、feelH"、ポケット電話から ： （局番なし）157 一般加入電話、携帯電話・PHS等から ： 0077-7-157

と、ありましたから、まずは2003.8.31にDDI-POCKETにJ700で157に電話をかけて説明を試みる。
想像通り、よくわかっていない。折り返し、返事を差し上げますのでお宅様の 電話番号をというので教え、その数分後に電話がかかってくる。 サンヨーのJ700はファームウェアがバージョンアップしていますので お近くのサンヨーのお店に持ち込んで直してもらってくださいとのこと。 いかし、これは疑問。もしそうなら、他社のように、掲載があるはず。 しかし、そう言って逃げられたので、そうですかと引き下がる。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Sun Aug 31 15:56:41 2003
Date: Sun, 31 Aug 2003 15:56:38 +0900 (JST)
From: Masashi Kamii
To: sales@master-corp.co.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: 本日発送致します

> DPC-SLZ　のご注文ありがとうございました。

荷物が無事に届きまして、さっそく よろこんでSL-C760とSANYO RZ-J700を結んで
ためしてみたのですが、どうにもおかしなところがあります。
こちらでも、さらに調べるつもりですが、なにか、こういったことで
情報を持っていたらお知らせねがえないでしょうか。

私はIIJ4Uに入っていますので、すぐにAirH"接続オプションwo
をオンにしてIIJ4UとＪ７００で３２Ｋパケットをこころみました。
しかし、途中でうまく交信できません。ハンドシェークはうまくいきます。
しかしデータ交換でこちらからのセンドはうまくいっても
むこうからくるレシーブがちゃんと機能しないようです。
いままではPRINで少しためしていたのですが、そのときはちゃんとSEND/RECVが
できていました。同じく DPC-SLZ でPRINにつなげると、いままでのように
ちゃんとSEND/RECVができます。
リナザウではなくてデスクトップのマックからIO-DataのUSB-AH64だと
ちゃんとIIJ4Uに３２Ｋパケットでつながります。
USB-AH64とこのDPC-SLZとで何か微妙に違うことがあるでしょうか？
そのあたり、なにかわかっていればお教えください。

---

From sales@master-corp.co.jp Sun Aug 31 17:33:06 2003
Date: Sun, 31 Aug 2003 17:32:01 +0900
From: sales@master-corp.co.jp
To: Masashi Kamii
Subject: Re: 本日発送致します

神居様

On Sun, 31 Aug 2003 15:56:38 +0900 (JST)
Masashi Kamii wrote:

こちらで試したのは、prin、@nifty、asahi-net等ですがいずれも神居様の様な
症状は経験しませんでした。
残念ながらIIJ4Uに関してはまったく情報をもっておりません。
（ただ従来の機器との接続でIIJには若干癖が有るような話は聞いた覚えがあり
ます。）
考えられるとしたらATコマンドか、IIJ4U側のアクセスポイントの問題かと
思われますが確信を持って言えるという事では有りません。
取りあえずザウルスで設定しますATコマンドの部分をUSB-AH64の設定と同じに
するか「AT&F（工場初期化）　AT（コマンド無し）」にしてみてはいかがでしょうか？
あまりお役に立てず申し訳ございません、よろしくお願いいたします。

sales@master-corp

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Sun Aug 31 17:17:38 2003
Date: Sun, 31 Aug 2003 17:17:37 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Air-H setzuzoku OPTION

pfzzzzzXX です。神居雅志です。
昨日、DDI-Pocketのほうを「つなぎ放題」コースで契約しなおしをして
IIJ4UのほうをAir-H"接続オプションをオンにしました。
というのはDDI-POCKETのサンヨーRZ-J700からPRINへの接続は
３２Ｋパケットで順調にいってたからです。
PDAはリナザウ(SL-C760)を利用しています。
しかし、IIJ4U Air-H"接続のほうでためしてみましたら、うまく
接続しません。 telnet をよく使うのですが、
ユーザ名、パスワードのネゴーシエイトまでは
普通にいくのですが、そこで止まってしまいます。
テスト用にと思い、UDPの送受だけをするプログラムを作りためしてみたところ
ザウルスからホストへの送信はうまくいきますが、逆の
レシーブが失敗します。これではせっかくつなぎ放題に変えた意味が
ありません。困ったので
https://help.iij4u.or.jp/HelpDesk/OptionAirH/ に、
こういう、以下の文章がありましたので
-----ここから----
SANYO RZ-J700をご利用のお客様へ

SANYO RZ-J700を32kパケット方式でご利用の場合、当社AirH"用アクセスポイントでは正
常に接続できない場合があることを確認しております。詳しくは、DDIポケットにお問い
合
わせください。
-----ここまで-----
とありましたので、１５７にかけて、質問をしたところ、
「RZ-J700」のファームをバージョンアップしてくださいという返答でした。
しかし、これはちと信じられません。PHS機種をRZ-J700に変えたのは今年の４月ですし、
サンヨーのＨＰを調べても、そのようなことを見つけることができません。
はたして、この、「RZ-J700」のファームをバージョンアップしてください」
というのは正しい回答でしょうか？
そちら(IIJ4U）でわかっていることを教えてください。
私は原因は別だろうと思っているのですが、まだ特定できていません。

---

From support@iij4u.or.jp Mon Sep 1 16:49:29 2003
Date: Mon, 01 Sep 2003 16:49:27 +0900
From: support@iij4u.or.jp
To: kkkkk@ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION
Cc: support@iij4u.or.jp

神居 雅志 様

平素は、弊社サービスをご利用いただき、誠にありがとうございます。

> サンヨーのＨＰを調べても、そのようなことを見つけることができません。
> はたして、この、「RZ-J700」のファームをバージョンアップしてください」
> というのは正しい回答でしょうか？
> そちら(IIJ4U）でわかっていることを教えてください。
> 私は原因は別だろうと思っているのですが、まだ特定できていません。

ユーザサポートページにてご案内しておりますように、SANYO RZ-J700
を 32kパケット方式でご利用の場合、AirH"用のアクセスポイントにて正
常に接続できない場合があることを確認しております。

しかしながら、弊社ではお客様にご利用いただく機器について詳細な情
報がございません。そのため、対処方法についてサービスの提供元であ
る DDIポケットへご相談いただくようご案内致しております。

既に DDIポケットへお問い合わせいただき、ファームウェアのバージョ
ンアップについてご案内があったとのことですが、ファームウェアにつ
きましては機器の製造元である SANYO にて提供されているかと存じます。

恐れ入りますが、まずは SANYO へお問い合わせいただき、ファームウェ
アのバージョンアップをお試しいただきますようお願い致します。

今後ともよろしくお願い致します。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Tue Sep 2 10:52:07 2003
Date: Tue, 2 Sep 2003 10:52:07 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

ご返事、ありがとうございました。その後の進展状況をお知らせします。
pfzzzzzXXの神居です。
ご返答のほどよろしくお願いします。

> 恐れ入りますが、まずは SANYO へお問い合わせいただき、ファームウェ
> アのバージョンアップをお試しいただきますようお願い致します。

今朝、まずサンヨーの修理の窓口に電話をし、そこからフリーダイアルの
別の番号に電話するように言われ、そこにかけると、折り返し、こｔらに
でんわがかかってきて、そしたら、また電話番号を教えられ、それがさっきの
ｄん和番号だったりして、なかなか最後まで到達しませんでしたが、
いよいよ最後まで到達して、聴いた返事が、「ファームウェアの更新は
今年の１月以降はありません。お客様のは４月に購入なので、新しいのが
入っている」ということでした。

こちらで、pppの設定で、option.ttyS0あたりに、いろいろなことを
書いてためしてみました。いまもまだトライ中ですが。
MRU,MTUを変える。圧縮を有無にする。noccpにするなどためしていますが、
いまだに成功はしていません。それと、IIJ4U以外でためしたのは
prin、@nifty、asahi-netです。これらの場合はちゃんとつながります。
天下の、技術のIIJですから、きっと、シビアな設定を
しているのだろうと想像できます。私は技術のすばらしさでIIJを
選びましたから。
そこで、いったいどのあたりがシビアになっているかお教えねがえないでしょうか。
それをヒントにさらにテストをしたいと思います。

---

ご返事ありがとうございました。 では、そのように掲載させていただきます。

---

From support@iij4u.or.jp Tue Sep 2 19:59:50 2003
Date: Tue, 02 Sep 2003 19:59:47 +0900
From: support@iij4u.or.jp
To: kkkkk@ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION
Cc: support@iij4u.or.jp
Sender: support@iij4u.or.jp

神居 雅志 様

平素は、弊社サービスをご利用いただき、誠にありがとうございます。

> 今朝、まずサンヨーの修理の窓口に電話をし、そこからフリーダイアルの
> 別の番号に電話するように言われ、そこにかけると、折り返し、こｔらに
> でんわがかかってきて、そしたら、また電話番号を教えられ、それがさっきの
> ｄん和番号だったりして、なかなか最後まで到達しませんでしたが、
> いよいよ最後まで到達して、聴いた返事が、「ファームウェアの更新は
> 今年の１月以降はありません。お客様のは４月に購入なので、新しいのが
> 入っている」ということでした。

ご利用のデータ通信端末(SANYO RZ-J700S)についてご確認いただき、誠
にありがとうございました。

データ通信端末(SANYO RZ-J700S)のファームウェアは適切に更新されて
いるにも関わらず AirH"接続オプションでの接続が出来ないとのことで
すので、本件につきましては、弊社にて調査を行わせていただきたいと
存じます。

お客様のご利用いただいている端末等以下の項目について、大変お手数
ではございますが、改めて、詳細にお知らせいただきますようお願い致
します。

・接続にご利用の端末
・データ通信端末(SANYO RZ-J700S)とご利用の端末を接続いただく際
の通信ケーブルを含む機器
・データ通信端末(SANYO RZ-J700S)の発信者番号
・データ通信をご利用いただいている地域(都道府県、市町村まで)
・ご利用のアクセスポイント番号
・接続をお試しいただいた詳細な時刻

お客様よりお知らせいただきました上記の情報を元に、弊社にて可能な
範囲で調査を行います。

今後ともよろしくお願い致します。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 3 00:48:29 2003
Date: Wed, 3 Sep 2003 00:48:28 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

ご返事、ありがとうございました。
pfzzzzzXXの神居です。
説明の都合上、長文になるかと思いますが、ご容赦ください。

> すので、本件につきましては、弊社にて調査を行わせていただきたいと
> 存じます。
>
> お客様のご利用いただいている端末等以下の項目について、大変お手数
> ではございますが、改めて、詳細にお知らせいただきますようお願い致
> します。
>
> ・接続にご利用の端末
> ・データ通信端末(SANYO RZ-J700S)とご利用の端末を接続いただく際
> の通信ケーブルを含む機器
> ・データ通信端末(SANYO RZ-J700S)の発信者番号
> ・データ通信をご利用いただいている地域(都道府県、市町村まで)
> ・ご利用のアクセスポイント番号
> ・接続をお試しいただいた詳細な時刻

接続の設定条件は私の http://spock.ss.u-tokai.ac.jp/~kkkkk/のほうにも
列記してありますので、そちらを見ていただいてもかまいません。

PDA端末は SHARP SL-C760 通称「リナックスザウルス」です。中身のOSは Linux 2.4.18 です。
PHS端末はサンヨーのRZ-J700です。
そして、これを結ぶケーブルはDPC-SLZという単なる電圧変換器です。
SL-C760の１６ピンポートにシリアルの端子が出ていて、（これはＴＴＬレベルの
電圧）それと、J700にはモーデムが内蔵されていますので、そこの端子と
つなぐだけのものです。
データ通信端末(SANYO RZ-J700S)の発信者番号は 0705552XXXX です。
地域は東京都多摩市です。
アクセスポイントは 0570570439##61 です。
で、いまから、試してみます。
いちおうデバッグ情報を取るために、手動で
% pppd call ファイル名 debug kdebug 7 logfile zlog
として起動してログをzlogファイルにとるようにしました。
いま強制的に切りました。
９月３日００：０９〜００：１２です。
zlogファイルの中身はこうでした。
% cat zlog
Removed stale lock on ttyS0 (pid 1956)
abort on (NO CARRIER)
abort on (NO DIALTONE)
abort on (BUSY)
send (AT&F&C1&D2&K3&S0E0^M)
expect (OK)
AT&F&C1&D2&K3&S0E0^M^M
OK
-- got it

send (ATDT0570570439##61^M)
expect (CONNECT)
^M
^M
CONNECT
-- got it

send (\d\d^M)
Serial connection established.
using channel 3
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS0
sent [LCP ConfReq id=0x1 ]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP ConfReq id=0x2 ]
lcp_reqci: returning CONFACK.
sent [LCP ConfAck id=0x2 ]
rcvd [LCP ConfReq id=0x3 ]
lcp_reqci: returning CONFACK.
sent [LCP ConfAck id=0x3 ]
sent [LCP ConfReq id=0x1 ]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP ConfNak id=0x1 ]
Untimeout 0x20084bc:0x203b440.
sent [LCP ConfReq id=0x2 ]
Timeout 0x20084bc:0x203b440 in 3 seconds.
rcvd [LCP ConfAck id=0x2 ]
Untimeout 0x20084bc:0x203b440.
rcvd [CHAP Challenge id=0x2a <15575b6e88d78f97c4e2b0f7160d147d>, name = "xxxxxxxxx03"]
ChapReceiveChallenge: using 'IRDA1062050718' as remote name
sent [CHAP Response id=0x2a <6a1ccc14b9aba6335d545ecc5d729478>, name = "pfzzzzzXX"]
Timeout 0x200f698:0x203b710 in 3 seconds.
rcvd [CHAP Success id=0x2a ""]
Untimeout 0x200f698:0x203b710.
sent [IPCP ConfReq id=0x1 ]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfReq id=0x1 ]
ipcp: returning Configure-ACK
sent [IPCP ConfAck id=0x1 ]
rcvd [IPCP ConfRej id=0x1 ]
Untimeout 0x20084bc:0x203b6a0.
sent [IPCP ConfReq id=0x2 ]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfNak id=0x2 ]
Untimeout 0x20084bc:0x203b6a0.
sent [IPCP ConfReq id=0x3 ]
Timeout 0x20084bc:0x203b6a0 in 3 seconds.
rcvd [IPCP ConfAck id=0x3 ]
Untimeout 0x20084bc:0x203b6a0.
ipcp: up
local IP address 210.130.58.187
remote IP address 202.232.1.171
primary DNS address 210.130.0.1
secondary DNS address 210.130.1.1
Script /etc/ppp/ip-up started (pid 3601)
Script /etc/ppp/ip-up finished (pid 3601), status = 0x0

そして、つながりましたので、
PDA(SL-C760)のほうからtelnetで大学のマシンにつなぎます。
% script
して記録したのがつぎのものです。
# cat typescr*
Script started on Wed Sep 3 00:08:56 2003
bash-2.05% telnet 150.7.21.XX

login: kkkkk
Password:　　（ここで改行は出力されてる）
Terminated
bash-2.05# exit
exit

Script done on Wed Sep 3 00:17:57 2003
大学のマシンはサンのマシンです。
ここで注意したいのは、Password:とプロンプトが出て、
こちらからパスワードを打って、リターンキーを押したときの動作です。
リターンキーを押したときに反応があります。つまり、画面上で改行が
起こります。そのため、ここまでは動いていると、確認できます。
その後、sunのほうからメッセージが出て、プロンプトが
出るはずなんですが、それがダメなんです。参考のために、無事につながったときの
様子を示します。
# telnet 150.7.21.XX


SunOS 5.8


Entering character mode
Escape character is '^]'.

login: kkkkk
Password:
Last login: Wed Sep 3 00:10:05 from h187.p058.iij4u
Sun Microsystems Inc. SunOS 5.8 Generic February 2000

You have new mail.
(qqqqq-101)%
と、こんな感じになるのが普通です。
それと、lastで調べると、ちゃんとログインはされていることが確認
できています。こんなふうに。
kkkkk pts/1 216.98.180.203.d Wed Sep 3 00:27 ログイン中です。
kkkkk pts/1 h187.p058.iij4u. Wed Sep 3 00:10 - 00:18 (00:08)
kkkkk pts/2 216.98.180.203.d Tue Sep 2 23:51 ログイン中です。
kkkkk pts/1 216.98.180.203.d Tue Sep 2 22:52 - 00:10 (01:17)
kkkkk pts/1 h037.p058.iij4u. Tue Sep 2 21:06 - 21:06 (00:00)
kkkkk pts/1 h037.p058.iij4u. Tue Sep 2 21:03 - 21:04 (00:00)
kkkkk pts/1 216.98.180.203.d Tue Sep 2 19:05 - 19:36 (00:30)
kkkkk pts/1 216.98.180.203.d Tue Sep 2 16:35 - 16:59 (00:24)
kkkkk pts/1 216.98.180.203.d Tue Sep 2 13:53 - 16:35 (02:41)
kkkkk pts/1 216.98.180.203.d Tue Sep 2 13:00 - 13:53 (00:53)
kkkkk pts/2 216.98.180.203.d Tue Sep 2 10:48 - 23:51 (13:03)
kkkkk pts/1 216.98.180.203.d Tue Sep 2 10:23 - 13:00 (02:36)
kkkkk pts/2 216.98.180.203.d Tue Sep 2 00:41 - 00:42 (00:01)
kkkkk pts/1 P061204006211.pp Mon Sep 1 23:44 - 00:45 (01:00)
kkkkk pts/1 P061198131005.pp Mon Sep 1 17:14 - 17:19 (00:05)
kkkkk pts/2 P061198165024.pp Mon Sep 1 16:46 - 16:51 (00:05)
kkkkk pts/3 h108.p057.iij4u. Mon Sep 1 15:37 - 15:46 (00:08)
kkkkk pts/4 h048.p049.iij4u. Mon Sep 1 15:24 - 15:33 (00:08)
kkkkk pts/3 h048.p049.iij4u. Mon Sep 1 15:22 - 15:30 (00:08)
kkkkk pts/3 h083.p058.iij4u. Mon Sep 1 14:31 - 14:39 (00:08)
kkkkk pts/2 216.98.180.203.d Mon Sep 1 13:58 - 16:46 (02:47)
kkkkk pts/1 h019.p058.iij4u. Mon Sep 1 13:33 - 13:33 (00:00)
kkkkk pts/2 h145.p059.iij4u. Mon Sep 1 13:13 - 13:18 (00:04)
（この中でP061204006211などは IIJ4Uではなく、PRINで接続したものです。
PRINの32Kパケットを使って接続したときは、正常につながります。）
ということで、telnetdからログインシェルに移るときにダメに
なるのかなあと。forkしてexecしたときに、何か変化があるのかなあと。
そんなところです。
ちなみに、通信のやりとりができてるのかをごくごく簡単な
プログラムをＣで作成して
udpsend -- UDPで送る。
udprecv -- UDPで受ける。
tcpserv -- TCPで受け答えする
という３つを作り、それぞれsunとSL-C760に用意しました。
（SL-C760のほうではtcpservは不要だから作らなかった）
そして、さきほどの接続状況の中で試すと
SL-C760からUDPで送ると、sunに届く。
SL-C760のほうで telnet 150.7XX1.44 8888 すると、sunのほうでは
ちゃんと8888番ぽートでRECV/SENDができる。（受けは tcpserv プログラム）
sunからUDPを送ってもSL-C760には届かないという状況になります。
しかし、同じことをアクセスポイントを 0423556916##4 つまり回線交換の
ほうの電話番号に変え、回線交換でやってみると
telnet 150.7.21,XX もちゃんとできるし、
sunからUDPで送ると、無事にSL-C760に届きます。
変えたのは電話番号だけです。
pppのoption設定についても、必要かもしれませんので書きます。
/dev/ttyS0
115200
connect '/usr/sbin/chat -s -v -t 60 ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT
"BUSY" "" "AT&F&C1&D2&K3&S0E0" OK "ATDT0570570439##61" CONNECT "\\d\\
d"'
crtscts
nodetach
lock
modem
user "pfzzzzzXX"
usepeerdns
defaultroute
connect-delay 1000
remotename IRDA1062050718
noipdefault
asyncmap 0xa0000
mtu 570
mru 570
以上です。
ほかにも何か必要であればやっておきます。
また私が貴社のほうに出向いてもかまいません。

---

いままではサポートという公の立場での返事でしたので 公表していますが、 これ以降もIIJ4Uとのメールのやりとりがあるのですが、 サポートの人の個人名が出てきてしまいますので それを公表するのはまずいので、 これ以降のメールは公表しません。知りたい人は 個人的に連絡をください。
ただ、かなりの進展がありました。 原因は近いうちに解明されると思います。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 3 22:54:06 2003
Date: Wed, 3 Sep 2003 22:54:06 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

ＸＸ様、神居です。
さきほどはお電話ありがとうございました。

いま、テストしていて気づいたことがあります。
% telnet 150.7.21.XX してユーザー／パスワード認証まではいくと、
また ifconfig ppp0 で見ているとキーを打つたぶに
送信パケットが増えているようだと、今日の電話で申しあげましたが、
Username: kkkkk
Passwd:
のあと、改行が現れるのが特筆すべきことと言いましたが、
気になったので
その後、エコーバックがないのにもめげずに、コマンドを打ってみました。
loopという独自のコマンドなのですが、そうすると、
大学のqqqqq(qqqqq)というサンのマシン（別ルートつまり光のＢフレッツから）の
ほうでログインしてモニタをしているほうで
% netstat -a | fgrep telnet
してみると、たとえばこんなように
qqqqq.telnet h248.p059.iij4u.or.jp.1049 2120 148 24864 0 ESTAB
^^^
なっていて、いつまでたっても 148が減りません。つまりサンから見ての送信が
ある文字だけ（１パケット分か？）
止まっています。
この表の読み方は
DISPLAYS
Active Sockets (First Form)
The display for each active socket shows the local and
remote address, the send and receive queue sizes (in bytes),
the send and receive windows (in bytes), and the internal
state of the protocol.
となています。
しかし、コマンドは読み込んでいるので
サンのほうで % ps -ef をしてやるとたしかにコマンドが
実行されているのがわかります。
つまりサン側からの送信がストップしたままになっています。
このような状況は別のlinuxマシんでも起きています。
とりあえず、いまわかったことをお知らせしました。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Thu Sep 4 01:39:42 2003
Date: Thu, 4 Sep 2003 01:39:41 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

さらに、いま、逆方向のtelnetをためしてみました。
そうすると、
qqqqq.47264 h046.p049.iij4u.or.jp.8887 0 0 24820 0 SYN_SENT
でとまったままになります。
つまりTCP接続だと、ハンドシェークの途中、SYN_SENT状態から先に進まなく
なります。
どうも、あれこれ試してみると、１パケット送られないものがでるような
気がします。そのため、その１パケットが送られない状態がしばらく
続くのでTCP接続が終了したりするんではないかと。
何かの拍子に１パケットだけこぼす？

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Fri Sep 5 11:30:27 2003
Date: Fri, 5 Sep 2003 11:30:26 +0900 (JST)
From: Masashi Kamii
Message-Id: <200309050230.h852UQFT023601@qqqqq.ss.u-tokai.ac.jp>
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

おはようございます。まだ興奮冷めやらぬ状態ですが、
パケットサイズの増減をしたら、センドするパケット長が４４までは
送れます。しかし４５（以上）になると、送られずに溜まったままに
なってしまいます。

ただ、これだけでは、まだ説明がつかないこともありますので、
引き続き、調べておきたいと思います。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Fri Sep 5 16:45:06 2003
Date: Fri, 5 Sep 2003 16:45:04 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

そろそろ、こちらとしてやっておくべきことはなくなりつつありますが、
今日、行ったことでの現象を説明しておきます。
PDAとsunという言葉でローカルサイドとリモートサイドを現わすことにします。

前回パケット長が４４以下ならいいといいましたが、そうでもないことが
わかりました。もっとぐっと少ない数でないとダメなこともありました。ですので
４４というのは的確な数ではありませんでした。
つぎにsunからPDAに向けてtelnetしますと、ESTABLISHEDまでは行かず
SYN_SENTで止まってしまうと以前、言いましたが、ずっとそのままに
しておいて、PDAからsunに向けてtelnetしますと、さきほどSYN_SENTで
止まっていたものが先に進みます。無事にESTABLISHEDされてログインも
オーケーになり、普通に使えます。ただ、しばらく放っておいてから
キーを打つと反応がしばらく遅くなります。
休まずにキーを入力してるようなときはスムーズに入ります。

また、UDPについてですが、PDAからsunにUDPをセンドするのは
なんの問題もなくスムーズに行きます。しかし、逆はそうなりません。
前は、「逆はできない」と書きましたが、じつはそうでもないらしい。
つまり、このときにPDAからSUNにtelnetをしかけると
どっとUDPデータがPDAに入ってきます。そして、そのときは
SUNからPDAにUDPセンドすると割とスムーズに送られていきます。
しかし、しばらく休憩を入れてからセンドすると、また黙り込んで
しまいます。つまり、何かの拍子に溜まってたデータが送られるという感じです。

以上です。何かヒントになればいいのですが。

---

From support@iij4u.or.jp Fri Sep 5 18:42:20 2003
Date: Fri, 05 Sep 2003 18:42:16 +0900
From: support@iij4u.or.jp
To: kkkkk@ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION
Cc: support@iij4u.or.jp

神居 雅志 様

平素は、弊社サービスをご利用いただき、誠にありがとうございます。

AirH"接続オプションでの接続の件につきまして、詳細な検証結果をご連
絡いただきありがとうございます。

お客様より頂戴しました情報をもとに、弊社にて調査を行っております
が、現在のところ特に問題は見つかっておりません。

現在も調査を行われているとのことですが、先日お電話にて確認させて
いただいた、HTTP、FTP、POP、SMTP、SSH 等の通信ができない点につき
ましても、通信ができなくなるタイミング等詳細をお知らせいただけれ
ば幸いです。

いただきました情報をもとに、弊社側に問題がないかにつきまして、継
続して調査を行わせていただきます。

今後ともよろしくお願い致します。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Fri Sep 5 20:04:49 2003
Date: Fri, 5 Sep 2003 20:04:48 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

> いただいた、HTTP、FTP、POP、SMTP、SSH 等の通信ができない点につき
> ましても、通信ができなくなるタイミング等詳細をお知らせいただけれ

では、今回はsunOSではなくてLINUXのサーバーとの接続をトライしてみます。
まずはPDAからIIJ4Uにつなぎます。
そして、LINUX側のnetstat -a をみせます。
LINUXは150.7.21.YYです。
始めにHTTPをします。ただし、ドメインネームが使えません。つまり
PDAからうまくIIJのDNSとのやりとりができていませんから、
DNSのところでダメになってしまいますから、すべてIPアドレスをダイレクトに
打ちます。
PDAのほうにはWEB-Browserとして、NetFrontが入っています。
あとはw3mもあります。いまはNetFrontで http://150.7.21.YY/
を入力してみます。
LINUX側ではnetstat -aは
tcp 0 1214 spock:www h015.p058.iij4u.or:1040 ESTABLISHED
です。このときPDA側は「タイムアウトしました」と表示がでます。（数分後にですが）
これは1214バイトが送りたくても、引っ張ってくれてなくてLINUX側に
残っているからです。PDAには１バイトも送られてきてないと思います。

次は ftp にします。
PDAから　ftp 150.7.21.YY して接続を試みます。
（ちなみに現在の時刻は９／５の19:40です）
Connected to 150.7.21.YY.
とPDAに表示したまま止まっています。このとき、LINUX側では
tcp 0 80 spock:ftp h015.p058.iij4u.or:1041 ESTABLISHED
が表示されています。
もしも正常につながる場合ですと、
Connected to 150.7.21.YY.
220 spock FTP server (Version wu-2.6.0(1) Tue Jun 27 16:50:13 JST 2000) ready.
Name (150.7.21.YY:kkkkk):
こんな感じに出る予定です。

つぎはPOPにしますか。
POPはまだ試したことがありません。POPを使ってしまうと、
もしも成功したりすると、メールがPDAに流れてめんどうなことに
なるからです。でも、まあいでしょう。
やります。
あれしまった。/etc/resolv.confがうまくいかないのでネームレゾルーション
ができない。だから、
「ホストがみつかりません。メールサーバーの設定を再確認してください」
というエラーで終わってしまう。待ってください。いま、ダイレクトに
IPアドレすに変更してみます。
少し先へ進みましたが、
tcp 0 50 spock:pop3 h015.p058.iij4u.or:1042 ESTABLISHED でおなじく、動きません。
SMTPはPOP before SMTP なんでやりません。

次はsshです。
% ssh 150.7.21.YY をやってみます。
tcp 0 276 spock:ssh h015.p058.iij4u.or.:981 ESTABLISHED となりました。PDA側にはなにもメッセージが出ません。
すべて、同じようにsend-Qがゼロでない状態で止まっています。

そして、自家製のproxytelnetを間にかませて、ゆっくりゆっくりと、小出しに
センドをさせてあげると、 ftp, ssh telnet は動きます。
確認済みです。
以上です。私がそちらに行って、実演してもかまいません。

---

自家製のproxytcpであれこれやっていくうちに
MSSが56にできると、すんなり通信ができることがわかった。 ただ、MSSを56に自動では設定できないから、 困った。
int siz = 56;
setsockopt(socket,SOL_TCP,TCP_MAXSEG,&siz,sizeof(siz));
ができればうまくいく。

---

(2003.9.7 16:45)
こんな大胆な実験をしてみた。
Linuxマシンにたいして、普通なら MTU 1500 なんだけど、
# ifconfig eth0 mtu 96
をしてみた。こうすれば、強制的にすべてのパケッＴＰは セグメントサイズが５６以下になってしまうから。 こうやるとすべての送受パケットがうまくいった。 でも、これじゃあね。
wwwブラウザもちゃんと見れた。
(2003.9.7 17:00)
すべて成功と思いきや。失敗があった。 ただし、これは受けのｈぷのプログラムのせいかも しれないので、いまいちはっきりはしないが、 UDPパケットをLinuxから送ってみた。（短いサイズのパケット） しかし、受け手のSL-C760には届かない。 だけど、いつものように、そのときに、SL-C760のほうから telnetでLinuxに結ぶしぐさをすると、溜まってたパケットがどっと、 なだれこんでくる。ただし、このドドっときたパケットが 問題で、
"Resource temporarily unavailable"
というエラーが出る。これがまだ解明できていない。
SL-C760からSL-C760にIIJ4U経由でUDPを送ると、 それは無事に届くし、パケット自体もあっている。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Sun Sep 7 17:44:48 2003
Date: Sun, 7 Sep 2003 17:44:47 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

ＸＸさま、神居です。
少しずつ、いろいろなマシンに対して、ソフトを作って
模索を繰り返していますが、
だんだんとそちらで使っているルーターのことが気になりました。
情報の開示といいますか、３２Ｋパケットを担当しているルータの
製品名を教えてもらえませんか。
シスコのルータを使っていますか？
少し、調べておきたいのですが。

いろんなマシンというのは
Linux,Sun-OS,昔のBSDのSun-OS,MacOSXです。
そうそう、 IIj4UにもＨＰを置いてあったのでそっちも
を見ようとしましたが、ダメでした。 ftp.iij4u.or.jp でもあれば
そっちも ftp で試そうとも思いましたが、それはないようです。

---

(2003.9.8 18:18)
IIJ4Uからは連絡が来ないので、きょうは、少し解説を。 PPPでPRINに接続するときとIIJ4Uに接続するときの相違点を 見たいと思う。PRIN接続なら何も問題がないからだ。

prinに接続の場合

リナザウ	IIJ4Uサイド
REQ#1 (mru 128)(asyncmap 0x0)(pcomp)(accomp)		要求
	REQ#1 (mru 1500)(auth pap)	要求
ACK#1 (mru 1500)(auth pap)		快諾
	REJ#1 (asyncmap 0x0)(pcomp)(accomp)	拒否
REQ#2 (mru 128)		要求
	NAK#2 (mru 1500)	不満
REQ#3		要求
	ACK#3	快諾

このあと、PAP Authetication に移る


IIJ4Uに接続の場合

リナザウ	IIJ4Uサイド
REQ#1 (mru 128)(asyncmap 0xa0000)(pcomp)(accomp)		要求
	NAK#1 (mru 1500)	不満
REQ#2 (asyncmap 0xa0000)(pcomp)(accomp)		要求
	REQ#2 (auth chap MD5)	要求
ACK#2 (auth chap MD5)		快諾
	REQ#3 (auth chap MD5)	要求
ACK#3 (auth chap MD5)		快諾
REQ#2 (asyncmap 0xa0000)(pcomp)(accomp)		返事がないから再送
	ACK#2 (asyncmap 0xa0000)(pcomp)(accomp)	快諾

このあと CHAP Challenge に移る
★少し不思議に思ったのはなぜIIJ4UからREQ#1がないの？

次に、UDPに関しての不思議を説明しよう。
PDAからLINUXへはなんら問題なくUDPパケットがsendできる。
逆の場合が問題なのだ。LINUXからPDAにUDPsendをすると、LINUXのほうでは ちゃんと送ったことになっている。TCPの場合だとキューに溜まった状態で いくら待っても出ていかないが、UDPだとちゃんと出ていく。しか〜し、PDAには 届かない。満杯にしないと出ていかないのかなあと、いくつも繰り返して 見るが、PDAには到達しない。しかし、あるきっかけがあると、ドドっと PDAに現れるのがわかった。そのきっかけとは、PDAからtelnetを してみること。telnetの相手先はどこでもかまわない。それがトリガになって いままで溜まっていたUDPパケットがドドっと入り込んでくる。 しかも、そのようになったときは、LINUXからUDPを送ると、 すぐに、PDAに届く。しかし、小休止してからUDPsendすると、また前のように 届かなくなってしまう。

---

(2003.9.8 23:30)
もう一つ、気になってることは Little-Endian Big-Endian は大丈夫？
かなです。ネットワーク関係のソフトで ときどき、このあたりがバグの元になるからです。

---

(2003.9.9 11:50)
１１日から４泊５日で後援会のために中部地方に行くのだが、これに リナザウ＋ＰＨＳでモバイルをと思っているのに、それに 間に合いそうにないか？
このままウヤムヤにされてしまうのか。。。

---

(2003.9.10 15:43)
たかだか１８バイトのパケットを５分ごとに送信するのが 「他人に多大な迷惑を及ぼすかもしれないので（おやめください）」とは 考えられないのだが、 ここで喧嘩をしてはいけないので、すなおに、引き下がる。

---

(2003.9.10 23:10)
あまり進展がなくなった。
このままになってしまうんでは、がっかり。 私はIIJが好きなのに。なぜ好きかというと「技術のIIJ」だから。 このままうやむやにされるよりは、「じゃあ、IIJを脱退してください」と 向こうから言われるほうがいい。こちらからは辞められない事情があるからだ。 それは、最近、自宅を光ケーブル（Ｂフレッツ）に換える際、IIJを続ける という条件で無料にしてもらっているせいだ。これがなければ、もう辞めても いいのだが。ほかのISPのほうがずっと安いでしょう。このままでは 「技術のIIJ」が泣く。
クルマで言えば、ニッサンが好きだ。 「技術のニッサン」だからだ。だから、販売量ではダントツにいいトヨタより、 ニッサンが好きなのだ。これが技術をなくしたニッサンなら魅力を亡くす。 昔から好きだったのは、セドリックとフェアレディーＺ。 そう思ってる人は大勢いるだろう。コンピュータでも、なぜ 私がアップルが好きか、想像できるだろう。アップルが先進性を失ったとき、 アップルの魅力は消える。SCSIしかりCD しかり、QuickTimeしかり、hypercardしかり、GUIしかり、FireWireしかり、 USBしかり、 である、常に三歩も前を進み、あまりにも前すぎて こけるのがアップルである。 もう興味を失って、面白くなくなったころ、ブームが始まる。 コーラだったら、コカコーラより、ペプシ。 ここまでいくと偏屈か。 なぜか我ながら日本人だなあと感じる。

---

From support@iij4u.or.jp Tue Sep 9 18:33:19 2003
Date: Tue, 09 Sep 2003 18:33:17 +0900
From: support@iij4u.or.jp
To: kkkkk@ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION
Cc: support@iij4u.or.jp

神居 雅志 様

平素は、弊社サービスをご利用いただき、誠にありがとうございます。

AirH"接続オプションでの接続の件につきまして、検証結果をお知らせい
ただきありがとうございました。

本件につきましては、問題の原因を確認するため、お客様にはお手数を
おかけ致しますが以下の内容をお試しいただき、検証の結果を再度弊社
までお知らせいただきますようお願い致します。

・パケットサイズを変更しつつ、PDA から Sun に ping をお試しい
ただき、通信が途絶える数値をご確認ください
・上記により通信が途絶える数値を確認後、消失箇所を確認するた
め、traceroute にて現れる各ホストに対して ping をお試しくだ
さい
・Sun から PDA に対しても同様の検証をお試しください

また、現在 MTU値を 570 に設定し検証を行われているようですが、DDI
ポケットが推奨する 1,500 の値に変更し、上記検証をお試しいただきま
すようお願い致します。

> だんだんとそちらで使っているルーターのことが気になりました。
> 情報の開示といいますか、３２Ｋパケットを担当しているルータの
> 製品名を教えてもらえませんか。
> シスコのルータを使っていますか？

弊社にて利用しております機器等の詳細につきましては、セキュリティ
上、重要な情報と捉えておりますので、ご案内しておりません。何卒、
ご了承ください。

> そうそう、 IIj4UにもＨＰを置いてあったので
> http://www.nn.iij4u.or.jp/~kamii/index.html
> を見ようとしましたが、ダメでした。 ftp.iij4u.or.jp でもあれば
> そっちも ftp で試そうとも思いましたが、それはないようです。

お客様のユーザ用ホームページへ FTP接続をお試しいただく場合には、
以下の FTPサーバへお試しいただきますようお願い致します。

上、重要な情報と捉えておりますので、ご案内しておりません。何卒、
ご了承ください。

> そうそう、 IIj4UにもＨＰを置いてあったので
> http://www.nn.iij4u.or.jp/~kamii/index.html
> を見ようとしましたが、ダメでした。 ftp.iij4u.or.jp でもあれば
> そっちも ftp で試そうとも思いましたが、それはないようです。

お客様のユーザ用ホームページへ FTP接続をお試しいただく場合には、
以下の FTPサーバへお試しいただきますようお願い致します。

FTPサーバ : nn.iij4u.or.jp

今後ともよろしくお願い致します。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Tue Sep 9 23:34:51 2003
Date: Tue, 9 Sep 2003 23:34:50 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

返事が遅れました。
いまから，実験をしたいと思います。いまの時刻は22:40です。

> までお知らせいただきますようお願い致します。
>
> ・パケットサイズを変更しつつ、PDA から Sun に ping をお試しい
> ただき、通信が途絶える数値をご確認ください
> ・上記により通信が途絶える数値を確認後、消失箇所を確認するた
> め、traceroute にて現れる各ホストに対して ping をお試しくだ
> さい
> ・Sun から PDA に対しても同様の検証をお試しください
>
こんなようなスクリプトを作って実験したいと思います。
#! /bin/sh
SIZE=50
ADDR=150.7.21.44
while [ $SIZE -lt 2500 ] ; do
ping -c 3 -s $SIZE $ADDR
SIZE=`expr $SIZE + 1`
done
exit

> また、現在 MTU値を 570 に設定し検証を行われているようですが、DDI
> ポケットが推奨する 1,500 の値に変更し、上記検証をお試しいただきま
> すようお願い致します。

従来のまま(MTUとかを変えず）PDA->SUNでpingしました。
ええと、どんどんサイズが上がっていきます、
５０から始めましたが２５００でも大丈夫でした。どうにも止まりません。
これ以上SIZEを増やしても無駄でしょう。

つぎに逆向きに SUN->PDA にします。
% ping -v 210.130.48.196 しました。ちょっと引数の形式が
違うのでやりづらい。
そうしたら、
ICMP Time exceeded in transit from gate.birthday.co.jp (210.225.110.253)
for tcp from queen (150.7.21.44) to jms09.jeton.or.jp (210.225.111.66) port 25
no answer from 210.130.48.196
と表示が出て、PDAにはとどきませんでした。このときのパケットサイズは
標準ですから５６です。
ところが、また同じコマンドを試してみると、同じエラーメッセージが出ました。
ものは試しと
ping -v 210.130.48.196 3
としてみたら、今度は
210.130.48.196 is alive
とでるのです。あれれと思って３ではなくて40,50,200,1500,2000と
増やしてためすと今度はすべて、210.130.48.196 is aliveになります。
再び最初に戻ってping -v 210.130.48.196すると、こんどは
エラーにならず210.130.48.196 is alive になります。
これは連続で試している為でしょうか。ちょっと、間合いを置いてまた
試してみます。
間合いをおいてからping -v 210.130.48.196 20しました。そうしたらダメです。
no answer from 210.130.48.196になります。こんどは何回くりかえしても
aliveにならなくなりました。no answer from 210.130.48.196という
メッセージになります。

つぎにtracerouteに移ります。まずはpdaから
# traceroute 150.7.21.44 します。

つぎに、SUNから210.130.48.196にトレースします。
% traceroute 210.130.48.196
traceroute to 210.130.48.196 (210.130.48.196), 30 hops max, 40 byte packets
1 router_cc (150.7.21.254) 1.730 ms 3.935 ms 2.156 ms
2 bld5-4.net.cc.u-tokai.ac.jp (150.7.20.200) 2.414 ms 6.127 ms 1.767 ms
3 bldg5-bd.net.cc.u-tokai.ac.jp (150.7.3.254) 2.726 ms 2.406 ms 1.697 ms
4 150.7.13.246 (150.7.13.246) 7.223 ms 1.855 ms 2.547 ms
5 sinet-gw.net.cc.u-tokai.ac.jp (150.7.12.254) 4.597 ms 3.254 ms 4.436 ms
6 150.99.133.1 (150.99.133.1) 7.717 ms 4.845 ms 2.858 ms
7 JT-tokyo-S1-P12-0.sinet.ad.jp (150.99.197.45) 4.807 ms 9.912 ms 5.463 ms
8 nii-S1-P4-0.sinet.ad.jp (150.99.197.22) 9.750 ms 5.654 ms 9.124 ms
9 nii-IX-P0-0.sinet.ad.jp (150.99.197.142) 7.142 ms 7.256 ms 6.049 ms
10 210.173.176.233 (210.173.176.233) 9.588 ms 6.607 ms 8.415 ms
11 210.130.142.185 (210.130.142.185) 209.251 ms 115.124 ms 203.067 ms
12 210.130.143.148 (210.130.143.148) 7.559 ms 76.282 ms 7.655 ms
13 210.130.143.227 (210.130.143.227) 7.716 ms 6.518 ms 7.735 ms
14 tky001nas02.IIJ.Net (210.130.7.245) 8.019 ms 7.308 ms 7.148 ms
15 * * *
16 * * *
17 * * *
18 * * *
19 *^C
%
つまり最後のツメで（もう一歩のところで）届かないですね。
ここでメールの整理のために、いったん、PDAの接続は切ります。
いまの時間は２３：２９です。

PDAでifconfig ppp0 するとこうなっています。

＊＊＊しまった。PDAのほうのscriptを失敗してしまいました。
typescriptファイルが空っぽになっていた。せっかくPDAのほうの
traceroute と ifconfig ppp0 を記録したと思ったのに。
あ〜あ。ショック！！
またこっちはやり直しをします。
いまはショックからたちあがれないので、いまはここまでとしてメールを
閉めます。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 10 00:25:44 2003
Date: Wed, 10 Sep 2003 00:25:44 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

それではまた気を取り直して再開します。
その前にご指摘があったようにMTUを576から1500になおしました。
tracerouteを両方向でまた試してみます。
それとoingが途中のどこまで通るかですね。

-----
あ、失礼しました。さきほどtypescriptが空っぽと言いましたが、
別のtypescriptを見てました。前のがありました。
疲れてたせいかな。ヘマしました。
さきほどPHSを切る前に試したものです。
これです。
Script started on Tue Sep 9 23:21:10 2003
bash-2.05# traceroute 150.7.21.44
traceroute to 150.7.21.44 (150.7.21.44), 30 hops max, 40 byte packets
1 202.232.1.170 (202.232.1.170) 3973.897 ms * 230.118 ms
2 210.130.7.249 (210.130.7.249) 259.573 ms 259.557 ms 229.689 ms
3 210.130.143.226 (210.130.143.226) 259.649 ms 209.588 ms 199.696 ms
4 210.130.143.149 (210.130.143.149) 259.618 ms 329.615 ms 409.696 ms
5 210.130.142.186 (210.130.142.186) 349.577 ms 249.552 ms 279.673 ms
6 210.173.176.27 (210.173.176.27) 329.668 ms 529.439 ms 509.803 ms
7 150.99.197.141 (150.99.197.141) 489.653 ms 239.594 ms 239.651 ms
8 150.99.197.21 (150.99.197.21) 279.654 ms 279.556 ms 249.673 ms
9 150.99.197.46 (150.99.197.46) 269.702 ms 249.557 ms 239.708 ms
10 150.99.133.6 (150.99.133.6) 279.640 ms 239.590 ms 239.648 ms
11 150.7.12.253 (150.7.12.253) 239.696 ms 249.563 ms 239.637 ms
12 150.7.13.254 (150.7.13.254) 239.700 ms 249.547 ms 239.679 ms
13 150.7.3.253 (150.7.3.253) 239.745 ms 259.577 ms 269.673 ms
14 150.7.20.201 (150.7.20.201) 279.666 ms 249.424 ms 229.835 ms
15 chappy (150.7.21.44) 249.603 ms 237.836 ms 259.527 ms
bash-2.05#
bash-2.05# ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:210.130.48.196 P-t-P:202.232.1.170 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:576 Metric:1
RX packets:1084 errors:0 dropped:0 overruns:0 frame:0
TX packets:1188 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:172962 (168.9 Kb) TX bytes:180286 (176.0 Kb)


これはこれで、いったんメールを閉じます。
私もまだこれらのデータを解析してません。解析は明日かな。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 10 00:57:04 2003
Date: Wed, 10 Sep 2003 00:57:03 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

> それではまた気を取り直して再開します。
> その前にご指摘があったようにMTUを576から1500になおしました。

こんどはほんとに、再接続からです。ですので、IPアドレスは変わってしまいます。
いまの時間は2003.9.10 00:31です。

SUN->PDAのtracerouteは
% traceroute 210.130.59.182
traceroute to 210.130.59.182 (210.130.59.182), 30 hops max, 40 byte packets
1 router_cc (150.7.21.254) 1.810 ms 1.528 ms 1.484 ms
2 bld5-4.net.cc.u-tokai.ac.jp (150.7.20.200) 2.792 ms 1.785 ms 2.360 ms
3 bldg5-bd.net.cc.u-tokai.ac.jp (150.7.3.254) 2.303 ms 2.705 ms 2.353 ms
4 150.7.13.246 (150.7.13.246) 2.541 ms 3.213 ms 3.041 ms
5 sinet-gw.net.cc.u-tokai.ac.jp (150.7.12.254) 4.362 ms 3.812 ms 4.550 ms
6 150.99.133.1 (150.99.133.1) 2.934 ms 4.201 ms 4.423 ms
7 JT-tokyo-S1-P12-0.sinet.ad.jp (150.99.197.45) 4.746 ms 5.427 ms 6.561 ms
8 nii-S1-P4-0.sinet.ad.jp (150.99.197.22) 5.753 ms 7.100 ms 6.133 ms
9 nii-IX-P0-0.sinet.ad.jp (150.99.197.142) 5.470 ms 5.326 ms 5.484 ms
10 210.173.176.233 (210.173.176.233) 139.100 ms 182.684 ms 10.101 ms
11 210.130.142.185 (210.130.142.185) 6.959 ms 8.324 ms 5.833 ms
12 210.130.143.148 (210.130.143.148) 6.592 ms 6.562 ms 5.991 ms
13 210.130.143.227 (210.130.143.227) 6.005 ms 7.826 ms 7.558 ms
14 tky001nas03.IIJ.Net (210.130.7.246) 6.724 ms 7.929 ms 6.622 ms
15 * * *
16 ^C
です。
tky001nas03.IIJ.Netで止まります。でもこれは40BytePacketだからってこともある。
man traceroute で調べたら、パケットサイズを変えられそう。では
パケットサイズを適当に200にしてやってみます。
% traceroute 210.130.59.182 200
traceroute to 210.130.59.182 (210.130.59.182), 30 hops max, 200 byte packets
1 router_cc (150.7.21.254) 2.512 ms 1.734 ms 1.726 ms
2 bld5-4.net.cc.u-tokai.ac.jp (150.7.20.200) 3.153 ms 3.150 ms 3.990 ms
3 bldg5-bd.net.cc.u-tokai.ac.jp (150.7.3.254) 2.807 ms 3.221 ms 2.667 ms
4 150.7.13.246 (150.7.13.246) 3.464 ms 3.244 ms 2.927 ms
5 sinet-gw.net.cc.u-tokai.ac.jp (150.7.12.254) 5.032 ms 3.910 ms 4.839 ms
6 150.99.133.1 (150.99.133.1) 5.884 ms 6.992 ms 3.814 ms
7 JT-tokyo-S1-P12-0.sinet.ad.jp (150.99.197.45) 6.680 ms 7.166 ms 6.139 ms
8 nii-S1-P4-0.sinet.ad.jp (150.99.197.22) 7.630 ms 8.085 ms 5.690 ms
9 nii-IX-P0-0.sinet.ad.jp (150.99.197.142) 7.828 ms 6.410 ms 7.646 ms
10 210.173.176.233 (210.173.176.233) 8.071 ms 6.860 ms 6.991 ms
11 210.130.142.185 (210.130.142.185) 7.903 ms 7.522 ms 8.002 ms
12 210.130.143.148 (210.130.143.148) 7.053 ms 7.740 ms 7.651 ms
13 210.130.143.227 (210.130.143.227) 7.990 ms 8.016 ms 7.879 ms
14 tky001nas03.IIJ.Net (210.130.7.246) 9.232 ms 9.787 ms 9.409 ms
15 * *
あ、それでも同じです。
tky001nas03.IIJ.Netでとまります。
あと、ちょっと気になったので、man pingしたらUDPでpingチェックというのも
あるのでそれもやってみようかなと。

（途中で切れてしまったのでＰＨＳ再接続しました）
% ping -v -R -U 210.130.57.57
no answer from 210.130.57.57
% ping -v -R -U 210.130.57.57 256
ICMP Time exceeded in transit from gate.birthday.co.jp (210.225.110.253)
for tcp from queen (150.7.21.44) to jms09.jeton.or.jp (210.225.111.66) port 25
ICMP Time exceeded in transit from gate.birthday.co.jp (210.225.110.253)
for tcp from queen (150.7.21.44) to jms09.jeton.or.jp (210.225.111.66) port 25
ICMP Time exceeded in transit from gate.birthday.co.jp (210.225.110.253)
for tcp from queen (150.7.21.44) to jms09.jeton.or.jp (210.225.111.66) port 25
^C
%
フームいったいどこに寄り道してるんだろう。
jms09.jeton.or.jp (210.225.111.66)などはtracerouteに出てこないサイトだ。
% ping -v -R -U tky001nas03.IIJ.Net
tky001nas03.IIJ.Net is alive
% ping -v -R -U tky001nas03.IIJ.Net 256
tky001nas03.IIJ.Net is alive
%
フム。これはすぐに答えがでる。さっきの no answer などは答えがでるまでに
相当、待つ。しかしtky001nas03.IIJ.Netにはスムーズに届く。
% ping -v -R tky001nas03.IIJ.Net 256
tky001nas03.IIJ.Net is alive
%
これもすんなりと通ります。
ちなみにPDA->SUNのトレースは先程と同じ結果でした。
それでは。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 10 12:05:45 2003
Date: Wed, 10 Sep 2003 12:05:45 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

おはようございます。さきほど、PHSから接続しました。
現在の時刻は11:56です。
接続のIPアドレスは210.130.56.227です。
いまからSUNのほうでこういうのを実行して５分ごとに17バイト（？）の
UDPパケットを繰り返し、送信します。おそらく、tky001nas03.IIJ.Netで
ストップしてしまうと想像するのですが、
その状態でチェックしてもらえますか？
５分毎というのは多分
オーケーだと思います。あまり感覚がせあまり間隔がせまいと次々に
流出するだろうし、あまり間隔が長いと自然放出するかもしれません。
なんともいえません。
こんなプログラムです。
% cat test-iij
#! /bin/sh
ADDR=210.130.56.227
while true ; do
date
date +%Y%m%d-%H:%M%S | ./udpsend/sendudp ${ADDR}:8889 -
sleep 300
done

これを今日の１４時ころまで続けますので、調査できたら幸いです。
PDSではUDPパケットの受信プログラムを動かしておきます。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 10 12:11:23 2003
Date: Wed, 10 Sep 2003 12:11:19 +0900 (JST)
From: Masashi Kamii
To: kkkkk@ss.u-tokai.ac.jp, support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

補足します。たしか、Air-H"接続だと３０分ぐらい無交信だと切れてしまう
と思ったので、たまに、これとは別にPDSから約２０分ごとに
pingをかけます。ただ、これをしたときに溜まってたUDPパケットが
（これがトリガになって）放出されるかもしれませんが。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 10 13:29:57 2003
Date: Wed, 10 Sep 2003 13:29:57 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

traceroute,pingをやっていて気がついたこと。
もしかして、tky001nas02.IIJ.Net(210.130.7.245)が210.130.56.227への
ルーティング情報をときどき失っているんでは？
tky001nas02.IIJ.Net(210.130.7.245)に載っているべき
210.130.56.227<----PtoP---->202.232.1.170
情報が欠落するんでは？
PDAからヨソをアクセスするときに、またルーティングテーブルに載るので
その時は情報があるけど、またすぐに１分後ぐらいで情報がなくなってしまうんでは？
いま、ふと、そう思いました。

tky001nas02.IIJ.Net(210.130.7.245)のマシンからpingあるいはUDPパケットを
210.130.56.227に送ってみてくれませんか。
また、202.232.1.170のマシンから210.130.56.227に送ってみてくれませんか。
そして、netstat -a でちゃんと送られたかチェックしｔみてくれませんか。

---

From support@iij4u.or.jp Wed Sep 10 13:30:30 2003
Date: Wed, 10 Sep 2003 13:30:27 +0900
From: support@iij4u.or.jp
To: kkkkk@ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION
Cc: support@iij4u.or.jp

神居 雅志 様

平素は、弊社サービスをご利用いただき、誠にありがとうございます。

> % cat test-iij
> #! /bin/sh
> ADDR=210.130.56.227
> while true ; do
> date
> date +%Y%m%d-%H:%M%S | ./udpsend/sendudp ${ADDR}:8889 -
> sleep 300
> done
>
> これを今日の１４時ころまで続けますので、調査できたら幸いです。
> PDSではUDPパケットの受信プログラムを動かしておきます。
ご連絡いただきましてありがとうございます。

現在、お客様がインターネット接続中であることを弊社にて確認致して
おりますが、記載いただきました内容の調査を弊社より行う場合、他の
お客様の通信に影響を及ぼす可能性がございます。

したがいまして、現状ではお客様に上記調査を続行していただく必要は
ございませんので、誠に恐れ入りますが、調査の作業を停止していただ
きますようお願い致します。

この度の AirH"接続オプションによる接続の件につきまして、検証等が
必要となった場合は、弊社より検証方法等詳細について改めてご連絡さ
せていただきます。

今後ともよろしくお願い致します。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 10 13:40:39 2003
Date: Wed, 10 Sep 2003 13:40:38 +0900 (JST)
From: Masashi Kamii
To: kkkkk@ss.u-tokai.ac.jp, support@iij4u.or.jp
Subject: Re: Air-H setzuzoku OPTION

> お客様の通信に影響を及ぼす可能性がございます。
わかりました。では中止します。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Wed Sep 10 14:03:10 2003
Date: Wed, 10 Sep 2003 14:03:10 +0900 (JST)
From: Masashi Kamii
To: kkkkk@ss.u-tokai.ac.jp, support@iij4u.or.jp
Subject: Re: Air-H setzuzoku OPTION

ポート番号を言うのを忘れました。ポート番号８８８９で待っています。
> tky001nas02.IIJ.Net(210.130.7.245)のマシンから
> 202.232.1.170のマシンから

---

(2003.9.11 01:15)
tracerouteやping実験での比較をしてみたいと思う。
いちおうPDA（リナザウ）とSUN（リモートホスト）との こうしんをして、違いを検討する。 たとえば、tracerouteではこうなった。

SUN-->PDA

PDA--->SUN

% traceroute 210.130.58.204 traceroute to 210.130.58.204, 30 hops max, 40 byte packets 1 router_cc 1.710 ms 1.517 ms 1.947 ms 2 bld5-4.net.cc.u-tokai.ac.jp 2.841 ms 1.810 ms 2.321 ms 3 bldg5-bd.net.cc.u-tokai.ac.jp 2.767 ms 2.417 ms 1.702 ms 4 150.7.13.246 2.773 ms 2.484 ms 2.378 ms 5 sinet-gw.net.cc.u-tokai.ac.jp 2.115 ms 3.434 ms 3.535 ms 6 150.99.133.1 4.264 ms 2.888 ms 4.997 ms 7 JT-tokyo-S1-P12-0.sinet.ad.jp 5.638 ms 5.201 ms 5.640 ms 8 nii-S1-P4-0.sinet.ad.jp 11.758 ms 159.364 ms 12.302 ms 9 nii-IX-P0-0.sinet.ad.jp 8.305 ms 6.570 ms 6.863 ms 10 210.173.176.233 6.123 ms 6.561 ms 6.429 ms 11 210.130.142.185 6.254 ms 6.154 ms 5.902 ms 12 210.130.143.148 7.596 ms 13.310 ms 5.882 ms 13 210.130.143.227 6.461 ms 6.549 ms 6.344 ms 14 xxxxxxxxx03.IIJ.Net 6.779 ms 8.050 ms 6.716 ms 15 ^C

# traceroute 150.7.21.44 traceroute to 150.7.21.44 30 hops max, 40 byte packets 1 202.232.1.171 2039.975 ms 207.689 ms 197.257 ms 2 210.130.7.249 235.901 ms 323.891 ms 262.537 ms 3 210.130.143.226 220.213 ms 293.380 ms 289.384 ms 4 210.130.143.149 269.089 ms 309.421 ms 259.668 ms 5 210.130.142.186 259.657 ms 219.540 ms 239.724 ms 6 210.173.176.27 239.615 ms 279.558 ms 239.666 ms 7 150.99.197.141 239.649 ms 279.587 ms 269.651 ms 8 150.99.197.21 209.644 ms 229.532 ms 289.660 ms 9 150.99.197.46 229.671 ms 219.526 ms 189.709 ms 10 150.99.133.6 209.707 ms 269.421 ms 239.850 ms 11 150.7.12.253 259.623 ms 259.561 ms 389.666 ms 12 150.7.13.254 289.663 ms 249.492 ms 239.701 ms 13 150.7.3.253 262.918 ms 229.621 ms 329.653 ms 14 150.7.20.201 329.487 ms 289.475 ms 259.725 ms 15 qqqqq 249.515 ms 517.842 ms 289.726 ms #

こうやって見てみると上りと下りではルートが違うんだなあと実感する。
つぎに ping をためす。SUNからやってみる。
% ping -v -U 202.232.1.171　　（すぐに返事が出る）
202.232.1.171 is alive
% ping -v -U 210.130.58.204　　（返事が出るまでに時間がかかる）
no answer from 210.130.58.204
ちなみに202.232.1.171と210.130.58.204はPPPでのピアツーピアの両端のアドレスである。

---

(2003.9.11 14:47)
熱くなりすぎていたから、このへんで、一回、整理しよう。冷静 になってみよう。今日から数日間は時間がとれない。 これはいま東海道新幹線の中から打っている。 いろいろな組み合わせで試したから、その組み合わせが○だった か×だったかをみよう。
PDA PB:PowerBook(USB) SL:SL-C760(リザナウ)
CABLE AH:AH-64(USB-Cable) SLZ:DPC-SLZ専用ケーブル
PHS J700:RZ-J700(PHS端末)
PHS J700:RZ-J700(PHS端末)
ISP PRIN:DDI-POCKET IIJ:IIJ4U
Connect 32K:32Kpacket SUB:回線交換

PB+AH+J700+any+any	○
SL+SLZ+J700+PRIN+SUB	○
SL+SLZ+J700+PRIN+32K	○
SL+SLZ+J700+IIJ+SUB	○
SL+SLZ+J700+IIJ+32K	×

これではSL,SLZ,J700,IIJのどれが悪いか、あるいは複合か断定できませんね。X-( 原因がどこにあるのか？特定するのは難しい。
ケーブルDPC-SLZが悪いと仮定すると、ハード的な問題となる。 その場合、モーデム信号の問題になる。RTS/CTS,DTR/DSR,CDの 結線が正しくないということになる。
J700が悪い場合、原因は不明
SL-C760が悪い場合、も考えられないとはいえない。これが真の原因 だった場合は一番困ったことになる。解決は難しい。
IIJ4Uが悪い場合、解明はIIJにまかせるしかない。

---

(2003.9.16 23:10)
きょう、進展があった。私は団体行動が苦手なので、４泊５日の大学後援会の 遠征は身体にこたえた。体調をすっかりくずしてしまい、帰ってきてから ずっと、寝床に臥していた。そのおかげか、思わぬ解答が見つかった。
冷静でいられたせいだろうか。やっと順調にIIJ4Uと32Kpacketでつながったのだ。 これで、安心してモバイル通信ができる。さっそく、解答をIIJ4Uのサポート担当の 人にも伝えておこう。
PRINではうまくいく。IIJ4Uではダメ。その差は なんだろうか。ログをずっとながめていた。そして、あんまり気にもとめていなかった accomp,pcompに目がとまり、これをPRINと同じになるようにしようと したのだ。これがビンゴ。なんとうまくつながったのだ。

---

From kkkkk@qqqqq.ss.u-tokai.ac.jp Tue Sep 16 23:52:35 2003
Date: Tue, 16 Sep 2003 23:52:35 +0900 (JST)
From: Masashi Kamii
To: support@iij4u.or.jp
Cc: kkkkk@qqqqq.ss.u-tokai.ac.jp
Subject: Re: Air-H setzuzoku OPTION

いつもお世話になっています。神居＠東海大学情報数理学科です。
私にとっては強行なスケジュールの（阪神タイガースではないけど）死の長期ロード
ならぬ、４泊５日のロードから帰ってきました。
自宅にもどってからも、しばらく放心状態から回復ができませんでしたが、
少し元気になりました。
冷静になって、うまくいってるPRIN接続と、うまくいかないIIJ4U接続の
デバッグ情報をじっと見比べてみました。
あんまり気にも留めていなかった「圧縮」の部分に今回は興味をもちました。
そしてPRINと同じになるように、pppdのオプションに
noaccompとnopcompを追加しました。そうしたら、なんと！！
スムーズに接続ができました。もうすこし、調整してみると、
nopcompだけをつけると、つながることがわかりました。
ということで が悪いということになります。
これはJ700が悪いのかIIJ4Uサイドのルータが悪いのか、それをこちらでは
判断はできません。（こちらには術がないからです）
でも、まあこれでいいとしましょう。すっきり爽快とはいきませんが、
いちおう動かせるので、これ以上の詮索はやめることにしましょう。
８月末からいままでの長い付きあい、とてもありがとうございました。
なんか拍子抜けするほど簡単な結末になりました。
これからもよろしくお願いいたします。

---

(2003.9.17 00:01)
＊＊＊＊＊＊＊＊＊＊結論＊＊＊＊＊＊＊＊＊＊
リナザウのほうのIRDAxxxxxファイルをおおむね、以下のようにすれば IIJ4U に つながる。

115200
connect '/usr/sbin/chat -s -v -t 60 ABORT "NO CARRIER" ABORT "NO DIALTONE" ABORT
"BUSY" "" "AT&F&C1&D2&K3&S0E0" OK "ATDT,,0570-570-439##61" CONNECT'
crtscts
lock
modem
user "pfzzzzzXX"
usepeerdns
defaultroute
connect-delay 1000
remotename IRDA9999999999
noipdefault
asyncmap 0x00000
mtu 1500
mru 1500
nodeflate
receive-all
#noaccomp
nopcomp

---

From support@iij4u.or.jp Wed Sep 17 15:08:37 2003
Date: Wed, 17 Sep 2003 15:08:31 +0900 (JST)
To: kamii@ss.u-tokai.ac.jp
Cc: support@iij4u.or.jp, kamii@queen.ss.u-tokai.ac.jp
Subject: Re: Re: Air-H setzuzoku OPTION
From: support@iij4u.or.jp

神居 雅志 様

平素は、弊社サービスをご利用いただき、誠にありがとうございます。
本件につきましてはご返答が遅くなっており、申し訳ございません。

お知らせいただきました検証結果から、弊社通信機器について確認を致
しましたところ、pcomp は対応しておりませんでした。

また、弊社機器を pcomp に対応させるための変更は、即時に行なうこと
ができません。何卒ご了承ください。

nopcomp の付加にて通信が可能になるとのことですので、弊社にて AirH"
接続を行なわれる場合には、お手数ですが、オプションを付加してご利
用いただければ幸いです。

pcomp の対応につきましては、今後の検討材料とさせていただきます。

ご連絡いただきありがとうございました。

よろしくお願い致します。

---

これで大団円ですかね。