On Thu, 13 Dec 2001, Matt Kowske wrote: > > > > 1. (B) --> ACK/FIN --> (A) > > 2. (B) <-- ACK <-- (A) > > 3. (B) <-- ACK/FIN <-- (A) > > 4. (B) --> ACK --> (A) > <snip> > > I think this means that your side is dropping the packet when > > it gets to step #3 "(B) <-- ACK/FIN <-- (A)" of the TCP > > tears down process. > > > > Does this make sence? > > > > Yes, that makes sense.. but I don't understand why it would not then be > associated with a connection. If the packet is being dropped at (3), > then it should still be an established connection because I have not > sent the final ACK packet to the server, right? I think we would need to see what your side sent before that last package you recorded. For example, did your side sent an packet there with an RST flag? The thing is that as far as I know RST are not ACK. This is why I am not sure that this is the case, but is just a thought. In that case (when you send and RST, maybe because a bad connection or delayed transmission) the server should not respond with 3. (B) <-- ACK/FIN <-- (A). >I found it difficult to reproduce these logs too, so it must not >be a consistent thing. Is this happening with other services? The ones you sent were all port 80 (on the server side) related. > The connection being made to tgftp.nws.noaa.gov is not via a web > browser, but apparently it is the site gweather uses to contact and > update it's weather information. gweather is a gnome applet I use on my > desktop. Perhaps there is something buggy with it's code not closing the > connection properly? > > -Matt It does not look to me that iptables rule itself is at fault, and no one has posted saying that is a bad rule. Also, you wrote that it does not seem to affect your web surfing. This would indicate to me that yes, "Perhaps there is something buggy with it's code not closing the connection properly". Regards, ::dc:: David Correa RHCE CCNA _ _ _ _ _ _ _ _ ___ ____ ____ _ _ tech@linux-tech.com | | |\ | | | \/ | |___ | |__| http://www.linux-tech.com |___ | | \| |__| _/\_ | |___ |___ | | ------------------------------------------------------------------------ To unsubscribe email security-discuss-request@linuxsecurity.com with "unsubscribe" in the subject of the message.
