Forum Replies Created
-
Posts
-
WinpkFilter driver by default has 500 buffers for queing packets. When you send a large amount of packets on the network interface which is in the tunnel mode then driver internal queue is overloaded and network will be frozen until your user mode application process all these packets. So the reason is the application which does not process packets fast enough. May be it just does get enough CPU time. Try to assign packet filtering application a higher priority than your UDP sending application has. However, I don’t think that your network is really frozen, you rather expirience a huge packet drops because of massive UDP spoofing and this causes TCP resends and etc…
I can’t see if your filter application really does anything except console output. However, please note that console output is relatively slow thing and if you call it for every packet this cause a serious delay for each packet processing, thus causing slower reading packets from the queue. May be this was a problem in you case, however, I have not been expecting your code thoroughly. Why you just don’t use the tha passthru sample instead compiled with no console output?
Ну это не так как я советовал, судя по тому сколько в коде изменилось…
Вообще, если что-то не работает или работает не так как ожидается, я бы поставил сниффер типа Network Monitor и начал разбираться, с тем какие пакеты куда и как ходят. Сделать нормальный редирект в четыре строчки не получится, могу сразу сказать. Можете посмотреть пример NAT в Internet Gateway, это почти то же самое по работе с пакетами, просто задача другая. А разбираться с чужим неработающим кодом занятие неблагодарное, ну если, конечно, не за отдельные деньги 8)
Я Дельфи не очень читаю, поэтому лучше расскажу как это надо было делать.
Если собираешься фильтровать на внешнем интерфейсе и меняешь destination IP, то нужно запомнить какое соединение и как ты изменил (source IP/port, original destination IP/port). Иначе пакет с измененным (TCP SYSN) IP адресом выйдет наружу, удаленный сервер (на который был осуществлен редирект) тебе ответит(TCP ACK), а затем в полученном от этого сервера на внешний интерфейс пакете нужно будет заменить source IP/port (они на момент получения принадлежат серверу на который был осуществлен редирект) на те которые были изначально (куда собственно клиент стучался). Ну и так далее для всех последующих пакетов. У тебя же в коде всего одна проверка на адрес, и такой логики судя по всему не присутствует.
Хотя обычно такая фильтрация делается на внутреннем интерфейсе с редиректом на локальный HTTP сервер. Так как то правильней чем редиректить с внешнего куда-то на удаленный сервер.
Actually that depends from the NAC implementation, an example NAC can be built using drivers similar to winpkfilter. So I can hardly advise anything without the details.
I have not seen the behaviour like this myself, but I have heard about one such case already. I agree with the second post in MSDN that this may be caused by pending NBL’s in underlaying NDIS miniport driver. Have you tried to update your WAN/LAN drivers? Which exactly causes the hang?
One possible option can be disabling network interfaces prior to LWF driver uninstallation. It can be also done from command line using devcon utility like described here http://wlanbook.com/enable-disable-wireless-card-command-line/
For Windows XP 32 bit you probably use WinpkFilter NDIS-hooking driver which intercepts bindings between TCPIP and network interfaces. This type of driver does not care about underlying network interface media type.
Unlike NDIS-hooking driver other WinpkFilter drivers (NDIS IM and NDIS LFW) are installed to filter media types specified in INF file. Current INF files specify ethernet, wan and ppip network media types. You can add nolower media type (VMWare adapters has this media type) into the INF file and this will cause WinpkFilter driver to bind to VMWare adapters. However, besides VMWare network adapters WinpkFilter will be also installed to filter other network interfaces with nolower media. This may cause stability side effects, so you can try this on your own risk.
Не все тут просто, как минимум нужно сохранять какой-то контекст для каждой интересующей TCP сессии. Дальше есть два варианта:
1) Кешировать пакеты сессии до тех пока не будет получен весь файл. Для этого придется генерировать ACK пакеты в обратном направлении. Как только файл получен проанализировать его и отправить соответствующие пакеты по назначению. В данном случае придется самостоятельно контроллировать доставку пакетов и делать ретрансмиты если пакеты теряются.
2) Для каждой сессии сохранять ее текущее состояние и каждый следующий пакет анализировать с учетом состояния сессии. Как, например, при обнаружении метода POST сохранить контекст сессии (IP адреса и порты) и затем все пакеты проверять на принадлежность этой сессии. Если пакет принадлежит этой сессии то анализировать его с учетом того что это метод POST.
Первый метод довольно сложный и я бы его не рекомендовал, а второй вполне реально реализовать. Придется конечно реализовать анализатор интересующего протокола, чтобы для каждого пакета понимать, что он содержит и как это должно быть проанализировано.
By the way, VirtualBox packet duplication issue it had in the past:
