Managing a Linux Wireless Access Point

In this conclusion to a five-part series on building a LInux wireless access point, you’ll learn how to manage the details, such as DNS caches. This article is excerpted from chapter four of the Linux Networking Cookbook, written by Carla Schroder (O’Reilly; ISBN: 0596102488). Copyright © 2008 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media

4.15 Turning Off Antenna Diversity 

Problem

Your wireless interface supports using two antennas, but you’re using just one. You know that this means half of your broadcast and unicast packets are hitting a dead end, which can hurt performance. How do you send power only to one antenna?

Solution

Set Pyramid’s filesystem to read/write, then add the following lines to /etc/sysctl.conf:

  dev.wifi0.diversity = 0
  dev.wifi0.rxantenna = 1
  dev.wifi0.txantenna = 1

Then, load the new configuration:

  pyramid:~# /sbin/sysctl -p

If the antenna is connected to the second port, just change 1 to 2 and reload sysctl.

Discussion

The Linux kernel sees the wireless interface as wifi0, which you can see by running dmesg | grep wifi. The MadWiFi driver creates a virtual interface named ath0.

Using two antennas might improve the quality of your wireless service, or it might not. Only one is used at a time, the one with the stronger signal.

Polarization diversity is when one antenna receives a stronger signal because it is lined up differently than the other one. Spatial diversity refers to distance between two antennas. A few inches might make a difference because of reflections, fading, physical barriers, and interference.

The radio hardware evaluates the signal strength at the beginning of the transmis sion and compares both antennas. Then, it selects the stronger antenna to receive the rest of the transmission. The only user-configurable options are to turn diversity on or off.

Multiple-input/multiple-output (MIMO) technology promises higher data rates and better performance by using both antennas at the same time. Different vendors mean different things when they say MIMO.

Some are referring to multiple data streams, while others use it to mean plain old channel bonding. The goal is the same: more bandwidth and reliability for delivering video, VoIP, and other high-demand applications.

There is considerable controversy and endless arguments over antenna placement, what kind of antennas to use, and how many. Pointless arguments can be fun; when that gets dull, whip out your 802.11 network analyzer and collect some useful data to help you figure it out.

See Also

  • Chapter 16, “802.11 Hardware,” in 802.11 Wireless Networks: The Definitive Guide, Second Edition, by Matthew Gast (O’Reilly)
  • Chapter 24, “802.11 Network Analysis,” in 802.11 Wireless Networks: The Definitive Guide, Second Edition

{mospagebreak title=4.16 Managing dnsmasq’s DNS Cache}

Problem

You know that dnsmasq automatically creates a local DNS cache. How do you know it’s working? How do you see what’s in it, and how do you flush it when you’re making changes to DNS and want to be sure it’s caching fresh data?

Solution

It’s easy to see if it’s working. From any Linux client or from your Pyramid server, query any Internet site with the dig command twice:

  $ dig oreilly.com
  <snip much output>
  ;; Query time: 75 msec
  ;; SERVER: 192.168.1.50#53(192.168.1.50)
  $ dig oreilly.com
  <snip much output>
  ;; Query time: 3 msec
  ;; SERVER: 192.168.1.50#53(192.168.1.50)

The second request is answered from your local dnsmasq cache, so it is faster. This also verifies that your clients are querying the correct DNS server.

What if you want to flush dnsmasq’s cache? Just restart it:

  pyramid:~# killall dnsmasq

dnsmasq is controlled from /etc/inittab, so it will automatically restart.

To view the contents of the cache, first open /etc/inittab and comment out the line that starts dnsmasq:

  pyramid:~# /sbin/rw
  pyramid:~# nano /etc/inittab
  # dnsmasq. This should always be on.
  # DN:23:respawn:/sbin/dnsmasq -k > /dev/null 2>&1

Tell init to reread inittab, stop the active dnsmasq process, then start dnsmasq in debugging mode:

  pyramid:~# telinit q
  pyramid:~# killall dnsmasq
  pyramid:~# dnsmasq -d

This runs it in the foreground, so the next thing you need to do is open a second SSH session, or log in on the serial console, and run this command:

  pyramid:~# killall -USR1 dnsmasq

This dumps the cache contents to your first screen. You should see just your localhosts. This line tells you your cache is empty:

  dnsmasq: cache size 150, 0/0 cache insertions re-used unexpired cache entries.

