WEP (Wired Equivalent Privacy)

Setup WEP (Wired Equivalent Privacy)

• Introduction
• Setting up the Access Point
• Setting up the Station

---

Introduction

The 802.11 standard describes the communication that occurs in wireless LANs.

The Wired Equivalent Privacy (WEP) algorithm is used to protect wireless communication from eavesdropping, because wireless transmissions are easier to intercept than transmissions over wired networks, and wireless is a shared medium, everything that is transmitted or received over a wireless network can be intercepted.

WEP relies on a secret key that is shared between a mobile station (e.g. a laptop with a wireless Ethernet card) and an access point (i.e. a base station). The secret key is used to encrypt packets before they are transmitted, and an integrity check is used to ensure that packages are not modified during the transition. The standard does not discuss how the shared key is established. In practice, most installations use a single key that is shared between all mobile stations and access points APs.

WEP employs the key encryption algorithm, Ron's Code 4 Pseudo Random Number Generator (RC4 PRNG). The same key is used to encrypt and decrypt the data.

WEP has defences against this attack. To avoid encrypting two cipher texts with the same key stream, an Initialisation Vector (IV) is used to augment the shared WEP key (secret key) and produce a different RC4 key for each packet, the IV is also included in the package. WEP key (secret key) are available in two types, 64-bits and 128-bits. Many times you will see them referenced as 40-bits and 104-bits instead. The reson for this misnomer is that the WEP key ( 40/104 bits ) is concatenated with the initialisation vector ( 24 bits ) resulting in a 64/128 bit total key size.

---

Setting up the Access Point 

Most access points and clients have the ability to hold up to 4 WEP keys simultaneously. You need to specify one of the 4 keys as default Key for data encryption. To set up the Access Point, you will need to set the one of the following parameters: 

•  64-bit WEP key (secret key) with 5 characters
•  64-bit WEP key (secret key) with 10 hexadecimal digits
• 128-bit WEP key (secret key) with 13 characters 
• 128-bit WEP key (secret key) with 26 hexadecimal digits

You can set up the Access Point by SMT or Web configurator

---

• Setting up the Access Point  from SMT Menu 3.5

B1000 hold up to 4 WEP Keys. You have to specify one of the 4 keys as default Key which be used to encrypt wireless data transmission.
For example,

Menu 3.5 - Wireless LAN Setup                                   ESSID= B1000                                   Hide ESSID= No                                   Channel ID= CH01 2412MHz                                   RTS Threshold= 2432                                   Frag. Threshold= 2432                                   WEP= 64-bit WEP                                          Default Key= 3                                          Key1= 0x123456789A                                            Key2= 0x23456789AB                                             Key3= 0x3456789ABC                                             Key4= 0x456789ABCD                                       Edit MAC Address Filter= No

Key settings    

Hexadecimal digits have to preceded by '0x', 

WEP Key type	Example
64-bit WEP with 5 characters	Key1= 2e3f4 Key2= 5y7js Key3= 24fg7 Key4= 98jui
64-bit WEP with 10 hexadecimal digits ('0-9', 'A-F')	Key1= 0x123456789A Key2= 0x23456789AB Key3= 0x3456789ABC Key4= 0x456789ABCD
128-bit WEP with 13 characters	Key1= 2e3f4w345ytre Key2= 5y7jse8r4i038 Key3= 24fg70okx3fr7 Key4= 98jui2wss35u4
128-bit WEP with 26 hexadecimal digits ('0-9', 'A-F')	Key1= 0x112233445566778899AABBCDEF Key2= 0x2233445566778899AABBCCDDEE Key3= 0x3344556677889900AABBCCDDFF Key4= 0x44556677889900AABBCCDDEEFF

Select one of the WEP key as default  Key  to encrypt wireless data transmission.
The receiver will use the corresponding key to decrypt the data.

For example, if access point use Key 3 to encrypt data, then station will use Key 3 to decrypt data.
So, the Key 3 of station has to equal to the Key 3 of access point.
Though access point use Key 3 as default key, but the station can use the other Key as its default key to encrypt wireless data transmission.

Access Point (encrypt data by Key 3) -------->  Station (decrypt data by Key 3)

Access Point (decrypt data by Key 2)  <--------  Station (encrypt data by Key 2)

In this case, access point transmits data to station which encrypt data by Key 3 of access point. The station will decrypt the data by its Key 3.

At the same time, when the station transmits data to access point which encrypt data by Key 2.The access point will decrypt the data by its Key 2.

---

• Setting up the Access Point with Web configurator

Key settings 

Select one WEP key as default key  to encrypt wireless data transmission.

---

Setting up the Station

1. Double click on the utility icon in your windows task bar or right click the utility icon then select 'Show Config Utility'.

 

The utility will pop up on your windows screen.

Note: If the utility icon doesn't exist in your task bar, click  Start -> Programs -> IEEE802.11b WLAN Card -> IEEE802.11b WLAN Card.

2. Select the 'Encryption' tab.
    Select encryption type correspond with access point.
    Set up 4 Keys which correspond with the WEP Keys of access point.
    And select on WEP key as default  key  to encrypt wireless data transmission.

 

 Key settings    
The WEP Encryption type of station has to equal to the access point.
Check 'ASCII' field for characters WEP key or uncheck 'ASCII' field for Hexadecimal digits WEP key.
Hexadecimal digits don't need to preceded by '0x'.For example,

64-bits with characters WEP key :  
Key1= 2e3f4
Key2= 5y7js
Key3= 24fg7
Key4= 98jui 

64-bits with hexadecimal digits WEP key :  
Key1= 123456789A
Key2= 23456789AB
Key3= 3456789ABC
Key4= 456789ABCD

Thanks to : 

http://www.zyxeltech.de/SNotep660hw/app/WEP.htm

http://www.cisco.com/en/US/docs/wireless/access_point/12.3_7_JA/configuration/guide/s37wep.html

Mark your real location with Google Maps

Google Maps has added a new feature to allow you to “Edit” where your address falls on the map. To do so, you simply enter in your address on Google Maps and select the “Edit” function. From there, you’re now able to move the marker to more accurately show where your residence or business is located.

The idea here is that often times it’s difficult to actually find certain places, even if you have the physical address. I’ve often found this is especially true with newer housing developments, where the location in Google Maps is very approximate at best. The new feature encourages you to drag the marker for a given location to the real entrance point.

Much like a wiki, Google will also save a history of all changes to markers, with an option to “Show Original.” Additionally, when you play around with moving the marker, Maps notes that if you move the marker more than 200 meters, the change will not appear immediately.

The Google Maps team has been busy of late, adding in YouTube videos, expanding Google Transit support, and upgrading their mobile version.

how to remove Babylon Search from Internet Explorer

Even if you remove the software from the computer, in IE it will still let babylon search as the default site for new tabs in the browser.

I don´t know if it is possible to find it in any menu in IE (at least I didn´t), but you can change it in the windows registry.

Open a dos shell, or execute "RegEdit" through the launch menu.

Find the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\About URLs\Tabs

and change the entry that points to babylon search, to the one you desire (be it google, bing, or whatever).

I hope that helps

Edit 2012-03-20:

As spotted by many of you, the right registry key doesn't include "Wow6432Node",

just try:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\About URLs\Tabs  

Thanks to :

http://answers.microsoft.com/en-us/ie/forum/ie8-windows_xp/how-to-remove-babylon-search-from-internet/dee481a1-a563-e011-8dfc-68b599b31bf5

Overview of the CAPWAP Protocol

Current Status and Overview of the CAPWAP Protocol


Author: Gabe Conradi ,

--------------------------------------------------------------------------------

Abstract

This paper presents an overview of the Control and Provisioning of Wireless Access Points (CAPWAP) working group, and the proposals that have emerged from it. The paper covers the current architecture of enterprise WLAN deployments, as well as proposed protocols that attempt to simplify their management and configuration, and allow inter-vendor compatibility of access points (APs) and controllers. The Lightweight Access Point Protocol (LWAPP), Secure Light Access Point Protocol (SLAPP), and CAPWAP protocols are all discussed and compared. Current vendor solutions and interoperability is also covered, and the current state and trends in the enterprise WLAN market are discussed. Open source solutions such as OpenCAPWAP are also inspected, and compared to vendor solutions currently available.





--------------------------------------------------------------------------------

Keywords

