Dispatcher trouble

[jbrovont]

I've noticed a strange behavior under XP Pro (Latest service packs) The dispatcher doesn't crash, but after a period of time (not sure how long) it stops working. It doesn't crash, the service doesn't stop, but clients can't login. Here's my set-up:

Internet -> Firewall/Router -> Firstspot Box -> WRT54G -> Clients connected by wireless

I checked the application log, and there's nothing in there. If I check status on the FirstSpot box, it stops logging people out after their inactivity period - I'm still running the trial version, but it will leave people logged in for hours even after they disconnect. Sometimes I can ping computers on the network between the routers, and sometimes the WAN IP of the router. By sometimes I mean I can send a ping request, and 2 of 5 might make it. I can always ping the public and private interfaces of the firstspot box.

The DNS server sort of dies, and stops resolving names, but the local DNS commands like "logout" still work. Access to computers outside the local net is intermittant if referenced by IP address.

Also, the DHCP server dies, and if a lease expires, computers connected to the network loose their ability to ping/get new addresses. It runs for somewhere between 18-24 hours before this happens. I set windows to auto-restart the service, but because it doesn't really "die," windows won't restart it.

Ability to access the internet from a browser on the FirstSpot box is never interrupted.

The WRT54Gs are set to auto-restart at about 3am. I've sat up to watch them do this, and it doesn't appear to cause the problem. Any ideas?

~Jules

[alan]

Your network is very strange. FirstSpot usually won't fail in several fronts at once. So I suspect something happens to your network, in particular WRT54G. Please:

1) make sure the DHCP server in the WRT54G is off
2) turn off the auto-restart for your WRT54G for the time being as a test

Also, you need to pinpoint the pattern of your problem. Is it a reproducible problem? Or is it a intermittent problem? Note that if the problem is intermittent, you need to find out the pattern and make it reproducible. That way it is much easier for us to give you a accurate diagnosis.
_________________
~ Patronsoft Limited ~

[plescht-bt]

i agree, we have to find a pattern to be able to produce a solution.
BUT: I exypirenced the very same problem on our W2k, SP4 machine:
after a couple of ours firstspot appears to be died.
There is no entry in the W2k Eventlor nor in the logs of firstspot.
It just sticks.
Not even the local configuration UI is working then.
rebooting the machine makes everything working well again.
But for how long?
_________________
Kind regards
Tp..

[jbrovont]

Okay, I'll work on it. I have the DHCP in the router off, and the restart turned off. I just rebooted everything. I'll keep you guys updated.

~Jules

[alan]

plescht-bt, you problem is due to Apache crashes.

Can you post the log under FirstSpot\www\Apache\logs subdirectory when your problem occurs again (please open a new forum thread)?

As a workaround at this moment, you can now write a script to perform "graceful restart" of the Apache server once a while. The command should be like:

apache.exe -k restart
_________________
~ Patronsoft Limited ~

[plescht-bt]

We have installed the FirstSpot agein.
From scratch and out-of.the-box on W2k out-of-the-box also.
Yes, we mentioned that apache craches and that that services was stopped.
Now we have configured apache
to start automaticaly
and to restart the service when it crashes.
I will post the logs, after apache hung again, in a new thread.
Many THanks.
_________________
Kind regards
Tp..

[jbrovont]

With the DHCP and restart disabled in the routers. I restarted everything, and made sure it was working. Everything was fast & functional. In the morning, I logged in from a laptop on a wireless card, and the laptop associated with the access point right away, but firstspot didn't respond with a DHCP address for about 2 minutes. Once it got it, I keyed in www.google.com which is still in my "unrestricted hosts" list from the install. After another couple minutes of page loading, I got a "page cannot be displayed." I did this two more times, and on the third attempt, I got the google home page. I surfed to www.ebay.com and was not challenged to login. After about an hour of being on the internet, FirstSpot asked me to login, so I did. FirstSpot then reported I was already logged in. I checked the status in the FirstSpot control panel and it said I had been logged in since the day before (I have a screen grab of this if you want - I'm still running the beta version.) The MAC address was the MAC of the computer I had been using the night before, so that seemed to work okay. I forced a logout, and then re-logged in from my laptop and surfing worked fine after that. Rather than restart the service again, I left it run over night (2nd continuous night with no restart). In the morning, the system had stopped working.

The application event log is full of the following messages:

"The description for Event ID(3) in Source(Named) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE=flag to retrieve this description; see Help and Support for details. The following information is part of the event:"

Then the above message plus each of the below messages in a seperate entry.

"starting BIND 9.3.1 -n1"

"found 1 CPU, using 1 worker thread"

"loading configuration from 'C:\Program Files\FirstSpot\dns\\etc\named.conf"

"listening on IPv4 interface Loopback Interface 1, 127.0.0.1#53"

"listening on IPv4 interface TCP/IP Interface 2, 192.168.1.2#53"

"listening on IPv4 interface TCP/IP Interface 3, 10.1.1.1#53"

"command channel listening on 127.0.0.1"


The System Log had the following:

"Microsoft(R)Windows(R)5.01.2600 Service Pack 1 Uniprocessor Free"
"The Event log was started"

And then right when the Application events started, the system log shows:

AMLI:ACPI BIOS is attempting to read from an illegal IO port address (0x4d1), which lies in the 0x4d0 - 0x4d1 protected address range. This could lead to system instability. Please contact your system vendor for technical assistance."

3 seconds later:

"The browser has forced an election on network \Device\NetBT_Tcpip_{18C9F410-B19C-4633-ACD9-BE09E0AB87A7} because a master browser was stopped."

"The PatronSoft FirstSpot Dispatcher service hung on starting."


Here's my current server set-up:

PIII 750, 348MB RAM, 12.7 GB Hard Drive, 10.1 GB Free, Windows XP, 1 Linksys PCI 10/100 NIC (public), one DYNEX PCI 10/100 NIC (private)

After the above, I was unable to restart the service, and had to restart the computer. Now it's working again. Could this apache crash behavior have something to do with this?

~Jules

[alan]

Jules, except for the "AMLI:ACPI BIOS" error, most of the errors are fine as far as I can tell. Please check on the "AMLI:ACPI BIOS" error though.

Your machine is bit under-powered to run XP. You might want to run Windows 2000 instead.

Please post your firstspot_gw_srv_[timestamp].log file under FirstSpot\log subdirectory for further analysis.

BTW, your problem may not lie in dispatcher. There are several components (both in Windows and FirstSpot) that can potentially cause your issue.
_________________
~ Patronsoft Limited ~

[jbrovont]

You guys may be fascinated by this one - I got my license key from Karl Ma yesterday about 10am. (Standard Edition) Installed it, got it working, and left it running. No problems thus far. No strange application or system warnings - except a message about not being able to synch to a time server, which doesn't appear to be an issue. There's no delay when requesting the login page, getting a DHCP address, or authenticating. Also, timing out sessions and auto-logging them off is on too. Still no glitches.

The only two possibilities I can think of, is that something about running in demo mode caused it, or one of the features that are available in demo mode, but isn't available in standard mode caused it - but I can't test either scenario now. Suffice to say it works. :)! If that changes, I'll let you guys know.