Wireless LAN Implications, Problems, and Solutions

This chapter will introduce you to:

  • Security Vulnerabilities
  • Radio Signal Interference
  • Impacts of Multipath Propagation
  • Roaming Issues
  • Battery Limitations
  • Interoperability Problems
  • Installation Issues

As Chapter 1, “Introduction to Wireless LANs,” describes, wireless LANs (WLANs) offer tremendous benefits. When designing and supporting a WLAN, however, you must be aware of potential implications, such as security vulnerabilities, radio signal interference, multipath propagation, and other issues. This chapter explains the impacts of these problems and introduces some ways to resolve them. Later chapters explain more details on how to combat the implications.

Security Vulnerabilities

Network security refers to the protection of information and resources from loss, corruption, and improper use. With WLANs, security vulnerabilities fall within the following areas (see Figure 4-1):

  • Passive monitoring
  • Unauthorized access
  • Denial-of-service attacks

The sections that follow explain these security problems in greater detail.

Figure 4-1Figure 4-1 Wireless LAN Security Vulnerabilities Include Passive Monitoring, Unauthorized Access, and Denial-of-Service Attacks

Passive Monitoring

Wireless LANs intentionally propagate data throughout buildings, campuses, and even cities. As a result, the radio signals often go beyond the limits of the area an organization physically controls. For instance, radio waves easily penetrate building walls and can be received from the facility’s parking lot and possibly a few blocks away, as illustrated in Figure 4-2. It is possible for an unauthorized person to passively retrieve a company’s sensitive information by using a laptop equipped with a radio card from this distance without being noticed by network security personnel. A hacker, for example, might be sitting in an automobile outside a business, capturing all 802.11 transmissions using a freely available packet sniffer, such as WireShark. After capturing the data, the hacker will be able to retrieve contents of e-mails and user passwords to company servers. Of course, the hacker can use this information to compromise the security of the company. This problem also exists with wired Ethernet networks, but to a lesser degree. Current flow through the metallic wires emits electromagnetic waves that someone could receive by using sensitive listening equipment. The person must be much closer to the cable, though, to receive the signals. Thus, in terms of passive monitoring, WLANs are not as secure as wired networks.

The method for resolving the issues of passive monitoring is to implement encryption between all client devices and the access points. Encryption alters the information bits in each frame, based on an encryption key, so that the hacker cannot make sense of the data he captures via passive monitoring. An example of an 802.11 encryption process is Wired Equivalent Privacy (WEP), which was part of the original 802.11 standard ratified in 1997. WEP is fairly easy to crack, however, so it is not recommended for encrypting sensitive information. Other encryption methods, such as Wi-Fi Protected Access (WPA), offer much stronger security.

Figure 4-2Figure 4-2 Without Effective Encryption, an Unauthorized Person Can Listen in on Wireless LAN Data Transmissions

Unauthorized Access

If someone can connect to a WLAN, she can potentially access anything on the network, including client devices, servers, and applications, as illustrated in Figure 4-3. Some organizations do a good job of locking down servers and applications, but others do not. A hacker who can connect to a WLAN will look for backdoors and other security glitches to compromise the security of the network. For example, a hacker connected to an access point can use a TCP port scanner to implement a scan for open (unsecured) ports on servers. If one is found, the hacker has access to the port’s utilities, which might allow her to directly access sensitive information or reconfigure the network in a manner that makes it less secure (and thus easier to access more sensitive information).

Figure 4-3Figure 4-3 Unauthorized Access Enables Someone to Gain Access to an Organization’s Servers and Applications

One way that a hacker can gain unauthorized access to a WLAN is to stage a man-in-the-middle attack, as illustrated in Figure 4-4. There are a variety of methods to set up a man-in-the-middle attack. One is to exploit the TCP/IP Address Resolution Protocol (ARP) functions. ARP is a crucial function that a source station (such as an 802.11 radio) uses to discover the physical address of a destination station. This physical address is the MAC address, which is embedded in the client radio by the manufacturer and unique from any other client device or network component. The MAC address is analogous to the street address of your home. Just as someone must know this address to send you a letter, a sending 802.11 radio must know the MAC address of the destination. The 802.11 radio understands and responds to only the physical MAC address.

Figure 4-4Figure 4-4 A Hacker Can Hijack a Session Away from a Legitimate User

