Я сейчас пробую работать с OpenVPN драйвером виртуального адаптера под Виндой из консольного приложения,
пытаюсь открыть его и выставить флаг коннекта (TAP_IOCTL_SET_MEDIA_STATUS), чтобы можно было посылать/принимать данные на его интерфейсе.
Почему-то вызов DeviceIoControl(TAP_IOCTL_SET_MEDIA_STATUS) возвращает ошибку "ERROR_INVALID_FUNCTION"(1).
Тестирую пока на WinXP SP3 (x32), но надо, чтобы код работал и на других виндах...
#define TAP_IOCTL_SET_MEDIA_STATUS TAP_CONTROL_CODE (6, METHOD_BUFFERED)
HANDLE tap = INVALID_HANDLE_VALUE;
GetAdaptersAddresses(...);
if (!_wcsicmp(MY_VNIC_DEVICE_NAME, a->FriendlyName))
{
std::string dn("\\\\.\\Global\\");
dn += a->AdapterName;
//dn += ".tap"; // С суффиксом не открывается!
cout << "device name to open is: " << dn.c_str() << endl;
tap = CreateFileA(dn.c_str(),
MAXIMUM_ALLOWED,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_SYSTEM | FILE_FLAG_OVERLAPPED,
NULL
);
if (INVALID_HANDLE_VALUE == tap)
{
cout<<"Failed to open device!\n"<<endl;
}
else
{
cout<<"Device opened...\n"<<endl;
DWORD len=0;
DWORD uState = TRUE, uOut = FALSE;
if (!::DeviceIoControl(tap, TAP_IOCTL_SET_MEDIA_STATUS,
&uState, sizeof(uState),
&uOut, sizeof(uOut),
&len, NULL))
{
int nErr = ::GetLastError(); // ТУТ ВОЗВРАЩАЕТ "1"!
cout << "DeviceIoControl(): Error = " << nErr << endl;
cout << "WARNING: The TAP-Win32 driver rejected a TAP_IOCTL_SET_MEDIA_STATUS DeviceIoControl call.\n";
}
...
}
}
Подскажите, в чём причина ошибки и где посмотреть ещё инфу / примеры работы с этим драйвером...
При работе тестовой программы (эмуляция OpenVPN), работающей с драйвером виртуального адаптера (версия 9.6) и пересылающей поток данных между двумя машинами через обычный UDP сокет, наблюдается расхождение в скорости трафика при работе под WinXP (x86) и под Win7 (x86). Замедление передачи файлов по самбе идёт в обоих случаях, но под XP это уменьшение скорости в 1,5 — 2 раза, а под Win7 — в 5 — 6 раз! Если точнее, то скорость передачи большого файла (3 Гб) по SMB через реальный адаптер у меня, примерно, 240-250 Mbps на обеих конфигурациях, а через TAP-интерфейс и мою программу она составляет около 140-150 Mbps между XP системами и 30-50 Mbps между Win7 системами... Повышение класса приоритета процессов не меняет общую картину.
На саму программку нет смысла грешить, так как тормоза были и при использовании реального OpenVPN. Поэтому я и выясняю, где тут "затык".
Похоже, что это замедление чтения/записи данных в объект устройства TAP-драйвера. Его код у меня есть, но я его не отлаживал, только смотрю принципы работы.
Я нашёл также инфу на MSDN-е про то, что в Windows 6.0 и старше для драйверов NDIS 5.x используется специальная "прослойка" к драйверам NDIS 6.x, которые передают пакеты скопом (NET_BUFFER_LIST и т.п.), а не по одному, и это может замедлять передачу данных системе. Но действительно ли это преобразование буферов такое долгое?
Подскажите, пожалуйста, в чём тут может быть проблема и какие расхождения систем это вызывают.
Тестирую на реальных машинах с гигабитным интерфейсом и прямым соединением между ними.
Здравствуйте, sizeof_void, Вы писали:
_>В общем, появился ещё важный вопрос по этой теме:
_>При работе тестовой программы (эмуляция OpenVPN), работающей с драйвером виртуального адаптера (версия 9.6) и пересылающей поток данных между двумя машинами через обычный UDP сокет, наблюдается расхождение в скорости трафика при работе под WinXP (x86) и под Win7 (x86). Замедление передачи файлов по самбе идёт в обоих случаях, но под XP это уменьшение скорости в 1,5 — 2 раза, а под Win7 — в 5 — 6 раз! Если точнее, то скорость передачи большого файла (3 Гб) по SMB через реальный адаптер у меня, примерно, 240-250 Mbps на обеих конфигурациях, а через TAP-интерфейс и мою программу она составляет около 140-150 Mbps между XP системами и 30-50 Mbps между Win7 системами... Повышение класса приоритета процессов не меняет общую картину. _>На саму программку нет смысла грешить, так как тормоза были и при использовании реального OpenVPN. Поэтому я и выясняю, где тут "затык".
_>Похоже, что это замедление чтения/записи данных в объект устройства TAP-драйвера. Его код у меня есть, но я его не отлаживал, только смотрю принципы работы. _>Я нашёл также инфу на MSDN-е про то, что в Windows 6.0 и старше для драйверов NDIS 5.x используется специальная "прослойка" к драйверам NDIS 6.x, которые передают пакеты скопом (NET_BUFFER_LIST и т.п.), а не по одному, и это может замедлять передачу данных системе. Но действительно ли это преобразование буферов такое долгое?
_>Подскажите, пожалуйста, в чём тут может быть проблема и какие расхождения систем это вызывают.
_>Тестирую на реальных машинах с гигабитным интерфейсом и прямым соединением между ними.
Прикладываю, на всякий случай, код рабочих потоков чтения/записи: