0

netfilter を使用して TCP パケットを操作しているため、期待どおりに動作している TCP および IP チェックサムを再計算する必要があります。

Wireshark は、サーバーから出る途中でチェックサムが正しいことを報告します (これは、クライアントがそうあるべきだと考えているものとも一致します) が、クライアントに到達すると、チェックサムは常に 0xAA6A に置き換えられます。

ポストルーティングフックでは、アドレス/ポートを操作した後、次のように TCP チェックサムを計算しています。

 tcp_header->check = 0;
 tcp_header->check = tcp_v4_check(tcp_len,
   ip_header->saddr,
   ip_header->daddr,
   csum_partial((char *)tcp_header, tcp_len, 0));

IP チェックサムは使用しても問題ありません

 ip_send_check(ip_header);

サーバーでは、RX または TX に対して TCP オフロードが有効になっておらず、サポートもされていません。有効または無効にしようとすると、サポートされていないエラーが発生します。

Offload parameters for eth0:
rx-checksumming: off
tx-checksumming: off
scatter-gather: off
tcp-segmentation-offload: off
udp-fragmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: off
ntuple-filters: off
receive-hashing: off

私が確信していないもう1つの関連ポイント...サーバーの事前ルーティングフックでパケット/ポートも操作します。それらはトランスポート層によって受け入れられ、私が何を見ても確実にアプリケーションに到達していますIP アドレスとポートの変更後に TCP チェックサムが更新されなかった場合、TCP チェックサムが削除されると想定していました。

この動作には明らかな理由がありますか、それともネットワーク スタックの一部を誤解していますか?

アップデート:

ip_summed を CHECKSUM_NONE に設定すると、コードを離れるとチェックサムの再計算が停止します。よくわからないのは、なぜ間違った固定値に再計算されているのですか? 設定しない場合は、CHECKSUM_PARTIAL に設定されます。

4

1 に答える 1

1

反対側で値が常に同じである場合、主な可能性が 2 つあります: 1) このコードの後でチェックサムを上書きする 2) tcp_len が間違っているこの場合、カーネルは何か違うことをします

于 2013-05-14T17:27:25.927 に答える