Top過去ログ目次掲示板

作成日:2007年04月15日 作成:おやじ
掲示板で過去に質問された内容です。

No.6872 LZHファイル形式でダウンロードが中断してしまいます。


No.6872 投稿時間:2007年04月15日(Sun) 12:08 投稿者名:良平 URL:
タイトル:LZHファイル形式でダウンロードが中断してしまいます。

おやじ様、いつも参考にさせて頂き感謝しております。

ファイルの形式などによりデータ転送が中断するなど
不思議な現象がでております。
思いあたる節などございましたらご教授ねがえないでしょうか。
恐縮ですがよろしくお願いいたします。

さて現在FTPサーバを家庭内LANで立てておりますが
特定のファイル形式LZHでダウンロードが中断しております。
別の圧縮ファイルzipや普通のテキストファイルの4MB程度は
問題なくダウンロードできるようなのですがこの様な現象はそちらでも
あるでしょうか。色々と試してみたのですが解らず投稿させていただきました。

環境と現象は下記の通りです。

ADSL回線、ルータNEC DR202,FTPサーバはWindows/XP PRO
FTPサーバソフトは WarFTPD1.67-05
PMTUD Black Hole対策でMTUサイズを1454に設定
ダウンロードさせるファイルはテキストファイル ***.TXTを圧縮したもので
日によりサイズは違いますがおおよそ400KB前後のlzhファイルです。

このファイルをダイアルアップで接続した相手PCにダウンロードして
もらっているのですが殆ど途中で相手PC側からみて110KBあたりで中断
してしまいます。ただ小さい80kB程度のLZHファイルはダウンロードが
可能です。

他のファイルでは圧縮前のテキストデータなどサイズは10倍くらい
ですが問題なく転送できたり、また圧縮でもZIP形式なら転送可能です。

また同一のLANで別のPCにWarFTPD1.82-rc11を立てて同じように
しても現象は変わらずでした。

さらにこのファイルをプロバイダへのFTPサーバ転送すると
ダウンロードできてしまいます。こちらの環境に問題があるようですが
ファイルの形式によりダウンする部分がどうしても不明です。

相手の都合で現状はlzhファイルが限定されるのですがどうにも解らず
思いあたる部分などありましたらお教え願えないでしょうか。
よろしくお願いいたします。


No.6873 投稿時間:2007年04月15日(Sun) 14:41 投稿者名:良平 URL:
タイトル:Re: LZHファイル形式でダウンロードが中断してしまいます。

補足ですが他のPCからFTPサーバへのアップロードは全く問題できております。はじめはMTUのブラックホールかと疑いMTUを調整したり
したのですがどうも駄目のようです。


No.6875 投稿時間:2007年04月15日(Sun) 16:55 投稿者名:おやじ URL:
タイトル:環境依存のような気がしますが・・・。

> さて現在FTPサーバを家庭内LANで立てておりますが
> 特定のファイル形式LZHでダウンロードが中断しております。
> 別の圧縮ファイルzipや普通のテキストファイルの4MB程度は
> 問題なくダウンロードできるようなのですがこの様な現象はそちらでも
> あるでしょうか。色々と試してみたのですが解らず投稿させていただきました。

おやじは現用ではLinuxを使用しているので、ランニングしないと発生しない問題はおやじの環境ではわかりません。ただ、ftpですからファイル形式が理由で違いがでるとは論理的には考えにくいですね。WarFTPDにしろクライアント(FFFTP?)にしろ、転送フェーズでは中身を見ているわけではなく、単なるバイナリ/テキストデータを扱っているだけですから。唯一見ているとすれば、クライアントでは最初にファイルの拡張子を見て、転送モード(ASCII/バイナリ)を変更するぐらいではないないでしょうか?
従って、たまたま lzh や zip や txt であっただけではないかとおやじは想定します。
下記も参考にすると、環境依存のような気がするのですが?
zipやtxtでlzhと同じぐらい試験してみたのでしょうか?
ADSLが切れたり、エラーが多い(モデムのログを見る)ことはないですか?
時間帯などはどうでしょうか? (ADSLの場合、近くの工場が操業開始するときだけノイズが増えて調子が悪くなる等の例もあります。)

