This is just general view of what we have done and what it looks like to the user.
The code is a modified version of the nocat system. The implementation is in two parts called the gateway and the authentication. I have attempted to localize and minimize my changes because nocat is still in development and it would be nice to be able to use their bug fixes and upgrades. But their code does seem to be reliable even though it does not do what we or most ISPs would require.
The nocat implementors think the system would be more secure if the gateway and the authenticator are run on two different machines. I'm not convinced of that. I'm running them on the same machine. We can build firewalled systems that prevent hacking in from the outside. I don't see why this is any more insecure. I really believe that if some of the complexity were removed from the communication between the gateway and the authentication it might actually be more secure. It certainly would be simpler.
Almost all of the changes are to the authentication part. There are just a few in the gateway section which are required to log the user off if they exceed their time limit. I have changed all of the HTML screens in the release and most of these changes are in the cgi behind the pages the user sees. Many of the things that I have not changed I probably will before we are done testing. I think these changes are required, not just another case of "not invented here".
The system can use any standard AP that passes DHCP packets. It also can work off of regular ethernet (think of a motel with wireless in the public areas and ethernet in the rooms).
To get started the user does a port 80 (http) reference to any web page. It can be a port 443 (https) reference but it may get confusing to the user because both the authentication system and the site referenced by the user may be serving secure certificates and the the browser may be displaying error messages right and left.
The gateway system intercepts the port 80 request and redirects it to a secure web site currently called auth.ss-wl.net. (This is a fake address, it can be anything that is configured correctly because it is not referenced anytime except during authentication. Its name service is provided by the gateway system.)
The redirection presents a splash screen based upon the one on Jack's system. This presents a bunch of legalese that basically just tells the user he is supposed to be a good net citizen. At the bottom of the screen is a button labeled accept that indicates the user accepts all the legal verbiage. I've added a bunch of buttons on the side. These are mainly to inform the user of typical problems, a faq, hotspot maps, a way to send a pseudo web mail message to us, etc.
After pressing accept the user is presented with another screen that gives him the option to login to an existing account, update an account, add time to an account, register a new account, or to try the system free. If the user selects free, he is given 10 minutes per day. A day is assumed to start and stop at noon (typical motel checkout time). The 10 minutes and the start/stop time can be easily changed. It could even be changed to so many minutes per 6 hour or 12 hour period. Experience will probably present even more options.
If the user selects register, he is asked for his name, a valid email address, and the standard credit card information. He also selects if he wishes a day or a month of access. He is also given the option to give us a URL and some comments. The credit card number is checked for length, card type matching the number, correct checksum, and an expiration date in the future. The email address is checked that it meets the general form of user@place.com and that place.com has MX records. If these conditions are met, an email with all the information is sent to billing and the user is allowed on. (Sometime during testing we should change this to online clearing or have the user select PayPal payment.) The user will be given a day or month starting a couple of seconds after he enters the data. He will be expired at the same second of the day his initial request was made.
If the user selects update or add he is presented with a screen to allow him to do this. [[ code not done, there was an update screen in nocat, but it is not sufficient for us ]] This code is not required for initial testing because we can use the admin update options.
No matter what path the user uses to navigate this procedure, the system has made an attempt to remember the initial page the user referenced when he first made contact with us After completing his selection (registering, updating, logging in, etc.) the system redirects the browser to the initial page. It is not always successful, but it usually is. When it is not, it is usually because the user had errors logging in or had to register an account and made errors doing that. I've never seen a redirection problem when a user logged into an existing account or completed the registration process without doing something wrong. Even if the authentication system loses track of the original page, all the user has to do is reenter it and he will directly access it.
A free access user may get slightly more time than the allocation, but should get at least what we claim. He may log on several times during the day just as long as the total time limit is not exceeded.
During logging in the system sends a popup window to the user. The popup either has a java script program or a refresh meta tag to tickle the gateway system every few minutes so the gateway system knows the user is still on. This window includes a logoff option. "Free" users have to log off or their time will expire. If daily or monthly users don't log off, they will be automatically logged off after a timeout period in which they don't access the system.
The software should look like a standard ethernet connection to the user. Windows XP, Windows ME, and Linux all work flawlessly. I've not tested anything else yet, but except for Macs, it is unlikely a potential client will have anything other than what I've mentioned. I've not tested things like ICQ either. But anything that correctly passes through iptables and NAT should work without any additional effort on our part. I would like to use NAT in the final system. NAT eliminates the need for us to request additional IP space and provides a small layer of security for the wireless users.
The system uses mysql for its user database. It also uses mysql for another file of information about who is or has been on today. This file may be displayed with the URL https://auth.ss-wl.net/cgi-bin/who. There may be clickable links in the displayed data. If one of them is clicked on, it will remove the record from the file. This causes the system to forget the user was logged on today and allow the user to get an additional free time period for the day. The who link is protected with the standard code to limit access requests to only those which originate from our administrative machines.
It might be worthwhile to allow the validation of a certain class of our other users. There is a radius interface in the nocat release, but (based upon messages I've seen about it) there seems to be bugs in it. An additional problem is that the use of it excludes the standard use of a mysql database *sigh*. I'm certain its not the hardest thing I've done on this project to allow both if we decide use both methods of authentication.
The code is solid enough to test with. The only thing that really must be done before turning real users on is to make some more changes to the user interface. The admin interface works fine and we can use the admin pages to add time to test users.
The biggest question I have right now is "where should the antenna's be and how do we get bandwidth to them". That is not solely my problem and does not sound like a software problem at all. I can have the loose ends in the code finished before the antenna's get here and are mounted.
If you would like to discuss if it could be mutually beneficial for us to help you provide this service to your area, send an email message to newservice@solid.net with a note about what you would like to discuss.
home www.solid.net
last changed 25-May-03