Closing socket without sending FIN? - Unix

This is a discussion on Closing socket without sending FIN? - Unix ; Hi, is it possible to close a socket so that the remote end will not be notified about the fact? I'm writing a server program and would like to test such behaviour, but unpluging the network cable is tedious or ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Closing socket without sending FIN?

  1. Closing socket without sending FIN?

    Hi, is it possible to close a socket so that the remote end will not
    be notified about the fact? I'm writing a server program and would
    like to test such behaviour, but unpluging the network cable is
    tedious or impossible if you'd like to test several clients at once.

  2. Re: Closing socket without sending FIN?

    Kyku wrote:
    > Hi, is it possible to close a socket so that the remote end will not
    > be notified about the fact? I'm writing a server program and would
    > like to test such behaviour, but unpluging the network cable is
    > tedious or impossible if you'd like to test several clients at once.


    As far as I know, you cannot "close" a socket without letting
    the other side know. You could "kill" a socket without "closing"
    it by unplugging the network, or the server's power cord, or that
    sort of thing. As a less drastic measure you might try a firewall,
    let the socket get established, and then tell the firewall to block
    all the socket's packets (incoming, outgoing, or both).

    --
    Eric.Sosman@sun.com

  3. Re: Closing socket without sending FIN?

    Kyku wrote:
    > Hi, is it possible to close a socket so that the remote end will not
    > be notified about the fact? I'm writing a server program and would
    > like to test such behaviour, but unpluging the network cable is
    > tedious or impossible if you'd like to test several clients at once.


    Not a direct answer, but perhaps you could put a suitable packet filter
    rule in place to (effectively) selectively unplug the network cable.

    Alex

  4. Re: Closing socket without sending FIN?

    Kyku wrote:
    > Hi, is it possible to close a socket so that the remote end will not
    > be notified about the fact? I'm writing a server program and would
    > like to test such behaviour, but unpluging the network cable is
    > tedious or impossible if you'd like to test several clients at once.


    There is no api-call for this ... however, if you use a Linux
    system for the server side, you could configure the iptables
    (firewall) so that the communication is prohibited and incoming
    packets are dropped without generating RST segments, as well,
    outgoing packets are not sent. The reconfiguration has to be done
    after the sockets are opened by the client, and before the server
    closes the connection.

    For the clients, this has the same effect, as if the server has
    a network-outage. On the server, you see the sockets in question
    in either fin_wait1 (since the stack still waits for an ack for this
    packet, which wasn't delivered due to the modified iptables settings).

    So, this might be a solution to test the clientside, but not for
    the serverside.

    In principle, the same can be done with firewall/accesslist settings
    on any intermediate router (given that you can suppress the generation
    of "icmp/destination-unreach/administratively-prohibited" packets.



  5. Re: Closing socket without sending FIN?

    On Aug 19, 9:20*pm, Rainer Temme
    wrote:
    > Kyku wrote:
    > > Hi, is it possible to close a socket so that the remote end will not
    > > be notified about the fact? I'm writing a server program and would
    > > like to test such behaviour, but unpluging the network cable is
    > > tedious or impossible if you'd like to test several clients at once.

    >
    > There is no api-call for this ... however, if you use a Linux
    > system for the server side, you could configure the iptables
    > (firewall) so that the communication is prohibited and incoming
    > packets are dropped without generating RST segments, as well,
    > outgoing packets are not sent. The reconfiguration has to be done
    > after the sockets are opened by the client, and before the server
    > closes the connection.
    >
    > For the clients, this has the same effect, as if the server has
    > a network-outage. On the server, you see the sockets in question
    > in either fin_wait1 (since the stack still waits for an ack for this
    > packet, which wasn't delivered due to the modified iptables settings).
    >
    > So, this might be a solution to test the clientside, but not for
    > the serverside.
    >
    > In principle, the same can be done with firewall/accesslist settings
    > on any intermediate router (given that you can suppress the generation
    > of "icmp/destination-unreach/administratively-prohibited" packets.


    Yes I'm using Linux. The idea of using iptables seems quite
    interesting, especially that it seems that I could aply it to the
    local interface. Would you be so kind to give me an example for
    establishing such a rule and removing it. My plan is to get the client
    port with lsof, then halt the packets with iptables and kill the
    client (then drop the rule and restart the klient, all withing a loop
    and some 500 clients).

  6. Re: Closing socket without sending FIN?

    >Hi, is it possible to close a socket so that the remote end will not
    >be notified about the fact? I'm writing a server program and would
    >like to test such behaviour, but unpluging the network cable is
    >tedious or impossible if you'd like to test several clients at once.


    You can do a lot with firewalls, either on the server, on the client, or
    on a router in between them.

    Some firewalls allow you to block only packets with FIN set (or
    various other combinations of TCP flags).

    Linux iptables lets you qualify a rule with --tcp-flags FIN FIN,
    and FreeBSD ipfw lets you qualify a rule with tcpflags fin. You'd
    want to qualify the rule with the IP address and port of the server,
    and the IP address of the client. If you're only doing this to one
    connection from the client where there might be more than one
    connection from it, you'd need the client port also.


  7. Re: Closing socket without sending FIN?

    Kyku writes:
    > On Aug 19, 9:20*pm, Rainer Temme
    > wrote:
    >> Kyku wrote:
    >> > Hi, is it possible to close a socket so that the remote end will not
    >> > be notified about the fact? I'm writing a server program and would
    >> > like to test such behaviour, but unpluging the network cable is
    >> > tedious or impossible if you'd like to test several clients at once.

    >>
    >> There is no api-call for this ... however, if you use a Linux
    >> system for the server side, you could configure the iptables
    >> (firewall) so that the communication is prohibited and incoming
    >> packets are dropped without generating RST segments, as well,
    >> outgoing packets are not sent. The reconfiguration has to be done
    >> after the sockets are opened by the client, and before the server
    >> closes the connection.
    >>
    >> For the clients, this has the same effect, as if the server has
    >> a network-outage. On the server, you see the sockets in question
    >> in either fin_wait1 (since the stack still waits for an ack for this
    >> packet, which wasn't delivered due to the modified iptables settings).
    >>
    >> So, this might be a solution to test the clientside, but not for
    >> the serverside.
    >>
    >> In principle, the same can be done with firewall/accesslist settings
    >> on any intermediate router (given that you can suppress the generation
    >> of "icmp/destination-unreach/administratively-prohibited" packets.

    >
    > Yes I'm using Linux. The idea of using iptables seems quite
    > interesting, especially that it seems that I could aply it to the
    > local interface. Would you be so kind to give me an example for
    > establishing such a rule and removing it.


    Assuming TCP,

    iptables -A OUTPUT -p tcp --sport -J DROP

    would add a rule to the OUTPUT chain (affects all locally generated
    datagrams) causing everything sent from the client port[*] to be
    dropped 'silently'[**]. It could be removed again by

    iptables -D OUTPUT

    or by repeating the rule specification for the -D command (according
    to documentation -- I haven't used this so far).
    [*] For a multi-homed machine, specifiying the client IP (-s)
    may be necessary, too.

    [**] This isn't really true: The transmission call done by the
    client will return with an error of EPERM (at least for 2.4)

+ Reply to Thread