Я работаю над приложением серверного / клиентского сокета, использующим интерфейс Linux TUN.
Сервер получает пакеты непосредственно из интерфейса TUN и передает их клиентам, а клиенты помещают полученные пакеты непосредственно в интерфейс TUN.
<Server_TUN---><---Server---><---Clients---><---Client_TUN--->
Иногда пакеты от Server_TUN необходимо фрагментировать на уровне IP перед передачей клиенту.
Итак, на сервере я читаю пакет из TUN, начинаю фрагментировать его на уровне IP и отправляю их клиентам через сокет.
Когда была реализована логика фрагментации, решение не сработало.
После запуска Wireshark на Client_TUN я заметил, что для всех входящих фрагментированных пакетов я получаю ошибку контрольной суммы TCP.
На приведенном скриншоте кадр номер 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 может быть неверной для фрагментированных пакетов?