> 環境と現象は下記の通りです。
>
> ADSL回線、ルータNEC DR202,FTPサーバはWindows/XP PRO
> FTPサーバソフトは WarFTPD1.67-05
> PMTUD Black Hole対策でMTUサイズを1454に設定

MTUは、この現象を見る限りまったく関係ありません。PMTUD Black Holeなら、初めから転送が始りません。
因みに、モデムだとMTUはかなり小さかった(500数十Byte)と記憶してます。(OS依存だったかも?)

> ダウンロードさせるファイルはテキストファイル ***.TXTを圧縮したもので
> 日によりサイズは違いますがおおよそ400KB前後のlzhファイルです。
>
> このファイルをダイアルアップで接続した相手PCにダウンロードして
> もらっているのですが殆ど途中で相手PC側からみて110KBあたりで中断
> してしまいます。ただ小さい80kB程度のLZHファイルはダウンロードが
> 可能です。
>
> 他のファイルでは圧縮前のテキストデータなどサイズは10倍くらい
> ですが問題なく転送できたり、また圧縮でもZIP形式なら転送可能です。
>
> また同一のLANで別のPCにWarFTPD1.82-rc11を立てて同じように
> しても現象は変わらずでした。

ということは、デーモンではないですよね。従って、上記のように残るのは回線とかNIC(ドライバ含む)とか、OSとかだと思いますが、一番あやしいのは回線品質ではないかとおやじは思います。
かなりの頻度で発生するなら、切れるときの状況を把握できればもう少しわかるのではないでしょうか?
クライアントが待ち状態で切れるのか?サーバが待ちなのか? これはパケットキャプチャするなり、ログをみればある程度追い込めないでしょうか?
回線品質なら、ADSLモデムのログでエラーや切断回数などを見てみるとヒントがないでしょうか?
こういう場合、基本的に信じられるのは切れた時の共通項だけです。切れた以上、原因は必ずありますが、比較で切れないと思っていてもそれはたまたまであることが多いからです。何故なら、比較試験は問題が起きているケースと同じ時間、同じ回数は実施しないのが通常なので、うまくいっていると勘違いするケースが多いからです。
起こりえないことが起こっているときは、何か思い込みがあって追い込むための客観的な評価ができていないと見たほうが正解と思います。

> さらにこのファイルをプロバイダへのFTPサーバ転送すると
> ダウンロードできてしまいます。こちらの環境に問題があるようですが
> ファイルの形式によりダウンする部分がどうしても不明です。

これも、試験回数や条件設定を評価する必要があると思います。


No.6876 投稿時間:2007年04月15日(Sun) 18:28 投稿者名:良平 URL:
タイトル:Re: 環境依存のような気がしますが・・・。

おやじ様、早々に書き込みいただきありがとうございます。

ご指摘のように他地域のサーバではダウンロードできてこちらの別々の
PCにサーバを立てても駄目なので回線などの環境と考えてはおりました。
実はこの現象が出て3ヶ月以上経悩み続けています。
まずは回線環境の改善から色々とやってみました。
回線環境ではざっと下記のような事をしました。
1.近くにISDN回線がありましたのでそれをアナログ回線に変更
  (回線スピードが1.1MBから1.5MBへ上がりました。)
2.さらに結果がよくないので各PCの電源やLANケーブルと
  電話線などにフライトコアーなどノイズ除去対策を実施
3.サーバのMTUを536に設定など。

実務では相手の回線状況が悪いので仕方ないと考えておりましたが
あまりに酷いので試験回数はかなりやりました。
数メガのテキストファイルは全く問題なく、500KB程度のzipもOKですが
やはりこのlzhファイルは夜、昼、または平日、休日と関係なく
ダイアルアップだと100%ダウンしてしまいます。
Lzhだから駄目だとはどうにも理解できないのですが現状の通りです。

>これはパケットキャプチャするなり、ログをみればある程度追い込めないでしょうか?

パケットのキャプチャ方法などとうすればできるか解らないですが
一度調べてみます。またモデムのログと合わせて追い込みます。
しかし不思議な現象です、一棟12戸と小さいですがマンションで
ある事も影響が大きいのでしょうね。
また報告いたします。ありがとうございます。


No.6878 投稿時間:2007年04月15日(Sun) 20:26 投稿者名:おやじ URL:
タイトル:キャプチャは、WireShark(旧Ethereal)が定番です。

