LINEBURG


<< . .

 23
( 36)



. . >>

255.255.255.0, indicating that the first three sections of the address define the subnet.
The default gateway is the address of the next device in line along the path to the Internet.
Figure 10-5 shows one possible setup for IP addresses and default gateway addresses for the
AP, two NICs, and the DSL modem.
DNS permits “resolving” domain names like www.google.com into IP addresses. Thus, get-
ting the correct addresses for the DNS servers is crucial for making things work. If you use
your provider™s DNS servers, you should be able to ask your ISP what IP addresses are for the
provider™s DNS servers. Or you may get the DNS server addresses automatically using DHCP.
Your DSL modem may also function as a DNS server, in which case one valid DNS address
would be the address of your DSL modem, such as 192.168.1.1 from our examples above.
When you have finished filling in the “Configure Network Settings” screen, click “Forward.”
On the “Create Ethernet Device” screen, review the information displayed to make sure it is
correct. If it isn™t, click “Back” and correct the information. Otherwise, click “Apply.”
You™ll be taken back to the main “Network Configuration” screen, where you can activate the
new card. Finally, go to the command prompt of the GNOME terminal, (click on the red
248 Part III ” Playing with Access Points


Computer


DSL AP
eth1 eth0

IP:192.168.1.1
Subnet Mask: 255.255.255.0
Default Gateway: N/A IP:192.168.1.47
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.1.1
IP:192.168.2.254
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.1.47
IP:192.168.2.1
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.2.254

FIGURE 10-5: One possible configuration of IP addresses and default gateway addresses
for an AP, two NICs and a DSL modem.

hat ➪ System Tools ➪ Terminal) and type service network restart. Any time you want
to check the settings of these cards, go to the command prompt of the GNOME terminal
(click on the red hat ➪ System Tools ➪ Terminal) and type ifconfig.

Testing, Testing
Once your NICs seem to be configured correctly, open the browser on the Linux box and make
sure you can access both the DSL modem and the AP. You do this simply by typing the IP
address of the device in the address bar at the top of the browser. You should either get instant
access to the device, or else a login screen.
If you get an error such as “connection refused,” the problem could be a bad cable, a loose cable,
or a crossover cable used where a standard cable is required. Or you may have violated rule
number 3, as discussed above. You could also have connected to a bad port on the device.


The WAN
If your service provider has turned your service on, and it is properly configured on their side,
you should be able to follow their instructions and get things working. One possible wrinkle is
that you may prefer to run DHCP on your Linux box, whereas the provider™s instructions may
assume that the DSL modem will be the DHCP server. Remember that you should not have
two DHCP servers accessible to any DHCP client. So, if you are using the Linux box for
DHCP, you should turn off the DHCP capability on the DSL modem and the AP.
249
Chapter 10 ” Creating a Free Wireless Hotspot


If the Linux box and the WAN device are configured correctly, you should be able to browse
the Web from the Linux box. If you can™t, see if the lights on the front of the DSL modem
indicate a good WAN connection and a good Ethernet connection. Use the browser to access
the DSL modem and check out its status screen. If everything seems OK on the DSL modem
side, then you probably have a problem in the Linux box configuration.

The AP
With many APs, the recommended setup is to put the AP in bridged mode and use a crossover
cable to connect to the Linux box. However, what “bridged” means here is simply that the AP
is transparent to the IP network, acting as a simple Ethernet bridge. For example, your clients
would not use the address of the AP as their default gateway. Instead they use the address of
the Ethernet card that is connected to the AP. Clients essentially do not see the AP. Instead,
they see through it to the Ethernet card.
Unfortunately, terminology is not consistent among AP manufacturers or models. The Linksys
WAP11, for instance, has a “bridged” mode in which it can only talk to other Linksys
WAP11s. Do not use the bridged mode on the Linksys WAP11 for this project. The Linksys
WAP11 is inherently a transparent Ethernet bridge and does not need to be put into any spe-
cial mode to act that way.
When you™re buying an AP for NoCat, the simpler, the better. If you have a more sophisticated
AP, set it up in its simplest mode. For example, the AP may have a “gateway” mode, which
would be preferable to a “router” mode.
Whether you should use a crossover cable depends on how the AP port you are using is wired.
On the WAP11, you should always use a crossover cable when you are not connecting to a hub.
Since you are connecting directly to a NIC in this case, you would use a crossover cable with
the WAP11. Some APs have both crossover and “straight” wired ports, and you can generally
use either one, as long as you use the right kind of cable with it. You can usually tell whether
you are using the right kind of cable by looking at the lights on your AP, to determine whether
it is seeing a good Ethernet connection on the port.

