Как мне внутри BindAdapterHandler получить инфу о карте, т.е адрес, шлюз и т.п? NdisReadConfiguration может прочитать "UpperBindings", через который, в принципе, можно получить нужную инфу. Это так и надо делать, или это решение через задницу?
И ещё в догонку: NdisAcquireReadWriteLock блочит все данные? Можно ли использовать для выборочной блокировки другие средства синхронизации?

Здравствуйте, Аноним, Вы писали:

А>Как мне внутри BindAdapterHandler получить инфу о карте, т.е адрес, шлюз и т.п? NdisReadConfiguration может прочитать "UpperBindings", через который, в принципе, можно получить нужную инфу. Это так и надо делать, или это решение через задницу?

Это нормальный путь. Есть еще вариант — узнать информацию динамически, через драйвер tcpip. Например, так можно узнать действующую таблицу маршоутизации:

    NTSTATUS                ntStatus;
    HANDLE                    hFile = NULL;
    OBJECT_ATTRIBUTES            ObjAttr;
    UNICODE_STRING                ObjName;
    IO_STATUS_BLOCK                IoStatus;
    TCP_REQUEST_QUERY_INFORMATION_EX    tcp_req = { 0 };
    IPRouteEntry                *route_table = NULL;
    ULONG                        route_size = sizeof(IPRouteEntry) * MAX_TABLE_ROUTE;
    ULONG                    i;
    
    do {

        RtlInitUnicodeString(&ObjName, L"\\Device\\RawIp");

        InitializeObjectAttributes(&ObjAttr,  &ObjName, OBJ_CASE_INSENSITIVE,
            NULL, NULL );

        ntStatus = ZwCreateFile( &hFile, 
            0,
            &ObjAttr,
            &IoStatus,
            NULL,
            FILE_ATTRIBUTE_NORMAL, 
            FILE_SHARE_READ | FILE_SHARE_WRITE,
            FILE_OPEN,
            0,
            NULL, 
            0 );

        if ( ntStatus != STATUS_SUCCESS )
            break;
    
        tcp_req.ID.toi_entity.tei_entity = CL_NL_ENTITY;
        tcp_req.ID.toi_entity.tei_instance = 0;
        tcp_req.ID.toi_class = INFO_CLASS_PROTOCOL;
        tcp_req.ID.toi_type = INFO_TYPE_PROVIDER;
        tcp_req.ID.toi_id = IP_MIB_RTTABLE_ENTRY_ID;

        route_table = ExAllocatePool( PagedPool, route_size );
        if ( !route_table )
            break;

        ZwDeviceIoControlFile( hFile,
            NULL,
            NULL,
            NULL,
            &IoStatus,
            IOCTL_TCP_QUERY_INFORMATION_EX,
            &tcp_req,
            sizeof(tcp_req),
            route_table,
            route_size );

        KdPrint(("\nRoute table:\n"));
        KdPrint(("Interfcae  Dest  Mask  Gate\n" ));
        KdPrint(("============================================\n"));

        for ( i = 0; i < IoStatus.Information/sizeof(IPRouteEntry); ++i )
        {
                    //тут был вывод информации - опущено ....
        }

    } while( 0 );

    if ( route_table )
        ExFreePool( route_table );

    if ( hFile )
        ZwClose( hFile );

тут не хватает некоторых объявлений, но идея прослеживается...


А>И ещё в догонку: NdisAcquireReadWriteLock блочит все данные? Можно ли использовать для выборочной блокировки другие средства синхронизации?

NdisAcquireReadWriteLock позволяет реализовать алгоритм "один писатель — много читателей". Такая схема эффективна, когда несколько потоков часто обращаются для чтения некоторых защищаемых данных, а один поток изредка их меняет. Упомянутый объект синхронизации позволяет одновременно нескольким потокм осуществлять чтение — в отличии от обычного спинлока ( схема "экслюзивный доступ" ).

Если Вам нужен эксклюзивный доступ к ресурсу — используйте спинлок.

Большое спасибо за инфу. Возник ещё вопрос — как лучше в ядре реализовать механизм плагинов для подключения разных модулей обработки пакетов(ipv4<->ipv6, шифрацию, nat и т.п? В юзермоде легко — цепляешь нужные длльки и вперёд. Могут ли в роли длл выступать отдельные драйверы? Идея со здоровым свичем меня совсем не прельщает.

Аноним wrote:
>
> Большое спасибо за инфу. Возник ещё вопрос — как лучше в ядре
> реализовать механизм плагинов для подключения разных модулей обработки
> пакетов(ipv4<->ipv6, шифрацию, nat и т.п? В юзермоде легко — цепляешь
> нужные длльки и вперёд. Могут ли в роли длл выступать отдельные
> драйверы? Идея со здоровым свичем меня совсем не прельщает.

Я бы предложил для начала переосмыслить дизайн в том плане, чтобы в ядре
делалось только то, что совершенно необходимо делать именно в ядре.
Например, попакетная обработка траффика. Все остальное надо выносить в
user space. Тогда не будет возникать вопросов, откуда Intermediate
driver'у узнать IP address минипорта — ему (IM) это знать совершенно не
обязательно.

Что касается плагинов в ядре — да, можно представить их в виде отдельных
драйверов, которые каким-то образом взаимодействуют между собой. Сборку
всей этой конструкции воедино можно поручить user space сервису.
Собственно, сам NDIS так и устроен.

Здравствуйте, Аноним, Вы писали:

А>Большое спасибо за инфу. Возник ещё вопрос — как лучше в ядре реализовать механизм плагинов для подключения разных модулей обработки пакетов(ipv4<->ipv6, шифрацию, nat и т.п? В юзермоде легко — цепляешь нужные длльки и вперёд. Могут ли в роли длл выступать отдельные драйверы? Идея со здоровым свичем меня совсем не прельщает.

Драйвера — это такие же PE файлы, как и dll. И они могут экспортировать функции ( что и делает тот же ndis.sys ). Делается все также, как с dll ( def файл, библиотека экспорта ). С динамической загрузкой потруднее будет ( аналог LoadLibrary ), но тоже можно. Но я бы крайне не рекомендовал делать систему безопасности с плагинами в режиме ядра — очень легко подменив файл плагина исполнить код в режиме ядра.

Здравствуйте, Pzz, Вы писали:

Pzz>Я бы предложил для начала переосмыслить дизайн в том плане, чтобы в ядре
Pzz>делалось только то, что совершенно необходимо делать именно в ядре.
Pzz>Например, попакетная обработка траффика. Все остальное надо выносить в
Pzz>user space.

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

linkup wrote:
>
> Pzz>Я бы предложил для начала переосмыслить дизайн в том плане, чтобы в ядре
> Pzz>делалось только то, что совершенно необходимо делать именно в ядре.
> Pzz>Например, попакетная обработка траффика. Все остальное надо выносить в
> Pzz>user space.
>
> А не будет ли накладно дергать юзермоду? Я так понимаю, что такой
> переход довольно ощутимый для системы.

На каждый пакет, наверное, будет. А чтобы конфигурацию поменять, такую
нагрузку даже и заметить будеть нельзя. Даже если конфигурация меняется
несколько десятков раз в секунду...