Ошибка контрольной суммы TCP для фрагментированных пакетов
Я работаю над приложением сокет сервер / клиент, которое использует интерфейс Linux TUN.
Сервер получает пакеты напрямую от интерфейса TUN и передает их клиентам, а клиенты помещают полученные пакеты непосредственно в интерфейс TUN.
<Server_TUN---><---Server---><---Clients---><---Client_TUN--->
Иногда пакеты из Server_TUN должны быть фрагментированы на уровне IP перед передачей клиенту.
Поэтому на сервере я читаю пакет из TUN, начинаю фрагментировать его на уровне IP и отправляю их через сокет клиентам.
Когда была реализована логика фрагментации, решение не сработало.
После запуска Wireshark на Client_TUN я заметил, что для всех входящих фрагментированных пакетов я получаю ошибку TCP Checksum.
На данном скриншоте утверждается, что кадр № 154 собирается в 155.
Но контрольная сумма TCP считается неверной!
На стороне сервера я сохраняю данные tcp без изменений, и для данного примера, хотя вы видите обратное в Wireshark, я разделил пакет с 1452 байтами (включая заголовок IP) и 30 байтами (включая заголовок IP)
Я также проверил значение контрольной суммы TCP на сервере, и оно точно равно 0x935e, и хотя я не думал, что разгрузка контрольной суммы имеет значение для входящих пакетов, я проверил разгрузку на клиенте, и она была отключена.
$ sudo ethtool -k tun0 | grep ": on"
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: on
generic-segmentation-offload: on
generic-receive-offload: on
tx-vlan-offload: on
tx-vlan-stag-hw-insert: on
Несмотря на это, поскольку решение не работает сейчас, я не думаю, что оно вызвано эффектом разгрузки.
У вас есть идея, почему контрольная сумма TCP может быть неправильной для фрагментированных пакетов?
1 ответ
Надеюсь, я нашел проблему. Это была моя ошибка. Некоторые tcp-данные отсутствовали, когда я справлялся с буферами. Я отслеживал индексы и длины, но из-за изменений в данных значение контрольной суммы вычислялось по-разному на стороне клиента.