Socket Connection Probolem - SYN - RST

Discussion in 'Linux Networking' started by dave livingston, Apr 4, 2006.

  1. I have been working on a connection problem that has me totally baffled and
    I would not mind some pointers on where to start to search.

    I have a small White Box Linux server up and running with a small server app
    that listens to port 3020. I can telnet to that port from my workstation and
    connect.
    I have a small embedded device (Rabbit) that is supposed to connect to the
    server to transfer data. I cannot get a connection between the two systems.
    I've taken the code from the rabbit and the server and sent it to another
    developer to try. He can get a connection between the two devices.
    From the sniffer I can see the Rabbit sending out SYN packets and then RST
    packets, but the server never responds. I can ping the Rabbit from the
    server with no problem...
    There is nothing in the iptables and I'm at a loss as to where to check
    next..

    any ideas?

    thanks in advance

    dave
     
    dave livingston, Apr 4, 2006
    #1
    1. Advertisements

  2. dave livingston

    Rick Jones Guest

    Have you tried taking a packet trace on the server to make certain the
    SYN's are actually getting to the server? Also, when does the Rabbit
    sent RSTs? Just to be pendantic, you know those abort connections
    right?

    rick jones
     
    Rick Jones, Apr 4, 2006
    #2
    1. Advertisements

  3. Are the "Rabbit" and server in the same subnet? Check the ip address of the
    "Rabbit" and it's subnet mask. A wrong subnet mask could cause the problem.

    Klazmon.
     
    Llanzlan Klazmon, Apr 5, 2006
    #3
  4. Piggy backing on my own post. Another possibilty is the physical
    connection. I assume you are connecting the Rabbit via a switch or hub.
    Could be a speed mismatch problem. If the Rabbit only does 10mb HDX and
    your switch is forcing 100Mb FDX for example. Can you check the switch
    configuration?

    You need to verify that the hardware layer and also layer 2 is working
    before worrying about the tcp/ip stuff.

    Klazmon.
     
    Llanzlan Klazmon, Apr 5, 2006
    #4
  5. Thanks for the response....thoese were some of the first thing that I
    checked.
    Physical connection is fine, I can ping both the Rabbit and the Server from
    ny worksation, and the packet sniffer shows the packets being sent from the
    Rabbit to the Server. This small network is flat, ie only using a hub for
    testing so I know there is no problem with switches.

    I'm going to drop a packet sniffer on the linux box to see what is going on
    there...

    thanks again

    dave
     
    dave livingston, Apr 5, 2006
    #5
  6. I'm dropping a packer sniffer on the server as i type this to see what is
    going on...
    I'm assuming that the packets are getting there, since I can reach both the
    server and rabbit from my workstation
    and the server can ping the rabbit with no problem....it is a flat network
    at the moment..ie only a hub no switch...

    thanks for your help

    dave
     
    dave livingston, Apr 5, 2006
    #6
  7. dave livingston

    Rick Jones Guest

    Physical connection is fine, I can ping both the Rabbit and the
    That's fine - in "general" however, one cannot assume that because A
    can reach B and A can reach C that that B can reach C.

    Also, a clean ping does not always mean that duplex settings are fine
    because a ping on an otherwise idle network does not try to have more
    than one system access the network simultaneously.
    Excellent.

    rick jones

    And now for the insomniacs, some boilerplate on duplex:

    How 100Base-T Autoneg is supposed to work:

    When both sides of the link are set to autoneg, they will "negotiate"
    the duplex setting and select full-duplex if both sides can do
    full-duplex.

    If one side is hardcoded and not using autoneg, the autoneg process
    will "fail" and the side trying to autoneg is required by spec to use
    half-duplex mode.

    If one side is using half-duplex, and the other is using full-duplex,
    sorrow and woe is the usual result.

    So, the following table shows what will happen given various settings
    on each side:

    Auto Half Full

    Auto Happiness Lucky Sorrow

    Half Lucky Happiness Sorrow

    Full Sorrow Sorrow Happiness

    Happiness means that there is a good shot of everything going well.
    Lucky means that things will likely go well, but not because you did
    anything correctly :) Sorrow means that there _will_ be a duplex
    mis-match.

    When there is a duplex mismatch, on the side running half-duplex you
    will see various errors and probably a number of _LATE_ collisions
    ("normal" collisions don't count here). On the side running
    full-duplex you will see things like FCS errors. Note that those
    errors are not necessarily conclusive, they are simply indicators.

    Further, it is important to keep in mind that a "clean" ping (or the
    like - eg "linkloop" or default netperf TCP_RR) test result is
    inconclusive here - a duplex mismatch causes lost traffic _only_ when
    both sides of the link try to speak at the same time. A typical ping
    test, being synchronous, one at a time request/response, never tries
    to have both sides talking at the same time.

    Finally, when/if you migrate to 1000Base-T, everything has to be set
    to auto-neg anyway.
     
    Rick Jones, Apr 5, 2006
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.