In the past I have noticed two branches of the problem:
1. port 8001 is dead (i.e. there is no process running). Port 8000 is
still alive (thanks for clearing up what it does.)
2. port 8001 is alive but is not accepting the redirect (i.e. the user gets
an error message that the fqdn:8001 isn't there...sorry I didn't log the
exact error message yet.)
Number 2 happened (pun ... lol) this morning when I logged into it and I
hadn't seen your email. I will put a truss on 8000 and 8001 and wait for it
to fail again.
As for the netstat -an ... that was probably the first thing I checked...to
see if there was a daemon listening on the stack. then a ps auxww to nail
More to follow soon...
Thanks for the time to assist.
From: Manuel Kasper
To: Burkhart, John T.
Cc: m0n0wall dash dev at lists dot m0n0 dot ch
Sent: 6/12/2005 3:23 AM
Subject: RE: [m0n0wall-dev] Unstable mini_httpd for captive portal
On 09.06.05 16:33 -0700, Burkhart, John T. wrote:
> ps auxww showed 2739 as /usr/local/sbin/mini_httpd -S -a -M 0 -E
> /var/etc/cert-portal.pem -u root -maxproc 16 -p 8001 -i
> This happened after pid 2739 died...after the process died a new one
> appeared....pid 3106.
> $ cat /tmp/truss.log
> SIGNAL 15
> SIGNAL 15
> SIGNAL 15
Thanks for the truss output, John! I can't see anything out of the
ordinary in it - except of course for the fact that mini_httpd
received a SIGTERM, which it dutifully obeyed. For the life of me I
can't figure out what could possibly be sending it that TERM signal,
since the only way to restart the captive portal (thus
killing/restarting mini_httpd) is through manual action in the webGUI.
You say that a new process appeared after the old one died - so that
would mean there was a mini_httpd around, but not accepting
connections? What does "netstat -anf inet" say in that case?
Also, note that when the captive portal is in HTTPS mode, there are
two mini_httpd daemons running: one in HTTP mode on port 8000 (to
intercept outgoing HTTP connections by non-authenticated clients),
and one on port 8001 (in SSL mode). Could it be that the port 8001
mini_httpd is working OK, but instead the one on port 8000 is
misbehaving? (of course that wouldn't explain the SIGTERM) - You can
check that by trying to load https://<m0n0wall-addr>:8001/
In that case, some truss output on the port 8000 mini_httpd would be