TDI NDIS Raw IP Win32 Howto
Категорически приветствую.
Я тут пытаюсь решить такую задачу; надо из одного процесса отправлять UDP-датаграммы на той же машине другим процессам, но самому создавать IP и UDP headerы, чтобы получальсь, типа эти датаграммы пришли откуда-то с других машин. Этот процесс, который их отправлять будет, никак не может иметь админских привилегий, так что raw sockets тут не получится применить. Тут надо что-то в kernel mode придумать...
Я вижу такие варианты.
1. Эти датаграммы снизу с NDIS в Tcpip.sys запихивать.
Но это надо не иначе как NDIS Intermediate писать, что есть геморрой так, как 1) Его еще хитро инсталлировать надо с инф-файлом, 2) Этот драйвер повлазит в привязки исходя из совпадения свойства ндис-адаптеров "медиа-тип", который еще надо знать какой поставить и который только с инфа можно установить, 3) я где-то читал, что "виртуал-адаптеры", которые такой НДИС-фильтр посоздает, повылазят в трэй как иконки соединений, 4) НДИС драйверы еще разные бывают, connection/connectionless, serialized/deserialized, а поскольку мне фильтр писать, так надо все, что можно поддерживать,7) еще я читал, что с этим connection-oriented по-любому проблемы бывают (а соединение в инэт по модему, наверное именно такое...) 6) Не факт, что вышележащие НДИС-протоколы вообще захотят к адаптерам моего драйвера привязываться и 7) Клиент не поимет, зачем из-за такой фигни все это городить было, тем более, что все это слишком неопределенно и требует громоздких экспериментов..
2. Tcpip.sys создает такое устройство RawIp.
Если создать файл (в TDI он используется грубо говоря как сокет) в контексте процесса "Система", то наверное Security Reference Monitor должен пропустить такое (Рав-сокеты только для админов!)... (так или нет ХЗ, может Вы знаете?).. Только надо еще знать какие параметры ему задать при создании (локальный адрес).. Еще надо заставить устройство RawIp не лепить свой IP header а брать мой. В юзер моде для этого надо одно свойство сокета установить через setsockopt(), а в кернел-моде как? В общем надо бы что-то почитать про недокументированные, но успевшие стать традиционными возможности TDI и Tcpip.sys. Вы не подскажете что именно и (а главное!), где это слить?
3. Loopback. Никто не подскажет, как он реализован? Это протокольные драйверы внутри себя данные заворачивают к себе же или этим положено заниматься NDIS минипортам? Если это обязаны делать минипорты, то можно написать свой NDIS-протокольный драйвер (каковым и Tcpip.sys является) и из него слать пакеты в адаптер (только еще какой именно), нехай он их наверх заворачивает... Реален такой сценарий, как Вы считаете?
:eek: :confused:
Я тут пытаюсь решить такую задачу; надо из одного процесса отправлять UDP-датаграммы на той же машине другим процессам, но самому создавать IP и UDP headerы, чтобы получальсь, типа эти датаграммы пришли откуда-то с других машин. Этот процесс, который их отправлять будет, никак не может иметь админских привилегий, так что raw sockets тут не получится применить. Тут надо что-то в kernel mode придумать...
Я вижу такие варианты.
1. Эти датаграммы снизу с NDIS в Tcpip.sys запихивать.
Но это надо не иначе как NDIS Intermediate писать, что есть геморрой так, как 1) Его еще хитро инсталлировать надо с инф-файлом, 2) Этот драйвер повлазит в привязки исходя из совпадения свойства ндис-адаптеров "медиа-тип", который еще надо знать какой поставить и который только с инфа можно установить, 3) я где-то читал, что "виртуал-адаптеры", которые такой НДИС-фильтр посоздает, повылазят в трэй как иконки соединений, 4) НДИС драйверы еще разные бывают, connection/connectionless, serialized/deserialized, а поскольку мне фильтр писать, так надо все, что можно поддерживать,7) еще я читал, что с этим connection-oriented по-любому проблемы бывают (а соединение в инэт по модему, наверное именно такое...) 6) Не факт, что вышележащие НДИС-протоколы вообще захотят к адаптерам моего драйвера привязываться и 7) Клиент не поимет, зачем из-за такой фигни все это городить было, тем более, что все это слишком неопределенно и требует громоздких экспериментов..
2. Tcpip.sys создает такое устройство RawIp.
Если создать файл (в TDI он используется грубо говоря как сокет) в контексте процесса "Система", то наверное Security Reference Monitor должен пропустить такое (Рав-сокеты только для админов!)... (так или нет ХЗ, может Вы знаете?).. Только надо еще знать какие параметры ему задать при создании (локальный адрес).. Еще надо заставить устройство RawIp не лепить свой IP header а брать мой. В юзер моде для этого надо одно свойство сокета установить через setsockopt(), а в кернел-моде как? В общем надо бы что-то почитать про недокументированные, но успевшие стать традиционными возможности TDI и Tcpip.sys. Вы не подскажете что именно и (а главное!), где это слить?
3. Loopback. Никто не подскажет, как он реализован? Это протокольные драйверы внутри себя данные заворачивают к себе же или этим положено заниматься NDIS минипортам? Если это обязаны делать минипорты, то можно написать свой NDIS-протокольный драйвер (каковым и Tcpip.sys является) и из него слать пакеты в адаптер (только еще какой именно), нехай он их наверх заворачивает... Реален такой сценарий, как Вы считаете?
:eek: :confused: