How to determine server status through packet capture? - TCP-IP

This is a discussion on How to determine server status through packet capture? - TCP-IP ; I am trying to debug an imaps problem with Wireshark. It has been a while since I read the Douglas Comer book. How can I tell whether the lack of response is due to the absence of a server listening ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: How to determine server status through packet capture?

  1. How to determine server status through packet capture?


    I am trying to debug an imaps problem with Wireshark. It has been a
    while since I read the Douglas Comer book.

    How can I tell whether the lack of response is due to the absence of a
    server listening to a specific port, as opposed to the server ignoring
    the connection?

    Let's say a host does not have any process listening to the SMTP port.
    What happens (packetwise) if I try to open a connection to that port?
    I send the initial packet, which is picked by the TCP/IP stack in
    kernel. (Is there any response from that layer right away?) I guess
    the kernel checks whether there is a server process associated with
    that port and gives the packet to such process. Is there any packet
    response from the kernel that says: "sorry, there is no server
    listening on that port"?

    What I am seeing is two packets: one from my client into port 993 and
    a response. Nothing else happens.

    At this point I am interested only in the TCP behavior.

    -Ramon

  2. Re: How to determine server status through packet capture?

    In article <1180810092.481572.300860@q66g2000hsg.googlegroups. com>,
    Ramon F Herrera wrote:
    >Is there any packet
    >response from the kernel that says: "sorry, there is no server
    >listening on that port"?

    Yes. ICMP 3 3, Port Unreachable. Important ICMPs for this purpose include,

    ICMP 3 0 Net Unreachable
    ICMP 3 1 Host Unreachable
    ICMP 3 12 Destination Host access administratively prohibitted

    (Admittedly, I haven't seen many firewalls or routers send back 3/12's;
    they tend to send back 3/3's or 3/1's or just drop the packets.)

  3. Re: How to determine server status through packet capture?

    In article <0aj8i.255624$6m4.165213@pd7urf1no>,
    roberson@hushmail.com (Walter Roberson) wrote:

    > In article <1180810092.481572.300860@q66g2000hsg.googlegroups. com>,
    > Ramon F Herrera wrote:
    > >Is there any packet
    > >response from the kernel that says: "sorry, there is no server
    > >listening on that port"?
    >
    > Yes. ICMP 3 3, Port Unreachable. Important ICMPs for this purpose include,

    That's for UDP. For TCP, the response is a segment with the RST flag
    set.

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

  4. Re: How to determine server status through packet capture?

    On Jun 2, 5:14 pm, Barry Margolin wrote:
    > In article <0aj8i.255624$6m4.165213@pd7urf1no>,
    > rober...@hushmail.com (Walter Roberson) wrote:
    >
    > > In article <1180810092.481572.300...@q66g2000hsg.googlegroups. com>,
    > > Ramon F Herrera wrote:
    > > >Is there any packet
    > > >response from the kernel that says: "sorry, there is no server
    > > >listening on that port"?
    >
    > > Yes. ICMP 3 3, Port Unreachable. Important ICMPs for this purpose include,
    >
    > That's for UDP. For TCP, the response is a segment with the RST flag
    > set.
    >

    What you describe is exactly what I am witnessing, Barry.

    I have one client (Thunderbird) trying to connect to two different
    dovecot/imaps servers. For some reason, one of the server is working
    properly while the other is rejecting all conections, except those
    that come from the localhost.

    When I send the client sends the initial packet into port 993.

    - the 'good' server answers with a [SYN,ACK]
    - the 'bad' server answers with a [RST,ACK]

    What surprised me is that (a) both responses come within milliseconds
    and therefore they have to come from directly from the kernel's TCP/IP
    stack (debugging code tells me that the daemon is not being executed
    at all), and (b) I get exactly the same negative (RST) response
    independently of whether the imaps deamon is running or not.

    My diagnosis then is that:

    - the 'good' server is telling the system: "bind me to addresses
    12.34.56.78 and 127.0.0.1, port 993'

    - the 'bad' server is telling the system: "bind me only to address
    127.0.0.1, port 993".

    If that is the case, what I need to find out is where in the
    dovecot.conf file to configure the described discriminating behavior.

    Incidentally: sendmail can also be configured to have the described
    discriminating behavior. I guess I have to capture some packets of
    both cases to see if I witness the same SYN vs. RST responses in port
    25.

    -Ramon


+ Reply to Thread
« 16th USENIX Security Symposium Registration Now Open | Virtual private networks »