福井ケーブルテレビ局でのRakuten Linkの障害、原因が特定され対応も完了 36
ストーリー by nagazou
報道された結果のようで 部門より
報道された結果のようで 部門より
以前、福井のケーブルテレビ局が、楽天モバイルに技術サポートを求める異例の発表を行っていたが、その原因となる「Rakuten Link」で通話ができない問題が解決したとする内容がケーブルテレビ局側から発表された（FCTV・SCTV|障害情報、楽天モバイル）。
17日に発表された内容によると、あの報道の後に楽天モバイルから問題解決を行うことに合意する連絡があり、両社で検証したデータを元に楽天モバイル側で対応が行われたとしている。対応は5月13日に完了したとのこと。具体的な原因に関しては、UDPチェックサムの取扱に齟齬があったことが原因だとしている。
あるAnonymous Coward 曰く、
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/
よかったよかった (スコア:0)
リリース文に
> NAT機器での通信状況を調査したところUDPチェックサムの取扱に齟齬があり
ってあるけど、齟齬ってチェックサムがおかしかったってことですかね？ どういうことなんだろ。
Re:よかったよかった (スコア:1)
チェックサムには実際には送られない疑似ヘッダの分を計算入れるらしいけど
この疑似ヘッダには送り先送り元のIPアドレスがあってそれが
グローバルアドレスとローカルアドレスのどちらが入るかで
チェックサムが変わってしまって捨てられちゃうとかそんなんかな。
Re: (スコア:0)
NATでIPアドレスが変わるからUDPチェックサム0にしといたら、楽天側は0という値をそのままチェックサムとして判断したとか？
Re: (スコア:0)
単なるやじ馬だけど参考までに詳報が欲しいなあ。
関係者の方へ ACはこの問題原因周知が放置されることを適切と考えておらず、貴社からの連絡を歓迎致します。（技術者が個人的にご連絡頂く場合、その秘密は（たぶんスラドの中の人が）守ります）
Re: (スコア:0)
いつかJANOGで話される機会があるかも知れない
楽天モバイル「そのような対応はできない」と解決拒否 (スコア:0)
からの「UDPチェックサムの取扱に齟齬があり楽天モバイルが対応」
Re: (スコア:0)
そりゃ福井ケーブルテレビの機材を楽天モバイルが治すなんて出来ないよなあ。
それとも機器メーカーから貰ったパッチを楽天から来てた技術者に入れてもらったとか？
それだと営業としてやっているって事自体が不思議に思えるし。
Re:楽天モバイル「そのような対応はできない」と解決拒否 (スコア:2, 興味深い)
逆だよ。
NAPTでパケットが変化するのはNAPT環境では残念だが当然の動作なんだが、
楽天側のソフト・機材はそれを処理できなかった、と言うのがそもそもの問題。
IPv4アドレスが枯渇する中、NAPTが使われるのもそれでパケットが変化するのもほぼ不可抗力。
枯渇してるIPv4アドレスを買い集めて顧客にタダで配るなんてのは余裕のあるISPにしか無理な選択だ。
従ってこの問題は根本的には楽天側の機材やソフトを修正するかNAPTへの非対応を明示するかしか対処法は無い。
どちらの対処も楽天の責任なんだよ。
にも関わらず楽天は不具合の情報を開示すらせず責任転嫁したと言う訳。
もしかすると誰の責任かを判断できるだけの調査すら一切やらずに丸投げだね。
そらISPもブチギレますわ。
UDPチェックサムの取扱に齟齬がありって、それ (スコア:0)
バグだろう。
既製品市販デバイスでそんなとこにバグが入り込むとは考えにくいから
ハードウェアオフロードでの自社開発アクセラレータロジックにバグが有ったとか?
TCPしか十分テストしてなかったのかね
# チェックサムって言ってるけどCRCでしょ。
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:1)
IPv4でのUDPチェックサムは必須ではない（使用しない場合は0をセット）はずなのに、
どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:2, 参考になる)
> IPv4でのUDPチェックサムは必須ではない（使用しない場合は0をセット）はずなのに、
> どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
近いけど、
・65536分の1の割合でUDPチェックサムの計算結果が0x0000になったときに0xffffに上書きしないNAPTのバグ
・チェックサムが0x0000のパケットを廃棄してしまうRakutenLinkのバグ
の相乗効果と予想。
割合は65536分の1でも、0x0000になるパケットは何度再送しても0x0000だから永久に受信できない。
逆、つまり、
・RakutenLinkがチェックサム0x0000を0xffffにしない
・NAPTがチェックサム0x0000を廃棄する
の組み合わせだと、チェックサム0x0000で送ってくる端末、OSなんてたくさんあるから、
RakutenLinkで問題になる前に気づいているはず。
Re: (スコア:0)
その仮説だと特定のパケットだけまれに受信できないことから利用者には音抜けとして観測されるはず。
発表内容（「片通話になったり発着信が出来なくなったりする」）を読むに音抜けのニュアンスは感じ取れないから、素直に(#4034360)の仮説の方がまだ可能性高いと思う。
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:1)
RFC6935 と RFC2460 のどちらに従うかの「齟齬」と思われる。
Re:UDPチェックサムの取扱に齟齬がありって、それ (スコア:3, 興味深い)
RFC 2460 [ietf.org]→IPv6の基本仕様を定めたRFCで、UDPチェックサム必須
RFC 6935 [ietf.org]→RFC 2460のUDPチェックサム必須仕様を削除するRFC
だよね。でも「プライベートIPアドレスをお使いの方にこの問題が生じる」「NAT環境下では動作しないか、極めて不安定である」という話なので、本質的にIPv4でのUDPチェックサムの取り扱いに関する問題で、IPv6は関係ないんじゃないかと。
もしかすると「IPv4/v6デュアルスタック環境では片通話となる」現象には関係しているかもしれない？
だとしたら、VPN経由なら (スコア:0)
VPNでカプセルしてトンネルすれば、使えたかもしれないな
Re: (スコア:0)
トンネルの向こうはどこに？
Re:だとしたら、VPN経由なら (スコア:1)
Re: (スコア:0)
どこでもいいよ。
NAPTの変換方法は複数あるのに楽天はその一部の変換方法では動作しない不具合を抱えていた。
楽天が対応している変換方法を採用しているNAPT経由でインターネット上に出られれば一応動く。
ただまぁ遅延は酷くなりそう。
Re:福井ケーブル側の機器に問題があるのに (スコア:2, 興味深い)
福井ケーブル側の機器に問題があるっていう根拠は？
楽天側の機器がRFC 768 [ietf.org]で規定されたオールゼロ送信を想定していないのが問題だったのでは？
Re: (スコア:0)
FCTV ・ SCTV側の障害情報によると
>お客様には長期間大変ご迷惑をおかけしたことをお詫びするとともに、問題解決にご尽力頂いた楽天モバイル株式会社殿に謝意を表します。
と書いてありますよ。
Re: (スコア:0)
> お客様には長期間大変ご迷惑をおかけしたことをお詫びするとともに、問題解決にご尽力頂いた楽天モバイル株式会社殿に謝意を表します。
こんな対応じゃ許されないの？
Re: (スコア:0)
こんな案内することが心苦しいので，楽天側の情報提供を求めていたんですよね。
Re: (スコア:0)
つまりお前が勤めている局だったなら原因不明のため沈黙して放置ということだな。
個別の案件に矮小化しようだなんてひどい局だ。少しは福井ケーブルテレビを見習え。
Re: (スコア:0)
お客様には長期間大変ご迷惑をおかけしたことをお詫びするとともに、問題解決にご尽力頂いた楽天モバイル株式会社殿に謝意を表します。
そう言ってるだろ？敬語が難しかったか？
Re: (スコア:0)
原因と責任を分けて考えられないタイプ？
局側のNAT機器がパケットを書き換えた場合にのみ発生する問題であったとしても、局側（NAT機器）の問題とは限らない。
Re: (スコア:0)
楽天のサポートが、情報提供もなにもせずに福井ケーブルテレビに聞けってたらい回ししたのが発端。
どうあがこうと楽天のサポート部門に責が有るでしょうよ。
楽天のサポートの品質は魔窟。
キャンペーン適用対象かの問い合わせすら回答が二転三転するのが普通だし、技術的な問い合わせしたら失踪とかも起きる。
Re: (スコア:0)
わざわざ公に発表したということは、会社対会社で問い合わせたのに塩対応されたんだろう、という感じがする。
結果騒ぎになって楽天を巻き込むのに成功したので、この戦略は成功だったんだろうな。
福井ケーブル側は、発表した時点でかなり確信をもって「うちのせいじゃない」って言ってる感じがする。
技術的原因がどっちにあったのかは闇の中になるのかな。福井ケーブル側だとしたら自分のせいなのに大騒ぎしたことが、楽天側だと当初サポートを突っぱねたことが明らかになっちゃっうから。
お互い「こっちが折れてやったんだ」って思って収まるような解決になってそう。
Re: (スコア:0)
こういう何でもかんでも悪意によって行われると信じちゃう人って必ずいるね。
Re: (スコア:0)
>両社にて検証作業を行い、検証結果に基づき、楽天モバイル株式会社のネットワーク作業が5月13日に完了した旨の連絡をいただきました。
「楽天モバイル株式会社のネットワーク作業が5月13日に完了した」と書いてあって、変更したのは楽天モバイル側だ、という文字列が読めない？
Re: (スコア:0)
どう考えてもNAT機器の問題なのは最初から分かっていることなのに
自分は、これが正しいかどうかはわからない。
けれど、楽天モバイル側の変更で障害が解消されたことは、必ずしも楽天モバイル側に問題があったことを肯定するものではないと思う。
Re: (スコア:0)
とはいえ楽天にくだんのCATV業者より技術力があるとは思えないというのがアレ。
単に楽天嫌われすぎじゃね？と言われるがこれまでの所業のせいなので慈悲はない。
楽天側の完全敗北ですな。 (スコア:0)
>自分は、これが正しいかどうかはわからない。
>けれど、楽天モバイル側の変更で障害が解消されたことは、必ずしも楽天モバイル側に問題があったことを肯定するものではないと思う。
リリース読んだ？経緯はきちんと書かれていますよ。
【事象解決】【5/17追記】楽天モバイルの「Rakuten Link」で通話が出来ない事象について
http://fctv.mitelog.jp/syogai/2021/05/517rakuten-link-6348.html [mitelog.jp]
-----
弊社の調査では、ケーブルモデムを使用しているお客様および南越前町エリアのお客様のうち、プラ
Re: (スコア:0)
あなたの局ではこの事態はどう対応するのですか。
NAT機器の問題っていってるけど、出ている情報を読む限り楽天側でしか対処しえないはずだが。
Re: (スコア:0)
NAPTの変換モードを変えれば上手く行った可能性はあるが、
楽天以外の全てにおいて他の障害を引き起こすリスクもある。
まぁ、許容すべきとされるNAPTの変換モードを受け付けない実装にしていた楽天が悪いわな。
家庭内ルータ含めてNAPTじゃない環境の方が少ないのに、
わざわざNAPTとの組み合わせで相性悪めなUDP使った挙げ句、
NAPT周りの実装が雑で受け入れるべきを受け入れ損ねて死ぬとかもうね。
技術がねーなら遅延覚悟でTCPでも使ってろと。