Forum Replies Created
-
Posts
-
Возможно остался ключ в реестре HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesndisrd. Удалите и его тоже. По идее если драйвер деинтсталлирован, удалены кешированные INF и ключи реестра, то следов остаться не должно. После всех удалений желательно перезагрузить систему.
Возможно WinpkFilter устанавливался по разным путям, система запомнила первый и теперь не может найти драйвер. Я бы удалил драйвер стандартными средствами, а затем нашел бы INF файлы в папке Windows/INF которые содержат строку ndisrd. В случае с LWF нужно удалить пару файлов вида oemXXX.inf и oemXXX.pnf. Я бы еще перегрузил систему на всякий случай.
P.P.S. If you plan UDP spoofing on the network interface using large amounts of packets then it also may have sense to create a special WinpkFilter driver build with larger amount of packets buffers.
P.S. You can also try PackThru sample which reads/writes blocks of packets from/to the driver and thus faster processes the queue.
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/
