117409 - Unable to log on to Cisco VPN3000 device

Status: RESOLVED INVALID

(Core :: DOM: Events, defect)

Description

[Norbert Kiesel]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20011226
BuildID:    2001122611

When accessing the build-in web pages of Cisco VPN 3000 devices (formally Altiga
VPN 3000), you first get a login page asking for username and password.  After
logging in, you get a cookie "LoginTime" which must be passed back to the device
for all subsequent pages.

mozilla drops the value of the cookie (i.e. sends "LoginTime=;") which results
in a reply of the login page again.

Reproducible: Always
Steps to Reproduce:
1.login w username/passwd
2.click on ""


Actual Results:  back to login page

Expected Results:  the requested page

see attached ethereal dump

Comment 1

[Norbert Kiesel]

Attachment: ethereal tcp stream dump

login/password x'ed out

Comment 2

[Stephen P. Morse]

Obviously I can't reproduce this because I don't have the Cisco router.  So the 
best I can do is analyze the attached http traffic.

From the traffic I see the following request:

   POST /index.html HTTP/1.1
   Cookie: LoginTime=;

OK, something happened prior to this post (not shown in the traffic) that set a 
cookie to a null value.

The next response has

   Server: Agranat-EmWeb/R5_0_0
   Set-Cookie: LoginTime=1009689248

which means that now the router is setting the LoginTime cookie to a non-null 
value.

On the next request I see

   GET /menu-init.html HTTP/1.1
   Cookie: LoginTime=1009689248;

which shows that the browser is sending this cookie to the router.  This is 
true on all future requests as well.

So cookies seem to be behaving properly.  What point am I missing?

Comment 3

[Norbert Kiesel]

Hi,
I'll try to make this router accessible for you (just have to get to the office
to change the login filter).  Basically, the sequence is:
1) Mozilla sends POST /index.html LoginTime=;  ==>  new login for
login/password/logintime in parameters
2) router responds with OK, /index.html and LoginTime cookie set
3) Mozilla sends GET /menu-init.hmtl LoginTime=1009689248; => all ok, Mozilla
starts reading additional parts of the index page, cookie set
4) router responds with OK and LoginTime cookie set
5) Mozilla sends GET /config.html LoginTime=1009689248; => all ok, Mozilla
starts reading additional parts of the index page, cookie set
6) router responds, LoginTime cookie set
7) Mozilla sends GET /img/save-needed-text.gif LoginTime=1009689248; => all ok
8) router responds (with GIF), LoginTime cookie *not* set
9) Mozilla sends GET /config.html, LoginTime cookie set but value empty
10 router responds with login page because cookie is not set

The problem seems to be that in step 8, the router sends the image without the
cookie, which forces Mozilla to drop the cookie in step 9.  It might very well
be a bug in the router, but NS-4.7x and IE-5+ seem to treat this differently,
they continue sending the cookie in step 9.  My understanding of the cookie
protocol is that ths cookie should be send to the router during the whole
session unless the cookie is changed by the router.  Now the router does not
resets the cookie in step 8, it just does not send it.  Why is Mozilla then
clearing the cookie contents in step 9?

BTW, this was a complete ethereal dump, there was nothing dropped.  The router
never sends a "clear cookie".

Comment 4

[Stephen P. Morse]

> I'll try to make this router accessible for you (just have to get to the
> office to change the login filter).

Let me know when that happens and tell me how I can access it (URL?).  As soon 
as I get this information I'll investigate further.

> this was a complete ethereal dump, there was nothing dropped.  The router
> never sends a "clear cookie".

There had to be something more to it than that.  How else did the cookie get 
there in the first place.  Maybe from a previous session?  In that case you 
should start the test with a fresh profile, or at least with all cookies flushed 
first.

Comment 5

[Norbert Kiesel]

Hi,

thanks for the fast reply,  I'll be in the office in about 3 hours and will send
you the URL.

The one thing missing form the trace is the very first login page, but it
basically looks like the last page send from the router. The protocol is that
there is a hidden input field in this login page named "logintime" which is send
back by Mozilla together with login and password (very first HTTP POST).  The
router apparently reads this value and sends it then back as the value of the
cookie "LoginTime".  For subsequent messages, it always expects the cookie to be
set to that value (and uses it for auto-logout etc.).  As soon as it gets an
message from the browser without the correct cookie value, it replies with the
login page.

Comment 6

[Olivier Cahagne]

I work at Cisco, I'll also check our internal bug database and check Mozilla
with a Cisco VPN3000.

Comment 7

[Norbert Kiesel]

Ok, the router should be accessible from the internet
IP address: 209.66.77.48
login: user
password: user

then click on e.g. "configuration".  You will get a page basically saying that
you are not allowed to do any changes, but you can expand the Javascript menu. 
Actually you can't because Mozilla gets cicked out as soon as you click on one
of the links.

Comment 8

[Stephen P. Morse]

From Mozilla, from Nav4, and from IE I get the message "Invalid login or session 
timeout" when I press the login button with username and password set to "user".

Comment 9

[Norbert Kiesel]

I changed the access control list in the router.  Could you please try again?

Comment 10

[Stephen P. Morse]

Here's the traffic that I am seeing starting from the point at which the user 
clicks on the "configuration" link.

1. HTTP request: contains cookie LoginTime=1009767778;

2. HTTP response: contains page with the following javascript:

      if (top == self)
      {
         top.location = "/index.html"
      }

<< Obviously top==self above because we then make another request >>

3. HTTP request: contains cookie LoginTime=1009767778;