CAPWAP, Control and Provisioning of Wireless Access Points, SLAPP, Secure Light Access Point Protocol, LWAPP, Lightweight Access Point Protocol, WLAN, Multi-vendor, Split MAC, Local MAC, Remote MAC, OpenCAPWAP, Centralized Management, Wireless, WLAN, AP, Access Point, Wireless Switch, Wireless Router



Description

An overview of the architecture and protocols use in access point (AP) to controller communication in enterprise grade wireless networks.



Table of Contents

•1. Introduction to CAPWAP

◦1.1 Goals of CAPWAP

◦1.2 Overview of CAPWAP proposals

•2. AP-Controller Architecture

◦2.1 Wireless Controllers

◦2.2 Fat vs. Thin vs. Fit APs

◦2.3 Local MAC Implementations

◦2.4 Remote MAC Implementations

◦2.5 Split MAC Implementations

◦2.6 Important Considerations

•3. Specific Implementations: LWAPP

◦3.1 LWAPP Overview

◦3.2 Split MAC Operation in LWAPP

◦3.3 Security

◦3.4 Current Status

•4. Specific Implementations: SLAPP

◦4.1 SLAPP Overview

◦4.2 Security

◦4.3 Differences Between SLAPP and LWAPP

•5. Specific Implementations: CAPWAP

◦5.1 Protocol Overview

◦5.2 Vendor Positions

■5.2.1 Aruba Networks

■5.2.2 Trapeze Networks

■5.2.3 Cisco Systems

■5.2.4 Meru Networks

•6. Future Directions and Developments

◦6.1 OpenCAPWAP Overview

◦6.2 OpenCAPWAP Implementation

◦6.3 Current Status

•7. Summary

•References

•List of Acronyms

•List of Related Products



--------------------------------------------------------------------------------

1. Introduction to CAPWAP

The term CAPWAP is used for the Control And Provisioning of Wireless Access Points working group. The CAPWAP working group was created in the IETF in order to standardize and define a protocol to ease the implementation of large WLAN deployments that utilize the Controller-AP (Access Point) architecture. The nature of such systems is of such complexity, that vendor implementations can vary widely in their scope and features, leading to incompatibilities between vendors. The significant cost of enterprise level WLAN deployment, coupled with both hardware and software differences on Controllers and Access Points breeds vendor lock-in. Because a vendor change would require the purchase of duplicate Controller and AP hardware, it is often unfeasible for a wireless network to be migrated from one vendor to another. This lack of customer mobility leads to less innovative product offerings from the wireless vendors.



The size of many wireless networks in large companies and universities also introduces many problems of maintaining a consistent configuration across many similar devices, with potentially different hardware capabilities and physical locations. Vendors have provided individual solutions to these issues stated above. However, the implementations are proprietary and have different views on where functionality in the network should be.



The CAPWAP working group seeks to rectify this by specifying a protocol that ensures a common standard for APs and WLAN controllers to communicate with. Thus, the entire process of deploying an AP can be implemented in a vendor neutral format, from finding an initial controller, to deploying firmware updates, to configuration and access point redirection. Ideally controllers of any vendor could provision access points from any other vendor, provided they implement a common CAPWAP protocol. This would allow for more rapid reaction to new innovations in the WLAN sector, as well as improve implementation quality.



This paper is organized as follows: [Section 1] will talk about the goals of the CAPWAP working group. [Section 2] will talk about general architecture of current wireless 802.11 infrastructure, as well as discuss the differences between Split MAC, Local MAC, and Remote MAC layers in APs. [Section 2] will also focus on how so called "Fat APs" are managed and route traffic, as compared to "Thin APs". [Sections 3], [4], and [5] discuss 3 specific protocols that have been proposed, and discusses the differences between them. Next, [Section 6] will look at new trends in the CAPWAP space, and focus specifically on an open source alternative called OpenCAPWAP. Finally, [Section 7] will summarize the key concepts of CAPWAP.



1.1 Goals of CAPWAP

A unified CAPWAP standard aims to be a protocol that could enable centralized wireless hardware utilize a simple, streamlined method of communicating between access points and controllers. As specified by the CAPWAP working group in the IETF (Internet Engineering Task Force), CAPWAP should address 4 main issues. Firstly, it should enable a centralized management solution of the various hardware in a typical WLAN deployment. Second, it should make configuration of multiple hardware types transparent, and ensure configurations are consistent across the network. Third, monitoring the status of both hardware and software configurations is necessary to ensure a properly operating network. And finally, ensuring network security, both from 3rd party hardware, such as rogue access points being connected to the network, as well as preventing the loss of network secrets from the physical theft of access points is also critical. [RFC3990] [Villani] [Jou04]



1.2 Overview of CAPWAP proposals

The challenges facing wireless networks with regard to standardized management and provisioning are difficult. Proposals for a CAPWAP protocol have been submitted to the CAPWAP WG for review. However, some have been met with criticism. 3 specific protocols have surfaced, that have received the most attention and review. The first, LWAPP, or Lightweight Access Point Protocol was proposed, in part supported by Cisco Systems. Next, Aruba Networks and Trapeze proposed a competing protocol named SLAPP, or Secure Light Access Point Protocol, which took a more abstract approach to handling proprietary firmware for vendor's access points. Finally, an updated protocol called CAPWAP, penned by Cisco Systems, Aruba Networks, and Research In Motion, among others, took the place as the front runner of the proposals. [RFC5412] [RFC5413] [RFC5415]



Table of Contents



--------------------------------------------------------------------------------



2. AP-Controller Architecture

In order to understand the CAPWAP, one must first understand the basic controller-AP structure, common to most, if not all enterprise grade wireless network deployments. There are 2 primary components to the wireless network. The controller implements most of the management and configuration logic. The controller acts as a management station, configuration station, and potentially a router. The access point contains the wireless radio(s), and acts as the end point of the network, and communicates directly with user radios. The AP typically contains some amount of logic, however, that amount is governed by the MAC architecture that the AP implements, which will be covered in [Section 2]. A typical diagram of a WLAN network is in [fig1].





Fig. 1: Typical WLAN deployment, with a router, 2 controllers, 5 APs, and clients 2.1 Wireless Controllers

In the typical centralized architecture, one or more controllers manage a set number of deployed access points. Access points retrieve their configuration from the controller, and report their status back to the controller for management purposes. With the typical usage case, data from an access point is tunneled back to the controller for processing, and sending onto the back haul network. In this regard, the controller acts in similar fashion to a router, by accepting and processing layer 2 frames, and then switching layer frames on to the access network. [Sridhar06] Controllers may also provide SNMP (Simple Network Management Protocol) data about associated access points, or other types of monitoring information, such as graphs of traffic data, or numbers of associated users. [Cisco69561]



Wireless controllers have some general tasks that they perform. They are responsible for discovering, authenticating, and registration of APs, as well as maintaining a service channel to communicate over. There are 6 main portions of a controller's duties.



1.AP Discovery

2.Authentication

3.Association

4.Firmware Distribution

5.Management Traffic

6.Configuration

AP Discovery allows a controller to take ownership of an AP, or potentially redirect control to another controller. The controller can then authenticate the AP, and negotiate its advertised capabilities, such as being 802.11a, b, g, or n capable, OFDM (Orthogonal Frequency Division Multiplexing) capable, or what encoding the AP is capable of performing, radio transmit and receive power, and more. The controller then authenticates the AP, and begins uploading firmware to the AP. The firmware is used to program radio capabilities on the AP. During this initialization, as well as operation, periodic control messages must be exchanged between the AP and the controller, for management and statistical purposes. The controller opens a channel to the AP, which stays open for the up time of the access point. Finally configuration takes place, and the AP is set into active mode. All of these capabilities fall into the domain of CAPWAP. [RFC4564]



2.2 Fat vs. Thin vs. Fit APs

Not all access points are alike, as they fall into 3 categories. "Thick APs", or Local MAC implementations perform all the required data processing and relay locally. "Thin APs", or Remote MAC, speak only a proprietary protocol with the controller. The AP's 802.11 MAC layer exists on the controller, so all frames sent by the AP are processed by the controller, and forwarded on, as if it was a remote MAC layer for the AP. Third, so called "Fit APs" have gained popularity in recent years, as they combine both the intelligence of a Local MAC implementation with the agility of a Remote MAC implementation, by splitting realtime and non-realtime functionality between the controller and AP. [Sridhar06]



These 3 MAC layer concepts will be discussed in greater detail in [Section 2.3] and [Section 2.4].



2.3 Local MAC Implementations

