🚀 go-pugleaf

ありたです。

> はたの％お仲間募集中

に釣られてやってきました。。
同じ現象かどうかわからないのですが．．．

私の遭遇している現象は、以下の２件。
・あるニュースサイトの描画が終了しないことが多い。
　（ＨＴＭＬデータは、それなりに？届いているみたい）
・ある特定のＳＭＩＬコンテンツの再生が終了しない。

ＩＳＰのＡＰへのダイヤルアップでは再現しません。
一度dti.support.miscでお仲間募集してみません？＾＾

環境
　ＩＳＰ：ＤＴＩ
　ＮＴＴ：西日本
　ダイヤルアップルータ：YAMAHA RTA52i

＃時間があれば、他のＩＳＰのフレッツＩＳＤＮで試してみたいけど．．


はたの wrote:
> 
> はたのともうします。
> 
> フレッツISDNである特定のパケットが消失するという問題で困って
> います。
> このような経験をお持ちの方はいらっしゃいませんか？
> 
> 現象は、
> 
> データ部がある特定の条件を満たす、下り方向(インタネット ->
> 自宅)のパケットが、フレッツISDN経由で、必ず消失する。
> プロバイダのダイヤルアップアクセスポイント経由では問題ない。
> 上り方向(自宅 -> インタネット)は、フレッツISDN経由でも問題な
> い。
> 

-- 
===========================
K.Arita <E-Mail> mailto:k-arita@mars.dti.ne.jp
[Hyogo] <  Web > http://www.mars.dti.ne.jp/~k-arita/
[Japan] <i mode> http://www.hi-ho.ne.jp/crucis/imode/
                          ===========================

はたのです。

ご応募ありがとうございます。(^^)

まず、現象の確認方法をいくつか。

ftpの場合は、簡単です。
ダウンロードの途中で転送が停止し、resumeしても先に進まない。
最初からダウンロードやり直すと、まったく同じバイト数で停止す
る。
という症状になります。
どうしても最後まで欲しい場合には、1460の倍数にならないバイト
数分、停止した時点で転送されたファイルの末尾から、適当なユー
ティリティで削除して、そこからresumeすれば先に進みます。
そのファイルを、別の適当なftpサーバーにアップロードして、ダ
ウンロードすると同じ現象が再現するはずです。

httpの場合は、やっかいです。
この現象によって、ダウンロードが途中で止まっても、resumeする
と、その続きをダウンロードできてしまうからです。これは、http
ヘッダのために、resume後の最初のパケットのデータが、本来送っ
てくるはずだった消失したパケットと異なるためです。
画像ファイルなどであやしいと思ったら、URLを調べて、Go!Zilla
やGetRightなどで個別にダウンロードしてみた方がよさそうです。
最初から何回かダウンロードしてみて、ぴたり同じバイト数で転送
が停止するようであれば、この現象と思われます。
httpヘッダがサーバーごとに異なるために、そのファイルを別のサ
ーバーに持っていっても再現しない可能性が高いです。
両方のサーバーのhttpヘッダサイズの差分を、問題のファイルの先
頭部分で調整することもできますが、ファイルの転送できていた部
分を切り落として、残りの転送できなかった部分で、ftpを使って
再現テストする方が簡単と思います。

次に問題となるデータを特定する方法です。

転送できなかった部分の先頭1460バイト、1パケット分を切り出し
ます。
その前半を0クリアしたファイルと後半を0クリアしたファイルを作
製し、ftpで転送テストします。
どちらかが転送できないはずです。うまくいかない場合は、0では
なく1(0xFF)の方がいいかもしれません。
転送できなかった方のファイルのクリアされていない部分の前半と
後半をまたそれぞれクリアしたファイルを作製して、同じように転
送テストします。
これを繰り返せば、最後に問題となるデータにたどり着きます。

時間のあるときにでもやっていただけるとありがたいです。

Arita wrote in message <3AB23440.A9342B50@geocities.com>...
> ありたです。
>
> > はたの％お仲間募集中
>
> に釣られてやってきました。。
> 同じ現象かどうかわからないのですが．．．
>
> 私の遭遇している現象は、以下の２件。
> ・あるニュースサイトの描画が終了しないことが多い。
> 　（ＨＴＭＬデータは、それなりに？届いているみたい）

こちらは、ちょっとわかりませんが、

> ・ある特定のＳＭＩＬコンテンツの再生が終了しない。