4. HTTP response: contains page with the following javascript

      document.write("<frameset border=0 framespacing=0 frameborder=0
                     bordercolor=white rows=\"70, *\"
                     onUnload=\"killCookie()\">")

      function killCookie()
      {
         document.cookie = "LoginTime=; ";
      }

<< so that's where the cookie is getting cleared >>

Bottom line:

I see nothing here to indicate that cookies are not behaving properly.  I do 
observe that we are bounced out of the page at step 4 under the mozilla browser 
but not under the N4 browser or the IE browser.  I do not know what is causing 
that, but it is definitely not cookies.

Comment 11

[Norbert Kiesel]

Yup, is seems that somehow Mozilla runs this killCookie() function.  Should I
resubmit this bug under a new component or will you try to follow up?

Comment 12

[Stephen P. Morse]

Not cookies.  Reassigning to networking component.

Comment 13

[Stephen P. Morse]

Really reassigning this time.

Comment 14

[Matthias Versen [:Matti]]

confirming based on the comments..

Comment 15

[Doug Turner (:dougt)]

over to darin.

Comment 16

[Olivier Cahagne]

The VPN3000 running on 209.66.77.48
 seems to be 2.5.2F.
3.1 Release Notes mention Netscape 6 is now supported in
http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/3_1/3kcon_rn.pdf

I'll check a VPN3000 device soon.
However, it remains to be seen if this is truly a Mozilla bug (the onUnload()
thing).
This comment is not meant to solve the bug, but I add it as a memo. :)

Comment 17

[Olivier Cahagne]

I forgot the bug number is identified in the Cisco bugs database:
 (you need a CCO login to access this, you can have one if you're a Cisco
partner, customer, etc.).
However, this bug is identified and fixed in VPN3000 v.3.5 (and fix seems to be
backported on the 3.1.x  branch):
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdt07783

So, I believe this was not a bug within Mozilla but from Cisco VPN3000. Should
we mark this bug FIXED ?
Reporter, you might want to upgrade your VPN3000.

Comment 18

[Darin Fisher]

-> [e-mail]

Comment 19

[Norbert Kiesel]

I'll try with a 3.5 version and report status (although this does not solve my
initial problem as i have to work with older VPN3000 OS versions).

Comment 20

[mrroach]

After seeing this thread, I updated my conecentrator to version 3.5 last night
and it still kicks me out to the login screen. (running moz 0.9.7)

-mark

Comment 21

[Vinay Badami]

Unable to connect to this site. Can u please make sure that the router is still
accessible on the internet ?

Comment 22

[Vinay Badami]

Reporter,
Can u please give me access to this site from the internet ?

Comment 23

[Norbert Kiesel]

Hi,

I added it again (209.66.77.48, user/user)

I also tested with VPN3K version 3.5, but this also does not work.

Thanks for your help.

--nk

Comment 24

[Vinay Badami]

This is a result of the UnLoad handlers firing. Nothing to do with networking.
Changing component to DOM Events.
Assigning to [e-mail] 

Comment 25

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Hmm, if this was a bug in the router software that is now fixed I see this as
pretty low priority. Are there lots of routers stuck with old software?

Looking at the client/server traffic, it would seem Mozilla was doing the right
thing in clearing the cookie (onunload -> killCookie()). Or was Mozilla doing
this too early? Do IE & NS 4.7 do it later, or do they have a bug and never
trigger onunload? Does document.write() confuse things somehow?

Over to DOM Events owner.

Comment 26

[Norbert Kiesel]

Hi, some remarks from my side:
1) Yes, there are lots of these routers out there
2) The problem is still there even with the latest VPN3K OS release (3.5.1)
3) I don't know when the unload trigger is supposed to fire, but it happens only
in Mozilla, not in NS4, IE5, or Konqueror
4) if this is a Cisco bug: is there a possible workaround which forces Mozilla
not to fire the unload? I really hate to boot up windows and run IE to configure
these boxes (konqueror has some HTML rendering problems, so it's not a real
alternative).  I might try Opera...

5) Thanks for all your help!  Mozilla rules!

Comment 27

[Norbert Kiesel]

May I ask about the rationale for moving the target milestone?

Comment 28

[Charles Bronson]

My UA: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826
VPN3000 software: v3.6

This bug is still occuring. I get to the login page, enter my credentials and
get in no problem. I select config and the config page comes up for less than 1
second then the previous page is immediately displayed, it is up for less than 1
second and then I am pushed back to the login page.

Comment 29

[Vladimir Ermakov]

That IP address is no longer working, is there a new one?

Comment 30

[Norbert Kiesel]

Hi.
I set up another VPN3K with IP address 63.209.25.106
Log in as user "user" with password "user".  Then click on "Configuration" in
the main screen.  Under IE, you get an "access denied" page (which is correct
because I set up this user to have no access to anything (it's a production
router)), but
Mozilla goes into an endless loop.

Please be careful because apparently Mozilla - while looping - starts eating
sessions on the router, so it might be that you can't login again.  If this is
the case just wait for 5 minutes until the sessions timed out.

Comment 31

[Olivier Cahagne]

Please upgrade to v.3.6.6, this should finally be fixed in this version, see
release notes:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/vpn3000/366con3k.htm#xtocid54
and the associated DDTS:
http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCdx87630

Comment 32

[Vedran Miletic]

retargeting

Comment 33

[Olivier Cahagne]

anyone still experiencing this with VPN 4.0.x (or 4.1.x) and Mozilla 1.7 (RC) ?

Comment 34

[Wayne Mery (:wsmwk)]

(In reply to comment #33)
> anyone still experiencing this with VPN 4.0.x (or 4.1.x) and Mozilla 1.7 (RC) ?

apparently not.
per comment 31 it should be fixed and it's not moz's problem per comment 17, so INVALID.