Local MAC refers to the location of the 802.11 MAC layer on the device. In this case, the whole MAC stack exists on the AP. Fat APs use this type of MAC layer. All beacon generation, RTS, CTS, and ACKs originate from the Local MAC layer. [RFC4118] As seen in [fig2], both the 802.11 MAC and physical layer reside on the AP.





Fig. 2: 802.11 MAC Distribution in Local MAC

Local MAC has the benefit of being able to perform all of the MAC functions quickly, without having to rely on the controller. However, this power comes at a cost. Fat APs are much more complex, and cost much more per unit than their thinner cousins. Because they are standalone devices, they also cause difficulties when managing a growing network of many devices, as firmware and configuration must be handled on an individual basis for each device.



A Fat AP understands and speaks layer 2 and possible layer 3 protocols, and is addressable on the network. It can perform forwarding between its wireless and wired interfaces, and direct traffic directly onto the network. There is no back haul required for Fat APs, because it can put packets and frames directly on the wire, in contrast to Thin AP implementations. Some Fat APs may handle configuration locally, on a per AP basis. A configuration GUI may be provided over HTTP, as is common with many consumer grade wireless routers, or a command line interface is provided over the SSH or Telnet protocols. Fat APs may implement features such as routing, QoS (Quality of Service), and DHCP configuration for hosts.



2.4 Remote MAC Implementations

A large corporate network with hundreds of APs could use a more centralized solution, which is realized by Thin APs. Thin APs may be found in AP-controller style deployments. The Thin AP speaks only a low level protocol between the controller, and is not accessible via IP. As previously discussed, in the typical AP-controller architecture, access points are not layer 2 or 3 devices. Thin APs have their MAC layers implemented entirely on the controller, and use tunneling to a controller to have all of their frames processed for forwarding onto the back haul network. The controller acts as the AP's remote MAC layer, and handles higher level functions like routing, QoS, and more. The AP would only implement the 802.11 physical layer, and leave the implementation of the MAC layer to the controller. This reduces complexity of the AP. [RFC4188] As seen in [fig3], only the 802.11 physical layer resides on the AP, and the 802.11 MAC layer is on the controller.





Fig. 3: 802.11 MAC Distribution in Remote MAC

The reduction in functionality of the AP with a Remote MAC layer provides many benefits. The cost per unit is much lower than Fat APs, as the only logic necessary for functioning is the radio hardware and a simple wired interface, with memory to store firmware. In some vendor's access points, even wireless encryption is not even performed at the AP. It merely relays the encrypted frames to the controller for processing. Because the AP relies on the controller for its MAC layer, it is sensible to extend this to apply to firmware and configuration as well. [RFC4188] Thin APs lend themselves well to centralized management through controllers. Often refered to as remote antennas, Thin APs lower price allow for a more thorough wireless coverage at a given price point, and are attractive offerings for large deployments.



2.5 Split MAC Implementations

Split MAC layers address the issue of latency in the Remote MAC system, by defining 2 classes of MAC functions: realtime, and non-realtime. Realtime traffic are beacon generation, RTS, CTS, and ACK messages. Non-realtime capabilities are authentication procedures, fragmenting and defragmenting frames, and more. [Sridhar06] As seen in [fig4], the 802.11 physical layer and realtime MAC layer is on the AP, while the controller handles the non-realtime MAC functions.





Fig. 4: 802.11 MAC Distribution in Split MAC

Fit APs are a combination of the Thin and Thick metaphors. The Fit AP may implement a Split MAC layer, or a Thin MAC layer. Fit APs still rely on the controller for configuration and some frame processing. However, the AP can now perform some complex tasks, such as tagging frames with certain VLAN (Virtual LAN) IDs, based on the SSID (Service Set Identifier) of the incoming frame. Fit APs may implement either the Remote MAC 802.11 layer, or the new Split MAC. Split MAC divides the functionality of the MAC layer between the AP and the controller. [RFC4188]



2.6 Important Considerations

It is important to realize that the definition of what a controller is is not clearly defined. The difference between Local, Remote, and Split MAC is also not defined by any standards body. It usually falls to the vendor to create a specific implementation. Many vendors use this to their advantage, and create product differentiation by including features into their wireless products, such as firewall capability in their controller hardware. Allowing, disallowing, or standardizing this is not the goal of the CAPWAP working group, however. CAPWAP only seeks to relay what a device is and is not capable of, in order to classify and provision the device into operation.



Table of Contents



--------------------------------------------------------------------------------



3. Specific Implementations: LWAPP

The LWAPP protocol was the first protocol to be proposed. It was initially designed by Airespace, which was later bought out by Cisco in 2005. LWAPP was introduced in [RFC5412], and defined the process of authenticating an AP with a controller, distributing firmware and configuration, as well as defining the transport header for LWAPP traffic. [RFC5412]



3.1 LWAPP Overview



Fig. 4: Diagram of LWAPP State Machine

LWAPP defines the state machine that governs both the AP and the controller's communication with each other. [fig5] The basic functionality that is encapsulated within this protocol is as follows.



1.Discovery - New APs must seek out a controller with which to associate. This is accomplished by the AP broadcasting a Discovery Request. A controller must respond with a Discovery Response. The AP then joins to a controller, and is acknowledged by the controller.



2.Image Download - The newly joined AP then may request a firmware update, upon seeing the controller advertise a higher version of code. The AP then downloads the firmware, and once completed, enters the Reset state, and then attempts to rejoin a controller.



3.Configure - An AP with a sufficient version of code may then request to be configured by the controller. The AP sends the controller its current configuration, and the controller responds with an updated configuration. Once the AP has received the configuration, it may enter the Run state.



4.Run - Both the controller and AP operate in the Run state. The AP forwards packets to the controller, and maintains normal operation. From the Run state, an AP and controller may exchange new key material, by entering the Key Update state. This state updates the encryption keys on both devices, which is used to encrypt all further messages, until a new key is requested.



The standard also defines the layer 2 and 3 headers to encapsulate LWAPP messages. However, the header does not warrant any particular attention, and as such, will not be covered by this paper. Because the protocol can operate over IP networks, the network topology of an LWAPP compliant WLAN is not limited by broadcast domain requirements. [Cisco99947] This is necessary to enable AP Discovery to function outside of a subnet. This overview of LWAPP is by no means comprehensive. A full specification is preserved in [RFC5412].



3.2 Split MAC Operation in LWAPP

LWAPP defines certain operation modes for compliant hardware. The controller has a fixed set of 802.11 duties, as does the AP. As part of LWAPP's 802.11 binding, it specifies both Split MAC and Local MAC functionality. The Split MAC implementation in LWAPP is identical to the description given in [Section 2.5]. [RFC4118]



The Local MAC implementation pushes all operation of the MAC layer onto the AP. The only duties that the controller is responsible for under this scheme is wireless key management and authentication proxying. The AP handles the encryption of traffic between itself and its clients, with the controller provided keys.



3.3 Security

Communication between a controller and AP must be encrypted, as all data sent to and received by the AP will be tunneled over the local LAN to or from the controller. However, LWAPP only specifies how to encrypt traffic between the controller and AP endpoints. It claims that the physical security of the LAN prevents most attackers from accessing the stream between controller and AP, but does not guarantee against traffic sniffing beyond the scope of LWAPP, and suggests that in the requirement of full end to end encryption, IPsec be used.



The controller and AP will exchange 2 types of messages: control messages, and data messages. The proposal cites the availability of IPsec for general data traffic, and does not provide any mechanism of encrypting data messages between the controller and AP, only control messages, and the key exchange process between both devices. However, some control messages are transmitted unencrypted, such as Discovery Requests and Responses, because of the lack a preexisting association between the 2 devices. The rest of the control sequence, from the Configure state onward, is encrypted with AES-CCM. The wireless key exchange is handled in a fully encrypted fashion, by utilizing preshared keys (PSKs), or a security certificate model. [RFC5412]



3.4 Current Status

The [RFC5412] that defines LWAPP has been marked as "Historic", as it has been superseded by the CAPWAP specification [RFC515] [Section 5]. Vendors such as Trapeze criticized the specification, as it makes assumptions about the topology of the network that the WLAN will be deployed on, as well as assumptions about the complexity and functionality implemented by the AP, by allowing only Local and Split MAC implementations. [Trapeze05] The protocol was originally proposed by Airespace as a vendor neutral alternative to Cisco's wireless offerings. It was seen as overly complex, as well as lacking in security, as portions of the control stream are unencrypted, and the entire data stream between controller and AP are unencrypted. However, Airespace was purchased by Cisco in 2005, and the LWAPP proposal would later become the basis of the CAPWAP standard, as discussed in [Section 5].



