パスワードを忘れた? アカウント作成
15288336 story
携帯通信

福井ケーブルテレビ局でのRakuten Linkの障害、原因が特定され対応も完了 36

ストーリー by nagazou
報道された結果のようで 部門より
以前、福井のケーブルテレビ局が、楽天モバイルに技術サポートを求める異例の発表を行っていたが、その原因となる「Rakuten Link」で通話ができない問題が解決したとする内容がケーブルテレビ局側から発表された(FCTV・SCTV|障害情報楽天モバイル)。

17日に発表された内容によると、あの報道の後に楽天モバイルから問題解決を行うことに合意する連絡があり、両社で検証したデータを元に楽天モバイル側で対応が行われたとしている。対応は5月13日に完了したとのこと。具体的な原因に関しては、UDPチェックサムの取扱に齟齬があったことが原因だとしている。

あるAnonymous Coward 曰く、

【事象解決】【5/17追記】楽天モバイルの「Rakuten Link」で通話が出来ない事象について
http://fctv.mitelog.jp/syogai/2021/05/517rakuten-link-6348.html

(復旧済み)「Rakuten Link」に関する福井ケーブルテレビ・さかいケーブルテレビの障害情報について
https://network.mobile.rakuten.co.jp/information/news/other/582/

福井のケーブルテレビ局、楽天モバイルに技術サポートを求める異例の発表
https://mobile.srad.jp/story/21/03/09/0139216/

  • by Anonymous Coward on 2021年05月19日 14時10分 (#4034345)

    リリース文に

    > NAT機器での通信状況を調査したところUDPチェックサムの取扱に齟齬があり

    ってあるけど、齟齬ってチェックサムがおかしかったってことですかね? どういうことなんだろ。

    ここに返信
    • by Anonymous Coward on 2021年05月19日 14時23分 (#4034362)

      チェックサムには実際には送られない疑似ヘッダの分を計算入れるらしいけど
      この疑似ヘッダには送り先送り元のIPアドレスがあってそれが
      グローバルアドレスとローカルアドレスのどちらが入るかで
      チェックサムが変わってしまって捨てられちゃうとかそんなんかな。

    • by Anonymous Coward

      NATでIPアドレスが変わるからUDPチェックサム0にしといたら、楽天側は0という値をそのままチェックサムとして判断したとか?

    • by Anonymous Coward

      単なるやじ馬だけど参考までに詳報が欲しいなあ。

      関係者の方へ ACはこの問題原因周知が放置されることを適切と考えておらず、貴社からの連絡を歓迎致します。(技術者が個人的にご連絡頂く場合、その秘密は(たぶんスラドの中の人が)守ります)

      • by Anonymous Coward

        いつかJANOGで話される機会があるかも知れない

  • からの「UDPチェックサムの取扱に齟齬があり楽天モバイルが対応」

    ここに返信
    • by Anonymous Coward

      そりゃ福井ケーブルテレビの機材を楽天モバイルが治すなんて出来ないよなあ。
      それとも機器メーカーから貰ったパッチを楽天から来てた技術者に入れてもらったとか?
      それだと営業としてやっているって事自体が不思議に思えるし。

      • by Anonymous Coward on 2021年05月19日 23時01分 (#4034766)

        逆だよ。
        NAPTでパケットが変化するのはNAPT環境では残念だが当然の動作なんだが、
        楽天側のソフト・機材はそれを処理できなかった、と言うのがそもそもの問題。
        IPv4アドレスが枯渇する中、NAPTが使われるのもそれでパケットが変化するのもほぼ不可抗力。
        枯渇してるIPv4アドレスを買い集めて顧客にタダで配るなんてのは余裕のあるISPにしか無理な選択だ。
        従ってこの問題は根本的には楽天側の機材やソフトを修正するかNAPTへの非対応を明示するかしか対処法は無い。
        どちらの対処も楽天の責任なんだよ。

        にも関わらず楽天は不具合の情報を開示すらせず責任転嫁したと言う訳。
        もしかすると誰の責任かを判断できるだけの調査すら一切やらずに丸投げだね。

        そらISPもブチギレますわ。

  • by Anonymous Coward on 2021年05月19日 14時14分 (#4034352)

    バグだろう。
    既製品市販デバイスでそんなとこにバグが入り込むとは考えにくいから
    ハードウェアオフロードでの自社開発アクセラレータロジックにバグが有ったとか?
    TCPしか十分テストしてなかったのかね
    # チェックサムって言ってるけどCRCでしょ。

    ここに返信
    • by Anonymous Coward on 2021年05月19日 14時22分 (#4034360)

      IPv4でのUDPチェックサムは必須ではない(使用しない場合は0をセット)はずなのに、
      どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ

      • by Anonymous Coward on 2021年05月20日 1時20分 (#4034811)

        > IPv4でのUDPチェックサムは必須ではない(使用しない場合は0をセット)はずなのに、
        > どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ

        近いけど、
        ・65536分の1の割合でUDPチェックサムの計算結果が0x0000になったときに0xffffに上書きしないNAPTのバグ
        ・チェックサムが0x0000のパケットを廃棄してしまうRakutenLinkのバグ
        の相乗効果と予想。
        割合は65536分の1でも、0x0000になるパケットは何度再送しても0x0000だから永久に受信できない。

        逆、つまり、
        ・RakutenLinkがチェックサム0x0000を0xffffにしない
        ・NAPTがチェックサム0x0000を廃棄する
        の組み合わせだと、チェックサム0x0000で送ってくる端末、OSなんてたくさんあるから、
        RakutenLinkで問題になる前に気づいているはず。

        • by Anonymous Coward

          その仮説だと特定のパケットだけまれに受信できないことから利用者には音抜けとして観測されるはず。
          発表内容(「片通話になったり発着信が出来なくなったりする」)を読むに音抜けのニュアンスは感じ取れないから、素直に(#4034360)の仮説の方がまだ可能性高いと思う。

    • by Anonymous Coward on 2021年05月19日 15時43分 (#4034433)

      RFC6935 と RFC2460 のどちらに従うかの「齟齬」と思われる。

      • by Anonymous Coward on 2021年05月19日 16時02分 (#4034452)

        RFC 2460 [ietf.org]→IPv6の基本仕様を定めたRFCで、UDPチェックサム必須
        RFC 6935 [ietf.org]→RFC 2460のUDPチェックサム必須仕様を削除するRFC

        だよね。でも「プライベートIPアドレスをお使いの方にこの問題が生じる」「NAT環境下では動作しないか、極めて不安定である」という話なので、本質的にIPv4でのUDPチェックサムの取り扱いに関する問題で、IPv6は関係ないんじゃないかと。

        もしかすると「IPv4/v6デュアルスタック環境では片通話となる」現象には関係しているかもしれない?

  • by Anonymous Coward on 2021年05月19日 14時27分 (#4034366)

    VPNでカプセルしてトンネルすれば、使えたかもしれないな

    ここに返信
typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...