- This topic has 2 replies, 2 voices, and was last updated 18 years, 6 months ago by
.
-
Posts
-
Hi, I’ve got f*ing problem with my WinPkFilter application.
I pack all outbound traffic captured on the sender’s side to UDP and send it out (checksums recounted, original ip protocol number stored in the transport protocol, my transport protocol within UDP needs some fields so i have decreased MTU). The packets pass a gateway which does NAT, and are delivered to a destination in WAN. At the destination host I correctly unpack the data and recreate the original packet. Then I send it to the mstcp. Original protocol number is restored, IP, TCP or UDP checksums are correctly counted, the packet seems to be OK. But there is no response for this packet from the upper layers so the communication is broken. I keep track of UDP ports so I would correctly set the destination port on response, but no outbound pakcet is generated, so I can’t reply.
I use windump and it does not detect any outbound traffic too.When I test this application in LAN (without NATing) everything works fine. Could anybody give me some advice what could have been wrong???
Thanx
I would start analyses of this problem with the simplest packet which expected to be replied by MSTCP – ICMP ping. It has simple structure, so it must be easy to verify that the packet which you indicate from the name of the WAN interface after decapsulation is OK.
I have one idea regarding problems with WAN you have, what MAC addresses do you have in the Ethernet header? If when operation over LAN it does not matter much, then over WAN you must use pair of MAC’s associated with particular WAN connection. In your case you must use MAC’s from the original (UDP?) packet received over WAN, but not the MAC’s that packet had before encapsulation or any other MAC’s. Otherwise NDISWAN fails to associate packet with the particular WAN connection and silently drops it.
May be this is not your case, but this is one of the common problems with WAN. If it does not help then please provide more details and I hope we will be able to figure out the exact reason.
Hello SerpentFly, first I’d like to thank you for the response. I have already solved the problem.
As I analyzed it, I saw that I had two problems. First – I had a bug in IP header total length computation – so the packets on the receiver’s side were discarded by the mstcp (I feel a little bit shamed about it 😳 …….). The second problem was really with MACs. In my application I did not pass the “not IP packets” like ARP to adapter/mstcp. I took care only of IP packets, others were dropped. This resulted in connection brakedown of course. What confused me was that the packet was really delivered and processed by my routines on the WAN host. But I realized that I was sending ICMP messages between those hosts before I had started my application, so MACs were known. When I paused it for a while, the ARP cache had exceeded or something (I should read more details about ARP) and therefore no packet could be delivered to the destination host. Another confusion was that it worked fine on LAN. Maybe MS doesn’t take care of IP length field when processing packets from the local network. I was transmitting 75 MB file with no perceptible error on the local network.
Now it works perfectly, so once again, thank you very much.
- You must be logged in to reply to this topic.