Table of Contents



--------------------------------------------------------------------------------



4. Specific Implementations: SLAPP

Wireless vendors Aruba and Trapeze took a different route than Airespace in designing their protocol, called Secure Light Access Point Protocol, or SLAPP. SLAPP was designed as a simple, extensible protocol that could be extended to other wireless standards, and allow for newer authentication schemes and control protocols to be implemented on top of SLAPP. [Trapeze05] This more abstract approach enables SLAPP to be implemented in standards outside of 802.11, with different topology, hardware, and implementation details. [Judge06] A stated goal in the specification is to allow this technology to be applied to any application requiring a master controller provisioning clients from different vendors. Thus, SLAPP does not seek to implement a control protocol, or manage the configuration of nodes. Rather, it attempts to provide the framework with which devices may request a specific configuration method, which is then layered on top of SLAPP. However, [RFC5413] does give two example protocols: one for controlling wireless APs, and one to manage firmware updates to APs.



4.1 SLAPP Overview



Fig. 6: SLAPP State Machine

SLAPP operates as the framework to make a connection between two devices, and negotiate a protocol. In [fig6], the same SLAPP protocol would be used by an AP to decide how to download updated firmware, as would be used to determine a protocol to communicate with the controller. The state machine in [fig6] show the 4 states attainable during protocol negotiation by a device. [RFC5413]



1.Discovery - Discovery is the initial broadcast from an AP, informing controllers that they are interested in communicating in a specific protocol. The controller awaits a Discovery Request from an AP. Once received, the controller moves to the Acquiring phase without responding yet.The AP broadcasts a Discovery Request, and upon reception of the response, moves to the Acquiring phase as well.



2.Acquiring - This state represents both devices connecting to each other, to begin encrypting their communications. The controller processes the Discovery Request, and if valid, responds in the positive, and moves to Securing. Otherwise it moves back to the Discovery state. The AP transitions to the Securing phase when a "client hello" message has been received. This marks the beginning of a DTLS conversation, or Datagram Transport Layer Security [RFC4347]. If a timer expires while the AP is in the Acquiring phase before receiving a "client hello", the AP goes back to Discovery mode.



3.Securing - This phase establishes an encrypted tunnel, over which a protocol can be agreed upon. The controller transmits a "client end" message, to signify the termination of the DTLS exchange. The controller then moves into the Negotiated Control Protocol state. The AP reciprocates the DTLS connection, and when finished, transmits the "server end" message. When the DTLS exchange is completed, the AP moves to Negotiated Control Protocol.



4.Negotiated Control Protocol - Here both devices begin communicating in the previously agreed-upon protocol. This protocol can be anything, as long as both sides agreed on it.



4.2 Security

As mentioned in [Section 4.1], a DTLS tunnel is created between the controller and AP for encrypting their session. [RFC5413] The connection between the 2 devices is not necessarily a fully encrypted stream, however. The DTLS tunnel allows for different authentication styles, ranging from full stream encryption, to one way encryption, to anonymous authentication. The benefits of this model are such that it does not enforce a specific security model onto the design of the underlying standard, and as mentioned previously, allows the SLAPP standard to be applied to more protocols than just 802.11.



4.3 Differences Between SLAPP and LWAPP

The process of pairing and authentication of the controller and AP is considerably more simple than in LWAPP from [Section 3]. However, this simplicity does not come at the expense of flexibility. The security model in SLAPP allows for a wider range of deployment across different controller-AP configurations. However, the SLAPP protocol is fundamentally different from LWAPP, in that it attempts to solve only a subset of the problems that the CAPWAP specification is meant to address. More specifically, it fails to define key duties mentioned in [Section 2.1], such as number 4, Firmware Distribution, number 5, Management Traffic, and number 6, Configuration. The reasoning behind this incomplete fulfillment of the CAPWAP goals is due to the extensible nature of the SLAPP protocol. Unlike LWAPP, which specified that there must be a configuration exchange as part of the AP association, SLAPP leaves such technicalities to the specific implementation, being able to adapt to future protocol changes.



Critics of SLAPP argue that it is an incomplete specification, as it enforces no minimal compatibility. Vendors do not have a clearly defined set of protocols that must be implemented, in order to be compatible with other vendors. Instead, this protocol leaves the market vulnerable to more proprietary firmware and configuration exchange protocols running on top of SLAPP. For example, vendor X may use SLAPP in its hardware, negotiate proprietary protocols A, B, and C over SLAPP. Vendor Y also uses SLAPP, but cannot interact with vendor X's products, because it implements protocols B, C, and D. By this logic, the SLAPP protocol has done nothing to further the CAPWAP working groups goals of vendor neutrality in the managed WLAN product space.



A different benefit of SLAPP is that it does not enforce a specific 802.11 MAC implementation on the AP. A client AP is free to use Local, Remote, or Split MAC layers, as long as the controller it is associated to supports it. Additionally, because of its generic design, the network location of an AP and controller do not necessarily have to be within the same broadcast domain. Because SLAPP supports both layer 2 and 3, access points may be in completely different routed networks as the controller, or even across the Internet. And finally, in contrast to LWAPP, all traffic over SLAPP is encrypted, not just control channel traffic.



It should be noted that SLAPP has since obsoleted by CAPWAP [RFC5415].



Table of Contents



--------------------------------------------------------------------------------



5. Specific Implementations: CAPWAP

The most recent protocol that has come out of the CAPWAP working group is named CAPWAP. It was produced in part by Cisco, Aruba Networks, and Research in Motion. It combines the strengths of SLAPP's generic design and extensibility, while utilizing LWAPP's state machine for managing the connection between AP and controller. The security model is not ported over from LWAPP, as there were many concerns about the validity of the security. An express goal of the CAPWAP protocol is enabling thinner APs, which implement Split MAC, in order to drive innovation in the market by lowering the required computing power in an AP, and thus AP prices. [Cisco69561] Local MAC operation is permitted as well. [RFC5415]



5.1 Protocol Overview

The state machine of CAPWAP is similar to LWAPP's, but with the addition of a full DTLS tunnel establishment, borrowed from SLAPP. The standard provides configuration management and device management, allowing for configurations and firmware to be pushed to APs. Because the overall state design of the CAPWAP protocol is largely the same as the FSM in LWAPP, a detailed diagram is not needed. Consult [RFC5415] for a full overview.



This protocol differentiates between data traffic and control traffic, as LWAPP did. However, only the control messages are transmitted in a DTLS tunnel still. The publishers argue that an unencrypted data channel is not a security threat, because full IPsec is available. More consideration has been placed on ensuring that CAPWAP is secure, by taking advantage of the security offered by requiring full encryption with authentication between the controller and AP. This creates some inconveniences, however, in that both APs and controllers need to be preconfigured in order to associate with each other. Both the AP and controller must be either loaded with PSKs or certificate files to enable encrypted communication. Access Control Lists are also implemented to prevent rogue CAPWAP controllers from hijacking unassociated APs.



5.2 Vendor Positions

LWAPP has been approved by the IETF, but has not seen very widespread deployment. There has been no major consensus between these two technologies, until the CAPWAP protocol was proposed. Now, vendors have begun to slowly migrate towards CAPWAP support. However, the process is slow, as upgrade paths are not necessarily direct and simple.



5.2.1 Aruba Networks

Aruba was one of the core members of the SLAPP proposal. Although it strongly advocated SLAPP, it currently uses a homegrown system called PAPI. [Aruba09] Aruba states many issues with CAPWAP, namely that of inflexibility. [Aruba09] SLAPP's strong suite was in allowing freedom of control protocol, in the face of new architecture advances. [Judge06] CAPWAP and LWAPP do not take into account new and upcoming standards that could potentially change the problem of CAPWAP. Aruba also claims that as of March 2009, no vendor has implemented CAPWAP per the [RFC5415] specifications, instead claiming that vendors have been using proprietary extensions to complete the specification. [Aruba09]



Aruba plans to roll out support for CAPWAP when the specification has become more standardized, but does not plan to replace its current PAPI technology. [Aruba09] However, Aruba is known for its management hardware, such as AirWave Management System, which can interface with other vendor's APs over various technologies. Examples of support include both Meru and Cisco wireless access points, using SWAN, LWAPP, and CAPWAP protocols.



5.2.2 Trapeze Networks

Trapeze was also involved in penning the SLAPP standard. In a press release in 2005 [Trapeze05], it talked about SLAPP's benefits over implementations such as LWAPP. Quoting increased consumer choice and innovation, However, Trapeze makes no indication of future support of the CAPWAP protocol. [Trapeze05]



