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

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

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.

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).

>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.

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)