Start dnsmasq again, visit some web sites from client PCs to generate some cache entries, then dump the cache again to see what they look like. You should see a lot more entries now. When you’re finished, put /etc/inittab back the way it was, and rerun
telinit q and /sbin/ro .

Discussion

It’s unlikely that you’ll ever have to do anything with your dnsmasq cache because it’s pretty much self-maintaining. There are three options in /etc/dnsmasq.conf for configuring cache behavior:

local-ttl

The default is zero, which means do not cache responses from /etc/hosts and your DHCP leases. This ensures fresh local data all the time. If your network is stable and doesn’t have DHCP clients popping in and out a lot, you can set a Time To Live (TTL) value to speed up local look ups.

no-negcache

Do not cache negative responses. Caching negative responses speeds up perfor mance by caching “no such domain” responses, so your clients don’t wait for additional lookups to fail. dnsmasq handles negative caching well, so you shouldn’t disable negative caching unless it causes problems.

cache-size

The default is 150 names. The maximum is around 2,000. Because the cache is stored in RAM, having a too large cache will hurt router performance without appreciable gain. 150 is just fine for most sites; I wouldn’t go over 300.

You are at the mercy of the administrators of the authoritative servers for domains that you visit. If they make changes to their DNS without setting short TTL values, stale data will be cached all over the Internet until their TTLs expire. It can be helpful to flush your dnsmasq cache when you’re debugging DNS and trying to figure out if a DNS problem is local or remote.

Here are some examples of the output you’ll see. This is an empty cache showing only local DNS:

  pyramidwrap:~# dnsmasq -d
 
dnsmasq: started, version 2.23 cachesize 150
  dnsmasq: compile time options: IPv6 GNU-getopt ISC-leasefile no-DBus
  dnsmasq: DHCP, IP range 192.168.1.100 — 192.168.1.200, lease time 10h
  dnsmasq: using local addresses only for domain alrac.net
  dnsmasq: read /etc/hosts – 4 addresses
  dnsmasq: reading /etc/resolv.conf
  dnsmasq: using nameserver 12.169.174.3#53
  dnsmasq: using nameserver 12.169.174.2#53
  dnsmasq: using local addresses only for domain alrac.net
  dnsmasq: cache size 150, 0/0 cache insertions re-used unexpired cache entries.

dnsmasq: Host

Address

Flags

 

Expires

dnsmasq: stinkpad.alrac.net

192.168.1.102

4FRI

H

 

dnsmasq: localhost

127.0.0.1

4F I

H

 

dnsmasq: xena.alrac.net

192.168.1.10

4FRI

H

 

dnsmasq: pyramid.alrac.net

192.168.1.50

4FRI

H

 

dnsmasq: stinkpad

192.168.1.102

4F I

H

 

dnsmasq: xena

192.168.1.10

4F I

H

 

dnsmasq: localhost.alrac.net

127.0.0.1

4FRI

H

 

dnsmasq: pyramid

192.168.1.50

4F I

H

 

This is a snippet from a populated cache:

  dnsmasq: cache size 150, 0/178 cache insertions re-used unexpired cache entries.

dnsmasq: Host

Address

Flags

 

Expires

dnsmasq: stinkpad.alrac.net

192.168.1.102

4FRI

H

 

dnsmasq: localhost

127.0.0.1

4F I

H

 

dnsmasq: i.cnn.net

64.236.16.137

4F

 

Wed Jan 24 15:36:42

2007

 

 

 

 

dnsmasq: i.cnn.net

64.236.16.138

4F

 

Wed Jan 24 15:36:42

2007

 

 

 

 

dnsmasq: bratgrrl.com

67.43.0.135

4F

 

Wed Jan 24 17:45:49

2007

 

 

 

 

dnsmasq: a.tribalfusion.com

204.11.109.63

4F

 

Wed Jan 24 15:29:08

2007

 

 

 

 

dnsmasq: a.tribalfusion.com

204.11.109.64

4F

 

Wed Jan 24 15:29:08

2007

 

 

 

 

dnsmasq: ad.3ad.doubleclick.net

216.73.87.52

4F

 

Wed Jan 24 15:27:29

2007

 

 

 

 

dnsmasq: ads.cnn.com

64.236.22.103

4F

 

Wed Jan 24 16:21:41

2007

 

 

 

 