5.2.3 Cisco Systems

Cisco incorporated the LWAPP protocol into its WLAN offerings after purchasing Airespace in 2005, who initially proposed LWAPP. Cisco then pushed CAPWAP, based on LWAPP, and is currently in the process of migrating from LWAPP to CAPWAP in its controller offerings, and as of Cisco's controller software 5.2, CAPWAP has become the only controller-AP communication scheme. This limits interoperability to only vendors who have implemented [RFC5415], which is just Cisco as of the time of this writing. [Cisco69561]



5.2.4 Meru Networks

Meru has not been involved in any of the IETF proceedings for the creation of the CAPWAP specification. Currently, their WLAN controllers can only interface with Meru brand access points, utilizing a proprietary protocol. Meru Air Traffic Control software may be used to provision and manage APs, but provides no multi vendor support. However, Aruba hardware may be used to provision and monitor Meru APs via SNMP. Meru has made no plans public for enabling support for a standards compliant method of AP-controller interaction.



Table of Contents



--------------------------------------------------------------------------------



6. Future Directions and Developments

The creation of a vendor neutral protocol is a potential boon to consumers of enterprise grade managed wireless solutions. However, the capabilities of CAPWAP may only be realized if and when vendors decide to support the protocol. Vendors have expressed doubt about the importance of an overarching standard for AP-controller interaction [Judge06], because of the lack of visibility to the end user. The WLAN market is structured similarly to an oligopoly, because the market is controlled by a very small set of vendors, namely Aruba, Cisco, Meru, and Trapeze. Oligopolies are typically resistant to destabilization of the market, introduced by large paradigm shifts, such as the shift that is promised by CAPWAP.



6.1 OpenCAPWAP Overview

An open source project named OpenCAPWAP aims at providing an alternative to large vendors. OpenCAPWAP is an open source implementation of the CAPWAP protocol, targeting commodity hardware running Linux. The goal of the project is to provide a free and open source to proprietary controller hardware and software, which can cost in upwards of $20,000. [Ecrater]



6.2 OpenCAPWAP Implementation



Fig. 7: OpenCAPWAP Server threading model

OpenCAPWAP is implemented as 2 Linux applications. The first is targeted at server hardware, and handles the operation of the controller. It is a multi-threaded implementation of the CAPWAP state machine specified in [RFC5415]. There are two types of threads that may be instantiated on the controller: Receiver and Session Manager [fig7]. A single Receiver thread receives and processes any requests from APs. The Receiver is then responsible for processing the packets, and either dropping the packets, or moving a good connection into a Session Manager Thread. A Session Manager is instantiated for each open connection to an AP, and engages in communication with the AP with the CAPWAP protocol. [Bernaschi09]





Fig. 8: OpenCAPWAP AP threading model

The second program is run on each AP, in order to facilitate communication between the AP and controller. There are 3 types of AP threads, and no more than 3 threads may be active at any one time: Principal, Receiver, and Receiver-From-STA. Please see [fig 8] for a diagram. The Principal thread begins communication with the CAPWAP Discovery Request message. It is responsible for sending CAPWAP messages to the controller. The Principal thread creates a Receiver thread, to handle the responses from the controller. However, the Principal and Receiver thread share sent and received packets with each other. The division between the sending and receiving of CAPWAP messages is that the communication between the AP and controller is not necessarily synchronous, and the controller may send a request while the Principal thread is sending. The final thread that is created in the AP is the Receive-From-STA thread. This thread is used to accept non-realtime requests from the associated client stations, such as any message in Split MAC that may need to be forwarded to the controller in the CAPWAP protocol. The Receiver-From-STA thread can pass along messages through the Principal thread, which are sent back to the controller for processing. [Bernaschi09]



6.3 Current Status

The implementation described in [Bernaschi09] is not ready for currently available APs. The testing was conducted with computers running Linux, with wireless cards as their radio, and wired interfaces as their link to the controller. The authors of OpenCAPWAP note that because the definition of Split MAC is fairly loose, in that the definition of what realtime MAC functionality is changes from vendor to vendor, each AP that supports Split MAC has a different implementation. The lack of a vendor consensus of what functionality should reside in the AP and in the controller for Split MAC is currently preventing the OpenCAPWAP team from supporting a wide range of AP hardware with Split MAC mode currently. [Bernaschi09] However, Local MAC is fully supported, albeit on a desktop Linux platform, and not the embedded platforms common to most vendor's APs. Thus, OpenCAPWAP is only a proof of concept, as they are limited in the hardware that they may support, by a lack of common target hardware, as well as differencing 802.11 MAC implementations.



Table of Contents



--------------------------------------------------------------------------------



7. Summary

In this survey, a look at different proposed standards for enabling WLAN controllers to support multi-vendor APs, and how to solve the problems introduced by the AP-controller architecture, has been taken. First, an overview of the 4 overarching goals to be addressed by a CAPWAP protocol was given. The protocol must enable centralized management of the components of a WLAN, allow for transparent support of different vendor's hardware, be able to provide monitoring of hardware and software configuration and status, and finally ensure network security. The AP-controller architecture was discussed in detail, and the distinction between Local MAC, Split MAC, and Remote MAC 802.11 MAC layer implementations was given, in order to accurately cover the current and possible divisions of labor between APs and controllers at the MAC layer.



3 protocols were introduced that attempted to solve these issues: LWAPP, SLAPP, and CAPWAP. Two different approaches were taken with LWAPP and SLAPP. LWAPP tried to solve the specific problem of associating APs to controllers, and managing firmware and configuration updates. However, LWAPP introduced many security concerns with its design. SLAPP attempted to solve a more general problem, not limiting itself to 802.11 networks, and not enforcing specific phases of association. Instead, SLAPP proposed a generic protocol for an AP style device to seek out a controller, and establish an encrypted connection, over which a protocol would be agreed upon, and carried out. SLAPP was criticized because it did not solve the specific problem statement laid out by the CAPWAP working group. The CAPWAP protocol was then analyzed, which combined the direct approach of LWAPP, with the powerful and flexible security of SLAPP.



CAPWAP has emerged as the most promising standard, and has obsoleted the previous RFCs that defined LWAPP and SLAPP. The support of the protocol from the 4 major WLAN vendors Aruba Networks, Cisco Systems, Trapeze Networks, and Meru Networks were given brief overviews. The status of interoperability between vendors currently was discussed, as well as the plans of each vendor to support CAPWAP in the future. Finally, the open source OpenCAPWAP proof of concept was discussed, both in its implementation, and current status.



CAPWAP is becoming the defacto standard for enabling operation between different hardware vendors. However, the protocol itself is not finalized, resulting in both hesitation to implement on vendor's parts, and incomplete or incompatible current implementations. Major vendors have also expressed doubt over the demand from customers for interoperable WLAN infrastructure. Some vendors have produced products that allow operation with multiple brands of AP, such as Aruba Network's AirWave being able to provision and control Aruba, Cisco, and Meru access points. However, this compatibility was not the result of CAPWAP, but rather specific licensing deals between each supported company. The only vendor that has produced a CAPWAP implementation thus far is Cisco, but it relies on some proprietary protocols, thus limiting compatibility.



The need for flexible wireless network infrastructure will become more pronounced as WLANs become larger and more widespread. A standard that ensures compatibility between vendors is necessary to prevent vendor lock-in. The migration towards a unified standard will be long, and not necessarily even happen, because each vendor already supports its own proprietary protocols, and sees little motivation to commoditize their AP hardware by introducing CAPWAP across the industry. However, open source solutions such as OpenCAPWAP could provide incentive to vendors to begin deploying an interoperable standard for CAPWAP.



Table of Contents



--------------------------------------------------------------------------------



References

[Sridhar06] T. Sridhar, "Wireless LAN Switches -- Functions and Deployment" The Internet Protocol Journal Vol. 9 Num 3, September 2006, http://www.cisco.mn/web/about/ac123/ac147/archived_issues/ipj_9-3/wireless_lan_switches.html



[Cisco69561] "Wireless LAN Controller (WLC) FAQ", Cisco Systems, Document ID 69561, http://www.cisco.com/en/US/products/ps6366/products_qanda_item09186a008064a991.shtml



[Villani] Alessandro Villani, Renato Lo Cigno, "AP Management and Handover support CapWap and 802.11f", http://www.dit.unitn.it/~locigno/didattica/NC/08-09/4_CapWap-802-11f_H.pdf



