[bk]

@SerpentFly wrote:

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?

Well, there is still a lot of IBM hardware out there..

[bk]

@SerpentFly wrote:

NDIS_STATUS_FAILURE is the same as STATUS_UNSUCCESSFUL. Are you sure that you get STATUS_INVALID_PARAMETER?

Yes, pretty sure. I’m not at work, so I cannot post the exact code, but roughly is:

… initialize the irp structure …

status = IoCallDriver( devObj, irp );

if( status == STATUS_PENDING )
WaitForSingleObject( devObj, …);
else if ( status == STATUS_INVALID_PARAMETER ) {
DbgPrint(“Invalid parameter”);
}
…

This code is called in a cycle: where there are packets in queue, the status is correct, but on the last cycle, where there are no more packets on queue, it prints “invalid parameter”. Sadly I’m not at work so I can’t give you the exact hex value, but if I remember correctly it’s 0xC000000D.

The same happens with IOCTL_NDISRD_FLUSH_QUEUE on an empty queue.

[bk]

I’ve done some tests, it seems that IoCallDriver returns STATUS_INVALID_PARAMETER when I try a IOCTL_NDISRD_READ_PACKET on an adapter without packets in queue. Is this correct?

I’m also receiving a STATUS_INVALID_PARAMETER when I try a IOCTL_NDISRD_FLUSH_QUEUE on an adapter with an empty queue. Is this correct?

[bk]

Pardon me, the status returned by what?

[bk]

Thank you, I think I’ve sorted out my problems. 🙂

[bk]

@SerpentFly wrote:

In order to wait on this event you should first get event object with ObReferenceObjectByHandle call.

You pointed the hard part. How to wait for an event in a driver model (i.e. with dispatch routines).

[bk]

That’s strange. Try removing the driver, perhaps you touched the configuration of your network (i.e. the gateway). Also try a traceroute to the internet and to ping the gateway or a host on the internet.

[bk]

Answer: NotifyAddrChange()

[bk]

@Voxen wrote:

a) what about the destination MAC address?

If I’ve understood what you said, I guess it is:
ORIGINAL:
source: 192.168.0.10
destination: POP3 IP
MAC source: MACA
MAC destination: MACB

CHANGED:
source: a fake IP on the same net, i.e. 192.168.0.100
destination: must be your IP on that adapter / network, in our example 192.168.0.10
MAC source: MACB
MAC destination: MACA

Well, you must try.. Since you are simulating a fake host, you should also fake its MAC address. But this could lead to problems with your ARP table (the system table that the OS keeps to know how to link an IP with a MAC address), depending on how the OS works. The best bet here is to use MACB as source and MACA as destination, as you guessed. Again, you must try because your OS might decide that the source IP is not correct for that source MAC and drop the packet. This should not happen, btw.

The MAC address is the same as the IP address but on a lower level. Each host on an ethernet has a MAC address, which is associated with an adapter. MAC addresses are limited to the local ethernet the adapter is connected to and have no meaning on other networks. When the OS must send a packet, it checks the destination IP address and using the routing table it discovers the next host (hop) on the path of the packet, the network to use and its adapter on that net. Notice that the destination address of the packet is not always the same as the destination of the next hop along the path. As an example, if you have a local net connected to the internat through a gateway, and your host is trying to send a packet to http://www.microsoft.com, the destination IP address on the packet is the IP of http://www.microsoft.com, but the destination IP of the next hop is the IP of your gateway. So to send that packet to microsoft, your host sould know that it must send the packet to the gateway and not to the real destination. The gateway will then send the packet to the real destination. As another example, if the destination of the packet is instead on a net the host is directly connected, then it can send the packet directly to the destination host. All this informations can be found in the routing table of the OS, which links each host IP address, or network IP address, with an adapter / network and if present with a gateway. So using this table your OS knows the next host on the path and the adapter to use.
Now it must send the packet to this host (next hop), that can be the real destination or a gateway. Since the next hop can only be on a local net, it only needs the lower level address of the hop, since lower level protocols don’t understand IP addresses. There is a standard way to do so, it’s the ARP table. This table is keept by the OS using a standard packet exchange with other local hosts on the nets it’s connected to. It can also contain static entries, that are inserted by the users and not discovered using the ARP protocol.
Btw, the ARP table links each IP address with the MAC address of a host on a local net. So using the ARP table the OS can know the MAC address of the next hop of the IP address. The packet is then incapsulated in a lower level packet (the ethernet packet) with the correct destination MAC address.
Each host on an ethernet listens each packet send, but sends the packet to the OS only if the destination MAC address is its MAC address on that adapter.

