This is an IE browser problem. Normal browsers don't send RST after the connection has ended. On Mon, 2003-06-30 at 16:29, Ramin Dousti wrote: > On Sun, Jun 29, 2003 at 07:22:13PM -0700, Michael wrote: > > > What would you like me to confirm? That it's broken? It is broken. That > > the RST sending port is not the same as the initiating SYN port? It is > > not; it's low, just above 1024, so I assumed it to be > > netfilter-generated, whereas the Squid port was in the 30000 range. That > > my rule set isn't sending it? "I have no reject-with-tcp-reset lines in > > my tables." Don't know what else you could mean. > > What I mean is this: > > squid: ip1:port1 > webserver: ip2:80 > > Then what you say is: > > packet1: ip1:port1 -> ip2:80 (SYN) > packet2: ip2:80 -> ip1:port1 (SYN ACK) > packet3: ip1:port2 -> ip2:80 (RST) > > What I'm saying is that the third packet should not be able to tear down > the connection between ip1:port1 <-> ip2:80 just because the ports are > different. The TCP stack on ip2 should discard this RST packet... > > Again, my question: > do you see any other packets between ip1:port1 <-> ip2:port2 after the RST > packet? > > Ramin > > > -- -- Raymond Leach <raymondl@xxxxxxxxxxxxxxxxxxxxxx> Network Support Specialist http://www.knowledgefactory.co.za "lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import" Key fingerprint = 7209 A695 9EE0 E971 A9AD 00EE 8757 EE47 F06F FB28 --
Attachment:
signature.asc
Description: This is a digitally signed message part