> ご指摘のように他地域のサーバではダウンロードできてこちらの別々の
> 実務では相手の回線状況が悪いので仕方ないと考えておりましたが
> あまりに酷いので試験回数はかなりやりました。
> 数メガのテキストファイルは全く問題なく、500KB程度のzipもOKですが
> やはりこのlzhファイルは夜、昼、または平日、休日と関係なく
> ダイアルアップだと100%ダウンしてしまいます。
> Lzhだから駄目だとはどうにも理解できないのですが現状の通りです。

「このlzhファイル」という表現が気になりますが、特定の1個のファイルということですか?
もしそうなら、ファイルの形式ではなくある特定のビットパターンが関係しているというのも無きにしも非ずです。
lzhならあるサイズを超えるとどれでも駄目ならその可能性はありませんが・・・。

> >これはパケットキャプチャするなり、ログをみればある程度追い込めないでしょうか?
>
> パケットのキャプチャ方法などとうすればできるか解らないですが
> 一度調べてみます。またモデムのログと合わせて追い込みます。

キャプチャは、WireShark(旧Ethereal)が定番です。大きなファイルでしょうから最初から見る必要はないと思いますので、そろそろかなと思うときからキャプチャすれば良いのではないでしょうか?
頻繁に再送が起きてないですかね。


No.6880 投稿時間:2007年04月16日(Mon) 00:34 投稿者名:良平 URL:
タイトル:Re: キャプチャは、WireShark(旧Ethereal)が定番です。

> 頻繁に再送が起きてないですかね。

はじめてですがWireSharkを使ってみました。
ご指摘のように TCP Dup ACKが23個ほど連発し中断しておりました。
中断する直前のシーケンス番号のパケットを相手先から何度も要求
されおります。
サーバー側は送信しているのですがパケットロスになっているのでしょうか。

転送試験ですが500kほどのテキスト、zip, lhzとも相手から
送信→サーバ受信では再送がおきておらず
相手受信−サ−バ送信ではテキスト、zipは10数回の再送要求が
数回にまとまって発生するものの乗り越えております。
相変わらずlhz形式では再送が20数回と連続し落ちてしまいます。
テキストなどのアスキー転送は再送が殆どなくzipやエクセルなどの
バイナリー形式では再送要求は多い目のようです。しかしlzh形式で
再送要求が酷くなる理由が全く不明です。
毎回単純なテキストデータを圧縮して置いているので
中身は異なりデータの破損はないようです。
相手からのアップロードは問題なくできておりますし。
試しに相手からアップされたデータをダウンロードさせても
中断してしまいます。う〜ん、こんな事があるんですね。
何か対策があるでしょうか。


No.6881 投稿時間:2007年04月16日(Mon) 12:09 投稿者名:すいすい URL:
タイトル:Re^2: キャプチャは、WireShark(旧Ethereal)が定番です。

良平さん、はじめまして。

あまり関係は無いかもしれませんが、以下の文字が入っていたりするとエラーになった経験が私はあります。
http://proxy.f3.ymdb.yahoofs.jp/bc/6af1a383/bc/FTP%a5%c0%a5%e1%ca%b8%bb%fa.txt?bcOwuIGB6PAeXJkb

FTPサーバがWarFTPDということですが、一度設定の拒否リストとかを見てみるのはいかがでしょうか?
もしくはレートの設定も関わっているのかもしれません。
(全部関係ないかもしれませんが。m(_ _)m)


No.6882 投稿時間:2007年04月16日(Mon) 18:23 投稿者名:良平 URL:
タイトル:Re^3: キャプチャは、WireShark(旧Ethereal)が定番です。

すいすいさんレスありがとうございます。

ご案内頂きましたURLですが見れないのですが
何か相手サイトが閉じたのでしょうか。恐れいります。


No.6883 投稿時間:2007年04月16日(Mon) 19:52 投稿者名:すいすい URL:
タイトル:Re^4: キャプチャは、WireShark(旧Ethereal)が定番です。

> すいすいさんレスありがとうございます。
>
> ご案内頂きましたURLですが見れないのですが
> 何か相手サイトが閉じたのでしょうか。恐れいります。

良平さん、こんばんわ。
すみません、私のヤフーのブリースケース内のテキストを表示したつもりだったんですが、
ログインできなかったようですね。m(_ _)m
以下にその内容を一覧表示しました。

