Forum Replies Created
-
Posts
-
We ordered it exactly 7 days ago and didn’t get anything by email
or else. I mailed the order # to support@.The download information was just resent to the address specified in the order details. Please check if it is correct. There is also a possibility that notification was killed by one of the spam filters along the way. In this case please change the e-mail in the order details.
OK, what information do you need ?
Where do you actually set up the breakpoints?
Localhost API helper driver intercepts TDI level of TCP/IP stack and you must be carefull when working with it. It is difficult to say how debugger affects system functionality in this case, but if you provide more information may be I would be able to advise.
I am still using the Demo API version (waiting for the CD
to arrive).If you have ordered Localhost API then you should receive the download link for the full version. If you have not received it then please e-mail support@ntkernel.com.
There is no difference on the NDIS level between network adapter connected to the corporate network and internet adapter connected to the Internet. However, you can use IP HELPER API to query routing table, usually the default gateway interface (route 0.0.0.0 mask 0.0.0.0) is the Internet one. IP Helper API can be also used for enumeratimg active connections.
Does this driver works with token rings?
No, token ring networks are not supported. Actually, I have not heard about token ring networks for years. Do you really need to support this out-of-date standard?
Does NDISRD.SYS only bind itself to interfaces with TCP/IP enabled?
Yes. For your needs you’d better use protocol driver (Winpcap, PCAUSA RAWETHER or etc.).
You just need to create virtual NDIS miniport and extend it with required functionalities. The sceleton driver can be generated by DriverNetworks suite from Compuware or you just can adopt your ne2000 derrived driver (I don’t remember all the details, it’s gone pretty much time since I did similar thing).
I have rechecked the code, and yes you are right. Internal request processing routine returnes STATUS_UNSUCCESFULL, but higher level dispatching routine returnes STATUS_INVALID_PARAMETER for any status different from STATUS_SUCCESS. So your code is pretty correct.
NDIS_STATUS_FAILURE is the same as STATUS_UNSUCCESSFUL. Are you sure that you get STATUS_INVALID_PARAMETER?
You should check the returned status, when there are no packets in the queue WinpkFilter driver returnes NDIS_STATUS_FAILURE.
How to wait for an event in a driver model (i.e. with dispatch routines).
I’m not sure that I understand your question. In kernel mode you can wait on the event object using KeWaitForSingleObject. It should be called on the passive level IRQL only but you can create the dedicated system thread for this…
Please refer CNdisApi::SetPacketEvent regarding translating Win32 event to Ring0 event under Windows 9x/ME.
For Windows NT/2000/XP/2003 you can create Win32 event in kernel with ZwCreateEvent and pass it to driver. In order to wait on this event you should first get event object with ObReferenceObjectByHandle call.
Hope it helps…
However, are there any special thinks to consider when using your pkt filter ??
I’m not sure what you actually mean here, but there is no technical problems to realize NAT using WinpkFilter.
If you mean packet sent to localhost (127.X.X.X) then the answer is NO. These packets (actually they never have the form of packets with IP and TCP headers, just chunks of data) are processed internally by TCP/IP and never reach NDIS level.
It looks that something was wrong when processing the packets below:
PCA <- SYN/ACK <- PCB
PCA <- SYN/ACK <- PCB
and connection was terminated due to time out. I would try to check what happens there.