Unfortunately, there are a thousand things that can go wrong with hardware, IP, DHCP and
DNS setup. Make sure that the hardware and basic networking functions are working cor-
rectly before jumping into the NoCat install. You™ll be glad you did.




Installing NoCat
Here are the instructions for installing NoCatAuth on your Linux box:

1. Make sure you are logged on as the root user.
2. Go to the temporary directory where you downloaded the NoCatAuth software and
decompress it using the File Roller or a similar utility. All the files for installing the
gateway will be unpacked into a subdirectory named NoCatAuth-nightly.
250 Part III ” Playing with Access Points


3. Go to the NoCatAuth-nightly subdirectory and type: make gateway. This installs the
unpacked program files in their operational folders. Although it™s possible to edit the
Makefile to specify your own paths for installing program files, I would recommend
that most people install in the default configuration first, if possible. Using a custom
configuration creates one more possible source of problems. You should try to simplify
things as much as possible at this point.

That™s it. NoCatAuth should be installed.
Do a very basic test by typing /usr/local/nocat/bin/gateway at the command prompt
to start the gateway. You should see something like this:
[2004-02-12 08:39:23] Resetting firewall.
[2004-02-12 08:39:23] Detected InternalDevice ˜eth0™
[2004-02-12 08:39:23] Detected ExternalDevice ˜eth1™
[2004-02-12 08:39:23] Detected LocalNetwork ˜192.168.2.0/255.255.255.0™
[2004-02-12 08:39:24] Binding listener socket to 0.0.0.0
If you get error messages, read the INSTALL file for possible fixes. Some problems may also
be fixable by modifying the configuration file as described in the next section.
However, it is common for installation to go smoothly up to this point. That doesn™t mean that
you are out of the woods. In fact, you just stepped into the woods.



Configuring NoCat
Once NoCat is installed, the next step is to review and edit the configuration file,
/usr/local/nocat/nocat.conf, to reflect your network and preferences. Note that most of
the parameters can remain commented out in most cases. Many do not need to be manually config-
ured. For instance, NoCat is usually smart enough to figure out which of your Ethernet cards is
connected to the Internet, and which is connected to the local (“internal”) wireless network. That is
why, at the end of the previous section, you may have been able to fire up NoCatAuth, and,
without changing anything in the configuration file, get start-up messages like Detected
InternalDevice ˜eth0™ NoCat also usually figures out the IP address of the internal subnet.
.
That being said, here are some of the more important parameters that you may need to or want
to set:

GatewayName” The gateway name displayed to users on the locally stored splash and
status pages (/usr/local/nocat/htdocs/splash.html and
/usr/local/nocat/htdocs/status.html). Note that this does not affect the
login and logout screens displayed by the public NoCat auth server.
GatewayMode” This parameter configures the gateway to operate in Open, Passive, or
Captive mode. Open mode displays a local splash screen that you can edit, and does not
support username/password login. The other two display a login screen served by the
auth server, and do support username/password login. The difference between Passive
251
Chapter 10 ” Creating a Free Wireless Hotspot


and Captive is that Passive allows the gateway to operate even if there is a Network
Address Translation (NAT) device between the gateway and the auth server. Captive
mode is present for compatibility with past versions of NoCatAuth; you won™t use it in
this chapter. Use Passive instead of Captive for new installations.
InternalDevice”Usually auto-configured. The NIC connected to the AP. In Red
Hat 9, usually eth0.
ExternalDevice”Usually auto-configured. The NIC connected to the WAN. In
Red Hat 9, usually eth1.
LocalNetwork”Usually auto-configured. The subnet address of the
InternalDevice. Examples: 192.168.2.0/255.255.255.0 or 192.168.2.0/24 (two ways
of expressing the same thing)
DNSAddr”If you have a local caching DNS server on your Linux box, you should leave
this option commented out. Otherwise, this parameter should specify the IP address of
the external DNS server.
AuthServiceAddr and AuthServiceURL”These specify the authentication
server™s IP address and URL. Just leave the defaults if you want to use the auth server at
nocat.net.
AllowedWebHosts”A list of allowed domains. All other Web sites are inaccessible.
MembersOnly”Disables the Public access class of service when set to 1. (But hosts
named in AllowedWebHosts remain accessible to everyone.) In Passive mode, users
can prove that they belong to the Owners or Co-op class by submitting a username and
password to the auth server. In Open mode, since there is no opportunity to submit a
username and password, all users are treated the same: Uncommenting MembersOnly 1
disables Internet access, except to hosts named in AllowedWebHosts. MembersOnly is
commented out by default.
IncludePorts and ExcludePorts”These allow you to restrict the use of certain
ports for Public class users, either by allowing certain ports and no others
(IncludePorts) or by disallowing certain ports and permitting all others
(ExcludePorts). This is where, by default, outgoing mail is blocked by excluding port
25. If you set up a public portal, comment out the Exclude Ports 25 line in
nocat.conf if you want your users to be able to send mail using mail clients such as
Microsoft Outlook. The alternative will probably be dealing with lots of questions and
complaints. (It will not be clear to users why they can™t send mail. It just won™t work. Of
course, you can explain it on the splash page, which everyone will read with meticulous
attention.) If both these parameters are commented out, all ports are allowed.



