Answer a packet

Home Forums Discussions Support Portal Answer a packet

This topic contains 5 replies, has 2 voices, and was last updated by  smilish 13 years, 9 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #4827

    smilish
    Participant

    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!

    #5457

    Vadim Smirnov
    Moderator

    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.

    #5458

    smilish
    Participant

    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.

    #5459

    smilish
    Participant

    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.

    #5460

    Vadim Smirnov
    Moderator

    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.

    #5461

    smilish
    Participant

    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!

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.