[RFC4564] "RFC 4564 - Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", http://tools.ietf.org/html/rfc4564 July 2006



[RFC5412] "RFC 5412 - Lightweight Access Point Protocol", http://tools.ietf.org/html/rfc5412 February 2010



[RFC5413] "RFC 5413 - SLAPP: Secure Light Access Point Protocol" http://tools.ietf.org/html/rfc5413 February 2010



[RFC5415] "RFC 5415 - Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification" http://tools.ietf.org/html/rfc5415 March 2009



[RFC5416] "RFC 5416 - Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11" http://tools.ietf.org/html/rfc5416 March 2009



[RFC5417] "RFC 5417 - Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option" http://tools.ietf.org/html/rfc5417 March 2009



[RFC4118] "RFC 4118 - Architecture Taxonomy for Control and Provisioning of Wireless Access Points" http://tools.ietf.org/html/rfc4118 June 2005



[RFC3990] "RFC 3990 - Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement" http://tools.ietf.org/html/rfc4118 February 2005



[RFC4347] "RFC 4347 - Datagram Transport Layer Security version 1.2" http://tools.ietf.org/html/rfc4347.txt, April 2006



[Bernaschi09] M. Bernaschi, F. Cacace, G. Iannello, M. Vellucci, L. Vollero, "OpenCAPWAP: An open source CAPWAP implementation for the management and configuration of WiFi hot-spots", Computer Networks Volume 53, Issue 2, Page 217, 2009, http://portal.acm.org/citation.cfm?id=1482177.1482276



[Cisco99947] "LWAPP Traffic Study", Cisco Systems, Document ID 99947, http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a0080901caa.shtml



[Aruba09] "Aruba Networks Position Statement on CAPWAP", Aruba Networks, http://airheads.arubanetworks.com/vBulletin/attachment.php?attachmentid=25∧d=1245859157 March 27, 2009



[Trapeze05] "Trapeze Networks Drives New Solution for Access Point Interoperability in IETF CAPWAP Working Group", Trapeze Networks, http://www.trapezenetworks.com/news/press_releases/69/



[Molta05] "WLAN standards battle: In search of the real CAPWAP" Dave Molta, Network Computing, http://www.commsdesign.com/news/tech_beat/showArticle.jhtml?articleID=160501719 April 06, 2005



[Molta07] "Enterprise Wi-Fi Architecture -- Proprietary from Edge to Core", Dave Molta, Network Computing, http://www.networkcomputing.com/wireless/enterprise-wi-fi-architecture--proprietary-from-edge-to-core.php March 12 2007



[Fierce06] "IETF selects Cisco's LWAPP" http://www.fiercebroadbandwireless.com/story/ietf-selects-cisco-s-lwapp/2006-01-11 January 2006



[Judge06] Peter Judge, "IETF approves controversial Cisco Wi-Fi standard" http://news.techworld.com/mobile-wireless/5126/ietf-approves-controversial-cisco-wi-fi-standard/ January 2006



[Jou04] Tyan-Shu Jou, Ted Kuo, Ming Sheu, "WLAN Mesh in CAPWAP Architecture", May 2004, https://mentor.ieee.org/802.11/dcn/04/11-04-0527-01-0wng-wlan-mesh-in-capwap-architecture.ppt



[Mathias08] Craig Mathias, "The WLAN wars are back - with a vengeance" http://features.techworld.com/mobile-wireless/4065/the-wlan-wars-are-back--with-a-vengeance/ April 2008



[Jones05] Dan Jones, "Aruba Doffs Its CAPWAP", Light Reading Mobile, http://www.lightreading.com/document.asp?doc_id=71482 April 5 2005



[Judge05] Peter Judge, "Aruba open sources access-point code", Tech World, http://news.techworld.com/mobile-wireless/3290/aruba-open-sources-access-point-code/ March 10 2005



[Ecrater] "Meru (MN-MC3100-xx) Wireless gateway/controller for (1-100 AP's)", eCrater, http://www.ecrater.com/product.php?pid=4823713 Website that retails Meru Wireless Controllers

Thanks to :
For references:
http://www.cse.wustl.edu/~jain/cse574-10/ftp/capwap/index.html
http://www.ietf.org/rfc/rfc5415.txt

ADSL2 + Linksys WRT310N - Setting up a Linksys router for DSL Internet connection

Setting up a Linksys router for DSL Internet connection

This article will guide you on how to properly setup your Linksys router for DSL Internet connection.
Before setting up your Linksys router, make sure that your computer has active Internet connection.  You can do this by connecting your computer to the modem using an Ethernet cable and try browsing any website.  If you cannot access the Internet, contact your Internet Service Provider (ISP).  You can also contact them if you are uncertain about the type of Internet connection you have.
NOTE:  If your Internet service does not involve a modem, you can contact your ISP to verify your connection type and determine what kind of cable is to be used.

NOTE:  Image may vary depending on the type of modem and computer you are using.
Setting up a Linksys router for DSL Internet Connection
There are two ways to do this:

i.      Setting up your Linksys router using Cisco Connect (Setup CD)
ii.     Setting up your Linksys router using the web-based setup page

Setting up your Linksys router using Cisco Connect (Setup CD)

All Linksys devices come with a Setup Wizard for easy installation.  All you need to do is follow the steps provided.  The Setup Wizard/Cisco Connect software will automatically detect the type of Internet connection from your ISP.  If you lost the Setup CD that came with the router, you may download from the Cisco HomeSupport website.

NOTE:  The software assumes that your computer is connected directly to the modem as shown in the image above.

Also, the modem might have the same IP address as the Linksys’ default gateway address.  It is recommended to change the IP address of either the modem or the Linksys router to avoid an IP address conflict.  To learn how to change the IP address of the router, click here.

Setting up your Linksys router using the web-based setup page

The steps provided below will guide you on how to set up your router manually.  It is recommended to do the following steps if the Setup Wizard/ Cisco Connect software did not succeed in setting up the router automatically.

NOTE:  Before doing the following steps, make sure you know the configuration type of the modem.  To know the current configuration type of your modem, contact your ISP.

Step 1:
Connect the computer to one of the Ethernet ports on the router using an Ethernet cable.

NOTE:  Images may vary depending on the type of computer or router you are using.

Step 2:
Plug-in the router’s power adapter to a power source and connect the other end to the power port of the router.

NOTE:  If your router has a power switch, turn it ON.  Observe the power light of your router until it becomes stable.

Step 3:
Access the router’s web-based setup page by opening a web browser such as Internet Explorer or Safari.  On the Address bar, enter your router’s local IP address then press [Enter].  When the login prompt appears, enter your router’s Username and Password.

NOTE:  The default IP address of Linksys routers is 192.168.1.1 while the default password is “admin” and the user name field is left blank.  If you have set a password before but forgot it, you need to reset the device.  For instructions on how to reset a Linksys router, click here.

Step 4:
Set your preferred Internet connection type:

i.     For PPPoE Connection Setting
ii.    For Automatic Configuration – DHCP Setting

For PPPoE Connection Setting

This type of router configuration is ideal for connecting to a modem which is set to Bridged Mode.  A Bridged modem means you need to have a PPPoE dialer setup on a computer or router to activate Internet connectivity.

Step 1:
On the Setup tab, click the drop-down arrow for Internet Connection Type then, select PPPoE.

Step 2:
Enter the PPPoE Username and the Password provided by your ISP.  Select Keep Alive and click on the Save Settings button at the bottom of the page.

NOTE:  The PPPOE password is case sensitive and would not let you save your settings when you have entered the wrong one.  Make sure that you enter the password using the correct letter cases.  For information regarding your PPPoE Username and Password, contact your Internet Service Provider (ISP).

NOTE:  For information regarding your PPPoE Username and Password, contact your Internet Service Provider (ISP).

Step 3:
Click the Status tab.

Step 4:
On the Status tab, click on the Connect button if the Login Status is Disconnected.

NOTE:  If you don’t have Internet IP address and DNS servers under the Status tab you might need to powercycle the router.  Powercycling is done by unplugging the power adapter of the router for 30 seconds and plugging it back in.

For Automatic Configuration – DHCP Setting

This type of router configuration is ideal for connecting to a modem in PPPoE Mode.  This means that the modem may have its router capability activated as well.  This might create a conflict with the router’s routing operation if the IP address of the modem and router are the same.  To solve this issue, you can change the router’s IP address range to eliminate the conflict.

