Answer a packet

[smilish]

Hi,

imagine a TCP connection request (TH_SYN). I want to drop this packet (no problem). But I want to signal the originating application the failed request through a injected packet sending it to MSTcp. This would mean not just only to modify a packet, but to inject a totally converted packet in opposite direction. Would this work like this:

//

---

begin snippet pseudo code

---

// clear “send” flag -> turn this into a “receive”-packet
m_PacketBuffer.m_dwDeviceFlags &= ~PACKET_FLAG_ON_SEND;

// exchange source and destination (eth address)
ether_header_ptr pEth = _GetEtherHeader();
_exchange(pEth->h_dest, pEth->h_source);

// exchange source and destination (ip address)
iphdr_ptr pIp = _GetIpHeader();
_exchange(pIp->ip_dst, pIp->ip_src);
pIp->ip_hl = 5;
pIp->ip_v = 4;
pIp->ip_tos = 0;
pIp->ip_len = 10240;
pIp->ip_id = 6156;
pIp->ip_off = 0;
pIp->ip_ttl = 128;
pIp->ip_p = 6;

// exchange source and destination (port numbers)
tcphdr_ptr pTcp = _GetTcpHeader();
_exchange(pTcp->th_dport, pTcp->th_sport);
pTcp->th_flags = TH_RST | TH_ACK;
pTcp->th_ack = pTcp->th_seq+1;
pTcp->th_seq = 0;
pTcp->th_win = 0;
pTcp->th_x2 = 0;
pTcp->th_off = 5;
pTcp->th_urp = 0;

// recalc checksums
RecalculateIPChecksum();
RecalculateTCPChecksum();

// send this packet into opposite direction
pApi->SendPacketToMstcp(&m_Request);

//

---

end snippet pseudo code

---

My application won’t react on this packet. So I guess I’ve done something wrong converting this packet, or this won’t work generally. Any clue?

Thanks in advance!

[Vadim Smirnov]

In general the idea is correct and it should work. Only one note, setting m_PacketBuffer.m_dwDeviceFlags is not necessary, this field is used only when you read packets to distinguish incoming and outgoing ones, but it is ignored when you send packets.

Probably your RST packet is somehow wrong, in order to check this let you application to send SYN packet to the system which has not the requested port opened and capture resulting RST packet by sniffer. Then do the same with your WinpkFilter application running and compare the generated RST packet with captured one to find the difference.

[smilish]

Well, I have watched such a RST packet with Ethereal. And did set it up like thath. Thanks anyway.

Btw: Generally, I am rejecting connection request through a TDI filter, that schedules TCP-Connection-IRPs to ring3, but some IRPs can’t be scheduled to ring3 (those with RequestorMode == KernelMode). So I got to get this to work.

[smilish]

I am not sure, if you got me right. I am *not* trying to reject a remote machine. I am trying to reject a connection initiated from my *local* machine (outgoing connection)

I’ve checked that out in more detail. The RST-packet I am generating is definetly ok. I’ve sent my packets to Ethereal, and it stated them as valid (checksums are ok etc.).

The local system sends 3 SYN packets. If they will be rejected (RST) by a remote machine, these 3 packets will be sent in a row very quickly. So the local TCP-Stack obviously recognizes these reject packets.

If *my* software do answer those SYN packets with a RST, further SYN packets come with a gap. Although SendPacketToMstcp returned with “TRUE”, the RST packet has *not* been recognized. The local TCP-Stack timedout, as if the SYN packet has been got lost.

[Vadim Smirnov]

Yes, I understand what you are doing. However, there should be no problem to indicate any custom generated packets to MSTCP (actually there is no difference in reinjecting filtered packet or injecting new packet, both are done with one function). So the problem can be only in the packet itself.

[smilish]

Well, you were absolutly right! Again another “Net to Host” failure. Here’s the corrected line of code:

pTcp->th_ack = htonl(ntohl(pTcp->th_seq)+1);

Thanks again!

[Author]

Posts