 |
|
5. Overview on Wireless network setup.
5.1 Fundamental steps
Once you have got the needed material and you have compiled all the needed you should do the fundamental step in a Wireless configuration:
- Low level kernel config Let the Linux Kernel see your Wireless card (at low level, such as ioport, interrupts, dma...): you must see some kind of kernel message that advertise you that Wireless card has been right found and configured.
- Data-link level setting For each particular Wireless card there is an utility that can set typical Wireless data-link level value. For example in Proxim Symphony the utility is called "rl2cfg" while in pcmcia cards settings are in pcmcia config files. You have to set all your Wireless cards with coherence to make them talk together.
- Ip setting Now you should be able to use ifconfig and route capabilities to change IP settings.
- Tricks for better performance and to a avoiding conflicts. Now your Wireless Network is basically working: in addition you have to adjust some particular setting like proxy-arp, icmp echo redirect, bridging, channel change and so on to optimize your network and avoiding strange and bandwidth killing conflicts
N.B.: step 1, 2 and 3 correspond to level 1, 2 and 3 of standard ISO/OSI, while step 4 is an addendum to solve situation generated by netmask 255.255.255.255. In fact 32 bit netmask violates standard ISO/OSI cause the network force to use the same address for broadcast and ip machine and the network address doesn't exist.
Someone could criticize this point of view, but if you use the standard ISO/OSI to configure Wireless network with you'll loss many ones configuring subnets; for each subnet usually you discard 2 IP number (Network and broadcast) and you cannot achieve the flexibility on IP assigning (geographically kind). You can find more on Appendix A about this.
You could notice that step 2 is not present in Wired cards cause there's no particular settings to do there.
5.2 Low Level Kernel Config
Always it's a problem for Pc administration: to let kernel (or in general) see your hardware.
Wireless cards are more complex because many of them usually have a Pcmcia plug, so first of all you have to let your kernel see Pcmcia adapter card, then you can try to install specific hardware driver for your Wireless card.
So, in Pcmcia config you have to:
- install linux kernel source, from http://www.kernel.org to /usr/src/linux (see tar and gzip utilities)
- install linux pcmcia source, from ftp://projects.sourceforge.net/pub/pcmcia-cs to install to /usr/src/pcmcia (see tar and gzip utilities)
- config and recompile your kernel: read file README in your linux directory (/usr/src/linux)
- config and recompile your pcmcia source: under /usr/src/pcmcia use configure and make. Be sure your driver is here, else your have to install it following driver instructions (usually a tar zxvf driver.tgz under pcmcia dir is sufficient). After type "make all" to compile. At the end type "make install".
- After typed install you'll find some useful config files under /etc/pcmcia .
In non pcmcia case:
- If your driver is present (99% not) under linux sources, you have to install it in a directory, then to compile it.
Once you know module name you have to load it: in pcmcia config you only need to start pcmcia daemon (/etc/rc.d/init.d/pcmcia start for RedHat), for other "modprobe module_name options". With options you'll give ioport, irq and data-link settings (see Par 5.3) to Wireless driver. Anyway your useful tools to know if hardware has correctly been seen by driver are:
- "tail /var/log/messages" that explains info about syslog
- "dmesg" for more info.
- /proc dir: ioports, devices, irq files and driver specific sub-directories.
5.3 Data-link level setting
What is that?
Wired networks need only to connect each other and then you'll be able to set TCP/IP parameters.
In opposite Wireless networks need data-link settings, such as:
- What kind of Wireless network I belong to? (Adhoc or Infrastructure)
- What channel I have to use?
- What subnet (BSSID) I belong to, what is my ESS ID?
- Is my communication protected by such a encryption algorithm? Length key?
As you see there are many settings you have to adjust, the reason come from the architecture of Wireless network: there could be someone, in near distance, that could see your packets, use your services only pointing his antenna on the right direction and setting up right TCP/IP parameters.
In addition there could be many Wireless subnets that could generate interference each other.
So here are:
- Options at load-time module: "modprobe ray_cs essid='LINUX'" for example or
- Utilities at run-time driver: "rl2cfg eth1 master".
5.4 Ip setting
This is the third problem you have to face. Here situation become problematic only when your network begin to evolve in a bigger one.
Remember Wireless IP Networking doesn't stress you if you don't stress it!
A simple configuration
All the hosts view each other
A - - - - - C
\ /
| \ / |
/\
| / \ |
/ \
B - - - - - D
A configuration like this is very simple and don't require nothing special (at Ip level): you only need to assign an IP address for each host and to assign a coherent global netmask.
A more complex configuration
A doesn't see B directly
A <- - - -
NO\ |
TALK\ C
\ |
B <- - - -
Here A and B can communicate only passing through C.
If the network is in Infrastructure mode and C is the Access Point all is ok. In Adhoc mode you also can design a host to "master" capability (I know the term is not so formal!), a host that creates a BSS and to which any other host can join that BSS.
Full connectivity now is reached at IP level: A and B talk to C using the same C interface, so if you try to ping from A to B you'll receive many ICMP REDIRECT packets from C, cause C is telling A that the destination is already in the network from which come the request.
Solution: type a "echo 0 > /proc/sys/net/ipv4/conf/ethx/send_redirects" (where ethx is the interface on C towards A and C) to null all that.
Another problem: what netmask I assign to A and C? If you assign a netmask to A that include A and C nothing works because A don't use the gateway (C) but make the ARP request with unknown destination MAC address.
You could think to use proxy arp, but without effect cause proxy arp reply to source only when the destination is in a different interface from the source: this is not the case!!
So you have to set a very little netmask (Win9x let it be 255.255.255.254, WinNT at least 255.255.255.248), and you have to assure that hosts A and C don't have the same net address.
Examples:
- IP(A) = x.y.z.2/31, IP(B) = x.y.z.3/31. This doesn't work cause A asks for B in its network (ARP request) and C doesn't answer cause, for it, A and B belong to the same interface (so, no proxy arp).
- IP(A) = x.y.z.1/31, IP(B)= x.y.z.2/31. This works cause A ask to C (send requests to B with C MAC address) for B.
In general with a netmask 255.255.255.254 system works with 2 IP changing only for the final bit.
All that is a TCP/IP forcing but is the only method to obtain an high level of flexibility.
Note: If you use an Access Point (network in Infrastructure mode) you haven't redirect problem, cause all is solved at data-link level (almost every Access Point acts as a bridge...). But Access Point are expansive (about 1000 USD or more) and it is more economic to use a P133 32MB Ram to forward, even with 2 or more cards.
Internet Access
A - - - - - C - - Internet
\ /
| \ / |
/\
| / \ |
/ \
B - - - - - D
There is a number of situation:
- C is the only Public IP address. You only have to set private IP address (192.168.x.y for example) for the Wireless network enabling, on C, forwarding and masquering. A, B and D will have C as default GW.
- You have a public netmask visible from Internet and C is your default GW to Internet for the network. You only need to enable forwarding on C, setting up default GW on A, B and D to point to C.
- You have a public netmask visible from Internet and C is not the default GW to Internet. You have 2 possible solutions: Modify your default GW to let it point to C for your network. Symmetrically you have to let C point to default GW to go to Internet. You could, instead, enable proxy arp feature to C (echo 1 > /proc/sys/net/ipv4/conf/ethx/proxy_arp where ethx is the interface towards the default GW) and set your default GW on C to point to the default GW. Proxy arp is a TCP/IP forcing but works well.
Mixed network: Wired and Wireless
Internet
\
\ E
\ /
\ / Wireless
A - - - - - C - - F
\ / \
| \ / | \
Wired /\ G
| / \ |
/ \
B - - - - - D
Now C joins 2 networks: on the right Wireless and Wired on the left.
More you have Internet Access, so in total you have 3 network cards in C.
What IP Address I assign to hosts? You have 2 possible solutions:
- Split up network in 2 subnets: for example 192.168.1.0/24 and 192.168.2.0/24. This solution is quickly but is not scalable if you are using Internet IP addresses cause you have to drop too many IPs.
- Enable Proxy Arp feature to C for all 2 interfaces. Network parameters (net address and netmask) are the same for Wireless and Wired, but with proxy-arp enabled I can choose which IPs are on Wired and which on Wireless.
Now we examine solution 2
For example: Consider you have Internet public subnet x.y.z.0/24.
Interfaces are:
- ifconfig eth0 x.y.z.C netmask 255.255.255.255 (Wired)
- ifconfig eth1 x.y.z.C netmask 255.255.255.255 (Wireless)
- ifconfig eth2 x.y.z.C netmask 255.255.255.255 (to Internet)
Static routes on eth2:
- route add IPGW dev eth2
- route add default gw IPGW
This route stands for addressing all Internet requests to your Default GW: as you notice, first you have to tell Linux where is the router, then let default requesting through it.
Static routes on eth0:
- route add x.y.z.A dev eth0
- route add x.y.z.B dev eth0
- route add x.y.z.D dev eth0
Hosts A,B and D on the Wired Network
Static routes on eth1:
- route add x.y.z.E dev eth1
- route add x.y.z.F dev eth1
- route add x.y.z.G dev eth1
Hosts E,F and G on the Wireless Network
Note that flexibility is very high, but you have to manual set each host.
Next Previous Contents
Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 17:58:37