The application software that needs to send the data will have the IP address of the destination, but the sending station must use ARP to discover the corresponding physical address. It gets the address by broadcasting an ARP request packet that announces the IP address of the destination station to all the other network devices. All stations within range hear this request, and the station that has the corresponding IP address will return an ARP response packet containing its MAC address and IP address. The sending station will then include this MAC address as the destination address in the 802.11 data frame being sent. The sending station also stores the corresponding IP address and MAC address mapping in a table for a period of time or until the station receives another ARP response from the station having that IP address. This is where ARP introduces a security risk.

A hacker can fool a station by sending (from an unauthorized laptop) a fictitious ARP response that includes the IP address of a legitimate network device, such as a wireless access point, and the MAC address of the client radio in the unauthorized laptop. This causes all legitimate stations on the network to automatically update their ARP tables with the false mapping to the unauthorized laptop. This causes these stations to send future 802.11 data frames to the rogue device rather than the legitimate access point. This is a classic man-in-the-middle attack, which enables a hacker to manipulate user sessions. As a result, the hacker can obtain passwords, capture sensitive data, and even interface with corporate servers as if she were the legitimate user.

A critical security concern of IT managers is the presence of rogue wireless access points on the corporate network. A rogue access point is one that the company does not authorize for operation. The trouble is that a rogue access point often does not conform to WLAN security policies, which enables an open, insecure interface to the corporate network from outside the physically controlled facility. Figure 4-5 illustrates a scenario where a rogue access point is providing open access to the network from outside the physically controlled area of a facility.

Figure 4-5Figure 4-5 A Rogue Access Point Can Offer an Unsecured Opening to the Network

Employees have relatively free access to a company’s facility, which makes it possible for them to inadvertently install a rogue access point. An employee, for example, might purchase an access point at an office supply store and install it without coordinating with the IT organization to support wireless printing or access to the network from a conference room. Or developers working on wireless applications might connect an access point to the corporate network for testing purposes. In most cases, employees deploying these types of access points do not understand the security issues they’re creating. These scenarios often lead to access points not conforming to adequate security practices. As a result, the corporate network is left wide open for a casual snooper or hacker to attack.

A hacker can install a rogue access point to provide an open, non-secure interface to the corporate network. To do this, the hacker must directly connect the access point to an active network port within the facility. This requires the hacker to pass through physical security, and it is easier to do than most companies assume. Nevertheless, the hacker will need to physically traverse the facility and install the access point without being noticed. It is unlikely that someone would do this unless the company has resources that are critical enough for a hacker to go to the trouble and risk of planting the rogue.

A way to counter unauthorized access is to employ an authentication system that verifies the identity of users, client devices, and access points before allowing them to operate on the WLAN. The user provides a form of credentials, such as username and password or digital certificate, and an authentication server determines whether the person (or client device) can access the network. If not, the network does not allow the client device to connect to the access point. As a result, the access point on the WLAN acts as a security gate to the network. In addition, for added protection, a company can keep all traffic on the WLAN on a virtual LAN (VLAN) that is separate from VLANs supporting sensitive applications and servers. This way, the company can limit the implications resulting from unauthorized access to only the applications and servers supporting the wireless network. A company can even go as far as keeping all WLAN traffic outside the company firewall and requiring all wireless users to implement virtual private network (VPN) client software similar to when connecting to the corporate network from public networks.

Unauthorized Access Leads to Compromise of Financial Data

A large private company in California implemented a WLAN to support enterprise mobility. The system was seemingly working great and providing significant benefits to its users. Over a year after the system went operational, the IT department noticed, through a routine network security audit, that several of its printers in the financial department had been configured to send all printed data to a file at a suspicious IP address. Unfortunately, the IT department had not locked down the administrative access ports on these printers. Even though all the details of what happened here are not known, it is likely that a hacker gained unauthorized access to the WLAN (which did not implement any form of authentication) and ran a port scan to find the open printer administration port. With the open port’s IP address (resulting from the scan), the hacker could easily log in to the administrative port and set the printer to send all print jobs to a file located on the hacker’s laptop. The printer would then continue to print on paper and also send the print data to the hacker’s laptop. Of course this would send to the hacker everything that the printer would print, such as internal goals and objectives, company sales information, employee salaries, and so on. After discovering this issue, the company promptly implemented an authentication system to disallow all unauthorized people from accessing the WLAN.

Denial-of-Service Attacks

