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

[Axel Thimm]

On Thu, Nov 08, 2007 at 10:58:33AM -0500, Steve Hsieh wrote:
> 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   -

TIME_WAIT is described as

       TIME_WAIT
              The socket is waiting after close to handle packets still in the
              network.

I wonder what packets that should be if the application has already
assembled the tcp/ip stream and has finished.

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

I'm not sure if that's true, have you tried two wget in succession?
Are there really two sockets in TIME_WAIT then, or is there only one?

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

CLOSE_WAIT is described as

       CLOSE_WAIT
              The remote end has shut down, waiting for the socket to close.

which in my understanding means that yum has forgotten to close the
socket. yum and CLOSE_WAIT inflation has been a problem in the past
(not an ATrpms one, but a global one, but I thought it had been fixed
since).

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

That's a real non-app issue: You are not getting the final FIN/ACK.

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

I would temporarily remove the firewall (or place the system in front
of it) for testing purposes. Or check the logs for dropped packets
that could be FINs or FIN/ACKs.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.atrpms.net/pipermail/atrpms-users/attachments/20071109/57f44531/attachment.bin