パスワードを忘れた? アカウント作成
14241898 story
バグ

NETGEARの無線LANルータ経由でファイル転送するとデータが破損するという報告 42

ストーリー by nagazou
これはちょっと 部門より
あるAnonymous Coward 曰く、

NETGEARの無線LANルータ経由でファイル転送すると特定の条件下でデータが破損するというツイートが話題になっている(タレコミ時点で790RT)。

ツイート主のtokkyo氏によれば、APモードのR7800でデータをコピーすると毎度データが破損するこの現象は、海外のネットワーク製品コミュニティで既知のバグとして報告されていたようだ(R7800 data corruption when in Accesspoint mode | SmallNetBuilder Forums)。

昨年1月からのコミュニティの書き込みによれば、この現象は4~5年前の旧機種にあたるR7500でも発生していたといい、700MB程度の大きなファイルを転送する際に、無線/有線を問わず、SMB/FTP/SCPといったプロトコルで発生するという。NETGEARに問題を報告したユーザーによれば昨年10月時点では調査中だったようだが、その後のことは明らかになっていない。

ファイルが正常に転送されたかに見えて破損しているというのは、ぞっとする話である。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ルータの低レイヤな処理のなにかトリガを引いてはいるものの、
    化けるバグはもっとPC側の上位の処理にあったりするんじゃなかろうか。
    ルータが上位のペイロード書き換えたりしてんのかな。

    • by Anonymous Coward

      TCPのチェックサムなんて16ビット単位でしかないので、あまりにもエラーが多すぎたら「たまたま正しくなる補数」も出てきてすり抜ける。

    • by Anonymous Coward

      WiFiはものによっちゃ案外化けるよ
      ISPから借りた無線付き複合ルータと安物PCのWiFi(多分Intelの無線モジュール)で
      200MBくらいの動画二〜三個に一個の割合で一部のデータが化けるとか経験あるし
      動画だと一瞬画像が乱れるだけだから、エンコエラーか回線エラーか分かんねーの
      確定再現する奴じゃなくてノイズ系で再ダウンロードすれば差異が確認できたけど
      バグの類だと毎回同じに化けて差分が出ないパターンもありうるのが怖い
      もちろん有線に切り替えて解決(そもそも有線張ってたのにメトリックの問題で無線になってた)

      元々有線信者だったけどこれのおかげで益々無線に忌避感が……

  • by Anonymous Coward on 2020年07月17日 16時14分 (#3853953)

    昔、AthlonMP用マザボの内蔵LANで同じ状態になったことがある。
    ファイルのコピー後にdiffを取ると、必ず同じ場所でコピー側のファイルが破損するが、別途LANカードを利用すると、問題が発生しない。
    めんどくさかったので、それ以上の原因は究明しなかったけど。

    • 昔、SCSIホストアダプタ(AHA-3940)とMOドライブの組み合わせで似たような状態になったことがあります。
      小さなファイルをコピーする分には大丈夫だけど、巨大ファイルのコピーで一部化ける。

      運良く取り返しがつくうちに気づいて、AHA-3940はHDD相手だと問題ないし、
      MOもAHA-1522相手だと問題なかったので、MO専用に追加でAHA-1522を挿して運用するようにしました。

      親コメント
    • by Anonymous Coward

      diffかぁ…
      コピー元コピー先で差が出ないのに、コピー元のファイルは開けないというのは有りましたね。
      相談受けて調べてたんですけど、別メディアに移動でもアウトで諦めました…
      #ネタ抜きに呪われたファイルと呼ばれた

      • by Anonymous Coward

        呪いのファイルはファイルシステムが壊れた時によく発生する印象がある

  • by Anonymous Coward on 2020年07月17日 16時06分 (#3853947)

    お宝が破損してしまうのか。つらい。

    • by Anonymous Coward

      社長の年始挨拶の動画ですか?

    • by Anonymous Coward

      > お宝
       
      LinuxのCDイメージとかですね。

    • by Anonymous Coward

      動画だと多少壊れてても再生できてしまうから気づかないかもね。

      • by Anonymous Coward

        大事な部分だけ壊れてたら悲しい。

        • by Anonymous Coward

          モザイクなら壊れて欲しい。

          • by Anonymous Coward

            モザイク処理された時点で元々の情報量が失われているのだから
            モザイク部分のデータが壊れた場合更に情報量が失われてモザイクが荒くなるだけでは?

            徹底的に情報量が失われて黒の四角だけで隠されると却ってエロく見えるかも。

            • by Anonymous Coward

              え?モザイクが消えるメガネとか知らないんですか?

              # いつの間にか見なくなったなその手の広告

              • by Anonymous Coward

                AI補完技術で本当にモザイクが消せるようになってしまったし

            • by Anonymous Coward

              社長の挨拶が?

  • by Anonymous Coward on 2020年07月17日 16時24分 (#3853962)

    バグの原因を想像すると、

    ・受信バッファーの内容を送信バッファーにコピーするときに、データ長を間違えて一部コピーし忘れてる
    ・受信・送信バッファーのキャッシュのハンドリングで何かミスってる
    ・何かのプロセスが自分に割り当てられた以外の範囲のメモリーにアクセスして破壊

    • by Anonymous Coward

      ルータがファイルを全部キャッシュするとも思えんから、手抜きで同一データのカウンタに上限があるんじゃなかろうか。

    • by Anonymous Coward

      お土産つけてたのバレちゃった
      だったりして((((;゚Д゚))))ガクガクブルブル

    • by Anonymous Coward

      ジャンボフレームで後半が無視されるとか結構前は有りましたが、
      あちらも最近SSDや10GbE周りで再燃して混乱してる模様

      • 私も最初子の話を読んだときこれだと思いました。タレコミでは触れられていないけど、元サイト読むと WAN 側インターフェースだけダメで、LAN側では問題ない、ということでしたし、WAN側で Jumbo frame が通らなくとも、まぁブリッジ対応では問題になるわけですが、仕様のような気がする。
        親コメント
      • by Anonymous Coward

        ジャンボフレームや省電力系などのある意味小手先芸の機能については、
        処理チップの能力が向上すると他の機器との接続性を考えて需要が減るから実装が雑になりがち。

        #そもそもネットワーク系って数百万レベルの機器でも書いてあることが実際は実装できてないなどが頻発するレベルなのでアレだけど

    • by Anonymous Coward

      大きいファイルで現象が発生というところからバッファ関係の問題を想像されたのかもしれませんが、件のフォーラムによれば数十MBと少ない転送量でもパケットのドロップが観測されています。おそらくAPモード特有の処理にメモリ破壊のバグがあって、大部分はCRCでエラーが判明しドロップ(再送)するものの、数百MBになるとCRCをすり抜けるパケットが出てきてしまうということではないかと。

  • by Anonymous Coward on 2020年07月17日 17時01分 (#3853985)

    L4/L3ヘッダのチェックサムはどうなっているんでしょうね。
    ルーターモードとブリッジモードで違うと言ってるので、ルーターモードにするとL3ヘッダのチェックサムを適切に計算して破棄してくれる(適切というか普通)とかだと思うのですが。

    個人的には、EthernetもIPも到着順序保証しないのになぜかそれを期待しているTV会議装置の実装で苦しんだこともあったりで、必ずしも各レイヤが期待した通りに動いているとは限らないよなあと感じます。

    • by Anonymous Coward on 2020年07月17日 17時35分 (#3854005)

      昔インターネット経由でファイル転送するソフト作ってて、低率だけどデータが化けるので、CRCでエラーチェックするようにしたことありますね…。
      TCP/IPはエラーチェックしてるから化けないはずだ! と主張されても、実際化けるんだもんよ。
      下のレイヤを信用しちゃいけない、というのがその時学んだ教訓ですね。

      もう20年ぐらいも前の話だから、Windows98とかも現役だったかな、ドライバあたりも怪しかったですけどハードも信用できなかったね。
      今だって信用しちゃいけないんだろうなと思う。

      親コメント
      • by Anonymous Coward on 2020年07月17日 20時31分 (#3854143)

        HTTPリクエストにはUser-Agentのようにほぼ固定の文字列が含まれているので、これを利用してメジャーなUser-Agentと1ビット違いの文字列をログから探して、そのエラー率を求めればよい。やってみれば、ちらほらそういうリクエストが実際に見つかってびっくりすると思う。そういったリクエストはおそらくメモリエラーを起こしたクライアントから送られてきている。

        https://note.com/ruiu/n/nbb7a52c374ae [note.com]

        なんて話もありますしね。

        親コメント
      • by Anonymous Coward

        ATERM を導入してから3ヶ月、我が家でもデータ破壊が2回ほどあって、
        微妙に装置を信用できてないんだよなぁ。
        wifi か USBメモリかとにらんでいるんだけど、頻度が頻度だけに
        追いかけるわけにもいかず、不信感だけがつのってつらいよぉ。

      • 比較的高いファイルサーバーにある、あまり使っていないデータを比較的安いNASに移して、
        ファイルサーバーから消して欲しいのですが、
        消してもらう決心をうながすため、「確実に複製できた」検証が必要です。

        なぜかNASにはハッシュを取る機能が無いので、ファイルサーバー(Windows)から、
        Get-ChildItem | Get-FileHash | Sort-Object | Export-Csv を
        やって、得た結果の比較をしようとしています。

        それにしても、何でNASには検証機能が無いのでしょうか? それこそ大事極まる話に思えますが。。。

      • by Anonymous Coward

        一般論として、CRCは付加されているがエラーを検出した場合の後処理は実装により異なる~という場合も少なくない
        受け側ではCRCの計算・コンペア省略、エラーを検出しても何もしない、フラグは立てるが意図的にフラグを読みに行かなければエラーを検知できない~こともある

    • by Anonymous Coward

      ラジコン飛行機による無線中継機器でイーサネットパケットを転送するシステムにて、
      無線区間でデータ化けが発生する可能性がある (検出・訂正機構なし) にも関わらず
      無線受信したパケットを元に イーサネットのチェックサムを「再」生成する、という無茶な処理に出会いました。

      実際に無線区間でデータが化けているにも関わらず、イーサネットレベルでは正常に見えるという...
       

  • by Anonymous Coward on 2020年07月17日 17時07分 (#3853988)

    まだ世の中 eepro100 の方が良いとされていたころの話。
    RedHatをNW経由でインストールした際に、
    特定のRPMファイルのインストールで必ず失敗していたことを思い出しました。

    その時は、ドライバのバグ情報(特定のビットパターンが化けるだったかな?)を見つけて、
    mtuサイズを調整して乗り切った。

  • by Anonymous Coward on 2020年07月17日 19時09分 (#3854074)

    > SMB/FTP/SCPといったプロトコルで発生
    FTPとか暗号化しなくとも通信できるSMBはともかく、完全性のチェックが必須のSCPで化けるってどういうことだってばよ……

    • つーかNETGEAR製品をつかってファイルがおかしいってなこと結構昔から聞くね。

      >完全性のチェックが必須のSCPで化けるってどういうことだってばよ……
      別に不思議でもなんでもないです、各レイヤーはそれ以外のレイヤー
      にたいして干渉しません。つまり完全性のチェック以外でデータが
      おかしくなっているのです。

      • by Anonymous Coward

        いやどのレイヤーでもデータがおかしくなったら完全性のチェック通らないから

    • by Anonymous Coward

      リンク先読んだら、こういう投稿だった(抜粋)。さすがにSCPでは未確認だろう。

      I only discovered the problem in SMB transfers and maybe SCP, never in HTTP(s).

      • by Anonymous Coward

        その文章に続けて"Did you also test this?"(他に試した人いる?)って質問に対して
        https://www.snbforums.com/threads/r7800-data-corruption-when-in-access... [snbforums.com]

        FYI: I faced this with SMB, FTP, SCP transfers when using WAN. Using cable, not W-Fi. So it is rather internal problem. Not Wi-Fi or specific protocol related.
        (参考までに、私はWANを使用した時にSMB,FTP,SCP転送でこの問題に直面しました。W-Fiではなくケーブルを使用しています。なのでこれはWi-Fiや特定のプロトコル関連というよりは内部的な問題です。)

    • 化ける前に通信エラーになる

typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

読み込み中...