アカウント名:
パスワード:
バグだろう。既製品市販デバイスでそんなとこにバグが入り込むとは考えにくいからハードウェアオフロードでの自社開発アクセラレータロジックにバグが有ったとか?TCPしか十分テストしてなかったのかね# チェックサムって言ってるけどCRCでしょ。
IPv4でのUDPチェックサムは必須ではない（使用しない場合は0をセット）はずなのに、どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
> IPv4でのUDPチェックサムは必須ではない（使用しない場合は0をセット）はずなのに、> どちらかが必須だと思ってチェックサムエラーと判定してしまっていた、というオチに50カノッサ
近いけど、・65536分の1の割合でUDPチェックサムの計算結果が0x0000になったときに0xffffに上書きしないNAPTのバグ・チェックサムが0x0000のパケットを廃棄してしまうRakutenLinkのバグの相乗効果と予想。割合は65536分の1でも、0x0000になるパケットは何度再送しても0x0000だから永久に受信できない。
逆、つまり、・RakutenLinkがチェックサム0x0000を0xffffにしない・NAPTがチェックサム0x0000を廃棄するの組み合わせだと、チェックサム0x0000で送ってくる端末、OSなんてたくさんあるから、RakutenLinkで問題になる前に気づいているはず。
その仮説だと特定のパケットだけまれに受信できないことから利用者には音抜けとして観測されるはず。発表内容（「片通話になったり発着信が出来なくなったりする」）を読むに音抜けのニュアンスは感じ取れないから、素直に(#4034360)の仮説の方がまだ可能性高いと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
UDPチェックサムの取扱に齟齬がありって、それ (スコア:0)
バグだろう。
既製品市販デバイスでそんなとこにバグが入り込むとは考えにくいから
ハードウェアオフロードでの自社開発アクセラレータロジックにバグが有ったとか?
TCPしか十分テストしてなかったのかね
# チェックサムって言ってるけどCRCでしょ。
Re: (スコア: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)の仮説の方がまだ可能性高いと思う。