Ethernet Bridge

Home Forums Discussions Support Portal Ethernet Bridge

This topic contains 26 replies, has 2 voices, and was last updated by  Vadim Smirnov 1 month, 3 weeks ago.

Viewing 15 posts - 1 through 15 (of 27 total)
  • Author
    Posts
  • #9678

    alexander
    Participant

    Здравствуйте!
    Использую вашу программу, которая организует мост между 2 сетевыми картами (link). При работе программы время от времени пропадает связь между компьютерами. Время работы до сбоя всегда разное: часы или дни. Закономерности не обнаружил. Перезапуск программы решает проблему: связь восстанавливается. Как добиться того, чтобы связь не пропадала?

    #9679

    Vadim Smirnov
    Moderator

    Судя по симптомам, скорей всего дело в том, что один из интерфейсов переподключается в процессе работы. Это поведением можно симитировать сделав disable/enable одной из сетевых карт моста в процессе работы.

    Простоты ради Ethernet Bridge не обрабатывает изменения сетевой конфигурации. Нужно бы добавить мониторинг изменений доступных интерфейсов (SetAdapterListChangeEvent) и останавливать/перезапускать мост когда один из адаптеров “уходит”/”возвращается”.

    Как-нибудь доработаю на досуге, по хорошему для длительной работы из него вообще предпочтительней сделать сервис.

    #9681

    alexander
    Participant

    Значит, чтобы в моей программе, которая организует мост таким же образом, как и ваш Ethernet Bridge, нужно мониторить событие по SetAdapterListChangeEvent и по его срабатыванию пересоздавать мост, используя новые индексы интерфейсов из GetTcpipBoundAdaptersInfo?

    #9682

    Vadim Smirnov
    Moderator

    В общем да, рестартовать мост имеет смысл если произошли изменения в используемых интерфейсах, остальные изменения можно игнорировать. Внутренне HANDLE сетевого адаптера – это указатель на структуру в ядре, она удаляется только при удалении адаптера из системы, то есть HANDLE может изменится только если адаптер был удален и снова добавлен.

    Единственно, если 32-битное приложение работает с драйвером на 64-битной системе, то NDISAPI включает дополнительный уровень трансляции для хэндлов (из 32 в 64 битные) и на постоянство хэндлов полагаться нельзя, 32-битные хэндлы в этом случае – индексы в массиве 64-битных.

    #9689

    alexander
    Participant

    В свою тестовую программу я внедрил реакцию на событие SetAdapterListChangeEvent. Это не помогло. Симптомы повторились, но событие не сработало (не просигнализировало). Однако перезапуск 2-х тридов, организующих мост, помог. Что еще может быть?

    #9690

    Vadim Smirnov
    Moderator

    Маловато конечно информации, чтобы делать какие-то выводы. Во-первых, какие интерфейсы включены в мост? Два обычных Ethernet 802.3?

    Для начала стоит посмотреть в отладчике чем заняты рабочие потоки после того как мост перестает работать. Для наглядности я бы добавил консольный вывод в рабочие потоки (получил пакеты -> переслал пакеты). Сразу будет понятно какой поток заснул или вообще вышел.

    Например, если мост перестал функционировать, но при этом потоки продолжают получать и перекладывать пакеты и оба сетевых интерфейса сами по себе работают нормально (пингают хосты в подключенных сетях), то возможно что-то сбрасывает promiscuous фильтр на одном или на обоих интерфейсах. Это несложно проверить, прочитав текущий фильтр, как, впрочем, несложно и поправить, восстановив promiscuous.

    #9691

    Vadim Smirnov
    Moderator

    И еще один момент, любое другое приложение обращающееся к драйверу может поставить свои события на пакеты и мост перестанет их получать. Например, достаточно запустить стандартный passthru на одном из интерфейсов моста, чтобы последний перестал нормально работать. В целом для production стоит ограничить доступ к драйверу (для демо версии это неудобно).

    #9693

    alexander
    Participant

    Оказалось, что сбился неразборчивый режим. В чем может быть причина? Как узнать о его изменении, кроме постоянного опроса через GetHwPacketFilter?

    #9694

    Vadim Smirnov
    Moderator

    Технически это может сделать любой драйвер сетевого протокола, в том числе TCP/IP или Winpcap (если использовался Wireshark).

    В принципе, поскольку драйвер фильтрует все NDIS запросы к сетевому интерфейсу, то можно либо добавить notification event на изменение фильтра, либо не позволять кому бы то ни было менять фильтр установленный через winpkfilter. Можно добавить такое к custom сборке…

    #9696

    alexander
    Participant

    А можно попробовать вариант (custom build) с event, который уведомлял бы об изменении режима?

    #9697

    Vadim Smirnov
    Moderator

    Кастомная сборка делается для клиента с новым имененм драйвера и рядом других параметров.

    Но если очень хочется попробовать, то почему нет. По ссылке тестовая сборка, заранее предупреждаю, что не проверял работоспособность нового API:

    • бинарники драйверов для Vista/7/8. Под десятку сложнее процедура подписи, поэтому не включен. Драйвера можно поставить вручную через свойства сетевого соединения.
    • бинарники и исходный код для NDISAPI.DLL с новой функцией
    #9699

    alexander
    Participant

    Добавьте, пожалуйста, новую ф-цию SetHwPacketFilterEvent в C-interface вашей dll.

    #9700

    Vadim Smirnov
    Moderator

    Добавил, так же немного обновил реализацию, добавил инсталлятор и подписал все драйвера.

    Для тестов руки не дошли, так что если не затруднит – напишите как отрабатывает новое событие.

    #9703

    alexander
    Participant

    У меня 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. Что делать?

    #9704

    alexander
    Participant

    Я нашел причину такого поведения. Версия 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?

Viewing 15 posts - 1 through 15 (of 27 total)

You must be logged in to reply to this topic.