Windows 11 игнорирует IPMI из‑за ошибки в драйвере e1r68x64.sys

Пользователь часами пытался заставить Windows 11 обмениваться данными с древним модулем IPMI Tyan SMDC по сети. Сначала попытки с программой TSO в среде Windows XP и родным инструментом ipmiutil увенчались провалом, сервер не отвечал. Даже на машине с Windows 10 утилита ipmiutil отказывалась общаться с устройством. Переход на Linux показал другое лицо проблемы: там инструмент ipmitool успешно связался с модулем, что заставило автора подозревать ошибку в настройке железа. Отключение фаерволов на Windows не помогло. Анализ с помощью Wireshark подтвердил наличие исходящего UDP-трафика на порт 623 и получение ответов, но операционная система Windows игнорировала входящие пакеты, что выглядит странно. Когда тестирование на ноутбуке с Windows 10 показало, что утилита ipmiutil работает нормально, гипотеза о новых Windows, «съедающих» пакеты, рухнула. На первой машине загрузчиком PktMon удалось разгадать тайну: пакеты теряются из-за ошибки проверки контрольной суммы, которую сообщает протокол INET. Wireshark, напротив, не заметил ошибок, считая контрольные суммы валидными. Единственное решение, которое сработало, заключалось в отгрузке опции UDP receive checksum offloading для IPv4 в драйвере сетевого интерфейса e1r68x64.sys на процессоре Intel I211. Тот же метод исправил ситуацию и на старой системе с драйвером e1i65x64.sys, тогда как ноутбук с адаптером Killer, не поддерживающим эту функцию, проблем не имел. Проблема не в целом сломанном оффлоадинге, так как DHCP и DNS работают, а в неправильной проверке контрольной сумм самим «железом» Intel или драйвером. Входящие и исходящие пакеты от IPMI-контроллера имеют одинаковый ID, что, как предполагает автор, сбивает драйверы Intel, чувствительные к фрагментации, хотя фрагментация в этой сцене маловероятна. Разработчики драйверов, вероятно, неверно интерпретируют поле Packet ID в IP-заголовке, несмотря на то что расчет контрольной суммы для таких простых пакетов несложен. Поскольку переписывать драйверы Intel в Windows не представляется возможным, выключение оффлоадинга приема для UDP на уровне IPv4 остается единственным рабочим вариантом, хотя и противоречит идее оптимизации сети.