That’s roughly how it works. Notice that’s correct only for ethernets and similar networks.

b) do I send the modified packets to Adapter or MSTCP?

Normally you modify the packets and send them along their normal path:

You receive an outgoing packet from MSTCP, modify it, and send it to the adapter.
You receive ad incoming packet from an adapter, modify it, and send it to MSTCP.

BUT there are other special cases, sugh ad modified routing behaviour, which might require to send a packet from an adater to another, or, as in your case, to send a packet from MSTCP to MSTCP again.

In your case, you catch outgoing packets, and send them back modified to MSTCP. Notice that you must not do this to ALL packets, or you will block normal network traffic. You must reroute only the correct packets (i.e. the packets with the IP address, protocol type, and TCP port you need to reroute).

So, to make it short, you will receive packets from MSTCP, and must send them back to MSTCP.

[bk]

Well, winpkfilter isn’t perfectly suitable to your needs, but you can work around the problems to make it work.

You can’t work with 127.0.0.1 packets, but you can simulate a “fake” host sending packets to your POP3 proxy. When the mail clients starts a connection, the PC will generate packets on the network adapter you use to connect to the internet or LAN. You can catch those packets, and send them back in. To do so, you must “simulate” a host on the same net your adapter is connected to. Suppose you are using an ethernet adapter with IP address 192.168.0.10, then outgoing packets will exit with that source IP. You must then change:

ORIGINAL:
source: 192.168.0.10
destination: POP3 IP

CHANGED:
source: a fake IP on the same net, i.e. 192.168.0.100
destination: must be your IP on that adapter / network, in our example 192.168.0.10

Recalculate the checksums, and send the new packet back to windows, dropping the original.

Now windows should think that an external PC is sending packets, and will reply to that (fake) IP. You must catch outgoing packets with the fake destination, and send them back in reversing what you’ve done in the previous step:

ORIGINAL:
source: 192.168.0.10
destination: 192.168.0.100 (fake)

CHANGED:
source: POP3 IP
destination: 192.168.0.100

Recalculate the checksums.

[bk]

To NAT you must change the source or destination IP in a direction and do the opposite in the other direction. Remember to recalculate the checksum of the packets. You’ll have no problems using winpkfilter driver to NAT, I’ve done it without problems.

[bk]

Voxen, I’ve seen now your post:

PCA -> SYN -> PCB
PCA <- SYN/ACK <- PCB
PCA <- SYN/ACK <- PCB
PCA -> RST -> PCB (ZeroWindow)

From what I understand, PCA does not respond to the SYN/ACK packet coming from PCB. I could help you better if you describe me exactly what you do, but I have a hint.
PCA generates a packet, you change the destination and PCB receives it.
PCB responds to the packet, sending the answer to PCA. But since PCA is not expeting an ACK from PCB (he thinks he’s talking with the original host you substituted) it will throw the packet away.
When you receive a packet from PCB, you must reverse what you’ve done before: substitute che source from PCB to the original destination.

I.e:

1) PCA sends a packet to PCX. You change the destination to PCB.
2) PCB answers to PCA, but PCA is expecting an answer from PCX, NOT PCB!
So you must reverse the changes you’ve done in step 1, reverting the sender from PCB to PCX.

I’m not sure it’s your problem, since you don’t describe exactly what you do. Btw, you are trying to NAT che packets, try reading some papers on this subject.

[bk]

If changing to localhost does not work, try with the IP address of the ethernet card you are catching the packets from (and make up a fake source IP address if source == destination does not work). This way your packets should appear as coming from an external host to the adapter and should work.

[bk]

@Voxen wrote:

As I’m running both the mail client, the POP3 server and the packet filter on the same PC, I guess that what I must do is:
– capture the outgoing packet
– change its IP and port to localhost/110
– change its MAC address to PC’s MAC address
– recalculate checksums
– send the packet to MSTCP (as stated by SerpentFly above) and not Adapter

So, since the packet originator is the mail client running on the same PC, the source MAC address it the one I should set as MAC destination, right?

Ehm, this is a kind of a special case. You can’t catch internal packets with winpkfilter, so I’m not sure you can also send localhost packets to windows that way. The steps above are correct, but I’m not sure you can inject a packet with localhost destination using winpkfilter. Windows might decide to throw your packets away.. 😕

[bk]

Thank you!

[Author]

Posts