A denial-of-service (DoS) attack is an assault that can cripple or disable a WLAN. Wireless networks are extremely vulnerable to DoS attacks (even when using modern security mechanisms), which can cause a WLAN to slow to crawling speeds or even quit working. This causes a company that’s dependent on a WLAN to experience delays, which can be costly for some applications, such as wireless security cameras, inventory systems, and PoS terminals.

One form of DoS attack is the “brute-force” method. This type of attack can come in one of two forms:

  • A huge flood of packets that uses up all the network’s resources and forces it to shut down
  • A very strong radio signal that totally dominates the airwaves and renders access points and radio cards useless

One of the ways a hacker can perform a packet-based brute-force DoS attack is to use other computers on the network to send large numbers of useless packets to the server. This adds significant overhead on the network and takes away usable bandwidth from legitimate users. The use of a very strong radio signal to disrupt the access points and radio cards is a rather risky attack for a hacker to attempt. Because a very powerful transmitter at a relatively close range must be used to execute this type of attack, the owners of the WLAN can find the hacker through the use of homing tools.

Another form of DoS attack fiddles with the 802.11 protocols in a way that disables the network. This can be done via specialized software running on a laptop without connecting to any of the network’s access points. For example, the software can continuously send 802.11 disassociation frames to all client radios, which causes them to disconnect from the access points with which they are associated. This cuts off the client devices from the network, which of course disables them from communicating on the network, accessing applications, and so on. This method and others are well known by network culprits and published readily on the Internet.

DoS attacks are not common, and they are generally implemented over the air, thus disturbing only a small portion of a WLAN. For example, a malicious hacker with a wireless laptop might be outside a building containing a WLAN and begin broadcasting disassociation frames, but only the client radios within range of the malicious person will receive the disassociation frames and disconnect from their respective access points. Other client radios operating farther inside the building, far enough away to not receive disassociation frames, will continue operating.

Sometimes a DoS occurrence on a wireless network might not be intentional. Because the 2.4-GHz version of 802.11n resides in such a crowded spectrum, 2.4-GHz cordless phones, microwave ovens, Bluetooth devices, and other devices that use the 2.4-GHz spectrum might cause a significant reduction in WLAN performance. As a result, a company should fully investigate the use of these devices and possibly put limits on their usage before a WLAN is deemed operational.

There is not much that you can do to entirely prevent a DoS attack. A company can minimize the possibility of DoS attacks against a WLAN by making the facility as resistive as possible to incoming radio signals. This includes using directive antennas near the periphery of the building and aiming the directive side of the antenna indoors to reduce the listening capability of the antenna to signals originating outdoors. In addition, the use of RF shielding paint and window film can add significant attenuation to the exterior walls of the buildings to nearly eliminate jamming signals from outdoors. The problem with these solutions, however, is that they can be expensive and also cut off the usage of other wireless devices, such as cell phones. Also, they are not effective if a hacker somehow gets inside the building to stage the DoS attack. Of course that’s where good physical security practices come into play.

Because of the potential harm, you must consider potential DoS attacks before launching mission-critical applications on a WLAN. If a DoS attack is even a remote possibility, think about how you will get by if the network is not available for an indefinite period of time. The benefits of the WLAN in the long term, however, will likely outweigh the disruption of an occasional DoS attack, assuming that the organization does not depend entirely on the wireless network. Something that should be put in place for any mission-critical WLAN application is a backup plan. A company should not be so dependent on its wireless network that if it goes down, everything grinds to a halt.

As with wired networks, a company should also have a “Plan B” in case the WLAN becomes unavailable because of a DoS attack. For example, a large retail store might use a wireless network to support wireless PoS terminals. In case the wireless network becomes inoperative (possibly due to a DoS attack), the retail store should have a backup plan, such as batching sale transactions for later processing when the network becomes available or when it is possible to connect the terminal to the retail system via a cable.

Nine Switch Commands Every Cisco Network Engineer Needs to Know

switchTo be considered experts, network engineers need experience with a wide variety of commands used with network technology. At the Cisco Certified Network Associate (CCNA) level, Cisco has indicated a number of commands that should be known initially for Cisco network switches. This article covers these commands, explaining what they do and how they alter the behavior and/or use of a Cisco switch.


Syntax: hostname hostname