おそらくダメ文字

― ソ Ы \ 噂 浬 欺 圭 構 蚕 十 申 曾 箪 貼 能 表 暴 予
禄 兔 喀 媾 彌 拿 杤 歃 濬 畚 秉 綵 臀 藹 觸 軆 鐔 饅 鷭
x x

ただ、良平さんの状態を考えてもあまり上記の内容とは関係ないように思えますので、
解決策にならないかもしれませんが。


No.6885 投稿時間:2007年04月16日(Mon) 22:13 投稿者名:おやじ URL:
タイトル:クライアントからTCP DUP ACKが出ているのでサーバから見た上り側駄目ですね。

> > 頻繁に再送が起きてないですかね。
>
> はじめてですがWireSharkを使ってみました。
> ご指摘のように TCP Dup ACKが23個ほど連発し中断しておりました。
> 中断する直前のシーケンス番号のパケットを相手先から何度も要求
> されおります。
> サーバー側は送信しているのですがパケットロスになっているのでしょうか。

TCP DUP ACKに対してサーバは、再送しているんですよね。
TCP DUP ACKが出ている以上、明らかにサーバから見た上り側(NIC->LANケーブル->ADSLモデム->回線)でパケットの到達性が失われていますね。
状況からするとNIC->LANケーブなどはあまり関係なさそうに見えますが、もし予備があるなら交換してみてはどうでしょうか?
一番怪しいのはADSLの部分でしょう。ADSLでどれくらいの速度が出ているのかはわかりませんが、下記のように上りは低い周波数を使っているので下りよりは比較的ノイズには強いはずです。

http://www.aconus.com/~oyaji/adsl/adsl_shift.htm

マンションとのことなので、電話回線にインターホンが乗っているとかはありませんか?
あとは、電話回線にスプリッタを介さずにブランチで電話機がぶら下がっているなんていうのはないでしょうか?
ADSLモデムの電源を壁コンから単独でとり、コアを入れる。アースも取ってみる。
ADSLの品質問題は自分ではほとんど何もできないので、これ以上は無理かもしれません。

> 送信→サーバ受信では再送がおきておらず
> 相手受信−サ−バ送信ではテキスト、zipは10数回の再送要求が
> 数回にまとまって発生するものの乗り越えております。
> 相変わらずlhz形式では再送が20数回と連続し落ちてしまいます。
> テキストなどのアスキー転送は再送が殆どなくzipやエクセルなどの
> バイナリー形式では再送要求は多い目のようです。しかしlzh形式で
> 再送要求が酷くなる理由が全く不明です。
> 毎回単純なテキストデータを圧縮して置いているので
> 中身は異なりデータの破損はないようです。
> 相手からのアップロードは問題なくできておりますし。
> 試しに相手からアップされたデータをダウンロードさせても
> 中断してしまいます。う〜ん、こんな事があるんですね。

本件は、事実としてTCP DUP ACKがクライアントから来ている以上、ほとんど因果関係はないと思ったほうが良いと思います。
単に、上り回線の伝送品質が悪いということだけと思います。


No.6887 投稿時間:2007年04月16日(Mon) 23:08 投稿者名:良平 URL:
タイトル:Re: クライアントからTCP DUP ACKが出ているのでサーバから見た上り側駄目ですね。

> 状況からするとNIC->LANケーブなどはあまり関係なさそうに見えますが、もし予備があるなら交換してみてはどうでしょうか?
> 一番怪しいのはADSLの部分でしょう。ADSLでどれくらいの速度が出ているのかはわかりませんが、下記のように上りは低い周波数を使っているので下りよりは比較的ノイズには強いはずです。

下りで2.3MB,上り0.8MBがモデムでの情報です。

> マンションとのことなので、電話回線にインターホンが乗っているとかはありませんか?
> あとは、電話回線にスプリッタを介さずにブランチで電話機がぶら下がっているなんていうのはないでしょうか?
> ADSLモデムの電源を壁コンから単独でとり、コアを入れる。アースも取ってみる。
> ADSLの品質問題は自分ではほとんど何もできないので、これ以上は無理かもしれません。

環境としてはインターホンとか余計なものはないですし
本日HUBとケーブルは交換し他のPCのLANケーブルも全て外して
みましたが改善はされなかったです。
またフライトコアも電源からLANケーブルなどこれでもかと
付けてみましたが変わらずのようです。