Testing and Using NoCat
This section describes some basic tests to make sure your hotspot is working properly. These
tests are designed to be performed in order, without leaving any of them out. In other words,
each test assumes the configuration changes of the previous test.
252 Part III ” Playing with Access Points


Test #1 Accessing NoCat
This tests whether you can access the NoCat network site, which you should always be able to
do in the default configuration, since NoCatAuth puts no restrictions on access to this site by
default.

1. Start with the default NoCat configuration file (/usr/local/nocat/nocat.conf). If you
have already edited this file, you can rename your edited file to a unique name, copy gate-
way.conf from the NoCatAuth install directory and rename it nocat.conf. In the default
configuration file, everything below LogoutURL is commented out, with the exception of
ExcludePorts 25. Important settings include:

GatewayMode: Passive

AuthServicerAddr: auth.nocat.net
2. Reboot the gateway machine and start NoCatAuth by typing /usr/local/nocat/
bin/gateway at the command prompt.
3. Assuming a smooth start-up, as described above in “NoCat Installation,” go to a client
machine and associate with the wireless AP by selecting its SSID. (For testing purposes,
you could also access the gateway from a cabled workstation. From the gateway™s point of
view, there is no difference between wired and wireless clients coming in over the same
interface, such as eth0.)
4. Start your browser and type nocat.net in the address bar. You should immediately be
taken to http://nocat.net

If you get an error message indicating that the server cannot be found, the problem may be
DNS-related. Try typing 216.218.203.211 in the address bar. This is the IP address of
nocat.net. If this works, then apparently the problem was in resolving the name
nocat.net to an IP address. Some things you might check:

Make sure the DHCP server is handing out good DNS addresses. You should be able to
determine this through the DHCP server management interface.
Make sure the client machine is either configured to automatically obtain its DNS infor-
mation or is configured with known-good DNS addresses.
Try setting one or more known-good DNS addresses in the DNSAddr parameter in
nocat.conf.

If you only make adjustments on the client, type /usr/local/nocat/bin/gateway -R at
the Linux command prompt, to reset any firewall rules that have been changed.

Keep a terminal window open on the Linux box just for starting and restarting the gateway. Press
Ctrl P to repeat the previous command. (This works even after you have rebooted the
machine.) Since you may be repeating the same command many times, this can save you a lot of
keystrokes.
253
Chapter 10 ” Creating a Free Wireless Hotspot


If you change things on the server side, reboot the server and restart the gateway. Then try nav-
igating to nocat.net again.


Test #2 Accessing Google
This tests whether you can access Google, which requires you to go through the login screen.

1. Type www.google.com in the browser address bar. You should get the NoCat login
screen, as shown in Figure 10-6.
2. Click the Skip button.
3. After a small NoCat Logout Agent window opens (don™t close it”it keeps your connection
alive and allows you to log out), you will be taken to the Google site. From there, you should
be able to go to any site on the Internet, without any further involvement with NoCat.


Test #3 Registering and Logging In
This is pretty much like the last test, except that you will register and log in this time, instead
of hitting the Skip button.




FIGURE 10-6: The NoCat login screen, displayed by the NoCat auth server.
254 Part III ” Playing with Access Points


1. Type /usr/local/nocat/bin/gateway “R at the Linux command prompt, to reset
NoCatAuth firewall rules.
2. On the client, type www.google.com in the browser address bar. You should get the
NoCat login screen, as shown in Figure 10-6 above.
3. Click “Register here.”
4. Fill out the registration form and click “Register.” A “thank you” screen will be displayed
briefly. Then you will be returned to the login screen.
5. Log in with the name and password that you just created. As in the previous test, you
should get the NoCat Logout Agent window and then be forwarded automatically to
Google. From there, you should be able to go to any site on the Internet.



Test #4 Checking IPtables
NoCatAuth uses IPtables to create firewall rules. Therefore, IPtables gives you a way to “look
under the hood” and determine whether NoCatAuth is operating properly. This test describes
one simple interaction with IPtables.

