Help required on TCP stack implementation - TCP-IP

This is a discussion on Help required on TCP stack implementation - TCP-IP ; Hi, I'm currently working on making my own basic TCP/IP stack, for my own education. I have already written the ethernet layer, the ARP layer, the ICMP layer, and the IP layer, and now I'm trying to make a simple ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Help required on TCP stack implementation

  1. Help required on TCP stack implementation

    Hi,

    I'm currently working on making my own basic TCP/IP stack, for my own
    education. I have already written the ethernet layer, the ARP layer, the
    ICMP layer, and the IP layer, and now I'm trying to make a simple TCP
    implementation.
    However, there's one part of the RFC that looks wrong to me (but I'm
    sure the RFC is correct, it's probably just me not reading it as I
    should I suppose).

    I'm trying to implement the 3-way handshake for an incoming connection.

    When a SYN packet is received, then 2 possibilities : No matching local
    socket in LISTEN state => send a RST, otherwise => send SYN-ACK.

    The SYN-ACK is working fine, but I have a little problem with the RST :

    According to the RFC793, in 3.9 - Event processing :
    ----------------------8<---------------------------------------
    [if] SEGMENT ARRIVES

    If the state is CLOSED (i.e., TCB does not exist) then
    [snip Need to send a RST with such settings :]
    If the ACK bit is off, sequence number zero is used,



    If the ACK bit is on,


    ---------------------->8---------------------------------------


    Now, I did a test with a linux box :
    There's no listening socket on TCP port 4242, now if I do a telnet
    localhost 4242 while sniffing with wireshark :
    The system generates a SYN packet with the value X as the sequence
    number and no data (length=0).
    The linux TCP stack replies with a RST packet where the acknowledgement
    number is : X + 1

    According to me and the formula, it should have been X + 0 since the
    length of the SYN payload was 0.

    Now, If I test it on my own implementation of TCP :

    On linux, if I do telnet localhost 4242, then Telnet immediately closes
    with a "Connection failed" since it received the RST.

    Now if I do telnet 192.168.1.2 4242 (192.168.1.2 is my own TCP
    implementation, and there's no TCP listening socket on this machine),
    then if I do as the formula states (ACK=SEG.SEQ+SEG.LEN), then Telnet
    doesn't return with "Connection failed" but instead keep sending SYN
    packets. Now if I don't follow the formula, and do as linux did in my
    previous test (adding 1), then it works. So basically linux filters my
    RST packet when it complies with the RFC (or at least with what I
    understand from the RFC).

    Now I know that the RFC can't be wrong, and I would doubt that Linux is
    wrong as well

    So I'm stuck here since I don't understand what I didn't get well.

    If there's a TCP guru around here, some help would be appreciable :-)


    Best regards,

  2. Re: Help required on TCP stack implementation

    In article <4909be5c$0$18530$426a74cc@news.free.fr>,
    Francois Goudal wrote:

    > Hi,
    >
    > I'm currently working on making my own basic TCP/IP stack, for my own
    > education. I have already written the ethernet layer, the ARP layer, the
    > ICMP layer, and the IP layer, and now I'm trying to make a simple TCP
    > implementation.
    > However, there's one part of the RFC that looks wrong to me (but I'm
    > sure the RFC is correct, it's probably just me not reading it as I
    > should I suppose).
    >
    > I'm trying to implement the 3-way handshake for an incoming connection.
    >
    > When a SYN packet is received, then 2 possibilities : No matching local
    > socket in LISTEN state => send a RST, otherwise => send SYN-ACK.
    >
    > The SYN-ACK is working fine, but I have a little problem with the RST :
    >
    > According to the RFC793, in 3.9 - Event processing :
    > ----------------------8<---------------------------------------
    > [if] SEGMENT ARRIVES
    >
    > If the state is CLOSED (i.e., TCB does not exist) then
    > [snip Need to send a RST with such settings :]
    > If the ACK bit is off, sequence number zero is used,
    >
    >
    >
    > If the ACK bit is on,
    >
    >
    > ---------------------->8---------------------------------------
    >
    >
    > Now, I did a test with a linux box :
    > There's no listening socket on TCP port 4242, now if I do a telnet
    > localhost 4242 while sniffing with wireshark :
    > The system generates a SYN packet with the value X as the sequence
    > number and no data (length=0).
    > The linux TCP stack replies with a RST packet where the acknowledgement
    > number is : X + 1
    >
    > According to me and the formula, it should have been X + 0 since the
    > length of the SYN payload was 0.


    Although SYN and FIN segments don't necessarily contain any actual
    payload, they're considered to take up a byte of sequence space so that
    they can be distinguished from other data segments. In other words,
    these flags each implicitly add 1 to SEG.LEN.

    See the last paragraph on p.26 of the RFC.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: Help required on TCP stack implementation

    On Oct 30, 8:02*am, Francois Goudal wrote:
    > Hi,
    >
    > I'm currently working on making my own basic TCP/IP stack, for my own
    > education. I have already written the ethernet layer, the ARP layer, the
    > ICMP layer, and the IP layer, and now I'm trying to make a simple TCP
    > implementation.


    That's interesting.

    0. What platform? Is it portable?
    1. What language are you using? C? C++?
    2. How did you do the Ethernet layer?
    3. Does it in user-mode or kernel-mode?
    4. How do you test it?
    5. You planning on doing anything different than socket interface?

    Just curious.

    I also have experimental protocol stack, though I have not had much
    time to work on it lately.

    -Le Chaud Lapin-

+ Reply to Thread