> 本件は、事実としてTCP DUP ACKがクライアントから来ている以上、ほとんど因果関係はないと思ったほうが良いと思います。
> 単に、上り回線の伝送品質が悪いということだけと思います。

となるとこちらでは光ケーブルにする以外手が無いような感じですね、本日EO光へは申し込んでみましたが何分集合住宅で
工事も難しく単独の引き込みになりそうです。
この数週間の事なのですが何か外的要因が発生し
以前では出来ていた事が出来なくなるとは何か釈然とせず
悔しい思いが募ります。
また報告させていただきます。ありがとうごさいます。


No.6890 投稿時間:2007年04月17日(Tue) 14:20 投稿者名:良平 URL:
タイトル:Re: クライアントからTCP DUP ACKが出ているのでサーバから見た上り側駄目ですね。

> 本件は、事実としてTCP DUP ACKがクライアントから来ている以上、
>ほとんど因果関係はないと思ったほうが良いと思います。
> 単に、上り回線の伝送品質が悪いということだけと思います。

ひとつ疑問なのですがFTPサーバーからFTPクライアントとして他の
プロバイダーのサーバーへは中断することなく転送ができてしまいます、
同一の回線上でFTPデーモンとして相手のリクエストでの送信で中断し
クライアントとし転送できるので同じ上り回線かと思うと何か矛盾するように感じます。
ただFTPクライアントとして送る相手は光かADSL回線なので今回のダイアルアップと状況がちがいます。
しかし中にはADSLで接続されても中断しますので益々混迷いたします。


No.6895 投稿時間:2007年04月18日(Wed) 21:13 投稿者名:おやじ URL:
タイトル:サーバが再送しているかどうかで違うのでは?

> > 本件は、事実としてTCP DUP ACKがクライアントから来ている以上、
> >ほとんど因果関係はないと思ったほうが良いと思います。
> > 単に、上り回線の伝送品質が悪いということだけと思います。
>
> ひとつ疑問なのですがFTPサーバーからFTPクライアントとして他の
> プロバイダーのサーバーへは中断することなく転送ができてしまいます、
> 同一の回線上でFTPデーモンとして相手のリクエストでの送信で中断し
> クライアントとし転送できるので同じ上り回線かと思うと何か矛盾するように感じます。
> ただFTPクライアントとして送る相手は光かADSL回線なので今回のダイアルアップと状況がちがいます。
> しかし中にはADSLで接続されても中断しますので益々混迷いたします。

前回、「TCP DUP ACKに対してサーバは再送しているんですよね。」と確認した答えがなかったのですが、再送していれば明らかに上り方向の問題で、相手がダイヤルアップでなくても同じであればますますその疑いが濃くなります。特定のクライアントだと、そのクライアント固有の話があるかもしれません。
また、TCP DUP ACKに対してサーバが再送していないとすると、既にサーバ葉切れたと見ないして無視している可能性もあると思います。


No.6896 投稿時間:2007年04月19日(Thu) 01:43 投稿者名:良平 URL:
タイトル:Re: サーバが再送しているかどうかで違うのでは?

> 前回、「TCP DUP ACKに対してサーバは再送しているんですよね。」と確認した答えがなかったのですが、

おやじ様この件すみません、TCP Retransmissionを連発して
その後に落ちる場合が多いようです。

やはり上り方向の回線品質でしょうか、
FTPサーバにFTPクライアントソフトを入れて
同じファイルを他へ送信(上り)は問題なく行くのが
やはり理解できないです。

単純にADSLから光りへ引越しするだけで治ればよいのですが
何か懸念が残るような感じです。
色々と恐れいります、ありがとうございます。


No.7035 投稿時間:2007年06月17日(Sun) 09:46 投稿者名:良平 URL:
タイトル:この件の最終報告です。

通信回線をやっと光りへ変更できすんなりと解決いたしました。
やはりADSLの回線品質の原因だったようです。
合わせてルータをOPT100Eに変えました。
ADSLでのサーバー運用は少し無理があるのかな、

一応LANアナライザーで確認してもエラーやリトライがなく
上手く通信できているようです。色々とありがとうございました。
またよろしくお願いいたします。



掲示板▲頁先頭