포토로그 마이가든 방명록



CPU, Memory 사용량 표시 Android


1. CPU 사용량


adb shell top -m 10
- 10개의 process에 대한 항목만 반복하여 표시

1
$ adb shell top -n 1

을 입력하면 CPU 사용량을 출력합니다.

top 에 대한 자세한 설명은 아래 명령을 입력합니다.

1
$ adb shell top --help

shell 명령을 Android App 에서 수행하려면 다음과 같이 합니다. ( shell 명령 수행시 App 의 권한은 항상 User 이기 때문에 su 권한을 필요로 하는 명령은 수행할 수 없음에 유의하셔야 합니다. )


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Runtime runtime = Runtime.getRuntime();
Process process;
String res = "-0-";
try {
        String cmd = "top -n 1";
        process = runtime.exec(cmd);
        InputStream is = process.getInputStream();
        InputStreamReader isr = new InputStreamReader(is);
        BufferedReader br = new BufferedReader(isr);
        String line ;
        while ((line = br.readLine()) != null) {
                String segs[] = line.trim().split("[ ]+");
                if (segs[0].equalsIgnoreCase([Your Process ID])) {
                        res = segs[1];
                        break;
                }
        }
} catch (Exception e) {
        e.fillInStackTrace();
        Log.e("Process Manager", "Unable to execute top command");
}

2. 메모리 사용량

$ adb shell procrank

procrank 명령이 가장 정확한 메모리 사용 정보를 보여준다고 합니다. (by Dianne Hackborn)

특히, 
uss 칼럼은 app 고유의 메모리 사용량을 나타내고,
pss 는 또한 프로세스간에 공유되는 메모리 량을 포함하고 있습니다.

하지만 이 명령은 production device 에는 지원하지 않을수 있습니다. 그때는 다음의 명령을 사용합니다.

1
2
$ adb shell dumpsys meminfo
$ adb shell dumpsys meminfo [processname]

위의 명령을 들을 이용하여 CPU 와 Memory 의 사용량을 차트 등으로 한눈에 보여줄 수 있습니다.

참고:

아래 링크 추가


SurfaceView, 예제 Android


프로그램은 크게 두가지 파일로 구성되어 있다.
ImgMove.java, GraphicsVies.java

ImgMove.java는 메인 엑티비티로, GraphicsView를 자신의 ContentView로 설정하게 된다.
그 소스코드는 다음과 같다.
===========================================
ImgMove.java
===========================================
package org.com;

import android.app.Activity;
import android.os.Bundle;

public class ImgMove extends Activity {
    --* Called when the activity is first created. --
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(new GraphicsView(this));
    }
}
===========================================
여기서는 큰 무리가 없을거라고 생각한다.
그럼 이제 GraphicsView.java로 넘어가보자.

이 클래스는 SurfaceView 클래스를 extends 한 것이다.
보통 쓰레드를 내부클래스로 하나 만들어놓고 사용하는 경우가 많은데,
필자는 GraphicsView를 Runnable을 implements하여서 사용하였다.
(간단히 애니메이션 효과만 내고 싶은거라면 이게 더 편해보인다.)
그럼 이제 메인 코드로 넘어가보자.
=====================================================================
public class GraphicsView extends SurfaceView implements SurfaceHolder.Callback, Runnable{
-- 여기서 주목할 점은 바로 SurfaceView를 extends했고, SurfaceHolder.Callback을 implements했다는 점!!
 * SurfaceHolder.Callback 은 surface의 변화에 대한 정보를 얻어오기 위해서 반드시 implements해야 하는 인터페이스이다.
 * SurfaceView 와 SurfaceHolder.Callback가 함께 사용될 경우, 잡혀있는 Surface는 created되는 사이사이마다만 사용 가능하다.
 * 그렇기 때문에 exclusive한 성질을 띄게 되고, synchronized(동기화)될 수 있는 것이다. 이 점에서 SurfaceView가 View에 비해
 * 사용이 편리하다는 것인 듯 싶다.
 --
    private Display display;
    private int width;
    private int height;
    private Bitmap img;
    private Bitmap src;
    private Paint paint;
    private SurfaceHolder holder; // surface의 동기화를 위해 화면을 잡아주고 있을 홀더
    private Thread thread;  // surface에 그려주는 작업을 해줄 thread

    int x = 0;
    int y = 0;
   
