[ATrpms-users] dl.atrpms.net connection problems
Karl Grindley
karl at spacechimp.net
Sat Nov 10 15:59:33 CET 2007
Another IP blocked? Note that I haven't hit atrpms in weeks, until this
morning to find atrpms dropping packets. (from 71.174.103.34)
Karl
Axel Thimm wrote:
> 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.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> atrpms-users mailing list
> atrpms-users at atrpms.net
> http://lists.atrpms.net/mailman/listinfo/atrpms-users
More information about the atrpms-users
mailing list