#c# #windows #udp #windows-10 #mtu
#c# #Windows #udp #windows-10 #mtu
Вопрос:
Краткая версия ниже — похоже, мы не можем успешно отправлять UDP-пакеты размером более 1472 байт при запуске сборки 1809 Windows, хотя в предыдущих версиях это работало нормально.
У нас есть существующее приложение на C # (на самом деле набор приложений), которое выполняется в локальной проводной сети и периодически отправляет UDP-пакеты для передачи статуса другим приложениям на разных компьютерах в сети. Некоторые из этих пакетов небольшие, но некоторые довольно большие, близкие к пределу 64 КБ для UDP. Это приложение написано на C # с использованием .NET 4.5.1 и использует класс UdpClient для широковещательной передачи и приема широковещательных сообщений. До тестирования с Windows 10 build 1809 / Windows Server 2019 build 1809 все работало нормально — мы отправляли и получали пакеты большего размера без проблем. Однако, начиная со сборки 1809, кажется, что мы больше не можем успешно отправлять большие пакеты. Вот некоторые из проведенных нами тестов:
Система 1: Windows 10 Build 1803 (MTU равен 1500)
Система 2: Windows 10 Build 1809 (MTU равен 1500)
Я написал тестовую программу, которая отправляет небольшой (200 байт или около того) и большой (8000 байт или около того) UDP-пакеты с использованием UdpClient, одновременно прослушивая эти пакеты. Вот что происходит, когда я отправляю из каждой системы:
-Отправка из системы 1:
-System 1 sees both packets
-System 2 sees both packets
-Отправка из системы 2:
-System 1 sees only the small packet
-System 2 sees both packets
Это происходит каждый раз — большие пакеты никогда не доходят успешно. Дальнейшее тестирование показало, что магическое число составило 1472 байта. Это или меньше сработало, и более того, произошел сбой. Вот почему я подозреваю, что что-то с fragmenting / MTU работает некорректно. Мы раньше не сталкивались с этой проблемой, поэтому я запустил Wireshark, чтобы посмотреть, что может происходить. Однако, и вот тут-то и возникает странность, запуск Wireshark в системе сборки 1809 внезапно позволяет ей отправлять пакет, даже если я выхожу из Wireshark. Однако перезагрузка системы возвращает ее в исходное состояние невозможности успешной отправки. Я должен отметить, что я всегда вижу «Фрагментированный IP-протокол» для этих пакетов в Wireshark на принимающей стороне независимо от того, работают они правильно или нет.
Я немного почитал в Интернете и обнаружил, что RDP поверх UDP подвергся капитальному ремонту в сборке 1809, но я ничего не видел о том, что UDP-пакеты, размер которых превышает MTU, имеют проблему, и я не смог найти кого-либо еще, сообщающего об этой конкретной проблеме.
Мы долгое время не вносили изменений в эту часть нашего кода — он работал в Windows 7, Server 2012R2, Server 2016 и Windows 10 до сборки 1809. Есть ли что-то новое в сборке 1809, требующее от нас установки флага где-либо или настройки чего-либо на сетевом адаптере? Я не знаю, что делает весь Wireshark при загрузке, но, похоже, он каким-то образом «исправляет» ситуацию, поэтому, если у кого-нибудь есть идея, что это может быть конкретно, это тоже могло бы помочь.
Комментарии:
1. Это звучит как проблема с драйвером. Смотрите: wiki. wireshark.org/WinPcap . Возможно, потребуется обновление. И osqa-ask.wireshark.org/questions/55441 / … . Попробуйте NCAP
2. Хотя это возможно, у нас обычно вообще нет Wireshark в наших системах (я просто включил его, чтобы протестировать). Кроме того, у меня была одна система под управлением 1803, которая работала нормально, затем, когда я установил обновление 1809, оно начало работать плохо, поэтому я сомневаюсь, что проблема в сетевых драйверах.
3. При запуске wireshark он заменяет PCAP / NCAP, поэтому я думаю, что это драйвер. Вы начинаете работать, когда запущен wireshark.
4. Я дважды проверил драйверы на наличие обновлений, и они были актуальными. Часть тестирования проводилась на виртуальных машинах, работающих под управлением либо 1803, либо 1809, и я вижу проблему на машинах 1809, но не на машинах 1803 (все с одинаковыми драйверами). Кроме того, просто запуск Wireshark и выход, похоже, «исправляют» ситуацию до перезагрузки, поэтому я думаю, что это может быть какая-то настройка, которую он изменяет, которая помогает (хотя я не знаю, что может быть).
5. Я провел некоторое дополнительное тестирование с Windows Server 2019 (все было обновлено до самой последней версии), и я вижу там ту же проблему. Я также пробовал использовать Packet Sender (только что скачал его), и это также показывает проблему.
Ответ №1:
В итоге я связался с Microsoft по этому поводу в начале прошлого года и настаивал, пока они не признали, что это проблема. Проблема затрагивает 1809, 1903, 1909, 2004 и 20H2. Они, наконец, опубликовали исправление публично в «Накопительном обновлении 2021-03 для Windows 10». Исправления доступны для 1903 и выше. Я подтвердил, что это обновление действительно устраняет проблему для нас.
Смотрите: https://www.catalog.update.microsoft.com/Search.aspx?q=KB5001649
В этом КБ нигде конкретно не упоминается, что я могу найти, но это версия, которую мне предоставил сотрудник службы поддержки, и она исправлена после применения этого обновления.
Комментарии:
1. Спасибо, что подтолкнули Microsoft к этому и нашли исправление. Я передам это нашей команде.
2. @Brian да, никаких проблем, для нас это был блокиратор. Пожалуйста, примите мой ответ, если это обновление решило проблему за вас.