    public GraphicsView(Context context){
        super(context);
        display = ((WindowManager) context.getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay();
        width = display.getWidth();
        height = display.getHeight();
        paint = new Paint();
        src = BitmapFactory.decodeResource(this.getResources(), R.drawable.van);
       
        holder = getHolder(); // 홀더를 만들고,
        holder.addCallback(this); // 홀더에 이 SurfaceView에 대한 콜백 인터페이스를 제공해준다.
--
 *  여기서 잠시, SurfaceHolder가 뭐하는 놈인지는 알고 넘어가는 편이 속시원할 것 같다.
 *  SurfaceHolder란, 화면의 디스플레이에 대한 권한을 가지고 있는 객체에 대한 인터페이스이다.
 *  그렇기 때문에, SurfaceHolder는 프로그래머로 하여금 surface size, format를 제어할 수 있게 해주고,
 *  surface의 픽셀을 수정하고, 변화를 모니터할 수 있게 해준다.
 --
        setFocusable(true);
    }

-- 
 *  SurfaceHolder.Callback을 implements했다면 반드시 surfaceCreated, surfaceChanged, surfaceDestroyed를 구현해주어야 한다.
 *  안그러면 에러가 날테니까??
 --

public void surfaceCreated(SurfaceHolder holder){
// surface가 첫번째로 생성되자마자 바로 호출되는 메소드
        thread = new Thread(this); // 나중에 밑에서 구현될 스레드를 시작하는 지점.
        thread.start();
    }
   
    public void surfaceChanged(SurfaceHolder holder, int a, int b, int c){
// surface에 포멧이나 사이즈 등 어떠한 변화가 생기면 바로 호출되는 메소드
       
    }
   
    public void surfaceDestroyed(SurfaceHolder holder){
// surface가 종료되기 직전 바로 호출되는 메소드
       
    }

--
 *  run()와 doDraw()는 이제 그리기 작업에 필요한 작업들만 해주면 된다.
 --
public void run(){
        int flag = 0;
        int flagCnt = 0;
       
        while(true){
            Canvas c = null; // 그림을 그릴 캔버스
           
            try{
                c = holder.lockCanvas(null); // 해당 캔버스에 이제 그림그리기를 시작하기 위해 lock을 얻어왔다.
                synchronized(holder){
// 동기화를 위해 반드시 필요한 synchronized. holder가 잡고 있는 surface에 대해서 비동기식이 아닌 동기식으로 업데이트가 진행되도록 해준다.
                    if(flag == 0 && y >= 0 && y < src.getHeight() - height){
                        doDraw(c); // 캔버스에 그림을 그립시다아~~
                        x++;
                        y++;
                        flagCnt++;
                       
                        if(flagCnt == src.getHeight() - height){
                            flag = 1;
                        }
                    }else{
                        doDraw(c);
                        x--;
                        y--;
                        flagCnt--;
                       
                        if(flagCnt == 0){
                            flag = 0;
                        }
                    }
                }
            }catch(Exception e){
                e.printStackTrace();
            }finally{
                if(c != null){
                    holder.unlockCanvasAndPost(c);
                    // surface의 픽셀들에 대한 수정작업을 마무리 한다. unlockCanvasAndPost가 호출되고 난 뒤에 수정된 픽셀들이 스크린에 반영이 된다.
                }
            }
        }
    }

    public void doDraw(Canvas c){
        img = Bitmap.createBitmap(src, x, y, width, height);
        c.drawBitmap(img, 0, 0, paint);
    }   

이 소스코드가 도움이 되었으면 한다.
다음은 외부 블로그에서 SurfaceView를 사용하기 위해 필요한 과정들에 대해 정리해져 있는 내용을 펌해온 것이다.
소스를 보고 공부를 했으면, 그를 바탕으로 마무리로 정리해본다는 마음으로 읽어보면 도움이 될 것이다.

출처: http://samse.tistory.com/entry/Android-Graphics-1

On a SurfaceView

SurfaceView View구 조내에서 surface 그리는 목적으로 고안된 특별한 subclass이 다. 목 적은 애 플리케이션의 두 번째 스 레드에서 별 도로 그 려서 시 스템의 View구 조에서 그 리기 타 임까지 기 다리지 않 도록 하 게 하 기 위 해 고 안되었다. 두 번째 thread에 서 참 조하는 SurfaceView 자신만의 Canvas 그리기를 수행한다.

1.     SurfaceView extend 새로운 클래스를 선언한다.

2.     SurfaceHolder.callback implement한 다. 콜백 subclass 하부의 Surface 대한 정보와 함께 통지하는데 생성, 변 경 또 는 제 거되었을 통지하게 된다. 이벤트를 통해서 언제 그리기를 시작해야 하는지 알수 있고, 새 로운 surface속 성에 맞 게 조 정하고, 언 제 그 리기를 종 료하고 테 스트를 죽 일지등을 알 수 있 다. SurfaceView에 서 두 번째 Thread 정의하여 모든 drawing procedure 수행하는 것이 좋다.

3.     SurfaceHolder 생성한다. Surface 객 체를 직 접 처 리하지 않 고 SurfaceHolder 통해서 하는 것이 좋다. SurfaceView 초기화되면 getHolder() SurfaceHolder 얻는다.

4.     addCallback() 호출하여 SurfaceHolder.Callback으 로부터 이 벤트를 수 신하도록 한 다. SurfaceHolder.Callback SurfaceView클 래스내에서 override하 여 addCallback()한 다.

5.     두번째 thread에 서 Surface Canvas draw하 려면 반 드시 SurfaceHandler 전달해야 하며 lockCanvas() canvas 얻어야 한다. 이 렇게 해 야 SurfaceHolder 제공해준 Canvas 얻게 된다.

6.     Canvas drawing 한번 수행하면 canvas object 인자로 unlockCanvasAndPost() 호출해야 한다. lockCanvad() unlockCanvasAndPost() draw 반드시 쌍으로 호출되어야 한다.

 

Note: 한 번 canvas 얻어져서 사용되면 canvas 이전상태를 유지한다. 따 라서 적 절하게 animate 하려면 surface전 체를 re-paint해 야 한 다. 경우 drawColor() drawBitmap()등 으로 background 갱신하면 된다. 그 렇게 하 지 않 으면 이 전 이 미지가 표 시될 것 이다.



Android NDK 개발환경 구축 (R7) Android

  1. 용어 설명
    1. JNI (Java Native Interface)
    2. NDK (Native Development Kit)
  2. 프로그램 준비
    1. NDK (Native Development Kit)
      1. Android NDK, r7
      2. File Name :  android-ndk-r7-windows.zip
      3. Site : http://developer.android.com
      4. Direct Link :
        http://developer.android.com/sdk/ndk/index.html
    2. Cygwin
      1. Cygwin 1.7.9-1
      2. File Name : setup.exe
      3. Site : http://cygwin.com
      4. Direct Link : http://cygwin.com/setup.exe
  3. 프로그램 설치
    1. NDK (Native Development Kit)
      1. android-ndk-r7-windows.zip 압축해제
      2. 설치 경로 : C:\Tools\Android\android-ndk-r7 (경로명에 공백 없어야 함.)
      3. 설정 (환경 변수)
        1. ANDROID_NDK : C:\Tools\Android\android-ndk-r7
        2. PATH : %ANDROID_NDK%;~~~
        3. 설치 확인 : Cygwin 설치 후 확인
    2. Cygwin
      1. setup.exe 실행
      2. 설치 경로 : C:\cygwin
      3. 선택 옵션 : Devel category : gcc, make 항목 설치
      4. 설치 확인
        1. Cygwin bash shell 실행
        2. .bashrc 편집
          - export ANDROID_NDK_ROOT = path
          - export PATH=$PATH:path
          - ln -s path android_ndk
        3. $ ndk-build 실행
  4. Sample Code 구동
    1. Import hello-jni
    2. Java source build (Class 파일 확인)
    3. header file 생성 및 이동
      $ cd ./bin
      $ javah com.example.hellojni.HelloJni
      $ mv com_example_hellojni_HelloJni.h ../src
    4. header file include
      #include "com_example_hellojni_HelloJni.h"
    5. c source build
      $ ndk-build
    6. Run Application
  5. Reference
    1. JNI 개념
      http://atin.tistory.com/347
    2. NDK 설치
      http://blog.naver.com/dizmahs?Redirect=Log&logNo=110087452000



NDK build in Visual Studio Android


android의 NDK 부분은 윈도우에서 시도를 하려면 ndk-r4까지는 무조건 Cygwin을 설치 해야만 했었다.
그나마 r5가 나오고 Cygwin에 대한 의존성 부분이 사라져서 다른 빌드 환경으로 교체할 수 있게되었다.
그중에 하나가 바로 Visual Stuido 2010을 사용하여 빌드하는 vs-android이다.

URL은  http://code.google.com/p/vs-android/ 이다.

0.소개 및 준비물



Android C/C++을 VS에서 Build 및 Link를 할 수 있다는 내용
NDK Header를 셋팅하면 Intellisense를 이용할 수 있다는 내용
Cygwin 환경이 필요 없다는 내용등
VS에 익숙한 개발자라면 혹할 만한 내용이 들어있다.

-사전 준비물

  • Android SDK
  • Android NDK r5 이상
  • JAVA SDK (JDK 1.6 이상 추천)
  • ant (http://ant.apache.org/bindownload.cgi)
    다운 받아서 적당한 곳에 압축을 풀어 놓는다.

-사전 설정 확인
Windows Key + R -> sysdm.cpl (시스템 속성) -> 고급 탭 -> 환경 변수 버튼 -> 시스템 변수 에서 확인 사항

  • ANDROID_NDK_ROOT 설정
  • JAVA_HOME 설정
    JAVA_HOME은 자바가 설치되어 있는 최상단을 지정한다. windows에서 기본적으로 설치하면 %PROGRAMFILES%\Java\jdk{version} 으로 떨어진다.
  • CLASSPATH 설정
    %JAVA_HOME% \lib;. 으로 설정
  • Path 확인
    Android SDK의 tools 및 platform-tools의 경로, %ANDROID_NDK_ROOT%, %JAVA_HOME%\bin 이 포함되어 있는지 확인한다.

1. 설치

-다운로드
http://code.google.com/p/vs-android/downloads/list 에서 vs-android와 example project를 다운로드 받는다.

-압축해제 후
설치시 의 주의점은 Vista, Windows 7에서는 "관리자 권한으로 실행"으로 설치해야 한다는 것 이외에는 특별한 내용이 없다.

2. 테스트 수행

사전 설치 사항과 환경 설정, 그리고 설치만 제대로 되었다면 example project를 압축을 적당한 곳에 풀어 놓는다.
-주의 사항

  • 경로에 한글이 포함되어 있으면 안됨
  • 경로에 공백이 포함되어 있으면 안됨

※ 다음은 사이트의 http://code.google.com/p/vs-android/wiki/UsageExample 내용 그대로 가져와 번역 및 첨부한 것이다.

New Project

  • Go to the 'File' menu, choose 'New -> Project...'
  • Pick 'Visual C++', and 'Empty Project'
  • The location you place the project isn't important. I suggest using a path that doesn't have spaces, since I haven't tested paths which contain spaces. (봐라! 공백 추천하지 않는다. 개발자가 테스트도 안했댄다. -_-)
  • Uncheck 'Create directory for solution'. This puts the sln file and the vcxproj in the same directory. It will still create one directory off the base path you give. So in my case below, it'll end up in "C:\projects\sanangeles" (솔루션 디렉토리 생성은 해도되도 안해도된다. 경로를 잘 살펴보는 것이 중요하다. 이 글에서는 "C:\projects\sanangeles"에 압축파일을 해제해 놓은 것을 전제로 하고 있다.)

Adding Files

  • You'll want to unzip this so that the directory containing '''AndroidManifest.xml''' sits alongside the sln and vcxproj files that were just created. So that same directory would have the 'jni', 'res', and 'src' sub-directories too.
  • Go into the 'jni' directory and drag over the following files into your project as shown:
    (앞서 말한 "C:\projects\sanangeles" 에 압축을 풀어 놓고 "C:\projects\sanangeles\jni"에서 필요한 파일들을 프로젝트에 포함시킨다. 드래그앤드랍으로 가겨오면 된다.)

Adding The Android Platform

  • Now go to the 'Build' menu and pick 'Configuration Manager...'.
  • In the top right of this dialog, the solution dropdown box, choose 'New...'

  • In the next dialog choose 'Android' from the dropdown list. If it is not present, then there was a problem with installing vs-android.
  • Copy settings from 'empty', and ensure 'Create new project platforms' is checked.

빌드 매니저에서 기본적으로 잡혀 있는 Win32 대신에 Android로 변경하는 것이다.

OpenGL Support

Preprocessor Symbol

  • Out of the box, the default setup doesn't hook in OpenGL support. You have to modify project settings to link in the library, and in the case of this sanangeles demo define a preprocessor symbol.
  • Right click on the 'sanangeles' project in the 'Solution Explorer' pane. This is the one that will be shown in bold, right above 'External Dependencies'. Choose 'Properties' from this menu.
  • In this dialog, navigate into the 'C++' part of the tree. Click on 'Preprocessor'.
  • In the right-hand part click on the "Preprocessor Definitions" line, and then on the little arrow that appears in the top-right corner.
  • Choose 'Edit...'

  • Type DISABLE_IMPORTGL into the top box. The 'importgl.h' header needs this defined in order to link statically with the OpenGL ES library. Click OK when you're done typing.

OpenGL과 관련된 것으로 해당 프로젝트에서만 해당하는 내용이다. 이런식으로 Preprocessor Definitions를 추가 할 수 있다.

Linker

  • Navigate into the 'Linker' part of the tree now. Go to the 'Command Line' option:

  • Type -lGLESv1_CM into the lower box. The letter after the initial dash is a lower case 'L'. This tells the linker to link in that OpenGL library.

우선 여기까지 수행해서 빌드를 하게 되면 당 프로젝트의 so 파일이 빌드되어 있다. 이를 바탕으로 eclipse에서 추가 작업을 진행할 수 있다. 다른 부분을 더 작업을 해야한다면 이정도 만으로도 Cygwin 환경없이 so 파일을 생성할 수 있기 때문에 좋다.

Ant Build

(skip these steps if you do not have ant installed)

  • In the same 'Linker' section of this properties dialog, click on 'Android Ant Build' on the left-hand side.
  • Change the top option 'Ant Build' to ant debug. You can just double click on the entry to cycle through the options.
  • For the 'Path To Ant Batch File', change this to the correct path of your ant.bat. If you installed ant to 'c:\ant'. It'll be 'c:\ant\bin\ant.bat'.

ant.bat 앞에 ant의 압축을 풀어놓은 위치을 추가로 넣어준다.

  • Finally, you'll also need to edit the 'local.properties' file that's at the root of the sanangeles project. There's a line denoting the path to your Android SDK. This will almost certainly be different from mine, modify it to path to your install.

이 부분은 sln이 존재하는 위치에 local.properties 라는 파일이 있는데 sdk.dir의 설정이 무조건 저렇게 되어있다. 노트패드 등으로 열어서 변경하면 된다.

Building

  • Click 'OK' to exit the properties dialog.
  • Go to the 'Build' menu. Choose 'Build Solution'.
  • It'll:
    1. Compile the .c files.
    2. Link the finished .so native executable.
    3. Run ant to build the final deployable apk file. (or not, if you chose to skip this)

빌드가 성공하면 다음과 같은 화면을 볼 수 있다.
빌드가 되지않는 사항은 다음과 같다.

  • so 파일 조차 빌드 되지 않는다.
    • 기본적인 android sdk, ndk 및 system path 등을 확인해 본다.
    • Java 프로젝트 파일과 vs 솔루션 파일 위치를 확인한다.
  • so는 빌드되었지만 apk는 빌드되지 않는다.
    • JDK 설치 확인
    • ant 설치 확인
    • JAVA_HOME 및 환경 변수 확인

Deploy

If you built the apk file with ant, here are some instructions on how to deploy it.

  • Ensure you have an emulated device set up, or a real Android phone connected via debug-USB.
    (에뮬레이터나 폰등에 옮겨서 설치해 보라는 내용)
  • The final apk file will be placed here, from your ant build:

sanangeles\bin\DemoActivity-debug.apk

  • Note the path to the Android SDK that you needed to enter in the 'properties.local' file earlier. These are the two command lines to run to deploy and run the app. They assume you're in the root directory of the project.

$(SDK_PATH)\platform-tools\adb install -r bin\DemoActivity-debug.apk

$(SDK_PATH)\platform-tools\adb shell am start -n com.example.SanAngeles/.DemoActivity

  • You'll then see the demo app running on your phone!
  • You may want to put these command lines into a batch file, and set up a post-build step in Visual Studio.
    (이후 사항은 "빌드 후 단계"에서 배치파일이나 adb-install 등을 이용해서 설치등을 시킬 수 있을 수 있다는 내용이다.)

SDK_PATH를 설정하는 것 보다는 기본적으로 tools와 platform-tools을 배치등록 하기 때문에 저런식으로 하지 않아도 될 듯하다.

3. 마무리

이상으로 VS를 이용하여 Android NDK의 so 및 apk 빌드과정을 살펴 보았다. 개인적인 생각은 처음부터 Cygwin에 익숙한 사용자라면 그렇게 선호 할 수 없는 것이 복잡한 설정 작업일 것이다. 하지만 VS에 익숙하고 그에 VS에서 제공하는 IDE 환경을 생각하면 좋을 듯 하다. 그러나 확인이 되지 않는 것이
-컴파일 중의 에러 처리
-디버깅 지원
에 대해서 어떻게 되어있는 가는 살펴보아야 할 것이다.


How 802.11 Wireless Works Wireless


How 802.11 Wireless Works

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How 802.11 Wireless Works

The IEEE 802.11 protocol is a network access technology for providing connectivity between wireless stations and wired networking infrastructures.

By deploying the IEEE 802.11 protocol and associated technologies, you enable the mobile user to travel to various places — meeting rooms, hallways, lobbies, cafeterias, classrooms, and so forth — and still have access to networked data. Also, beyond the corporate workplace, you enable access to the Internet and even corporate sites can be made available through public wireless “hot spot” networks. Airports, restaurants, rail stations, and common areas throughout cities can be configured to provide this service.

This section provides an in-depth view of how IEEE 802.11 works, including the architecture, related protocols, and technologies.

802.11 Architecture

The 802.11 logical architecture contains several main components: station (STA), wireless access point (AP), independent basic service set (IBSS), basic service set (BSS), distribution system (DS), and extended service set (ESS). Some of the components of the 802.11 logical architecture map directly to hardware devices, such as STAs and wireless APs. The wireless STA contains an adapter card, PC Card, or an embedded device to provide wireless connectivity. The wireless AP functions as a bridge between the wireless STAs and the existing network backbone for network access.

An IBSS is a wireless network, consisting of at least two STAs, used where no access to a DS is available. An IBSS is also sometimes referred to as an ad hoc wireless network.

A BSS is a wireless network, consisting of a single wireless AP supporting one or multiple wireless clients. A BSS is also sometimes referred to as an infrastructure wireless network. All STAs in a BSS communicate through the AP. The AP provides connectivity to the wired LAN and provides bridging functionality when one STA initiates communication to another STA or a node on the DS.

An ESS is a set of two or more wireless APs connected to the same wired network that defines a single logical network segment bounded by a router (also known as a subnet).

The APs of multiple BSSs are interconnected by the DS. This allows for mobility, because STAs can move from one BSS to another BSS. APs can be interconnected with or without wires; however, most of the time they are connected with wires. The DS is the logical component used to interconnect BSSs. The DS provides distribution services to allow for the roaming of STAs between BSSs.

The following figure shows the 802.11 architecture.

802.11 Architecture

802.11 Architecture

802.11 Operating Modes

IEEE 802.11 defines the following operating modes:

  • Infrastructure mode

  • Ad hoc mode

In both operating modes, a Service Set Identifier (SSID), also known as the wireless network name, identifies the wireless network. The SSID is a name configured on the wireless AP (for infrastructure mode) or an initial wireless client (for ad hoc mode) that identifies the wireless network. The SSID is periodically advertised by the wireless AP or the initial wireless client using a special 802.11 MAC management frame known as a beacon frame.

802.11 Infrastructure Mode

In infrastructure mode, there is at least one wireless AP and one wireless client. The wireless client uses the wireless AP to access the resources of a traditional wired network. The wired network can be an organization intranet or the Internet, depending on the placement of the wireless AP. An extended service set (ESS) is shown in the following figure.

802.11 Infrastructure Mode

802.11 Infrastructure Mode

802.11 Ad Hoc Mode

In ad hoc mode, wireless clients communicate directly with each other without the use of a wireless AP, as shown in the following figure.

802.11 Wireless Clients in Ad Hoc Mode

802.11 Wireless Clients in Ad Hoc Mode

Ad hoc mode is also called peer-to-peer mode. Wireless clients in ad hoc mode form an independent basic service set (IBSS). One of the wireless clients, the first wireless client in the IBSS, takes over some of the responsibilities of the wireless AP. These responsibilities include the periodic beaconing process and the authentication of new members. This wireless client does not act as a bridge to relay information between wireless clients. Ad hoc mode is used to connect wireless clients together when there is no wireless AP present. The wireless clients must be explicitly configured to use ad hoc mode. There can be a maximum of nine members in an ad hoc 802.11 wireless network.

802.11 Protocols and Technologies

The 802.11-related protocols and technologies are discussed in detail in the following section:

  • 802.11. The IEEE 802.11 wireless standard defines the specifications for the physical layer and the media access control (MAC) layer.

  • 802.1X. The IEEE 802.1X standard defines port-based, network access control used to provide authenticated network access for Ethernet networks.

  • Extensible Authentication Protocol (EAP) over LAN (EAPOL). EAP is a Point-to-Point Protocol (PPP)-based authentication mechanism that was adapted for use on point-to-point local area network (LAN) segments.

  • Wired Equivalent Privacy (WEP). WEP provides data confidentiality services by encrypting the data sent between wireless nodes.

  • Wi-Fi Protected Access (WPA). WPA is an interim standard until the IEEE 802.11i standard is ratified. These standards, intended to be a replacement for the WEP standard, offer more robust methods of data encryption and network authentication.

  • Wireless Auto Configuration. The Wireless Auto Configuration feature of Windows XP and Windows Server 2003 dynamically selects the wireless network to which a connection is attempted, based either on configured preferences or default settings.

802.11 Protocol

The IEEE 802 standards committee defines two separate layers, the Logical Link Control (LLC) and media access control, for the Data-Link layer of the OSI model. The IEEE 802.11 wireless standard defines the specifications for the physical layer and the media access control (MAC) layer that communicates up to the LLC layer, as shown in the following figure.

802.11 and OSI Model

802.11 and OSI Model

All of the components in the 802.11 architecture fall into either the media access control (MAC) sublayer of the data-link layer or the physical layer.

802.11 MAC Frame

The 802.11 MAC frame, as shown in the following figure, consists of a MAC header, the frame body, and a frame check sequence (FCS). The numbers in the following figure represent the number of bytes for each field.

802.11 MAC Frame Format

802.11 MAC Frame Format
Frame Control Field

The Frame Control field, shown in the following figure, contains control information used for defining the type of 802.11 MAC frame and providing information necessary for the following fields to understand how to process the MAC frame. The numbers in the following figure represent the number of bits for each field.

Frame Control Field

Frame Control Field

A description of each Frame Control field subfield are as follows:

  • Protocol Version provides the current version of the 802.11 protocol used. Receiving STAs use this value to determine if the version of the protocol of the received frame is supported.

  • Type and Subtype determines the function of the frame. There are three different frame type fields: control, data, and management. There are multiple subtype fields for each frame type . Each subtype determines the specific function to perform for its associated frame type.

  • To DS and From DS indicates whether the frame is going to or exiting from the DS (distributed system), and is only used in data type frames of STAs associated with an AP.

  • More Fragments indicates whether more fragments of the frame, either data or management type, are to follow.

  • Retry indicates whether or not the frame, for either data or management frame types, is being retransmitted.

  • Power Management indicates whether the sending STA is in active mode or power-save mode.

  • More Data indicates to a STA in power-save mode that the AP has more frames to send. It is also used for APs to indicate that additional broadcast/multicast frames are to follow.

  • WEP indicates whether or not encryption and authentication are used in the frame. It can be set for all data frames and management frames, which have the subtype set to authentication.

  • Order indicates that all received data frames must be processed in order.

Duration/ID Field

This field is used for all control type frames, except with the subtype of Power Save (PS) Poll, to indicate the remaining duration needed to receive the next frame transmission. When the sub-type is PS Poll, the field contains the association identity (AID) of the transmitting STA.

Address Fields

Depending upon the frame type, the four address fields will contain a combination of the following address types:

  • BSS Identifier (BSSID). BSSID uniquely identifies each BSS. When the frame is from an STA in an infrastructure BSS, the BSSID is the MAC address of the AP. When the frame is from a STA in an IBSS, the BSSID is the randomly generated, locally administered MAC address of the STA that initiated the IBSS.

  • Destination Address (DA). DA indicates the MAC address of the final destination to receive the frame.

  • Source Address (SA). SA indicates the MAC address of the original source that initially created and transmitted the frame.

  • Receiver Address (RA). RA indicates the MAC address of the next immediate STA on the wireless medium to receive the frame.

  • Transmitter Address (TA). TA indicates the MAC address of the STA that transmitted the frame onto the wireless medium.

For more information about the address types and the contents of the address fields in the 802.11 MAC header, see the IEEE 802.11 standard at the IEEE Web site.

Sequence Control

The Sequence Control field contains two subfields, the Fragment Number field and the Sequence Number field, as shown in the following figure.

Sequence Control Field

Sequence Control Field

A description of each Sequence Control field subfield are as follows:

  • Sequence Number indicates the sequence number of each frame. The sequence number is the same for each frame sent for a fragmented frame; otherwise, the number is incremented by one until reaching 4095, when it then begins at zero again.

  • Fragment Number indicates the number of each frame sent of a fragmented frame. The initial value is set to 0 and then incremented by one for each subsequent frame sent of the fragmented frame.

Frame Body

The frame body contains the data or information included in either management type or data type frames.

Frame Check Sequence

The transmitting STA uses a cyclic redundancy check (CRC) over all the fields of the MAC header and the frame body field to generate the FCS value. The receiving STA then uses the same CRC calculation to determine its own value of the FCS field to verify whether or not any errors occurred in the frame during the transmission.

802.11 PHY Sublayer

At the physical (PHY) sublayer, IEEE 802.11 defines a series of encoding and transmission schemes for wireless communications, the most common of which are the Frequency Hopping Spread Spectrum (FHSS), Direct Sequence Spread Spectrum (DSSS), and Orthogonal Frequency Division Multiplexing (OFDM) transmission schemes. The following figure shows the 802.11, 802.11b, 802.11a, and 802.11g standards that exist at the PHY sublayer. These standards are described in the sections that follow.

Standards for 802.11 at the PHY Layer

Standards for 802.11 at the PHY Layer
IEEE 802.11

The bit rate for the original IEEE 802.11 standard is 2 Mbps using the FHSS transmission scheme and the S-Band Industrial, Scientific, and Medical (ISM) frequency band, which operates in the frequency range of 2.4 to 2.5 GHz. However, under less-than-ideal conditions, a lower bit rate speed of 1 Mbps is used.

802.11b

The major enhancement to IEEE 802.11 by IEEE 802.11b is the standardization of the physical layer to support higher bit rates. IEEE 802.11b supports two additional speeds, 5.5 Mbps and 11 Mbps, using the S-Band ISM. The DSSS transmission scheme is used in order to provide the higher bit rates. The bit rate of 11 Mbps is achievable in ideal conditions. In less-than-ideal conditions, the slower speeds of 5.5 Mbps, 2 Mbps, and 1 Mbps are used.

Note

  • 802.11b uses the same frequency band as that used by microwave ovens, cordless phones, baby monitors, wireless video cameras, and Bluetooth devices.

802.11a

IEEE 802.11a (the first standard to be ratified, but just now being widely sold and deployed) operates at a bit rate as high as 54 Mbps and uses the C-Band ISM, which operates in the frequency range of 5.725 to 5.875 GHz. Instead of DSSS, 802.11a uses OFDM, which allows data to be transmitted by subfrequencies in parallel and provides greater resistance to interference and greater throughput. This higher-speed technology enables wireless LAN networking to perform better for video and conferencing applications.

Because they are not on the same frequencies as other S-Band devices (such as cordless phones), OFDM and IEEE 802.11a provide both a higher data rate and a cleaner signal. The bit rate of 54 Mbps is achievable in ideal conditions. In less-than-ideal conditions, the slower speeds of 48 Mbps, 36 Mbps, 24 Mbps, 18 Mbps, 12 Mbps, and 6 Mbps are used.

802.11g

IEEE 802.11g operates at a bit rate as high as 54 Mbps, but uses the S-Band ISM and OFDM. 802.11g is also backward-compatible with 802.11b and can operate at the 802.11b bit rates and use DSSS. 802.11g wireless network adapters can connect to an 802.11b wireless AP, and 802.11b wireless network adapters can connect to an 802.11g wireless AP. Thus, 802.11g provides a migration path for 802.11b networks to a frequency-compatible standard technology with a higher bit rate. Existing 802.11b wireless network adapters cannot be upgraded to 802.11g by updating the firmware of the adapter — they must be replaced. Unlike migrating from 802.11b to 802.11a (in which all the network adapters in both the wireless clients and the wireless APs must be replaced at the same time), migrating from 802.11b to 802.11g can be done incrementally.

Like 802.11a, 802.11g uses 54 Mbps in ideal conditions and the slower speeds of 48 Mbps, 36 Mbps, 24 Mbps, 18 Mbps, 12 Mbps, and 6 Mbps in less-than-ideal conditions.

802.1X Protocol

The IEEE 802.1X standard defines port-based, network access control used to provide authenticated network access for Ethernet networks. This port-based network access control uses the physical characteristics of the switched LAN infrastructure to authenticate devices attached to a LAN port. Access to the port can be denied if the authentication process fails. Although this standard was designed for wired Ethernet networks, it has been adapted to 802.11 wireless LANs.

Components of 802.1X

IEEE 802.1X defines the following terms, as described in the following sections:

  • Port access entity. A LAN port, also known as port access entity (PAE), is the logical entity that supports the IEEE 802.1X protocol that is associated with a port. A PAE can adopt the role of the authenticator, the supplicant, or both.

  • Authenticator. An authenticator is a LAN port that enforces authentication before allowing access to services accessible using that port. For wireless connections, the authenticator is the logical LAN port on a wireless AP through which wireless clients in infrastructure mode gain access to other wireless clients and the wired network.

  • Supplicant. The supplicant is a LAN port that requests access to services accessible on the authenticator. For wireless connections, the supplicant is the logical LAN port on a wireless LAN network adapter that requests access to the other wireless clients and the wired network by associating with and then authenticating itself to an authenticator.

    Whether for wireless connections or wired Ethernet connections, the supplicant and authenticator are connected by a logical or physical point-to-point LAN segment.

  • Authentication server. To verify the credentials of the supplicant, the authenticator uses an authentication server, which checks the credentials of the supplicant on behalf of the authenticator and then responds to the authenticator, indicating whether or not the supplicant is authorized to access the authenticator's services.

The following figure shows these components for a wireless LAN network.

Components of IEEE 802.1X Authentication

Components of IEEE 802.1X Authentication

The authentication server can be the following:

  • A component of the access point. In this case, the AP must be configured with the sets of user credentials corresponding to the supplicants that will be attempting to connect (it is typically not implemented for wireless APs).

  • A separate entity. In this case, the AP forwards the credentials of the connection attempt to a separate authentication server. Typically, a wireless AP uses the Remote Authentication Dial-In User Service (RADIUS) protocol to send a connection request message to a RADIUS server.

Controlled and Uncontrolled Ports

The authenticator's port-based access control defines the following different types of logical ports that access the wired LAN by means of a single physical LAN port:

  • Uncontrolled Port. The uncontrolled portallows an uncontrolled exchange between the authenticator (the wireless AP) and other networking devices on the wired network — regardless of any wireless client's authorization state. Frames sent by the wireless client are never sent using the uncontrolled port.

  • Controlled Port. The controlled portallows data to be sent between a wireless client and the wired network only if the wireless client is authorized by 802.1X. Before authentication, the switch is open and no frames are forwarded between the wireless client and the wired network. When the wireless client is successfully authenticated using IEEE 802.1X, the switch is closed, and frames can be sent between the wireless client and nodes on the wired network.

The different types of ports are shown in the following figure.

Controlled and Uncontrolled Ports for IEEE 802.1X

Controlled and Uncontrolled Ports for IEEE 802.1X

On an authenticating Ethernet switch, the wired Ethernet client can send Ethernet frames to the wired network as soon as authentication is complete. The switch identifies the traffic of a specific wired Ethernet client using the physical port to which the Ethernet client is connected. Typically, only a single Ethernet client is connected to a physical port on the Ethernet switch.

Because multiple wireless clients contend for access to the same frequency channel and send data using the same channel, an extension to the basic IEEE 802.1X protocol is required to allow a wireless AP to identify the secured traffic of a particular wireless client. The wireless client and wireless AP do this through the mutual determination of a per-client unicast session key. Only authenticated wireless clients have knowledge of their per-client unicast session key. Without a valid unicast session key tied to a successful authentication, a wireless AP discards the traffic sent from the wireless client.

EAP over LAN

To provide a standard authentication mechanism for IEEE 802.1X, the Extensible Authentication Protocol (EAP) was chosen. EAP is a Point-to-Point Protocol (PPP)-based authentication mechanism that was adapted for use on point-to-point LAN segments. EAP messages are normally sent as the payload of PPP frames. To adapt EAP messages to be sent over Ethernet or wireless LAN segments, the IEEE 802.1X standard defines EAP over LAN (EAPOL), a standard encapsulation method for EAP messages.

WEP

WEP provides data confidentiality services by encrypting the data sent between wireless nodes. Setting a WEP flag in the MAC header of the 802.11 frame indicates that the frame is encrypted with WEP encryption. WEP provides data integrity by including an integrity check value (ICV) in the encrypted portion of the wireless frame.

WEP defines two shared keys:

  • Multicast/global key. The multicast/global key is an encryption key that protects multicast and broadcast traffic from a wireless AP to all of its connected wireless clients.

  • Unicast session key. The unicast session key is an encryption key that protects unicast traffic between a wireless client and a wireless AP and multicast and broadcast traffic sent by the wireless client to the wireless AP.

WEP encryption uses the RC4 symmetric stream cipher with 40-bit and 104-bit encryption keys. Although 104-bit encryption keys are not specified in the 802.11 standard, many wireless AP vendors support them.

Note

  • Some implementations that advertise the use of 128-bit WEP encryption keys are just adding a 104-bit encryption key to the 24-bit initialization vector (IV) and calling it a 128-bit key. The IV is a field in the header of each 802.11 frame that is used during the encryption and decryption process.

WEP Encryption

The WEP encryption process is shown in the following figure.

WEP Encryption Process

WEP Encryption Process

To encrypt the payload of an 802.11 frame, the following process is used:

  1. A 32-bit integrity check value (ICV) is calculated for the frame data.

  2. The ICV is appended to the end of the frame data.

  3. A 24-bit initialization vector (IV) is generated and appended to the WEP encryption key.

  4. The combination of initialization vector and WEP encryption key is used as the input of a pseudo-random number generator (PRNG) to generate a bit sequence that is the same size as the combination of data and ICV.

  5. The PRNG bit sequence, also known as the key stream, is bit-wise exclusive ORed (XORed) with the combination of data and ICV to produce the encrypted portion of the payload that is sent between the wireless access point (AP) and the wireless client.

  6. To create the payload for the wireless MAC frame, the IV is added to the front of the encrypted combination of the data and ICV, along with other fields.

WEP Decryption

The WEP decryption process is shown in the following figure.

WEP Decryption Process

WEP Decryption Process

To decrypt the 802.11 frame data, the following process is used:

  1. The initialization vector (IV) is obtained from the front of the MAC payload.

  2. The IV is appended to the WEP encryption key.

  3. The combination of initialization vector and WEP encryption key is used as the input of the same PRNG to generate a bit sequence of the same size as the combination of the data and the ICV. This process produces the same key stream as that of the sending wireless node.

  4. The PRNG bit sequence is XORed with the encrypted combination of the data and ICV] to decrypt the combined data and ICV portion of the payload.

  5. The ICV calculation for the data portion of the payload is run, and its result is compared with the value included in the incoming frame. If the values match, the data is considered to be valid (sent from the wireless client and unmodified in transit). If they do not match, the frame is silently discarded.

Security Issues with WEP and IEEE 802.11

The main problem with WEP is that the determination and distribution of WEP encryption keys are not defined. WEP keys must be distributed by using a secure channel outside of the 802.11 protocol. In practice, WEP keys are text strings that must be manually configured using a keyboard for both the wireless AP and wireless clients. However, this key distribution system does not scale well to an enterprise organization and is not secure.

Additionally, there is no defined mechanism for changing the WEP encryption keys either per authentication or periodically for an authenticated connection. All wireless APs and clients use the same manually configured WEP key for multiple sessions. With multiple wireless clients sending a large amount of data, an attacker can remotely capture large amounts of WEP ciphertext and use cryptanalysis methods to determine the WEP key.

The lack of a WEP key management protocol is a principal limitation to providing 802.11 security, especially in infrastructure mode with a large number of stations. Some examples of this type of network include corporate and educational institutional campuses and public places such as airports and malls. The lack of automated authentication and key determination services also affects operation in ad hoc mode, in which users might want to use in peer-to-peer collaborative communication in areas such as conference rooms.

WPA

Although 802.1X addresses many of the security issues of the original 802.11 standard, issues still exist with regard to weaknesses in the WEP encryption and data integrity methods. The long-term solution to these problems is the IEEE 802.11i standard, which is currently in draft form.

Until the IEEE 802.11i standard is ratified, wireless vendors have agreed on an interoperable interim standard known as Wi-Fi Protected Access (WPA). The goals of WPA are the following:

  • To require secure wireless networking. WPA requires secure wireless networking by requiring 802.1X authentication, encryption, and unicast and multicast/global encryption key management.

  • To address WEP issues with a software upgrade. The implementation of the RC4 stream cipher within WEP is vulnerable to known plaintext attacks. Additionally, the data integrity provided with WEP is relatively weak. WPA solves all the remaining security issues with WEP, yet only requires firmware updates in wireless equipment and an update for wireless clients. Existing wireless equipment is not expected to require replacement.

  • To provide a secure wireless networking solution for small office/home office (SOHO) wireless users. For the SOHO, there is no RADIUS server to provide 802.1X authentication with an EAP type. SOHO wireless clients must use either shared key authentication (highly discouraged) or open system authentication (recommended) with a single static WEP key for both unicast and multicast traffic. WPA provides a pre-shared key option intended for SOHO configurations. The pre-shared key is configured on the wireless AP and each wireless client. The initial unicast encryption key is derived from the authentication process, which verifies that both the wireless client and the wireless AP have the pre-shared key.

  • To be compatible with the upcoming IEEE 802.11i standard. WPA is a subset of the security features in the proposed IEEE 802.11i standard. All the features of WPA are described in the current draft of the 802.11i standard.

  • To be available today. WPA upgrades to wireless equipment and for wireless clients were available beginning in February 2003.

WPA Security Features

WPA contains enhancements or replacements for the following security features:

  • Authentication

  • Encryption

  • Data integrity

Authentication

With 802.11, 802.1X authentication is optional; with WPA, 802.1X authentication is required. Authentication with WPA is a combination of open system and 802.1X authentication, which uses the following phases:

  • The first phase uses open system authentication to indicate to the wireless client that it can send frames to the wireless AP.

  • The second phase uses 802.1X to perform a user-level authentication. For environments without a RADIUS infrastructure, WPA supports the use of a pre-shared key; for environments with a RADIUS infrastructure, WPA supports EAP and RADIUS.

Encryption

With 802.1X, rekeying of unicast encryption keys is optional. Additionally, 802.11 and 802.1X provide no mechanism to change the global encryption key that is used for multicast and broadcast traffic. With WPA, rekeying of both unicast and global encryption keys is required. The Temporal Key Integrity Protocol (TKIP) changes the unicast encryption key for every frame, and each change is synchronized between the wireless client and the wireless AP. For the multicast/global encryption key, WPA includes a facility for the wireless AP to advertise changes to the connected wireless clients.

TKIP

For 802.11, WEP encryption is optional. For WPA, encryption using TKIP is required. TKIP replaces WEP with a new encryption algorithm that is stronger than the WEP algorithm, yet can be performed using the calculation facilities present on existing wireless hardware. TKIP also provides for the following:

  • The verification of the security configuration after the encryption keys are determined.

  • The synchronized changing of the unicast encryption key for each frame.

  • The determination of a unique starting unicast encryption key for each pre-shared key authentication.

AES

WPA defines the use of the Advanced Encryption Standard (AES) as an optional replacement for WEP encryption. Because adding AES support by using a firmware update might not be possible for existing wireless equipment, support for AES on wireless network adapters and wireless APs is not required.

Data Integrity

With 802.11 and WEP, data integrity is provided by a 32-bit ICV that is appended to the 802.11 payload and encrypted with WEP. Although the ICV is encrypted, it is possible through cryptanalysis to change bits in the encrypted payload and update the encrypted ICV without being detected by the receiver.

With WPA, a method known as Michael specifies a new algorithm that calculates an 8-byte message integrity code (MIC) with the calculation facilities available on existing wireless hardware. The MIC is placed between the data portion of the 802.11 frame and the 4-byte ICV. The MIC field is encrypted along with the frame data and the ICV.

Michael also provides replay protection through the use of a frame counter field in the 802.11 MAC header.

Note

  • WPA requires software changes to the following:

  • Wireless APs

  • Wireless network adapters

  • Wireless client software

Wireless Auto Configuration

Wireless Auto Configuration dynamically selects the wireless network to which a connection is attempted, based either on configured preferences or default settings. This process includes automatically selecting and connecting to a more preferred wireless network when it becomes available. If none of the preferred wireless networks is found nearby, Wireless Auto Configuration configures the wireless adapter so that there is no accidental connection until the wireless client roams within the range of a preferred network.

Wireless Auto Configuration corresponds to the Wireless Configuration service in Windows Server 2003 and the Wireless Zero Configuration service in Windows XP. You can use the Services snap-in (available in the Administrative Tools folder) to view the current status of (as well as stop, start, and restart) either service. You can also manage either service from the command prompt by using the net command. For example, to stop either service, type net stop wzcsv at a command prompt.

Wireless Auto Configuration minimizes the configuration that is required to access wireless networks and allows you to travel to different wireless networks without reconfiguring the network connection settings on your computer for each location. For the initial scan of available wireless networks, Wireless Auto Configuration performs the following process:

  1. Wireless Auto Configuration attempts to connect to the preferred networks that appear in the list of available networks in the preferred networks preference order.

  2. If there are no successful connections, Wireless Auto Configuration attempts to connect to the preferred networks that do not appear in the list of available networks in the preferred networks preference order. Thus, it can connect even when the wireless APs are configured to suppress the beaconing of the SSID of the wireless network.

  3. If there are no successful connections and there is an ad hoc network in the list of preferred networks that is available, Wireless Auto Configuration tries to connect to it.

  4. If there are no successful connections, and there is an ad hoc network in the list of preferred networks that is not available, Wireless Auto Configuration configures the wireless network adapter to act as the first node in the ad hoc network.

  5. If there are no successful connections to preferred networks, and there are no ad hoc networks in the list of preferred networks, Wireless Auto Configuration determines the Automatically Connect To Non-Preferred Networks setting (located on the Wireless Networks tab of the wireless network connection).

  6. If the Automatically Connect To Non-Preferred Networks setting is disabled, Wireless Auto Configuration creates a random network name and places the wireless network adapter in infrastructure mode.

    This behavior prevents the Windows XP wireless client from accidentally connecting to a wireless network that does not appear in the list of preferred networks. You then see the One Or More Wireless Networks Are Available message in the notification area. The wireless adapter is not connected to any wireless network, but continues to scan for preferred wireless networks every 60 seconds.

  7. If the Automatically Connect To Non-Preferred Networks setting is enabled, Wireless Auto Configuration attempts to connect to the available networks in the order in which the wireless adapter sensed them.

    If all connection attempts fail, Wireless Auto Configuration creates a random network name and places the wireless network adapter in infrastructure mode. You then see the One Or More Wireless Networks Are Available message in the notification area.

For subsequent scans, Wireless Auto Configuration determines whether there are any changes in the wireless environment that require switching the connection. If the Windows wireless client is already connected to a wireless network and there is no other preferred network higher in the preference list that has not been attempted already, Wireless Auto Configuration maintains the existing connection. If the Windows wireless client is already connected to a wireless network, but a more preferred wireless network becomes available, Wireless Auto Configuration disconnects from the currently connected wireless network and attempts to connect to the more preferred wireless network.

The operation of Wireless Auto Configuration provides the following:

  • The first time a wireless adapter is added to a computer running Windows XP or Windows Server 2003 and a wireless network is available, Wireless Auto Configuration prompts you with the One Or More Wireless Networks Are Available message in the notification area, which leads you to select a wireless network in the Connect To Wireless Network dialog box.

    After you select a wireless network and the connection is successful, the selected network is automatically added as a preferred network, and you are no longer prompted whenever you are within range of it. For an organization, this is the typical process for configuring the initial connection to a private wireless network. After the initial configuration, Wireless Auto Configuration connects (and then maintains the connection) to the organization’s wireless network.

    When you take your portable computer to your home wireless network, to an airport, or to another location with public wireless access, Wireless Auto Configuration first attempts to connect to your preferred network. When that connection attempt fails, you are prompted again to connect to your home wireless network or to the public access wireless network.

  • If there are two preferred wireless networks, and the most preferred one is not initially available, Wireless Auto Configuration configures a wireless connection to the next most preferred network. When the most preferred network eventually becomes available, Wireless Auto Configuration automatically switches the wireless client connection to it after the next scan.

  • If there are no preferred networks in the list of those available, Wireless Auto Configuration attempts to configure connections to the preferred networks in their configured order, in case the wireless APs for the wireless network are configured to prohibit the beaconing of their SSID.

Related Information

For more information about 802.11 and related technologies, see the Microsoft Wi-Fi Web site.


1 2 3 4 5 6 7 8 9 10 다음



메모장