こちらは、かなりあやしい気がします。
よくわからないのですが、ファイル個別のURLが得られて、個別に
ダウンロードできるのであれば、ぜひテストしていただきたいです。

>
> ＩＳＰのＡＰへのダイヤルアップでは再現しません。
> 一度dti.support.miscでお仲間募集してみません？＾＾

NTTのフレッツISDN網からプロバイダに接続される頃には、他の回
線とひとまとめにされているはずですから、プロバイダのサポート
の方が言われるように、条件は同じですというのもわからないでは
ないのです。
とすると、NTTの問題ということになるんですが、そうであれば、
他のプロバイダでも問題がでるはずなんですよね。

すべてのパケットが経路を正常に通過できることをテストする方法
ってないんでしょうか・・・。


ちまたでは、このくらいの転送障害なら、「ベストエフォート」の
範疇にはいるんでしょうかね。
最大限に努力しましたけど送れませんでした・・・なんてね。
---
はたの

ありたです。

確認方法ありがとうございます。
しばらく試す時間がなさそうです^^;

はたの wrote:
> 
> > ・ある特定のＳＭＩＬコンテンツの再生が終了しない。
> 
> こちらは、かなりあやしい気がします。
> よくわからないのですが、ファイル個別のURLが得られて、個別に
> ダウンロードできるのであれば、ぜひテストしていただきたいです。

ＦＴＰでダウンロードしましたが、正常に終了しました。
（ファイルサイズが数ｋから数10ｋByteの小さなもの）


> とすると、NTTの問題ということになるんですが、そうであれば、
> 他のプロバイダでも問題がでるはずなんですよね。

ＳＭＩＬコンテンツの再生に関しては、他のＩＳＰ（Hi-HO）のフレッツ
でも同様の現象となりました。
はたのさんの現象とは異なるのかもしれません。

他の方で、はたのさんと同様の現象に遭遇してらっしゃる方っていない
のでしょうか？


-- 
===========================
K.Arita <E-Mail> mailto:k-arita@mars.dti.ne.jp
[Hyogo] <  Web > http://www.mars.dti.ne.jp/~k-arita/
[Japan] <i mode> http://www.hi-ho.ne.jp/crucis/imode/
                          ===========================

はたのです。

ちょっと私の説明がまずかったようです。
httpとftpでは、同じファイルを転送しても、httpヘッダのせいで
ずれが生じて、同じデータのパケットにならないのです。あやしい
と思ったときと同じ転送方法で検証する必要があります。

Arita wrote in message <3AB44810.C34B2C39@geocities.com>...
> ありたです。
>
> 確認方法ありがとうございます。
> しばらく試す時間がなさそうです^^;
>
> はたの wrote:
> >
> > > ・ある特定のＳＭＩＬコンテンツの再生が終了しない。
> >
> > こちらは、かなりあやしい気がします。
> > よくわからないのですが、ファイル個別のURLが得られて、個別に
> > ダウンロードできるのであれば、ぜひテストしていただきたいです。
>
> ＦＴＰでダウンロードしましたが、正常に終了しました。
> （ファイルサイズが数ｋから数10ｋByteの小さなもの）

たぶん、httpだと思います。
詳しくはわからないのですが、SMILは、複数のファイルを同時にダ
ウンロードしているはずで、そのひとつがひっかかると止まってし
まうのではないかと。
一番あやしいのは、一番巨大なビデオ系のファイルじゃないかと思
いますが・・・。

> > とすると、NTTの問題ということになるんですが、そうであれば、
> > 他のプロバイダでも問題がでるはずなんですよね。
>
> ＳＭＩＬコンテンツの再生に関しては、他のＩＳＰ（Hi-HO）のフレッツ
> でも同様の現象となりました。
> はたのさんの現象とは異なるのかもしれません。

いえいえ、これは貴重な情報ですよ。
他のプロバイダでも状況は同じという・・・。

実は、土曜の夜にプロバイダのサポートの方からメールが届いて、
例のメンテナンス工事は、「NTT側の機材をNTTの作業で増設する」
工事だったというのです。以前、NTTのサポートに聞いたときには、
そのような工事は聞いていないし、記録にもないと言っていたんで
すけど。

でも、その方がツジツマがあっているような気がします。

