- This topic has 26 replies, 2 voices, and was last updated 6 years, 8 months ago by
.
-
Posts
-
Здравствуйте!
Использую вашу программу, которая организует мост между 2 сетевыми картами (link). При работе программы время от времени пропадает связь между компьютерами. Время работы до сбоя всегда разное: часы или дни. Закономерности не обнаружил. Перезапуск программы решает проблему: связь восстанавливается. Как добиться того, чтобы связь не пропадала?Судя по симптомам, скорей всего дело в том, что один из интерфейсов переподключается в процессе работы. Это поведением можно симитировать сделав disable/enable одной из сетевых карт моста в процессе работы.
Простоты ради Ethernet Bridge не обрабатывает изменения сетевой конфигурации. Нужно бы добавить мониторинг изменений доступных интерфейсов (SetAdapterListChangeEvent) и останавливать/перезапускать мост когда один из адаптеров “уходит”/”возвращается”.
Как-нибудь доработаю на досуге, по хорошему для длительной работы из него вообще предпочтительней сделать сервис.
Значит, чтобы в моей программе, которая организует мост таким же образом, как и ваш Ethernet Bridge, нужно мониторить событие по SetAdapterListChangeEvent и по его срабатыванию пересоздавать мост, используя новые индексы интерфейсов из GetTcpipBoundAdaptersInfo?
В общем да, рестартовать мост имеет смысл если произошли изменения в используемых интерфейсах, остальные изменения можно игнорировать. Внутренне HANDLE сетевого адаптера – это указатель на структуру в ядре, она удаляется только при удалении адаптера из системы, то есть HANDLE может изменится только если адаптер был удален и снова добавлен.
Единственно, если 32-битное приложение работает с драйвером на 64-битной системе, то NDISAPI включает дополнительный уровень трансляции для хэндлов (из 32 в 64 битные) и на постоянство хэндлов полагаться нельзя, 32-битные хэндлы в этом случае – индексы в массиве 64-битных.
В свою тестовую программу я внедрил реакцию на событие SetAdapterListChangeEvent. Это не помогло. Симптомы повторились, но событие не сработало (не просигнализировало). Однако перезапуск 2-х тридов, организующих мост, помог. Что еще может быть?
Маловато конечно информации, чтобы делать какие-то выводы. Во-первых, какие интерфейсы включены в мост? Два обычных Ethernet 802.3?
Для начала стоит посмотреть в отладчике чем заняты рабочие потоки после того как мост перестает работать. Для наглядности я бы добавил консольный вывод в рабочие потоки (получил пакеты -> переслал пакеты). Сразу будет понятно какой поток заснул или вообще вышел.
Например, если мост перестал функционировать, но при этом потоки продолжают получать и перекладывать пакеты и оба сетевых интерфейса сами по себе работают нормально (пингают хосты в подключенных сетях), то возможно что-то сбрасывает promiscuous фильтр на одном или на обоих интерфейсах. Это несложно проверить, прочитав текущий фильтр, как, впрочем, несложно и поправить, восстановив promiscuous.
И еще один момент, любое другое приложение обращающееся к драйверу может поставить свои события на пакеты и мост перестанет их получать. Например, достаточно запустить стандартный passthru на одном из интерфейсов моста, чтобы последний перестал нормально работать. В целом для production стоит ограничить доступ к драйверу (для демо версии это неудобно).
Оказалось, что сбился неразборчивый режим. В чем может быть причина? Как узнать о его изменении, кроме постоянного опроса через GetHwPacketFilter?
Технически это может сделать любой драйвер сетевого протокола, в том числе TCP/IP или Winpcap (если использовался Wireshark).
В принципе, поскольку драйвер фильтрует все NDIS запросы к сетевому интерфейсу, то можно либо добавить notification event на изменение фильтра, либо не позволять кому бы то ни было менять фильтр установленный через winpkfilter. Можно добавить такое к custom сборке…
Кастомная сборка делается для клиента с новым имененм драйвера и рядом других параметров.
Но если очень хочется попробовать, то почему нет. По ссылке тестовая сборка, заранее предупреждаю, что не проверял работоспособность нового API:
- бинарники драйверов для Vista/7/8. Под десятку сложнее процедура подписи, поэтому не включен. Драйвера можно поставить вручную через свойства сетевого соединения.
- бинарники и исходный код для NDISAPI.DLL с новой функцией
Добавил, так же немного обновил реализацию, добавил инсталлятор и подписал все драйвера.
Для тестов руки не дошли, так что если не затруднит – напишите как отрабатывает новое событие.
У меня Win7 64 bit. Я удалил предыдущую версию, установил “Windows Packet Filter 3.2.10.1 x64.msi”, потом скопировал в папку своего проекта файл “ndisapi.dll” из папки Win32/Release, вызвал ф-цию OpenFilterDriver, и проверил IsDriverLoaded. К сожалению, он вернул False. Если же я использую старую dll из файла “WinpkFilter Runtime & Tools 3.2.9.1.exe”, то IsDriverLoaded возвращает True. Что делать?
Я нашел причину такого поведения. Версия 3.2.9.1 содержит такой конструктор:
public: __thiscall CNdisApi::CNdisApi(char const *)А тестовая версия 3.2.10.1 содержит немного другой конструктор:
public: __thiscall CNdisApi::CNdisApi(wchar_t const *)Может для совместимости лучше использовать вариант из версии 3.2.9.1?
- You must be logged in to reply to this topic.