[ATrpms-users] dl.atrpms.net connection problems

[Steve Hsieh]

On Nov 7, 2007 7:33 AM, Axel Thimm <Axel.Thimm at atrpms.net> wrote:
>
> On Wed, Nov 07, 2007 at 12:14:11AM -0500, Steve Hsieh wrote:
> >
> > Same here. When I get blocked from the atrpms repository (downloading
> > using yum on just 1 machine), all of the connections are in the
> > LAST_ACK state.
>
> This looks like something is filtering away the FINs coming from your
> systems to ATrpms. I checked the local firewalls and they all properly
> pass FINs into the systems (and FIN/ACKs out as well).


I tried the following tests and here is what I found. Does this make
sense to anyone?

First, I tried using "wget http://130.133.35.8" and ran netstat to see
what happens. After download is complete, I found that netstat shows
this:

tcp        0      0 192.168.123.15:40290        130.133.35.8:80
     TIME_WAIT   -

Then several minutes later, it is gone. However, the fact that it
takes a few minutes would still mean that using wget to download a
bunch of packages (> 60 according to Axel's limit of total 60
connection) in serial succession would cause my IP to be considered a
DoS right?

The behavior when using "yum upgrade" is different. When I use yum to
upgrade mythtv-suite, every time yum downloads a header or package, an
additional line is created in the netstat output.  The CLOSE_WAIT
lines are files that have been downloaded. The ESTABLISHED line is the
current download. The files are being downloaded sequentially, but
prior download connections remain.

# netstat -pan | grep 130.133.35.8
tcp        1      0 192.168.123.15:42177        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        1      0 192.168.123.15:42178        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        1      0 192.168.123.15:42189        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        1      0 192.168.123.15:42190        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        1      0 192.168.123.15:42191        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        1      0 192.168.123.15:42196        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        1      0 192.168.123.15:42197        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        1      0 192.168.123.15:42198        130.133.35.8:80
     CLOSE_WAIT  9950/python
tcp        0      0 192.168.123.15:42199        130.133.35.8:80
     ESTABLISHED 9950/python
...etc....

The above is when yum is running. After yum has completed, everything
goes into LAST_ACK:

# netstat -pan | grep 130.133.35.8
tcp        1      1 192.168.123.15:42177        130.133.35.8:80
     LAST_ACK    -
tcp        1      1 192.168.123.15:42178        130.133.35.8:80
     LAST_ACK    -
tcp        1      1 192.168.123.15:42189        130.133.35.8:80
     LAST_ACK    -
tcp        1      1 192.168.123.15:42190        130.133.35.8:80
     LAST_ACK    -
tcp        1      1 192.168.123.15:42191        130.133.35.8:80
     LAST_ACK    -
tcp        1      1 192.168.123.15:42196        130.133.35.8:80
     LAST_ACK    -
tcp        1      1 192.168.123.15:42197        130.133.35.8:80
     LAST_ACK    -
tcp        1      1 192.168.123.15:42198        130.133.35.8:80
     LAST_ACK    -
...etc...


The machine is running CentOS 5 and sites behind a Linux firewall
(CentOS 4.5, firewall rules created using firehol)

Can anyone explain why there is different behavior between wget and
yum? And if this is indeed a problem with something filtering out the
FINs from my system, can someone instruct me as to where I should look
next?