On Mon, 21 Jun 2004, Dinesh Nair wrote:
> On Mon, 21 Jun 2004, Adam Nellemann wrote:
> > Filip Onkelinx wrote:
> >
> > > It looks like this is only happening using I.E. , did you try with any
> > > other browser (Mozilla FireFox, Opera, ...) ? I suspect your problem is
> > > related to the way IE handles persistent (trying to keep persistent
> > > connections open as long as possible , or opening too many simultaneous
> > > connection threads)
> >
> > (See my previous post in response to Joey Morin.)
> >
> > Still sounds like it must have been introduced when that connection
> > (or whaterver) limit was imposed on mini_httpd, but what do I know?
>
> i wrote the patch to mini_httpd to return a 503 http error (server
> overloaded) when the connection limit is reached. iianm, manuel has set
> the web server to max 8 simultanoues connections in the normal webgui and
> 16 in the captive portal.
Is it possible that the path where the code is diverted to the error is
failing to reclaim some resources?
On Tue, 22 Jun 2004, David Kitchens wrote:
>
[...]
> I have just hammered it with Firefox .08 and I cannot kill the GUI with it.
> Went back to IE and could not make it down the list before getting locked
> out again. This is using IE6 SP1, and I suspect it could be a browser issue
> but for the life of me can't figure why the GUI would respond any different
> using one or the other.
Sure it could, if the way the browser manages connections is different.
This gets especially "intersting" with HTTP/1.1.
I certainly *don't* think it has anything to do with the User-Agent
string. :-)
On Wed, 23 Jun 2004, Dinesh Nair wrote:
> On Tue, 22 Jun 2004, David Kitchens wrote:
>
> > I lost all connectivity to the GUI. Now all I get is "Cannot find server"
> > yet I still have access to outside pages and mail still seems to go thru
>
> the next time it hangs, try the following:
>
> 1. telnet to the m0n0wall ip address, port 80
> "telnet m0n0_ip_address 80"
> 2. enter "GET /status.php HTTP/1.1 Ok" (hit enter twice)
> 3. let me/us know what the output says
When I do this sort of thing, I do two things differently:
1) I specify HTTP/1.0. This avoids all the issues about whether to keep
the connection open or not, since HTTP/1.0 is required to close the
connection to report "end of file".
2) I use HEAD rather than GET, so that you only get a modest-sized
response no matter what. However, it appears that mini_httpd treats the
two the same, at least in the unauthorized case, which is completely in
violation of RFC1945. From section 7.2:
"All responses to the HEAD request method must not include a body, even
though the presence of entity header fields may lead one to believe they
do."
On Wed, 23 Jun 2004, zealot wrote:
> Dinesh Nair wrote:
>
> ------8<------8<------8<------
> > just to check, you're not running the HTTPS WebGUI right ? you'd need to
> > be running the normal HTTP WebGUI for telnets to port 80 to work. and m0n0
> > doesnt need a telnet daemon, you're trying to connect to port 80 of the
> > m0n0 which is the web HTTP port.
> ------8<------8<------8<------
>
> Something I failed to mention in my email message yesterday: I too
> browse m0n0wall using HTTPS rather than HTTP. This may be relevant to
> see if there's a pattern to httpd dying.
Apparently not, although it certainly affects whether telnetting to port
80 will work. :-)
Telnetting to port 443 would be of limited value unless you have a telnets
(SSL telnet) client, though it would be able to determine whether there's
a listener alive. Lacking telnets, the OpenSSL s-client command would be
better.
It's not clear to me why the HTTP/HTTPS choice is exclusive. There's no
reason in principle why you couldn't have it both ways.
On Wed, 23 Jun 2004, David Kitchens wrote:
>
> I do normally run in https mode but I turned it off and made it hang again,
> took a little longer to make it hang in http mode. When trying to connect, I
> get the same connection refused error as before. Rebooting mono and
> attempting telnet again connects and sits there with a blinking cursor,
> finally times out. If I try your command before the timeout, I get this,
>
> HTTP/1.1 Ok 401 Unauthorized
> Date: Wed, 23 Jun 2004 18:05:57 GMT
> Cache-Control: no-cache,no-store
> WWW-Authenticate: Basic realm="."
> Content-Type: text/html; charset=%s
> Connection: close
>
> <html>
> <head><title>401 Unauthorized</title></head>
> <body>
> <h3>401 Unauthorized</h3>
> Authorization required.
> </body>
> </html>
> Connection to host lost.
Although "lost" is a poor description, this is the appropriate point for
the connection to be closed.
> If I try to login at the blinking cursor, I get this,
First of all, you don't "login" to an HTTP server in that manner.
Secondly, the connection should be closed at that point, so your not
talking to anyone. An ordinary telent client should have exited here.
> (null) 400 Bad Request
> Date: Wed, 23 Jun 2004 18:12:56 GMT
> Cache-Control: no-cache,no-store
> Content-Type: text/html; charset=%s
> Connection: close
If you're really doing this without opening a new telnet connection, you
must have some weird telnet client with some kind of "auto-reconnect"
feature or something. Or maybe you're just running on an NT/2K/XP system
(see below).
On Thu, 24 Jun 2004, Dinesh Nair wrote:
> On Wed, 23 Jun 2004, Chet Harvey wrote:
>
> > not knowing enough under the hood of mini_httpd is there a session state
> > variable that can be modded?
>
> afaik, mini_httpd doesnt keep session states. and in all cases, once a
> connection is handled (either by returning the output of the php script,
> gif/jpeg image or html file), the connection is close(2)d. IE should not
> be having established sessions.
Well, "sesion state" and "connection state" are different. Unlike
HTTP/1.0, HTTP/1.1 permits multiple transactions in a single connection,
so it's commonplace for HTTP/1.1 browsers to keep at least one connection
open across transaction boundaries.
> i do know however that IE will pull a dirty trick of not going thru a
> proper TCP 3-way handshake if it detects an IIS as the web server it's
> connecting to. could IE be misdetecting mini_httpd as IIS and thus somehow
> borking the tcp state of mini_httpd on m0n0wall ? (it's highly unlikely,
> but it's also 3am here and i'm a little groggy)
It has no way to know that before it connects. :-) So it just tries it to
see what happens. It also appears that it isn't really the browser that
pulls this stunt, but rather the NT (/2K/XP?) *stack*. See:
http://grotto11.com/blog/slash.html?+1039831658
Particularly the note at the bottom. And although it doesn't say so, the
server-side issue may be more that fact that the it's running on an NT
system than the fact that it's IIS.
Fred Wright