パケットが迷子になっているのは、NTTの地域IP網内ではないかと
思えているからです。
プロバイダは、同じ地域IP網の別回線で、私の場合転送できないフ
ァイルを使ったテストで問題なかったと言っています。私宛ての場
合と何が違うかといえば、送り先のIPアドレスですが、このIPアド
レスは、接続するごとに変わりますから、それだけでは、私宛てを
特定する条件にはなりません。
その送り先IPアドレスと私が接続している回線を結びつける何かが
あるはずで、それがある条件を満たし、かつパケットのデータがあ
る条件を満たすときに、地域IP網のルーターが異常な動作をして、
そのパケットは迷子になってしまう・・・なんて考えています。

地域IP網の性質を満たすルーターってどういうものなんでしょうね。
かなり特殊なものを使っているのではないかと思われますが。

この説が正しければ、プロバイダを変更しても、状況は何も変わら
ないはずですね。
別のプロバイダと契約して検証してみます。(爆)
---
はたの％ケイゾク(^^;

ありたです。


はたの wrote:

> > > > ・ある特定のＳＭＩＬコンテンツの再生が終了しない。
> > >
> > > こちらは、かなりあやしい気がします。
> > > よくわからないのですが、ファイル個別のURLが得られて、個別に
> > > ダウンロードできるのであれば、ぜひテストしていただきたいです。
> >
> > ＦＴＰでダウンロードしましたが、正常に終了しました。
> > （ファイルサイズが数ｋから数10ｋByteの小さなもの）
> 
> たぶん、httpだと思います。
> 詳しくはわからないのですが、SMILは、複数のファイルを同時にダ
> ウンロードしているはずで、そのひとつがひっかかると止まってし
> まうのではないかと。
> 一番あやしいのは、一番巨大なビデオ系のファイルじゃないかと思
> いますが・・・。

すみません。中途半端な書き方をしてしまいました。
ＳＭＩＬは、自分自身で作成したものをＩＳＰに設置しＵＤＰで配信
しているものなのです。＾＾゛
怪しいと思われたリアルオーディオのデータをｇｅｔして比較してみ
たのですが、相違はみられませんでした。
ＳＭＩＬの作り方に問題があるのかも^^;


> 地域IP網の性質を満たすルーターってどういうものなんでしょうね。
> かなり特殊なものを使っているのではないかと思われますが。

フレッツＩＳＤＮの機材は、コストを下げるために安い機材を使って
いるという記事を日経ＢＰ誌で読んだ記憶があります。。


-- 
===========================
K.Arita <E-Mail> mailto:k-arita@mars.dti.ne.jp
[Hyogo] <  Web > http://www.mars.dti.ne.jp/~k-arita/
[Japan] <i mode> http://www.hi-ho.ne.jp/crucis/imode/
                          ===========================

Aritaさんの<3AB44810.C34B2C39@geocities.com>から

>他の方で、はたのさんと同様の現象に遭遇してらっしゃる方っていない
>のでしょうか？

こんにちは.curseです.
私も同じ現象に悩まされています.
今月初めからフレッツにしました.
以前は発生していなかったのでしょうか?

環境:
  NTT西日本(広島県)です.
  Router:MN128-SOHO
  プロバイダ:@nifty

私のとこでは,以下のような状態です.

1.現象の発生するファイルとしないファイルがある.
  (LINUXのCDイメージ等の500MB級は全滅ですが,
   10MBちょっとのものは出たり出なかったり,
   10MB以下のものは今のところ問題無し)

2.同じファイルでは決まったバイト数で停止する.(再現率100%)
  ただし,OSが異なると停止バイト数が全然違う.(LinuxとWinNT4で検証)
  また,FTPクライアントを変えても,同OS,同ファイルなら同じ箇所で止まる.

3.異なるミラーサーバを使用しても同名,同内容ファイルは同じ箇所で止まる.

4.WinNT4で止まったものにLinuxでレジュームすると,
  次に止まる箇所までは落ちる.その逆も同様.
  (現状では止まる所までいったら他OSでダウンロードと,
   交互に落としてMD5Checksumで確認している)

5.MN128-SOHOを使っているので,ルータ機能かと思い,
  シリアル接続してTA使用としても変わり無し.

6.WinNT4の普通インストール+SP6の最小構成でもかわらず.

7.niftyの通常アクセスポイント経由では全く発生しない.
  (接続料金の関係で2ファイルを3回ずつ実験しましたが,
   全然発生しません.フレッツ経由では再現率100%)

はたのさんのようにパケット調査する技量がないのでよくわかりませんが,
OSが違うと停止位置が違っています.
500MB級のファイルでは,4～5回交互にダウンロードしてやっと完了するという
状況です.

curse
e-mail:curse@nifty.com

-- 
curse mailto:curse@nifty.com

＃ 元記事が読めていません。話が違ったらすみません。

At Fri, 23 Mar 2001 15:47:43 +0900,
curse <curse@nifty.com> wrote:
(snip)
> はたのさんのようにパケット調査する技量がないのでよくわかりませんが,
> OSが違うと停止位置が違っています.
linux boxがあるのでしたらtcpdumpというコマンドでパケットへッダを
収集できます。GUIのetherealというものもありますので、停止位置の
直前からキャプチャーしてみてはどうでしょうか。後者ではある程度見易く
整形されるので試してみる価値はあると思います。

curse wrote:

> Aritaさんの<3AB44810.C34B2C39@geocities.com>から
>
> >他の方で、はたのさんと同様の現象に遭遇してらっしゃる方っていない
> >のでしょうか？
>
> こんにちは.curseです.
> 私も同じ現象に悩まされています.
> 今月初めからフレッツにしました.
> 以前は発生していなかったのでしょうか?
>
> 環境:
>   NTT西日本(広島県)です.
>   Router:MN128-SOHO
>   プロバイダ:@nifty

NTT 東日本で フレッツISDNを使って半年以上たちますが、
上記のような問題にはあったことがありません。
（ただし５００MB程度のファイルのダウンロードというのは
したことがありません。せいぜい大きくて２０MB程度です。
linux kernel ソースとか、emacs のソースとか。） ）

西日本で使っている機器（ルータ？）のファームウェアの
バグとかそんなことはないでしょうか。

もう少しバグ報告事例が増えて、ユーザの利用している通信機器、
ソフトウェアの統計データが集まらないと、
なんとも確信をもってはいえないでしょうけども。

あとは、そこそこの大きさで、「複数」の人で確実に再現して
転送問題がおきるファイルが特定できれば、
しぼり込みもしやすくなるかもしれませんね。

うるしのきょうたでございます。

直接の関係があるかは判りませんが、イー・アクセスのお知らせに
下記のような情報を見つけました。

平成13年3月28日
『送信パケットサイズ 1500バイト近辺におけるパケットロス多発
について』
http://www.eaccess.net/jp/user/i010328-2.html

平成13年4月2日
『送信パケットサイズ1500バイト近辺におけるパケットロス多発に
ついて（続報）』
http://www.eaccess.net/jp/user/i010402.html

これによると Centillium Communications, Inc のADSLチップ及び
制御ソフトウェアを使用した機器に、パケットサイズ1500バイト近
辺でパケットロスが多発するバグが確認されているそうです。


"はたの" <thatano@horae.dti.ne.jp> wrote
 in message news:zs6s6.1447$ux.147329@newsall.dti.ne.jp
> ところが、先日、メンテナンス工事なるものがあり、その後、ダウ
> ンロードできないパケットの条件が変わってしまいました。
> 値は同じなのですが、データ部先頭からのオフセットが、それぞれ
> 1420(0x58C)、1421(0x58D)になったのです。
> このメンテナンス工事には、NTT西日本は関係しておらず、プロバ
> イダのサポートによると、ADSL機材設置のためとのことでした。
                          ~~~~~~~~~~~~
                               ↑この辺があやしい？

-- 
漆野京太

はたのです。

eAccessの問題は、ADSLモデムのファームウェアの問題のようです。

フレッツADSLも同じように地域IP網を使うはずですから、フレッツ
ISDNとの関係に、ちょっとした疑いがあります。

フレッツADSLのMTUは、NTT東日本の資料によると、1454です。フレ
ッツISDNが、1500ですから、少なくなっている分、何かの情報を付
加しているものと思われます。一般的なPPPoEの場合のMTUは、1492
らしいので、さらに何かあるようです。

パケットのある特定の位置のデータに依存して、パケットが消失す
るということは、どこかの装置が、その位置のデータをチェックし
ているということになります。なぜ、あのような通常は用もないと
ころのデータを読んで、何かの判断をしているのか・・・。

このデータの位置が、フレッツADSLのパケットの付加情報の位置で
あれば、この事件の真犯人に近付きます。
すなわち、フレッツISDNとフレッツADSLで共通に使えるはずが、設
定に問題があるのか、設計自体の問題なのか、両者のパケットを混
同して、誤動作する装置があるということになるわけです。

なかなか問題のデータの位置まで調べていただけないので、ちょっ
とした疑いの域を出ていませんが・・・。
---
はたの