Table 4-1 shows what the flags mean.

  • Both F and R may be set for names from DHCP or /etc/hosts.

Table 4-1. dnsmasq cache flags and their meanings

Flag

Meaning

4

IPv4 address

6

IPv6 address

C

CNAME

F

Forward (name address) mapping

R

Reverse (address name) mapping

I

Immortal (no expiry time)

D

Originates from DHCP

N

Negative (name known not to have address)

X

No such domain (name known not to exist)

H

Originates from /etc/hosts

 

See Also

  • man 8 dnsmasq contains a wealth of helpful information about all the available command-line options, many of which are also dnsmasq.conf options
  • dnsmasq.conf is also a great help resource
  • dnsmasq home page (http://www.thekelleys.org.uk/dnsmasq/doc.html) is where you’ll find mailing list archives and excellent help documents
  • Chapter 24, “Managing Name Resolution,” in Linux Cookbook, by Carla Schroder (O’Reilly)

{mospagebreak title=4.17 Managing Windows’ DNS Caches}

Problem

You know that Windows 2000, XP, and 2003 Server include DNS resolver caches by default. Which is a big surprise to most Windows users, who sometimes get stuck with stale data and don’t understand why some addresses are not resolving correctly. Most of the time you don’t even have to think about it, but when you’re making changes, you want to be sure that your clients are receiving fresh DNS information. How do you handle this?

Solution

On Windows clients, open a DOS window and run this command to see the contents of the cache:

  C:> ipconfig /displaydns | more

This command clears the cache:

  C:> ipconfig /flushdns

The default TTL is 86,400 seconds, or one day, for positive responses. Answers to negative queries are stored for 300 seconds (5 minutes). You may change these values, or disable caching entirely by editing the Windows Registry. On Windows 2000, open the Registry Editor and change the TTL for positive entries by creating or modifying the DWORD value in:

  HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesDnscache Parameter s
  DWORD: MaxCacheEntryTtlLimit
  Value: 14400

14,400 seconds is four hours, which is typical for most ISPs these days. 0 disables all caching. Be sure you enter your values as Decimal Base, not Hexadecimal Base.

Disable negative answers with this key:

  HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesDnscacheParameters
  DWORD: NegativeCacheTime
  Value: 0

On Windows XP and 2003, change the TTL for positive entries with a different DWORD :

  HKEY_LOCAL_MACHINESYSTEM CurrentControlSet ServicesDnscache Parameters
  DWORD:  MaxCacheTtl
  Value: 14400

Turn off negative caching with this one:

  HKEY_LOCAL_MACHINESYSTEM CurrentControlSetServicesDnscache Parameters
  DWORD:  MaxNegativeCacheTtl
  Value: 0

You may disable caching entirely by setting both values to zero. Reboot, as always, to activate the changes.

Discussion

Linux clients do not activate their own DNS caches by default; you have to set these up on purpose. Client-side caching is a nice thing that speeds up lookups. All those caches cause problems only when DNS is changed and the caches get stale.

See Also

  • The documentation for your particular flavors of Windows; a quick Google search on “windows dns cache” should get you all the information you need

{mospagebreak title=4.18 Updating the Time at Boot}

Problem

You have one of those newfangled routerboards that doesn’t have a CMOS battery. BIOS settings are written to nonvolatile RAM, but the time and date are lost with every power-cycle. How do you make it set the time correctly at boot?

Solution

With good ole ntpdate. First, edit /etc/default/ntp-servers so that it points to pool.ntp.org:

  # /sbin/rw
  # nano /etc/default/ntp-servers
  NTPSERVERS="pool.ntp.org"

Then create a startup link so it will run at boot:

  # ln /etc/init.d/ntpdate
/etc/rc2.d/S90ntpdate

Now every time you boot up your routerboard, it will set the correct time. You can verify this with the date command:

  # date
 
Mon Jan 29 20:52:50 UTC 2007

Discussion

If you are familiar with the NTP documentation, you’re aware that the fine NTP folks keep trying to get rid of ntpdate and replace it with the nptd -g command.
However, ntpdate still works best for large time corrections.

See Also

  • man 1 ntpdate 
  • Chapter 19, “Keeping Time with NTP,” in Linux Cookbook, by Carla Schroder (O’Reilly) 

 

[gp-comments width="770" linklove="off" ]

antalya escort bayan antalya escort bayan Antalya escort diyarbakir escort