Forum Replies Created
-
Posts
-
А какой статус (NDIS_STATUS) возвращается? Нижележащий драйвер сетевой карты может просто не поддерживать этот OID…
The WinpkFilter library you mentioned, is it free or do I have to purchase it? Is it the free downloadable ndisapi.dll ?
WinpkFilter is free for non-commercial use and available for download from here (http://www.ntkernel.com/w&p.php?id=7). Package includes drivers(ndisrd.sys/ndisrd.vxd), API DLL (ndisapi.dll) and several simple samples.
If you register WinpkFilter (any type of subscription starting from 95$) you also get access to the Internet Gateway source code (http://www.ntkernel.com/w&p.php?id=31) which implements NAT and gives a good clue to how to redirect packets.
Some code samples can be also found by looking through this forum. I can also C&P a redirect relative portion of code from NeT Firewall source, but it may appear a bit difficult to understand.
Yes, this is possible to implement in Visual basic using WinpkFilter library, however I can’t provide you with ready to use code in VB (as I’m not a VB coder). If you can use the C code I think I can provide some.
Also you can use port/protocol mapping avalable in NeT Firewall (set up redirector rules on the internal LAN interface).
I would not recommend using IM drivers on the legacy systems NT4, 9x/ME because these OS’s have a poor support for this type of drivers (various problems were many discussed in the developers community). Since Windows 2000 IM drivers support was improved and in general you can use IM drivers for 2000/XP/2003 instead NDIS hooking ones. But here is another disadvantage, you have to sign your drivers with MS (expensive and you have to do signing each time you rebuild driver) if you don’t want users to be warned about unsigned “dangerous” driver many times during installation process. These warnings can be relatively easily disabled on the most modern Windows XP SP2 and Server 2003 (including x64 versions) and you can find the required script in the WinpkFilter x64 installation. However, this is problem to do the same for the earlier OS’s because of bugs in the relative MS code. We had to use IM drivers for x64 because of new patching policy from MS (it detects patching NDIS and BSOD the system), however we plan to release NDIS hooking version for x64 which will also disable patch guard.
Also, with NDIS hooking driver you get more flexibility (an example one our customer needed to see adapters and filter packets below MS Ethernet Bridge in Windows XP, this is easily doable with NDIS hooking driver but can’t say the same for the IM). The only disadvantage of NDIS hook is a chance for the incompatibility with another NDIS hook solution…
Я перехватываю входящий пакет, где исходный IP равен адресу машины в локальной сети, а адрес назначения равен адресу в Интернет. Меняю исходный IP на IP внешнего интерфейса и передаю в стек. И ничего… Стек игнорирует пакет!
1) Включи IP маршрутизацию (ключ в реестре плюс перезагрузка).
2) Исходящий пакет перехватываем на внешнем (интернет-интерфейсе, туда его отроутит стек), маки там уже правильные, нужно только подменить IP/порт источника иначе пакет не уйдет далеко.
3) Для входящих так же на внешнем интерфейсе восстанавливаем IP/порт источника на адрес в локальной сети.Все крайне просто…
Ahh, it is clear now (under binding usually meant another thing). Then the solution is intercepting TCP/IP protocol registering and setting a new handler for ProtocolStatus. This handler is called with status WAN line up indication each time when new WAN connection is established. Another option is creating a protocol driver and binding it to NDISWAN, so it should be also possible to receive line up indications.
NDISWAN is an intermediate driver, so you can also intercept its lower lewel bind/unbind by intercepting NdisOpenAdapter/NdisCloseAdapter. Or may be I missunderstood your question?
Well, may be it is not a good solution for your type of driver but you can track binding changes by hooking NdisOpenAdapter/NdisCloseAdapter in NDIS.SYS
Если адаптер будет удален из системы или соединение будет задизеблино (disabled), что в общем-то одно и то же, так как binding удаляется, то ReleaseInterface вызывать не нужно, все ассоциированные с сетвым интерфейсом ресурсы будут освобождены при его удалении.
Гм, тогда все понятно. Действительно, в версии 3.0.1 (2005-Nov-24) при переходе с VC6 на VS2005 была допущена ошибка (в следствии конвертации проекта был выброшен DEF файл). Так как все основные тесты отрабатываются С++ (и большинством разработчиков в данной сфере используется именно С/C++), проблема была замечена и исправлена только 2006-Jan-05. Все это отражено в ньюсах http://www.ntkernel.com/news.php
Проблема не является критической, и требовала единственного изменения в VS2005 проекте DLL (сборка с использованием VC++ 6.0 или из командной строки (sources) выполнялась правильно). В общем-то любой коммерческий WinpkFilter проект так или иначе требует пересборки драйверов (в случае Developers license пересборка осуществляется нами) и DLL во избежание конфликтов имен драйверов. Так что пересобрать и драйвера (с использование новых имен устройств, модулей и протоколов) и DLL все-таки необходимо иначе разработанное вами приложение будет конфликтовать со стандартной сборкой WinpkFilter и основанных на ней примерах.
Заказчик может получить обновление используя полученные ранее реквизиты. Хотя как следует из вышесказанного стандартная сборка DLL не должна использоваться для конечного продукта.
Прошу прощения за доставленные неудобства. Если возникнут вопросы относительно сборки драйверов, то пишите на [email protected] решим в рабочем порядке (единственое просьба указать покупателя, нашего клиента и вашего заказчика, приблизительную дату и номер ордера). Обычно, в случае Source Code license заказчик сам выполняет сборку драйверов и DLL, однако если это по каким-либо причинам проблематично мы так же делаем custom build как и в случае с Developer license.
Вот что выдает dumpbin по экспортам ndisapi.dll собранной в Visual C++ (та что стандартно идет в инсталляторе WinpkFilter):
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file ndisapi.dll
File Type: DLL
Section contains the following exports for ndisapi.dll
0 characteristics
43BD7734 time date stamp Thu Jan 05 21:44:52 2006
0.00 version
1 ordinal base
57 number of functions
57 number of names
ordinal hint RVA name
1 0 00001000 ??0CNdisApi@@QAE@ABV0@@Z
2 1 00001110 ??0CNdisApi@@QAE@PBD@Z
3 2 000011F0 ??1CNdisApi@@UAE@XZ
4 3 00001040 ??4CNdisApi@@QAEAAV0@ABV0@@Z
5 4 0000ABF0 ??_7CNdisApi@@6B@
6 5 00001080 ??_FCNdisApi@@QAEXXZ
7 6 00001E50 ?ConvertWindows2000AdapterName@CNdisApi@@SAHPBDPADK@Z
8 7 00001FB0 ?ConvertWindows9xAdapterName@CNdisApi@@SAHPBDPADK@Z
9 8 00001CA0 ?ConvertWindowsNTAdapterName@CNdisApi@@SAHPBDPADK@Z
10 9 00001220 ?DeviceIoControl@CNdisApi@@QAEHKPAXH0HPAHPAU_OVERLAPPED@@@Z
11 A 00001400 ?FlushAdapterPacketQueue@CNdisApi@@QAEHPAX@Z
12 B 000013D0 ?GetAdapterMode@CNdisApi@@QAEHPAU_ADAPTER_MODE@@@Z
13 C 00001430 ?GetAdapterPacketQueueSize@CNdisApi@@QAEHPAXPAK@Z
14 D 00001BB0 ?GetAdaptersStartupMode@CNdisApi@@SAKXZ
15 E 00001870 ?GetBytesReturned@CNdisApi@@QAEKXZ
16 F 00001800 ?GetHwPacketFilter@CNdisApi@@QAEHPAXPAK@Z
17 10 000019A0 ?GetMTUDecrement@CNdisApi@@SAKXZ
18 11 000012D0 ?GetTcpipBoundAdaptersInfo@CNdisApi@@QAEHPAU_TCP_AdapterList@@@Z
19 12 00001290 ?GetVersion@CNdisApi@@QAEKXZ
20 13 00001860 ?IsDriverLoaded@CNdisApi@@QAEHXZ
21 14 000016E0 ?NdisrdRequest@CNdisApi@@QAEHPAU_PACKET_OID_DATA@@H@Z
22 15 00001370 ?ReadPacket@CNdisApi@@QAEHPAU_ETH_REQUEST@@@Z
23 16 00001340 ?SendPacketToAdapter@CNdisApi@@QAEHPAU_ETH_REQUEST@@@Z
24 17 00001310 ?SendPacketToMstcp@CNdisApi@@QAEHPAU_ETH_REQUEST@@@Z
25 18 00001610 ?SetAdapterListChangeEvent@CNdisApi@@QAEHPAX@Z
26 19 000013A0 ?SetAdapterMode@CNdisApi@@QAEHPAU_ADAPTER_MODE@@@Z
27 1A 00001A90 ?SetAdaptersStartupMode@CNdisApi@@SAHK@Z
28 1B 000017B0 ?SetHwPacketFilter@CNdisApi@@QAEHPAXK@Z
29 1C 00001880 ?SetMTUDecrement@CNdisApi@@SAHK@Z
30 1D 00001470 ?SetPacketEvent@CNdisApi@@QAEHPAX0@Z
31 1E 00001540 ?SetWANEvent@CNdisApi@@QAEHPAX@Z
32 1F 000020B0 CloseFilterDriver
33 20 00002520 ConvertWindows2000AdapterName
34 21 00002540 ConvertWindows9xAdapterName
35 22 00002500 ConvertWindowsNTAdapterName
36 23 000022A0 FlushAdapterPacketQueue
37 24 00002260 GetAdapterMode
38 25 000022F0 GetAdapterPacketQueueSize
39 26 000024B0 GetAdaptersStartupMode
40 27 000024E0 GetBytesReturned
41 28 000020D0 GetDriverVersion
42 29 00002420 GetHwPacketFilter
43 2A 00002490 GetMTUDecrement
44 2B 00002120 GetTcpipBoundAdaptersInfo
45 2C 000024C0 IsDriverLoaded
46 2D 000023A0 NdisrdRequest
47 2E 00002090 OpenFilterDriver
48 2F 000021E0 ReadPacket
49 30 000021A0 SendPacketToAdapter
50 31 00002160 SendPacketToMstcp
51 32 00002380 SetAdapterListChangeEvent
52 33 00002220 SetAdapterMode
53 34 000024A0 SetAdaptersStartupMode
54 35 000023C0 SetHwPacketFilter
55 36 00002480 SetMTUDecrement
56 37 00002340 SetPacketEvent
57 38 00002360 SetWANEvent
Summary
2000 .data
4000 .rdata
2000 .reloc
1000 .rsrc
8000 .textКак видно их приведенного, ndisapi.dll экспортирует два набора функций, один в форме C++ класса (может быть использован только из C++) и второй в виде _stdcall функций (для использования из других програмных сред). C Visual C run time библиотека слинкована статически.
Думаю, что проблема в следущем, библиотека была собрана в C++ Builder без учета DEF файла (судя по тому что экспортируется только C++ класс). Что касается cc3260mt.dll, тут мне сложно сказать с уверенностью(нет под рукой проверить), но думаю с run-time библиотекой можно и в C++ Builder слинковаться статически.
Собственно, возможность сборки DLL под C++ Builder была добавлена только для использования с C++ Builder, из-за того что name decoration используемый Visual C++ и C++ Builder различен. Возникшие проблемы скорей всего обьясняются с переносом и сборкой проектов под версию C++ Builder отличную от используемой нами. Вот экспорты ndisapi.dll собранной под C++ Builder 6.0:
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file ndisapi.dll
File Type: DLL
Section contains the following exports for ndisapi.dll
0 characteristics
0 time date stamp Thu Jan 01 02:00:00 1970
0.00 version
1 ordinal base
54 number of functions
54 number of names
ordinal hint RVA name
1 0 00001258 @CNdisApi@$bctr$qpxc
2 1 00001344 @CNdisApi@$bdtr$qv
26 2 00001E0C @CNdisApi@ConvertWindows2000AdapterName$qpxcpcul
27 3 00001F30 @CNdisApi@ConvertWindows9xAdapterName$qpxcpcul
25 4 00001CAC @CNdisApi@ConvertWindowsNTAdapterName$qpxcpcul
3 5 00001390 @CNdisApi@DeviceIoControl$qulpvit2ipip11_OVERLAPPED
11 6 00001554 @CNdisApi@FlushAdapterPacketQueue$qpv
10 7 00001528 @CNdisApi@GetAdapterMode$qp13_ADAPTER_MODE
12 8 00001580 @CNdisApi@GetAdapterPacketQueueSize$qpvpul
24 9 00001BD8 @CNdisApi@GetAdaptersStartupMode$qv
20 A 00001960 @CNdisApi@GetBytesReturned$qv
18 B 000018EC @CNdisApi@GetHwPacketFilter$qpvpul
22 C 00001A38 @CNdisApi@GetMTUDecrement$qv
5 D 00001444 @CNdisApi@GetTcpipBoundAdaptersInfo$qp16_TCP_AdapterList
4 E 0000140C @CNdisApi@GetVersion$qv
19 F 00001954 @CNdisApi@IsDriverLoaded$qv
16 10 000017BC @CNdisApi@NdisrdRequest$qp16_PACKET_OID_DATAi
8 11 000014D0 @CNdisApi@ReadPacket$qp12_ETH_REQUEST
7 12 000014A4 @CNdisApi@SendPacketToAdapter$qp12_ETH_REQUEST
6 13 00001478 @CNdisApi@SendPacketToMstcp$qp12_ETH_REQUEST
15 14 00001710 @CNdisApi@SetAdapterListChangeEvent$qpv
9 15 000014FC @CNdisApi@SetAdapterMode$qp13_ADAPTER_MODE
23 16 00001B0C @CNdisApi@SetAdaptersStartupMode$qul
17 17 0000188C @CNdisApi@SetHwPacketFilter$qpvul
21 18 0000196C @CNdisApi@SetMTUDecrement$qul
13 19 000015AC @CNdisApi@SetPacketEvent$qpvt1
14 1A 00001664 @CNdisApi@SetWANEvent$qpv
30 1B 0000202C CloseFilterDriver
53 1C 00002398 ConvertWindows2000AdapterName
54 1D 000023B0 ConvertWindows9xAdapterName
52 1E 00002380 ConvertWindowsNTAdapterName
38 1F 000021AC FlushAdapterPacketQueue
37 20 00002184 GetAdapterMode
39 21 000021D4 GetAdapterPacketQueueSize
49 22 0000232C GetAdaptersStartupMode
51 23 0000235C GetBytesReturned
31 24 00002098 GetDriverVersion
45 25 000022D4 GetHwPacketFilter
47 26 00002310 GetMTUDecrement
32 27 000020BC GetTcpipBoundAdaptersInfo
50 28 00002338 IsDriverLoaded
43 29 0000227C NdisrdRequest
29 2A 00001FD8 OpenFilterDriver
35 2B 00002134 ReadPacket
34 2C 0000210C SendPacketToAdapter
33 2D 000020E4 SendPacketToMstcp
42 2E 00002254 SetAdapterListChangeEvent
36 2F 0000215C SetAdapterMode
48 30 0000231C SetAdaptersStartupMode
44 31 000022A8 SetHwPacketFilter
46 32 00002300 SetMTUDecrement
40 33 00002200 SetPacketEvent
41 34 0000222C SetWANEvent
28 35 000030F8 ___CPPdebugHook
Summary
1000 .data
1000 .edata
1000 .idata
1000 .reloc
1000 .rsrc
2000 .text
1000 .tls
Как видно экспорты опять отличаются от приведенных вами.
Решение проблемы в том что необходимо должным образом настроить проект под C++ Builder:
1) Убедится что DEF файл включен в сборку (по всей видимости он был убран в следствии конвертации проекта).
2) Вместо динамической run-time библиотеки использовать статическую.
В общем-то нет необходимости менять MAC адреса в случае реализации NAT (если это не MAC NAT конечно). В Internet Gateway задачи маршрутизации (и постановки нужных MAC адресов) возлагаются на стек, мы меняем тока адреса источника.