One of the most basic network commands, hostname configures the hostname used for a device. This hostname identifies the device to other locally connected devices for protocols such as the Cisco Discovery Protocol (CDP), which helps in the identification of devices attached directly to the network. Although it is not case-sensitive, the hostname must follow certain rules: It must begin with a letter and end in a letter or digit, and interior characters must be letters, digits, or hyphens (-).

ip default-gateway

Syntax: ip default-gateway gateway

The ip default-gateway command configures the default gateway for a switch when IP routing is not enabled (with the ip routing global configuration command), which is typical when lower-level Layer 2 switches are being configured. The easiest way to determine whether IP routing has been enabled is to run the show ip route command. When IP routing has not been enabled, the output will look similar to the following example:

SW1#show ip route
Default gateway is

Host               Gateway           Last Use    Total Uses  Interface
ICMP redirect cache is empty

When IP routing is enabled, the output looks similar to the output displayed on a router:

SW1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set is variably subnetted, 2 subnets, 2 masks
C is directly connected, Vlan1
L is directly connected, Vlan1


Syntax: username username {password | secret} password

The username command configures a username and associates a password with it. Using the password or secret version of this command is a matter of security:

  • The password version of this command will do one of two things with the configured password:
    • Place the password into the configuration in plaintext (if the service password-encryption command is not enabled).
    • Put the password through a Cisco-proprietary encryption algorithm before placing it into the configuration. (Note that this encryption is easily reversed.)
  • The secret version of this command will create an MD5 hash with the configured password and then place it into the configuration. This reconfigured password is much harder to crack than the encrypted version created with the password version of this command.

This username/password can be used for a number of different features, including Telnet and SSH.


Syntax: enable {password | secret} password

The enable command configures the password that will be used to access a switch’s privileged configuration mode. Because all configuration of a Cisco IOS switch requires privileged configuration mode, keeping this password private is very important. As with the username command, this command has two options: password and secret. The differences between these two options are the same as those for the username command in the preceding section. The enable secret version of the command should be used in all production environments.

Console and Terminal Login Commands

Five commands are used to configure login via the control and virtual terminal (VTY) lines of a switch:

  • password
  • login
  • exec-timeout
  • service password-encryption
  • copy running-config startup-config

The following sections describe these individual commands.


Syntax: password password

When entered in line-configuration mode (console or terminal), the password command is used to configure the password that will be used to access a switch from that specific line, depending on the line mode (console or terminal). However, the password configured with this command is used only if the login command is used (which is the default).


Syntax: login [local]

The login command is used to enable password checking on an interface. If this command is used without any parameters, the system will check the password entered with the login against the one entered with the password command discussed in the preceding section. If used with the local parameter, both username and password will be prompted, and the entries will then be checked against the local username database that was created with the username command discussed previously.


Syntax: exec-timeout minutes [seconds]

The exec-timeout command is used to configure the amount of time that can pass before a device considers the connection idle and disconnects. By default, timeout is set to 10 minutes. This timeout can be disabled with the no exec-timeout command. (This command is a shortcut and actually enters the exec-timeout 0 0 command into the configuration.)

service password-encryption

Syntax: service password-encryption

The service password-encryption command is used to enable the encryption of configured passwords on a device. The passwords referenced with this command are the ones configured with a command’s password parameter, such as username password and enable password. The passwords encrypted with this command are not highly encrypted and can be broken relatively easily. By and large this command is deprecated, as most network engineers will use the secret version of the appropriate commands; however, even weak protection is better than nothing.

copy running-config startup-config

Syntax: copy running-config startup-config

The copy running-config startup-config command (popularly shortened to copy run start) is one of the most fundamental commands learned by new Cisco network engineers. It copies the active configuration (running-config) on a device to non-volatile memory (NVRAM) (startup-config), which maintains a configuration across a reload. Without this command, a configuration can be lost when a device is reloaded or powered off. The copy command can also be extended to save configuration and IOS images to and from a local device, as well as to and from different locations on the local device.


Network engineers must learn many Cisco OS commands in the process of becoming a CCNA (and beyond), and understanding these basic management commands is where the process starts. Without the knowledge of how to access devices, the complex commands are useless. You must understand when learning these concepts that they are intended to be stacked on top of each other. Lack of knowledge of a few base concepts undermines learning other, more advanced concepts that build on top of those basics.

Five Crucial Commands for Verifying Cisco Switch Network Status and Operational State

CISCOFor Cisco (and many other vendors), new commands are introduced at each progressive level of system verification. This article looks at five essential commands used to verify a network switch’s status and operation:

  • ping
  • traceroute
  • telnet
  • ssh
  • show cdp neighbors


