Closed Bug 162875 Opened 22 years ago Closed 19 years ago

Possible error in TCP system?

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED EXPIRED

People

(Reporter: digital56k, Assigned: dougt)

References

(
URL
)

Details

(Keywords: qawanted) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020807
BuildID:    2002080713

I am using Kerio Personal Firewall 2, and my firewall log is littered with TCP
ACK attacks from numerous webservers which I regularly visit and know to be safe
machines. These all originate from port 80 on the target machine, which is of
course the HTTP service.

Is it possible that at the end of a TCP session (ie downloading images on a page
for example) that the Mozilla subsystem responsible is not waiting for the final
ACK to be received in the packet stream before closing the socket?

If so, this could lead to transfer errors in the last TCP packet, and erroneous
alarms on various firewalls.

Reproducible: Sometimes
Steps to Reproduce:
1. Use Kerio personal firewall (free for personal use)
2. Set it to "Log Packets Addressed to Unopened Ports" and "Log Suspicious Packets"
3. Use Mozilla for a while on a slow (i.e. dialup) connection. It appears as if
Mozilla does not always wait for the last ACK in a TCP sequence to be received
before closing the port. (Or at least this is the only explanation I can see).

Actual Results:  Firewall alerts in the log file for numerous known-safe webservers.

Expected Results:  Waited for the last ACK
Darin: what do you think?

I can do a trace, once I finish this next round of testing (give me a couple
days...)
Keywords: helpwanted
need to see a full packet trace i think.
I have seen sometning similar to this behaviour for a long time.
Since mozilla 1.0 infact.
I was seeing this on Agnitum outpost firewall. on Win98.
I assumed it was a windows networking issue.

I can't give more details right now as I'm using Linux.
If you would like further details, just ask.

I've been noticing another issue I believe to be related to this one (at the
same URL). At the bottom of the browser, Mozilla says its "downloading from
images.divx.com", seemingly forever, until I click Stop or click another
hyperlink.  The image it is downloading is never actually complete/displayed.

However, (and this is the important part), My firewall status window which lists
all open sockets and connections by all running processes shows that Mozilla has
close all its sockets.

This would indeed point to the fact that Mozilla is closing sockets before the
message sequence is complete, and thus why the image doesn't load completely and
which the browser says it is "downloading from images.divx.com" indefinately.
2 notes-

I've tested this with settings reduced to HTTP1.0 and no keep-alive, after
clearing the browser cache, and the problem continues. Also the problem is not
limited only to image resources. http://forums.divx.com seems to be the best
site I can find to reliably re-create the problem.
What you're seeing is (I'm guesiing here, without a packet-trace), ACK's that
arrive after the file has been closed. That's perfectly normal, and it can be
caused by a slow connection. Mozilla might have decided to close the connection
when there are still packets on the wire, and it's possible that an ACK arrives
(even in sequence), when the connection is already closed. You see it quite
often on networks with huge latencies (satellite networsk for instance).

PS : I really know I'm talking about : I work for Alcatel (but can't tell you
what I'm doing), and I meet similar things almost daily. Most bug-reports come
from unexperienced operators, or from ISP's that use cheap firewalls. A good
firewall will not report those ACK's for a while after the connection has been
closed (during lingering time). A lost packet is a pretty normal thing,
especially in large networks.

The only thing Mozilla can do here, is NOT to close the connection immediately
after the connection has been abandonned, but to keep it alive for a little
while (not the full 120 seconds, 10 seconds should be ok), so it can 'absorb'
those lost packets. It's like you would implement your own lingering-state. It's
a stupid trick, but I had to use it too on one of my applications, just to
prevent those operators from filing meanlingless reports.

I don't want to seem too harsh, but I hate to see those personal firewalls,
because they report innocent things too easily. 2 Weeks ago we had a
hacking-investigation by the Belgian police, because some complained that his
Alcatel ADSL-modem was attacking him. After investigation of his logs, we found
that an f*cking ARP-packet was sent from the router to his pc (a single one !),
and the firewall logged this as an attack. How stupid can you get ? Yeah, a 3
hour investigation in the Police HQ, where I had to explain what ARP was, and
that it wasn't used by a terrorist organization. I'm not joking.

This doesn't mean that a firewall can't report a DNS-attack, when it receives
hundreds of ARP-requests per second ofcourse, but a single one ? And it wasn't
even ARP-spoofing, the router just wanted to verify the MAC-address of the PC.
No offense or anything, but under TCP all ACKs for a socket should be received
to ensure the data transfer has succeeded, surely..

And how would you explain the other *nearly consistant* bug I've reported in
this same bug ID? Where Mozilla believes it is still downloading data
indefinately, but the firewall quite clearly shows Mozilla has closed all of its
sockets?
What I was saying is that's perfectly legal to close a socket while you're still
waiting for ACK's. That's what the lingering state is all about, but that's also
what the firewalls are reporting (who should ignore it). Some routers (ahum)
actually use this information to measure latency without really examining the
data-stream (virtually impossible on multi-gigbit routers). They often try to
drop those packets, to help the clients (bandwidth).

It's the TCP/IP stack of the host-OS that is responsible for acknowledging and
processing ACK's, and for swallowing them after the connection has closed
(lingering state). Don't blame Mozilla for that. It's perfectly normal. It's
atcaully impossible to get ntofied when those ACK's arrive, or to anything with
them.

I don't see any problem here, except some behaviour that I see every day on very
busy and large networks (large latency, lost or delayed packets). In my opinion,
the firewall is wrong to report an ACK-attack (if there is such a thing - it
would take dozens or hundreds of packets to speak of a real attack).

This is not to say that you can help the situation a little bit, by waiting a
little while to close the socket after the communication has stopped (and don't
use shutdown either). In other words : a delayed close. That's a trick what I've
used before (it also helps performance if you're closing hundreds of sockets a
second), but it's still a trick.

BTW : I see that you're reporting this on Windows 98. Need I say more ? TCP/IP
sucks big on Windows 98.
No other software on my system produces this kind of problem, need I say more? :P
What you're seeing, is that Mozilla probably closes a connection immediately
after writing some data. That's not illegal, it's just a wasteful. Maybe a
packet-trace can show what's really going on.

My immediate guess is that it has something to do with HTTP/1.1, pipelining
and/or keep-alive. But you already tried to switch that off.
if someone can generate a tcpdump of the mozilla/firewall interaction that would
be very helpful.  thx!
helpwanted is not for bug submissions anymore.
Keywords: helpwanted
Darin: if you want a packet trace before you assign this bug, I'll put this on
my list of things to do (but it will be pretty far back).
benc: yes, we need to see a packet trace.  if any of the folks cc'd can produce
one that would be great too.  thx!
If someone can suggest a tcpdump program for Win98, 
I'll be willing to try this.
But, you'll have to wait till I start up Win98 again...
I can give no gaurentees as to when this might be!
rob: perhaps www.ethereal.com, maybe??  i've used it on win2k, so i'm not sure
if works on win9x as well, but maybe ;-)
per bug 181135: all bugs owned by previous default owner that were not futured
are being reassigned to default owner.
Assignee: new-network-bugs → dougt
TCPdump needed.
Keywords: qawanted
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.