1. Open a new terminal window on the Linux box, and type IPtables -L at the Linux
command prompt.
Near the bottom of the displayed information, you should see the following, but with the
IP address of your client instead of 192.168.2.100.
Chain NoCat_Inbound (1 references)
Target prot opt source destination
ACCEPT all -- anywhere 192.168.2.100
The line beginning ACCEPT is a firewall rule that says traffic using any protocol
(prot all), from anywhere, and destined for your client will be accepted.
2. Go to the terminal window where you restarted the gateway. Use Ctrl P to bring up the
/usr/local/nocat/bin/gateway “R command, and hit the Enter key to reset
NoCatAuth firewall rules.
3. Go back to the terminal window where you executed the previous IPtables “L com-
mand. Use Ctrl P to bring up the command again, and hit the Enter key. You will see:
Chain NoCat_Inbound (1 references)
Target prot opt source destination
The rule allowing traffic to get your client has been removed.
4. Try refreshing the Google screen. You will get the NoCat login screen, because in step 2
above you “erased” NoCatAuth™s memory of you.
255
Chapter 10 ” Creating a Free Wireless Hotspot


Test #5 Open Mode
This test checks Open Mode operation.

1. Edit nocat.conf as follows:

GatewayMode: Open
2. Optionally, change GatewayName to reflect the change. You might make it “My Open
NoCat Portal,” for instance.
3. Reboot the computer and then use /usr/local/nocat/bin/gateway or Ctrl P to
start NoCatAuth.
4. On the client, type www.google.com in the browser address bar.
You should get the NoCat splash screen, as shown in Figure 10-6.
5. Click “Login.” You will be taken to the Google site. From there, you should be able to go
to any site on the Internet. (Note that there is no NoCat Logout Agent window in this
case.)


Test #6 Allowed Web Hosts
This test makes sure that the “Allowed Web Hosts” feature is working properly.

1. In nocat.conf, uncomment MembersOnly 1 and AllowedWebHosts. Edit as follows:
AllowedWebHosts: rockisland.com
MembersOnly 1
(Leave GatewayMode: Open)

2. Reboot the computer. Use /usr/local/nocat/bin/gateway or Ctrl P to start
NoCatAuth
3. On the client, type www.google.com in the browser address bar, or attempt to refresh
the Google screen, if it is already open. You get the NoCat splash screen, as shown in
Figure 10-7. The first time the gateway is accessed, a “none” message will appear. It will
be replaced by a date and time after the first login.
4. Click “Login.” You are not taken to the Google site, because it is not an allowed site.
Instead, you are returned to the splash screen.
5. Type www.rockisland.com in the browser address bar. You are taken to that site. If
you attempt to go to any other site, you will be returned to the splash screen.
6. Change back to Passive mode, reboot, and restart the gateway. The behavior is essentially
the same, except that you get the login screen instead of the splash screen.
256 Part III ” Playing with Access Points




FIGURE 10-7: The NoCat splash screen the first time the gateway is accessed.



Note that a user whose initial request is for an allowed site will never see the splash screen at
all. This is the intended behavior of AllowedWebHosts. However, if you want all users to view
and accept an AUP, it is an unfortunate behavior. One possible workaround is editing the
splash page to always redirect to a particular site (see instructions in the next section) and
putting the AUP on that site instead of on the splash page.


Test #7 All Roads Lead to Rome
This tests a configuration in which all users are redirected to one particular site, no matter
which site they initially request.

1. Make a copy of the splash page (/usr/local/nocat/htdocs/splash.html) so
that you can always go back to the original.
2. Open the splash page using your preferred text editor. (In Red Hat, you can get to the
gedit editor by clicking on the red hat, then selecting Accessories ➪ Text Editor.) Toward
the bottom of the page, where you see value“$redirect”, substitute a URL for
$redirect. For example: value “http://www.rockisland.com” (be sure to
include the http://.)
257
Chapter 10 ” Creating a Free Wireless Hotspot


3. Make any other changes you wish, as well, in the splash file. This is your chance to insert
an AUP, for instance. In addition, since users are not logging in, you may want to edit
the splash page so that it has a Continue button rather than a Login button. Toward the
middle of the page, where you see src=“images/login.gif,” substitute
src=”images/continue.gif.” If you want to see all the possible button images,
look in /usr/local/nocat/htdocs/images. Or you can create a new image and
use it, instead.
If you have multiple allowed sites, you can put links to all those sites on your splash page.
Be sure to include the http://, like this:
<a href=”http://www.rockisland.com”.Rockisland,</a.>
4. Save the file.
5. Edit nocat.conf, to change back to Open mode. Leave the other settings as shown in
the previous section.
6. Reboot the computer and restart the NoCatAuth gateway.
7. On the client, type www.google.com in the browser address bar, or attempt to refresh the
Google screen, if it is already open. You get the NoCat splash screen, as shown in Figure 10-8.

<< . .

 23
( 36)



. . >>

Copyright Design by: Sunlight webdesign