Available on almost all operating system platforms, including Cisco IOS, the ping command is used to verify the reachability of a targeted device. It does this by sending an Internet Control Message Protocol (ICMP) echo message to the target; if the target receives the message (and is not configured to drop it), it responds to the initial sender with an ICMP echo-reply message. In a perfect world, with no firewalls, and all devices configured to respond to these messages, the ping command would work perfectly. However, many devices (or devices en route, like firewalls) are purposely configured to ignore ICMP echo messages automatically, in order to hide their existence and avoid being targeted by attackers. In these cases, engineers must decide whether the unsuccessful ping is a real problem or a purposeful part of a network’s design.

Cisco IOS also has an extended version of the ping command that allows for more complex command configurations. For example, an engineer has the ability to control the source IP used (which makes sense when being run from a router configured with multiple IP addresses), the size of the messages being sent, and the content of the messages, among other options.


The traceroute command is typically used along with the ping command to further determine the reachability of a destination. traceroute works a bit differently from ping; instead of simply sending a message to the destination directly, it aims to find the path from the source to the target destination. It does this by using either ICMP echo messages on Windows or the User Datagram Protocol (UDP) probe messages on Linux and Cisco IOS. It figures out the path by taking advantage of the IP Time to Live (TTL) field.

It’s important to understand what the TTL field does. In normal circumstances, the TTL is used as a loop-prevention mechanism; it works by being set to a number which is then decremented at every respective IP “’hop.” If the TTL reaches a device and is decremented to 0, the packet is dropped and an ICMP “destination unreachable” message is sent back to the source device. When used by the traceroute command, the TTL finds each of the hops in the path between the source and the destination:

  1. Initially the source sends an ICMP or UDP message to the destination with a TTL of 1.
  2. When the packet reaches the first hop, the TTL is decremented to 0; the device drops the packet and sends back an ICMP “destination unreachable” message.
  3. To find the second hop, the TTL is set to 2, for the third hop it’s set to 3, and so on; typically three packets are sent for each step toward the destination (three with a TTL set to 1, three with a TTL set to 2, and so on).
  4. These ICMP “destination unreachable” messages are received by the running traceroute command and interpreted into a readable output showing the path toward the destination.

As with the ping command, many organizations block the ICMP echo messages and some of the UDP messages; and the output should be read with this fact in mind.

The traceroute command on Cisco IOS is extended in the same way as the ping command variant that allows for extended command configurations. The options offered by traceroute mirror most of the options available in an extended ping.


The telnet command has been around for a long time, allowing users to manage devices via a command-line interface. Its very simple operation provides an unsecured Transmission Control Protocol (TCP) session between the source and destination. Characters entered on the source are immediately relayed to the destination, providing an experience on Cisco IOS (and Linux) that is the same as if the user were directly connected into the device locally.

The telnet command uses TCP port 23.


The ssh (secure shell) command works similarly to the telnet command but creates a secure communications channel between source and destination. This means that the username and password are not sent in clear text and are protected (at least to some level) from anyone listening in on the conversation.

The ssh command uses TCP port 22.

show cdp neighbors

The show cdp neighbors command is used on a Cisco IOS device to view neighboring devices discovered by the Cisco Discovery Protocol (CDP). CDP is a Cisco proprietary protocol used for Layer 2 discovery; it has the ability to discover all other supporting CDP devices on a shared segment. (It doesn’t work across Layer 3 devices.) The following example shows some typical output of this command:

R1#show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R2               Fas 0/0            172              R    7206VXR   Fas 0/0

In this example, we learn that the remote device (R2) is connected via R1’s FastEthernet0/0 interface and is connected to R2’s FastEthernet0/0 interface, and R2 is a Cisco 7206VXR router. This information is very helpful when mapping out unfamiliar networks. It can also be used to help ensure that a device is connected to the correct remote device(s) on the correct interface; as engineers often must configure devices remotely, this command is useful when installing new equipment, to ensure that physical interfaces are connected to the appropriate networks.

Keep in mind that CDP is a proprietary protocol and will not work to discover most other non-Cisco devices; this command is enabled by default on Cisco devices. A standards-based alternative to CDP is the Link Layer Discovery Protocol (LLDP)—IEEE 802.1AB, which is supported by many other vendors, but is not enabled by default on Cisco devices.