Testing techniques/tools for setting up many tcp connections simultaneously

Testing techniques/tools for setting up many tcp connections simultaneously

Post by Tom » Tue, 21 Sep 2004 01:15:20


Hello,

This got a bit wordy, so there's a short version and a long version.

Short version:
Given control over machine A (gentoo linux) and machine B (probably windows,
but I could find a linux one at a pinch), can anyone recommend any tools or
techniques with which I could cause a specified, large number of tcp
connections to be simultaneously set up between A and B? I don't just mean
having a known number of connections open, I mean they should be being set
up simultaneously -ie. A has sent N SYNs, but has not sent any ACKs yet.

Long version:
The reason for this is that my cable modem (or some other part of my
provider's setup) has a problem which causes it to occasionally stop
working, requiring a powerdown/powerup of the modem to reconnect. Suffice
it to say that I have no expectation of the ISP even admitting to the
existence of the problem, let alone fixing it.
I have observed that the fault occurs when there are a large number of
simultaneous tcp connections, such as when bittorrent is running. Large
data rates do not cause a problem, as I can download and upload at maximum
data rates through one connection at a time without any trouble.
I have occasionally had many connections open at one time without the fault
occurring, and I have seen the fault occur when there haven't been that
many connections up. However, there are always multiple connections open.
This is what makes me think perhaps the problem might be to do with
simultaneously *setting up* numerous connections, rather than maintaining
them.
What I would like to do is figure out exactly which situations cause this
problem and then use my packet filter or some kind of traffic shaping tool
to prevent the situation from occurring.
I have much to learn before I can complete this, but perhaps someone could
help with the first step. Can anyone recommend any tools or techniques with
which I could cause a specified, large number of tcp connections to be
simultaneously established with another machine over the internet?

Many Thanks,
Tom
 
 
 

Testing techniques/tools for setting up many tcp connections simultaneously

Post by Jeroen Gei » Tue, 21 Sep 2004 04:56:43


Start by Googling for any and all info on the cable modem, dude.

If anybody else has already seen this behaviour it's pretty likely
something will have been written about it.


www.google.com/search?q=linux+network+testing+simultaneous+tcp+connections

F'rinstance.


--
J

All your bits are belong to us - again.

 
 
 

Testing techniques/tools for setting up many tcp connections simultaneously

Post by rdgentry » Tue, 21 Sep 2004 13:30:50

om < XXXX@XXXXX.COM > wrote in message news:<sgi3d.30011$ XXXX@XXXXX.COM >...

This is basically a SYN flood and yes you can bring down a computer
this way. It's the basis of SYN flood dos attacks. Doing this on a
lan will tell you _nothing_ about your ISP's weaknesses. Doing it on
your ISP's equipment will likely result in legal action these days.


What does "not working" mean? Does your CM drop connection? What do
the logs on the CM say? Try entering http://192.168.100.1/ in your web
browser. If the connection is dropping, does it ever come up on its
own? Does it come up "normally" after recycling the CM?


I think you're barking up the wrong tree here. These days most CMs
are quite effectively capped -- especially if your CM is supplied by
your ISP. In this case you can't very well "flood" the ISP with any
kind of traffic. Besides, you're only passing through the ISP's
network -- along with thousands of others. Most unlikely that you're
the sole cause or victim if "traffic" volume is the problem -- others
would be complaining too.


If your diagnosis is wrong (as I suspect) then this remedy won't help
anything.


First, you have to determine the nature and cause of what sounds like
a network problem. Is it signal related? Check the CM logs. It is
rare that signals restore quickly after a recycling _if_ it's a
network problem. If it's a CM problem (overheating is a common cause)
the recycling is necessary but sometimes requires waiting a few
minutes before bringing it back up.

Are there any signs before actual loss of network connectivity? Have
you confirmed loss of network connectivity by pinging your DNS
servers? Your gateway? Yahoo? Google? A neighbor on your subnet?

Are you using DHCP to acquire an IP address? Is it configured
correctly? What distro? What dhcp client? Do "outages" ever
correspond closely to the time of lease expiration/renewal?

Have you sniffed the wire after an outage? How does it compare to
"normal" usage? Is your ISP in one of those ever present "roll outs"
of new service?
Have you checked your ISP at http://www.dslreports.com/ ? Contacted a
techie there in one of the forums?

Check complaints about your ISP's service record. Some are pretty
lousy all the time, most are so on occassion, and some have adapted
"outages" as a way to deal with over subscribed lines -- when the
traffic volume gets "too high" they randomly or by algorithm drop
customers so they have to recycle the CM. Most likely "victims" are
those with heavy upload traffic patterns which indicates either
running a server or p2p software -- neither of which the ISP cares for
without you paying a cmomercial rate. Uploading traffic on cable dsl
is very expensive (spectrum and time wise) for the ISP.

This is the best one stop site to go when rooting out cable dsl
problems:
http://homepage.ntlworld.com/robin.d.h.walker/cmtips/index.html

Never mind the UK/Ireland specifics -- they are color coded and don't
apply (presumably :-). That's a joke -- Blueyonder gets specific
space there and good tips. In fact, go here before doing _anything_
else I've suggested. Seriously. No s**t.

hth,
prg
email above disabled