NOTE:  Make sure the modem is not connected to the router while doing the following steps.  Otherwise, you might end up accessing the modem’s web-based setup page.

Step 1:
On the Setup tab, select Automatic Configuration – DHCP for Internet Connection Type.  Then change the value of the 3rd box on the IP Address field.

NOTE:  In this example, the IP address used was 192.168.2.1.

Step 2:
Click Save Settings.

Now that you have configured the settings of the router, you can connect the modem to the Internet port of the router using an Ethernet cable.

You should now have successfully set up your Linksys Router for DSL Internet connection.



Thanks to :

http://www6.nohold.net/Cisco2/ukp.aspx?pid=80&login=1&app=search&vw=1&articleid=3687

Rescuing your DSL password from a Beetel 220BX ADSL2+ Modem

Posted by n00dl3s • Saturday, October 24. 2009 • Category: InSecurity In case it helps anybody...

If you don't know the DSL password which connects your Beetel 220BX to the ISP network (Airtel in India does never provide it to the customers, they'd rather send a guy to enter it by hand...), but the router still functions, you can get the passwords even though you only see ******** in the web-interface. It's really easy:

1. Connect to the router IP with telnet (user: admin, password is the same as for the web-interface)
2. Go to Management (press 9)
3. Go to Settings (press 1)
3. Dump settings (press 3)
4. Look for the line that starts with: ppp_conId1 userName="***********_dsl@airtelbroadband.in" password="cGFzc3dvcmQ=" ....
5. Copy and paste the value of password into a base64 decoder (locally or i.e. you can use an online decoder, such as here: http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/)
6. Congrats, you now have your DSL password which Airtel wouldn't tell you ;)

Thanks to :

http://united-geeks.org/blog/archives/99-Rescuing-your-DSL-password-from-a-Beetel-220BX-ADSL2+-Modem.html

Pinouts - Samsung cell phones cable connector pinout

------

many samsung pinouts in one image

------
Thanks to :
The pinouts of any standard makes can seen here :
http://pinouts.ru/CellularPhones-P-W/all_samsung_pinout.shtml

DVDs Regional coding-S-Video-Speaker Cables

-----------

DVD's Regional Coding

DVD's are encoded for six different regions around the world. Hollywood's film studios have been alarmed when DVD started to take off. An encoding principle was introduced, to prevent discs of the latest movies being played in countries where the particular movies have not been brought out at this time. A digital flag on the disc tells the DVD player where the DVD comes from. The DVD player should play only the permitted DVDs for the region where the DVD player was bought.
This priciple is not acceptable for professional and AV installations and a lot of interregional players are available already.

Region 0:	Plays on any DVD player
Region 1:	USA
Region 2:	Europe and Japan
Region 3:	Asian Pacific
Region 4:	Australia, New Zealand and Latin America
Region 5:	Africa, Russia and Eastern Europe
Region 6:	China and Hong Kong
Region 7:	Reserved for broadcasting
Region 8:	Special international venues (airplanes, cruise ships, etc.)

-----------

Television Standards by Country

