Hot Spot Deployment
Updates sent to the mailng lists...
Hotspot coordination (authentication)
Wed, 26 Feb 2003
For authenticating users on the network, there are three possibilities:
- Node sends request to a central database;
- Node sends request to local database, updated manually or by schedule;
- Node redirects user to a central server.
Any suggestions? Advantages or disadvantages of any of these? Any others?
Neal: nkras at visi dot com
Hotspot coordination (ping statistics)
Tue, 18 Feb 2003
Ping from laptop through the wireless bridge and router:
Destination: www.tcwug.org (crusader.real-time.com) (208.20.202.20)
Packets transmitted: 569
Packets received: 526
Duplicates: +6
Packet loss: 7%
Round trip minimum: 61.637 ms
Round trip average: 135.611 ms
Round trip maximum: 1258.91 ms
Respectfully submitted,
Neal: nkras at visi dot com
Hotspot coordination (Captive portal front end)
Sun, 16 Feb 2003
I am finalizing my selection of a web based front end for the captive portal.
The requirements for the web server are as follows:
- Open source;
- Easily compiled on Sys V, Berkeley, and Linux;
- Provide basic authorization services for access; and,
- Have a minimum impact on system resources: system load, memory, ancillary software or libraries, and hard drive space occupied.
Unless there is any objection or other ideas, I will utilize the CERN httpd server. It was last updated with a final release in 1996.
Respectfully submitted,
Neal: nkras at visi dot com
Hotspot routers: logging
Sat, 1 Feb 2003
I'm deciding on what level of logging I should use for the router. I am planning to use the following logging method (remember, this is Solaris 7, Linux has it's variants):
#snoop -P -V -d <device> -o <name>
where:
-P = non-promiscuous mode
-V = verbose/non-verbose compromise capture
-d = use interface <device> to capture packets
-o = log to file <name> (probably /var/log/<interface>)
This command will write the originating ip address with the source of the packet (ETHER), the destination ip, the protocol used (TCP), and the name of the service. Service name logging can be excluded, because the port is listed in the TCP data.
What level of logging does the group recommend?
Respectfully submitted,
Neal: nkras at visi dot com
Hotspot coordination progress (Router-RF bridge-dhcpd)
Sat, 1 Feb 2003
I have discovered that enabling WEP on the Linksys rf bridge is incompatible with dhcpd. This should not be a problem for any network: other means of authentication will be used.
Respectfully submitted,
Neal: nkras at visi dot com
Hotspot coordination progress (Routing and dhcp; completion)
Thu, 30 Jan 2003
I have completed the configuration of the routing tables and dhcp server on the rf network. The unix router is successfully negotiating with a laptop, assigning a lease, and allowing packet flow to and from the internet. Only the boot scripts need to be written, then I will begin development on a captive portal.
This message is being send by the wireless network and router.
Respectfully submitted,
Neal: nkras at visi dot com
Hotspot coordination progress (Routing)
Tue, 28 Jan 2003
I've been configuring routing for the node, settling on RIPv1, not r.disc, for dynamic routing. Though static routing can be used, I believe dynamic routing to be advantageous for all sites: major node, cloud (backhaul) relay, or independent hotspot. I am maintaining my policy of utilizing open source and common routing protocols and configurations to ensure the final result will be deployed across other platforms.
The demonstration will be a field test. I'll set the WEP key and anyone who wants to drive-by hack is more than welcome. I'll post all the access information on the lists and on the website when the installation goes beta.
This installation is alpha until I get the dynamic and static routing issues resolved. Routing should be resolved within a few days, then I will enable dhcp. The captive portal web server might prove somewhat difficult, but I've got an idea for using a web server allowing multiple permissions with site redirects upon authorization.
Respectfully submitted,
Neal: nkras at visi dot com
Hotspot coordination progress (Open Source, Authentication of Users)
Sat, 11 Jan 2003
FWIW, Solaris 7 x86 is being used as my current development platform. I'm quite used to this branch of Unix, and can subtract or add to the default installation, as well as navigate around it easier than Linux. This will not preclude the later development of a Linux wireless node, using Debian; nor BSD, using FreeBSD.
I am not using Sun's bundled DHCP server: in fact, I will be using only open source software (i.e. ftp://ftp.isc.org/isc/dhcp/dhcp-latest.tar.gz ). Such a policy will enable all wireless admins to use system wide configuration files, regardless of which *nix or architecture is used.
I will also be investigating the use of web servers instead of nocatauth for user authentication. nocatauth was designed for use with Linux, and will not be suitable for cross-platform deployment. I envision, with the help of the code warriors amongst us, the following auth scheme, used in one form by the Long Beach, California city government:
- User finds a TCWUG node.
- User connects to the node and receives an address using DHCP.
- The user automatically connects to the captive portal web page.
- The web page asks the user to acknowledge the acceptable use policy by entering a valid email address.
- The email address is verified by the server sending a test email to the address supplied by the user.
- The email will state "That someone has supplied us with your email address to access the TCWUG wireless network, and if this is you, then no action on your part is necessary. If this is not the case, please email TCWUG at...". If the email bounces, the user is denied access. A username and password database could be used in lieu of, or in addition to, this auth scheme.
- The user may proceed to TCWUG services if the information entered was correct.
Respectfully submitted,
Neal: nkras at visi dot com
Now that it's past the Holidays (Happy New Year!), it's time to get back to work on this Wireless stuff. After a number of configurations and failures, I have come to the following conclusions:
- Installing a wireless in the server requires not only the installation of drivers (straightforward enough), but the admin must install wireless tools. To utilize iwconfig, the admin must recompile the kernel. This will be necessary for each node.
- Installing the wireless card in the server requires the server itself to be physically placed in a location that will provide optimum coverage. That may not be possible, dependent on environmental restrictions of the node: susceptibility to adverse weather conditions, space restrictions, or a combination of the two.
- The node will be platform dependent. Admins will not be able to use any other platform besides Linux x86, for that will be the default gateway platform for all nodes. This will exclude any cross-platform development and deployment.
Therefore, I am pursuing the following solution:
- I am abandoning on board wireless cards in favor of the Linksys WET-11:
http://www.linksys.com/products/product.asp?grid=33&scid=36&prid=432
This will enable the location of the RF portion of the node to be located at distances up to 328 feet from the server. Because the WET-11 will act only as a bridge, passing all traffic over ethernet, any routing and dynamic IP assignments will be done by the server. The Bridge may be located at a more convenient place, allowing the server to be colocated with other equipment, if needed. - Locating the RF device external to the server relieves the admin of the need to recompile a kernel; use of specific kernels; loading of wireless device drivers and pcmcia support; and the use of wireless tools. What is left is only the requirement to compile, load, or add iptables or ipchains, a DHCP server, nocatauth, apache (dependent on portal requirements), and the installation of two ethernet cards. This will enable any platform to be used: FreeBSD, Solaris Sparc, Solaris Intel, Linux x86, MacOS X, et.al. Configuration of the WET-11, however, is dependent on Microsoft operating systems.
Respectfully submitted.
===================================
Neal: nkras (at) visi (dot) com