Closed Bug 82728 Opened 20 years ago Closed 13 years ago

InfoExpress' VSClient Universal (VPN), when disconnected or dies, causes mozilla to hang


(Core :: Networking, defect, P3)

Windows NT





(Reporter: gileadis, Unassigned)


(Keywords: hang)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010524
BuildID:    2001052404

I use a VPN connection, using the VSClient Universal 4.33, by InfoExpress, Inc.
 Sometimes that connection dies.  Whenever it does, it causes Mozilla to hang
badly; the process cannot even be killed using using End Process in the NT Task

The unkillable process continues to use large amounts of RAM; it dropped from
around 45 meg to 33 or so, but doesn't drop much more.

This problem has been around for a long time; I didn't report it since who uses
VSClient for VPN (other than Sybase employees)?  However, other apps I've tried
don't seem to hang when the connection dies, although IE usually needs
restarting to re-see the Internet.  Some apps, including Java ones, aren't even
phased when the connection dies--they just keep on chugging.

In any case, a hang this bad (unkillable process) certainly needs a bug.

Reproducible: Always
Steps to Reproduce:
1. Start up the VSClient VPN connection (I don't know if this happens with other
VPN connections or not).
2. Start up Mozilla; browse at will
3. Wait for the VPN connection to die
4. Try to close Mozilla, stop its current page from loading, whatever.

Actual Results:  Mozilla can be end-tasked, but its process doesn't disapper in
the Task List, and it continues to use large amounts of RAM

Expected Results:  Ideally, Mozilla should continue operating without problems.
 At the very least, an end-task should kill its process.
Keywords: hang
Marking NEW.
Ever confirmed: true
Keywords: qawanted
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3

Much worse than my report about Netscape's VPN. Please do NOT dupe, I want this
to stay separate
Keywords: qawanted
Summary: Hang when my VPN connection dies → Conn: Hang when my VPN connection dies
benc, can you reproduce this?

can you give me more technical information about you VPN clinet?
I'm not familiar with VPN protocols, and I'm not sure what you're looking for,
so I found this site with documentation on the product:

Once I'm connected, the client says Triple DES, MD5, Active.  I don't know what
that means :)

More info: After more experiences with this bug, it turns out that the hang ONLY
occurs if the VPN connection dies while the page is loading.  If the connection
dies while mozilla isn't loading anything, and then I try to load something, it
works fine.

So the bug lies in the fact that when mozilla starts loading something, it never
times out, to the point that it causes the unkillable hang.

VSClient seems to use the remote host's DNS lookups once I'm connected, and that
may be the point where we're hanging.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.8
Reporter: is this still a problem?
Target Milestone: mozilla0.9.8 → mozilla1.0
Unfortunatly I am unable to test this any more, since I have since finished my
contract with Sybase and they took back the laptop and VPN software that they
loaned to me.

If the same kind of hard hang (couldn't even close it using the NT Task Manager)
has been fixed in some other bug, then perhaps this one has been fixed as well;
in any case, you'll probably need to close this bug for lack of verification.
This bug can no longer be reproduced per commnets above.
Closed: 20 years ago
Resolution: --- → INVALID

There were some reported problems of in Windows when the DNS list changed.

I don't think anyone has tested or reported with trashing the physical
connection while something is loading. I've been meaning to add something like
that to my tests.
We at Kontiki use VSClient and hit this bug all the time. It's easy to 
reproduce: Just:

- establish a VPN connection
- run mozilla (1.4b) and retrieve your mail from a mailserver inside the 
firewall (this opens a connection to the mailserver)
- disconnect the VPN
- mozilla will hang next time you try to retrieve your mail -- must reboot to 
get it back.

Note that this hang is not dependent on mail, and can happen in general for any 
open connection (e.g. fetching a page), it's just that mail is the surest way 
to reproduce.

Workaround: Always be sure to go offline before disconnecting VPN.
Resolution: INVALID → ---
P.S. Our application has this same bug. We use nspr, and see that PR_Connect is 
hanging in the Windows kernel when this bug happens.
-> defaults
Assignee: neeti → darin
Target Milestone: mozilla1.0 → ---
This is a me too! It's really annoying. Have to reboot to get Mozilla to work.
(Otherwise you get a profile in use when you try to restart)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030718 on WinXP and
VSClient Universal 5.1a
I've tightened the summary because it seems to be product specific (3 reports
using VSClient). I've never had hangs when I used a VPN product at Netscape/AOL.

In theory, a VPN product should simply effect a network change, which gives a
system a new IP address, and breaks the current connections. Mozilla is not
completely graceful when this happens, (people do this all the time), but there
are not many other reports of hangs.

Summary: Conn: Hang when my VPN connection dies → Conn: VSClient (VPN) hangs when disconnected
Assignee: darin → nobody
QA Contact: benc → networking
Warren, do you still see this?

Dave Gileadi (reporter): "it's been quite a while since I've had this VPN client available to test with--I work for a consulting firm, and have since moved on to other clients and projects, losing both the software and the login credentials in the process."

[dave, poster from 2003-08-15, email bounces]

may be related to bug 327050 or bug 213637
Summary: Conn: VSClient (VPN) hangs when disconnected → InfoExpress' VSClient Universal (VPN), when disconnected or dies, causes mozilla to hang
seems likely to have been bug 213637
Closed: 20 years ago13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 213637
You need to log in before you can comment on or make changes to this bug.