COUNTRY	SIGNAL TYPE
AFGHANISTAN	PAL B, SECAM B
ALBANIA	PAL B/G
ALGERIA	PAL B/G
ANGOLA	PAL I
ANTARCTICA	NTSC M
ANTIGUA & BARBUDA	NTSC M
ARGENTINA	PAL N
ARMENIA	SECAM D/K
ARUBA	NTSC M
AUSTRALIA	PAL B/G
AUSTRIA	PAL B/G
AZERBAIJAN	SECAM D/K
AZORES	PAL B
BAHAMAS	NTSC M
BAHRAIN	PAL B/G
BANGLADESH	PAL B
BARBADOS	NTSC M
BELARUS	SECAM D/K
BELGIUM	PAL B/H
BELGIUM (ARMED FORCES NETWORK)	NTSC M
BELIZE	NTSC M
BENIN	SECAM K
BERMUDA	NTSC M
BOLIVIA	NTSC M
BOSNIA/HERZEGOVINA	PAL B/H
BOTSWANA	SECAM K, PAL I
BRAZIL	PAL M
BRITISH INDIAN OCEAN TERRITORY (AF DIEGO GARCIA TV - AFRTS)	NTSC M
BRUNEI DARUSSALAM	PAL B
BULGARIA	PAL
BURKINA FASO	SECAM K
BURUNDI	SECAM K
CAMBODIA	PAL B/G, NTSC M
CAMEROON	PAL B/G
CANADA	NTSC M
CANARY ISLANDS	PAL B/G
CENTRAL AFRICAN REPUBLIC	SECAM K
CHAD	SECAM D
CHILE	NTSC M
CHINA (PEOPLE'S REPUBLIC)	PAL D
COLOMBIA	NTSC M
CONGO (PEOPLE'S REPUBLIC)	SECAM K
CONGO, DEM. REP. (ZAIRE)	SECAM K
COOK ISLANDS	PAL B
COSTA RICA	NTSC M
COTE D'IVOIRE (IVORY COAST)	SECAM K/D
CROATIA	PAL B/H
CUBA	NTSC M
CYPRUS	PAL B/G
CZECH REPUBLIC	PAL B/G (cable), PAL D/K (broadcast)
DENMARK	PAL B/G
DIEGO GARCIA	NTSC M
DJIBOUTI	SECAM K
DOMINICA	NTSC M
DOMINICAN REPUBLIC	NTSC M
EAST TIMOR	PAL B
EASTER ISLAND	PAL B
ECUADOR	NTSC M
EGYPT	PAL B/G, SECAM B/G
EL SALVADOR	NTSC M
EQUITORIAL GUINEA	SECAM B
ESTONIA	PAL B/G
ETHIOPIA	PAL B
FALKLAND ISLANDS (LAS MALVINAS)	PAL I
FIJI	NTSC M
FINLAND	PAL B/G
FRANCE	SECAM L
FRANCE (FRENCH FORCES TV)	SECAM G
GABON	SECAM K
GALAPAGOS ISLANDS	NTSC M
GAMBIA	PAL B
GEORGIA	SECAM D/K
GERMANY	PAL B/G
GERMANY (ARMED FORCES TV GERMANY)	NTSC M
GHANA	PAL B/G
GIBRALTAR	PAL B/G
GREECE	PAL B/G
GREENLAND	PAL B
GRENADA	NTSC M
GUAM	NTSC M
GUADELOUPE	SECAM K
GUATEMALA	NTSC M
GUIANA (FRENCH)	SECAM K
GUINEA	PAL K
GUYANA	NTSC M
HAITI	SECAM
HONDURAS	NTSC M
HONG KONG	PAL I
HUNGARY	PAL K/K
ICELAND	PAL B/G
INDIA	PAL B
INDONESIA	PAL B
IRAN	SECAM B/G
IRAQ	PAL
IRELAND, REPUBLIC OF	PAL I
ISLE OF MAN	PAL
ISRAEL	PAL B/G
ITALY	PAL B/G
JAMAICA	NTSC M
JAPAN	NTSC M
JOHNSTONE ISLAND	NTSC M
JORDAN	PAL B/G
KAZAKHSTAN	SECAM D/K
KENYA	PAL B/G
KOREA (NORTH)	SECAM D, PAL D/K
KOREA (SOUTH)	NTSC M
KUWAIT	PAL B/G
KYRGYZ REPUBLIC	SECAM D/K
LAOS	PAL B
LATVIA	PAL B/G, SECAM D/K
LEBANON	PAL B/G
LESOTHO	PAL K
LIBERIA	PAL B/H
LIBYA	PAL B/G
LIECHTENSTEIN	PAL B/G
LITHUANIA	PAL B/G, SECAM D/K
LUXEMBOURG	PAL B/G, SECAM L
MACAU	PAL I
MACEDONIA	PAL B/H
MADAGASCAR	SECAM K
MADEIRA	PAL B
MALAYSIA	PAL B
MALDIVES	PAL B
MALI	SECAM K
MALTA	PAL B
MARSHALL ISLANDS	NTSC M
MARTINIQUE	SECAM K
MAURITANIA	SECAM B
MAURITIUS	SECAM B
MAYOTTE	SECAM K
MEXICO	NTSC M
MICRONESIA	NTSC M
MIDWAY ISLAND	NTSC M
MOLDOVA (MOLDAVIA)	SECAM D/K
MONACO	SECAM L, PAL G
MONGOLIA	SECAM D
MONTSERRAT	NTSC M
MOROCCO	SECAM B
MOZAMBIQUE	PAL B
MYANMAR (BURMA)	NTSC M
NAMIBIA	PAL I
NEPAL	B
NETHERLANDS	PAL B/G
NETHERLANDS (ARMED FORCES NETWORK)	NTSC M
NETHERLANDS ANTILLES	NTSC M
NEW CALEDONIA	SECAM K
NEW ZEALAND	PAL B/G
NICARAGUA	NTSC M
NIGER	SECAM K
NIGERIA	PAL B/G
NORFOLK ISLAND	PAL B
NORTH MARIANA ISLANDS	NTSC M
NORWAY	PAL B/G
OMAN	PAL B/G
PAKISTAN	PAL B
PALAU	NTSC M
PANAMA	NTSC M
PAPUA NEW GUINEA	PAL B/G
PARAGUAY	PAL N
PERU	NTSC M
PHILIPPINES	NTSC M
POLAND	PAL D/K
POLYNESIA (FRENCH)	SECAM K
PORTUGAL	PAL B/G
PUERTO RICO	NTSC M
QATAR	PAL B
REUNION	SECAM K
ROMANIA	PAL D/G
RUSSIA	SECAM D/K
ST. KITTS & NEVIS	NTSC M
ST. LUCIA	NTSC M
ST. PIERRE ET MIQUELON	SECAM K
ST. VINCENT	NTSC M
SAO TOMÉ E PRINCIPE	PAL B/G
SAMOA,	AMERICAN NTSC
SAUDI ARABIA	SECAM B/G, PAL B
SAMOA	NTSC M
SENEGAL	SECAM K
SEYCHELLES	PAL B/G
SIERRA LEONE	PAL B/G
SINGAPORE	PAL B/G
SLOVAKIA	PAL B/G
SLOVENIA	PAL B/H
SOMALIA	PAL B/G
SOUTH AFRICA	PAL I
SPAIN	PAL B/G
SRI LANKA	PAL
SUDAN	PAL B
SURINAME	NTSC M
SWAZILAND	PAL B/G
SWEDEN	PAL B/G
SWITZERLAND	PAL B/G
SYRIA	SECAM B, PAL G
TAHITI	SECAM
TAIWAN	NTSC
TAJIKISTAN	SECAM D/K
TANZANIA	PAL B
THAILAND	PAL B/M
TOGO	SECAM K
TRINIDAD & TOBAGO	NTSC M
TUNISIA	SECAM B/G
TURKEY	PAL B
TURKMENISTAN	SECAM D/K
TURKS & CAICOS ISLANDS	NTSC M
UGANDA	PAL B/G
UKRAINE	SECAM D/K
URUGUAY	PAL N
UNITED ARAB EMIRATES	PAL B/G
UNITED STATES	NTSC M
UNITED KINGDOM	PAL I
UZBEKISTAN	SECAM D/K
VENEZUELA	NTSC M
VIETNAM	NTSC M,SECAM D
VIRGIN ISLANDS (US & BRITISH)	NTSC M
WALLIS & FUTUNA	SECAM K
YEMEN	PAL B/NTSC M
YUGOSLAVIA	PAL B/G
ZAMBIA	PAL B/G
ZIMBABWE	PAL B/G

----------------

S-Video / S-VHS 4-pin Din Plug Wiring Diagram

For Wiring a Scart for SVHS - see Scart Connector Pin Tables All connectors are available from www.lektropacks.co.uk

S-Video Connection Pinout
PIN	DESCRIPTION		Impedance	Level
1	GND	Ground (Y)	.	.
2	GND	Ground ©	.	.
3	Y	Intensity (Luminance)	75 Ohms	1V incl. Sync.
4	C	Color (Chrominance)	75 Ohms	0.3V Burst
View to the solder side of the male connector

S-Video Cable for Scart S-Video Input
S-Video Out TV	Scart (Input)
Luminance Out (Y)	20	Luminance In
Chrominance Out (C)	15	Chrominance In
GND	4+17	GND
Audio Out L	2	Audio In L
Audio Out R	6	Audio In R

----------------

Understanding Resolutions, Pixels & Scan Rates

Resolutions Resolution means the number of pixels (dots), which are points of colour that a display monitor contains. This is expressed in the; number of pixels there are on the width, and the number of pixels on the height, of the display screen.

i.e. 640 x 480 = 680 dots across the screen and 480 dots down the screen.

Different resolutions are: i.e. VGA, SVGA, XGA, SXGA & UXGA

The following table summarizes the categories of screen resolution, as discussed above:

Width x Height (pixels)	Video Display Category
640 x 480	VGA
800 X 600	SVGA
1024 X 768	XGA
1280 X 1024	SXGA
1600 X 1200	UXGA

For DVI/HDTV formats see DVI & HDTV Formats.

What are Pixels?

The pixel is the basic unit of programmable colour on a computer display or image. The physical size of the pixel depends on how the resolution on the display screen has been set. Modern technology has given us the Plasma, LCD & Projector that can now offer a variety of screen settings (resolutions); and screen sharpness is often expressed as dpi (dots (pixels) per inch). Both the screen size and the resolution setting of the screen determine dots per inch - i.e. an image/picture will have a lower resolution (fewer dots per inch) on a large screen because the dots have to spread themselves out over a physical larger area.

Scan Rates

Scan rates are the determined speed of which the screen can redraw a single image it is also referred to as the Refresh Rate. The faster the scan rate (refresh rate) the quicker the re-draw thus less motion artefacts on fast moving action scenes.
-----------------

Speaker Cables

Hi-Fi purists make a lot of noise about speaker cables, sometimes spending several hundreds of pounds on a metre of specialist cable. However, the main function of speaker cable is to provide a low-resistance path between the amplifier and the loudspeaker, so thin bell wire is obviously a bad idea – not only will thin wire take some of your amplifiers power and turn it into heat, it will markedly reduce the damping factor of the amplifier.
Without getting too technical, the damping factor of an amplifier is its ability to sink the current being produced when a loudspeaker overshoots its position and starts to function as a generator rather than a motor; thus the amplifier damps the speaker movement, keeping it under control – producing a tighter more accurate bass end.
The most pragmatic approach is to use the shortest speaker leads you can, make sure they are both the same length, and choose heavier cable.
The simple matter about speaker cables is that by far the most important element is the cables resistance. Resistance is not everything, capacitance, inductance and other poindexter-type wire qualities do play their role, but none of them matter until the resistance is bought under control. Generally, you should think in terms of the resistance as being about 75% of any speaker cables performance.
To simplify, resistance can be thought of as the size of a pipe in a plumbing system. The bigger the pipe, the more water it can pass and the lower the resistance. The smaller the pipe, the less water it can pass and thus higher resistance. Resistance is a function not only of size but length too – therefore the longer your cable the more resistance it will have. The moral of this story is, the lower resistance a speaker cable has, the more signal it will allow to pass through.
The basic way to lower the resistance is to increase the amount (gauge) of wire used. Wire is typically measured in gauge, i.e. number of strands inside the cable.
We would recommend nothing less than a 42 strand, 79 strands being the most popular but gauges up to 252 strands are available.
Speaker cable is a minefield of conflicting information; many manufacturers claiming all manner of results, which cannot be electrically tested (very convenient), only when listening will one be able to experience the difference (obviously with the help of the placebo effect and an over zealous salesman).

Bi-Wire

At this point we fell we should mention bi-wiring, this is a system which uses a separate low and high frequency speaker signal being sent from a bi-wired amplifier to a pair of bi-wired speakers.
The principle being that your speaker has at least two drivers, a bass driver and a treble driver (tweeter) – speakers with this b-wire input are designed to accept separate low frequency (bass) and high frequency (treble) signals from your amplifier. Thus allowing each separate driver in the speaker to only receive the frequencies that it intends to output, i.e. your bass driver is only sent the bass sounds of any music playing and thus the bass driver does not try to reproduce the treble frequencies and can therefore produces a tighter, crisper and timely bass with the reverse being true for the treble.

So how can we summarise Speaker Cables?

1. Speaker cable cannot make your system any better – only reduce the amount of loss.
2. Shorter cable lengths where possible – the longer the cable the more signal loss.
3. Longer lengths double the gauge of cable. (i.e. short runs being made in a 79 strand, therefore for the longer runs double the gauge and use an 168 strand.)
4. If you have an amplifier and speakers that accept bi-wire – USE IT.
5. The best speaker cables – do not have any; use amplified speakers (of course you can then have pre-amp issues).

-----------------

Thanks to :
http://www.theavguide.co.uk/view_page.php?cat=10&&page=40