JP2007129274A - Using connected wireless computer as conduit for disconnected wireless computer - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system and method for using client conduits to enable bootstrapping and fault diagnosis of disconnected wireless clients. <P>SOLUTION: The client conduits are used to enable disconnected clients 305 to diagnose their problems with the help of nearby clients. This technique may take advantage of the beaconing and probing mechanisms of the IEEE 802.11 to ensure that the connected clients 308 do not pay unnecessary overheads for detecting the disconnected clients 305. Methods are also described for detecting rogue devices disguising as disconnected clients 305. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates generally to network operation, and more particularly to diagnosing faults in a wireless network.

  The convenience of wireless networking has led to widespread adoption of wireless networks (eg, IEEE 802.11 networks). Businesses, universities, homes, and public places are deploying their networks at a remarkable rate. However, a significant number of “pain points” remain for end users and network administrators. Users experience several issues such as intermittent connections, poor performance, lack of coverage, and authentication failures. The above problems arise due to various reasons such as poor access point layout, device configuration errors, hardware and software errors, the nature of the wireless medium (eg, interference, propagation), and traffic congestion. Users often complain about connectivity issues and performance issues, and network administrators are expected to diagnose those issues while maintaining corporate security and coverage. The network administrator's job is particularly difficult due to the unreliable nature of the wireless medium as well as the lack of intelligent diagnostic tools to determine the cause of those problems.

  For a company with a large scale deployment of an IEEE 802.11 network, there may be thousands of access points (AS) distributed in many buildings. Network problems result in end-user frustration and lost productivity for the enterprise. In addition, the resolution of each end-user complaint results in additional support staff costs for the company's IT department, which can be in the tens of dollars, which is a loss of end-user productivity. Does not include costs due to

  Fault diagnosis in an IEEE 802.11 infrastructure network has received less attention from the research community compared to other more research areas of interest in wireless networking. Several companies have attempted to provide diagnostic tools, but their products lack a number of desirable features. For example, these products do not perform comprehensive work to collect and analyze data to determine possible causes of problems. In addition, most products typically only collect data from the AP and neglect the findings from the client side of the network. Some products that monitor the network from the client perspective require hardware sensors that can be expensive to deploy and maintain. Also, current problem solving usually provides no support for disconnected clients, even those that need the most help.

US Patent Application Publication No. 10/428218

  The problems outlined above are addressed, at least in part, by systems and methods for detecting and diagnosing faults in a wireless network as described herein.

  The following presents a simplified overview of the present disclosure to provide a basic understanding to the reader. This summary is not an exhaustive or limiting overview of the disclosure. This summary is not provided to identify key or essential elements of the invention, to define the scope of the invention, or to limit the scope of the invention. Its sole purpose is to present some of the concepts disclosed in a simplified form as a prelude to the more detailed description that is presented later.

  In one embodiment, the system and method use client conduits to enable disconnected client bootstrap and fault diagnosis. In some embodiments, client conduits are used to allow disconnected clients to diagnose their problems with the help of nearby clients. This technology leverages the IEEE 802.11 beaconing and probe mechanisms to ensure that connected clients do not incur unnecessary overhead to detect disconnected clients. it can.

  In one embodiment, a computer that facilitates communication between an infrastructure network and a first wireless computing device disconnected from the network via a second wireless computing device connected to the network A computer-readable medium is provided that includes executable instructions, the computer-executable instructions are executed on a first wireless computing device, and monitor wireless traffic on a plurality of channels on the first wireless computing device. Enabling promiscuous mode and inspecting traffic packets of the second wireless computing device to ensure that the second wireless computing device is connected to the infrastructure network. Determining, creating a new wireless network on a channel corresponding to the second wireless computing device, broadcasting a distress signal on the new wireless network, Ending the distress signal in response to receiving an acknowledgment from the second wireless computing device and starting an ad hoc wireless network for connection by the second wireless computing device.

  In another embodiment, communication between an infrastructure network and a first wireless computing device disconnected from the network is facilitated via a second wireless computing device connected to the network. A computer-readable medium is provided that includes computer-executable instructions, wherein the computer-executable instructions are executed on a second wireless computing device and receive a distress signal from the first wireless computing device; Transmitting an acknowledgment to the first computing device; receiving a response to the acknowledgment from the first wireless computing device; and a second wireless computing device entering multi-net mode, and It was initiated by the computing device by to participate in (the originated) ad hoc network, the second wireless computing device to perform the steps to be connected substantially simultaneously to the ad hoc network and an infrastructure network.

  In yet another embodiment, a system is provided for enabling a disconnected wireless computing device to communicate with an infrastructure network via a wirelessly connected wireless computing device, the system disconnecting A first diagnostic client program running on the connected wireless computing device and a second diagnostic client program running on the connected wireless computing device, the first diagnostic client program comprising: Detecting a presence of a designated wireless computing device, allowing a distress signal to be transmitted, creating an ad hoc wireless network on the disconnected wireless computing device, and a second diagnostic client program Receiving, enter the Multi net mode, connect to an ad hoc network on the disconnected wireless computing device.

  BRIEF DESCRIPTION OF THE DRAWINGS While the appended claims describe in detail the features of the present invention, the invention and its advantages are best understood from the following detailed description, taken in conjunction with the accompanying drawings. .

  Methods and systems that allow disconnected computers to communicate information to network administrators and support staff via connected computers are described below in connection with preferred embodiments. However, the method and system of the present invention are not so limited. Moreover, those skilled in the art will readily appreciate that the methods and systems described herein are merely exemplary and that variations can be implemented without departing from the spirit and scope of the invention. . After reviewing the following description, it will be apparent to those skilled in the art that the foregoing is merely exemplary, and is provided by way of example only and not limitation. Numerous variations and other exemplary embodiments are within the scope of those skilled in the art and are intended to be within the scope of the present invention. In particular, many of the examples presented herein involve a specific combination of method operations or system elements, but other combinations of those operations and elements achieve the same purpose. Please understand that you can. Actions, elements and features described only in connection with one embodiment are not intended to be excluded from a similar role in other embodiments. In addition, the use of words representing an order, such as “first” or “second” in a claim that modifies a claim element, by itself, has priority over other claim elements in one claim element, It does not represent any priority, or order, or temporal order in which the operations of the method are performed, it simply represents one claim element with a name, with the same name (with the exception of the use of an order word). ) Is used as a label to distinguish billing elements from other elements having

  Listed below are many of the problems faced by users and network administrators when using and maintaining enterprise wireless networks.

  Connectivity issues: End users complain about inconsistent network connectivity or lack of network connectivity in some areas of the building. Such “dead spots” or “RF holes” can be caused by weak RF signals, lack of signals, changing environmental conditions, or obstacles. Finding RF holes automatically is essential for radio administrators, who can then relocate APs or increase AP congestion in the area in question, or better The problem can be solved by adjusting the power settings on the nearby APs for coverage.

  Performance issues: This category includes all situations where the client observes degraded performance, eg, low throughput or high latency. There are several reasons for performance issues, such as traffic slowdown due to congestion, RF interference due to microwave ovens or cordless phones, multipath interference, poor network design or poorly configured clients / There may be large co-channel interference due to the AP. Performance problems can also arise as a result of problems in the non-wireless part of the network, for example due to slow servers or proxies. Therefore, it is useful to be able to determine with a diagnostic tool whether the problem is in the wireless network or elsewhere. In addition, identifying the cause in the wireless part is important so that network administrators can better provision the system and improve the end user experience.

  Network security: Large enterprises often use enterprise-like solutions such as IEEE 802.1x to secure corporate networks. However, a nightmare scenario arises for IT managers when employees unknowingly compromise security by connecting unauthorized APs to corporate network Ethernet taps. This problem is commonly referred to as the “rogue AP problem”. These rogue APs are one of the most common and serious breach of wireless network security. Due to the presence of such APs, external users may be allowed access to resources on the corporate network, which may leak information or cause other damage. In addition, rogue APs can cause interference to other nearby access points. Detecting rogue APs in large networks via a manual process is expensive and time consuming. For this reason, it is important to detect such APs proactively.

  Authentication problems: According to IT support group logs, some complaints are related to the inability to authenticate themselves to the user, the network. In wireless networks that are secured by technologies such as IEEE 802.1x, authentication failures are usually due to missing certificates or expired certificates. For this reason, it is important to detect such authentication problems and assist in bootstrapping using the client and a valid certificate.

  The invention will be more fully understood through the following detailed description which should be read in conjunction with the accompanying drawings. In the following description, like reference numerals refer to similar elements within the various embodiments of the present invention. Aspects of the invention are illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as procedures, executed by a personal computer. Generally, procedures include program modules, routines, functions, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In addition, the present invention is implemented using other computer system configurations including handheld devices, multiprocessor systems, microprocessor-based consumer electronics or programmable consumer electronics, network PCs, minicomputers, mainframe computers. Those skilled in the art will appreciate that this is possible. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program module (s) can be located in both local and remote memory storage devices. The term computer system may be used to refer to a system of computer (s) found in a distributed computing environment.

  FIG. 1 illustrates an example of a suitable computing system environment 100 on which aspects of the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the usage or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100. While one embodiment of the present invention actually includes each component illustrated in the exemplary operating environment 100, another more exemplary embodiment of the present invention is other than, for example, input / output devices required for network communications. Exclude I / O devices.

  With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. The components of the computer 110 can include a processing device 120, a system memory 130, and a system bus 121 that couples various system components including, but not limited to, system memory to processing device 120. Not. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA). ) Buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses, also known as mezzanine buses.

  Computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media can include computer storage media and communication media. Computer storage media includes volatile and non-volatile media, removable media implemented in any manner or technique for storing information such as computer readable instructions, data structures, program modules, or other data Includes non-removable media. Computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage A device or any other medium that can be used to store desired information and that can be accessed by computer 110 includes, but is not limited to. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above media must also be included within the scope of computer-readable media.

  The system memory 130 includes computer storage media in the form of volatile and / or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input / output system 133 (BIOS) that includes basic routines that help to transfer information between elements within the computer 110, such as during startup, is typically stored in the ROM 131. The RAM 132 typically contains data and / or program modules that the processing device 120 can access immediately and / or is currently processing. By way of example and not limitation, FIG. 1 shows an operating system 134, application program (s) 135, other program modules (s) 136, and program data 137.

  The computer 110 may also include other removable / non-removable volatile / nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads or writes to a non-removable non-volatile magnetic medium, a magnetic disk drive 151 that reads or writes to a non-removable non-volatile magnetic disk 152, and a CD. An optical disc drive 155 that reads from or writes to a removable, non-volatile optical disc such as a ROM or other optical media. Other removable / non-removable volatile / nonvolatile computer storage media that can be used in typical operating environments include magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tapes, solid state RAM, Although solid state ROM etc. are included, it is not limited above. The hard disk drive 141 is normally connected to the system bus 121 via a non-removable memory interface such as the interface 140, and the magnetic disk drive 151 and the optical disk drive 155 are usually systems with a removable memory interface such as the interface 150. Connected to the bus 121.

  The computer 110 includes computer readable instructions, data structures, program modules, and other data storage, as described above and illustrated in FIG. 1 and associated computer storage media. In FIG. 1, for example, the hard disk drive 141 is shown storing an operating system 144, application program (s) 145, other program modules (s) 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application program (s) 135, other program module (s) 136, and program data 137. Operating system 144, application program (s) 145, other program module (s) 146, and program data 147 are here given different symbols to indicate that they are different copies. A user may enter commands and information into the computer 110 through tablets or electronic digitizers 164, a microphone 163, a keyboard 162, and a pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) include joysticks, game pads, satellite dishes, scanners, and the like. These and other input devices are often connected to the processing unit 120 via a user input interface 160 coupled to the system bus, but other devices such as a parallel port, game port, or universal serial bus (USB) You may connect by an interface and bus structure. A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. The monitor 191 may be integrated with a touch screen panel or the like. Note that the monitor and / or touch screen panel can be physically coupled to a housing in which the computing device 110 is incorporated, such as in a tablet-type personal computer. In addition, a computer such as computing device 110 may also include other peripheral output devices such as speakers 197 and printer 196 that may be connected via output peripheral interface 194 or the like.

  Computer 110 may also operate in a networked environment using logical connections to one or more remote computers, such as remote computer 180. The remote computer 180 can be a personal computer, server, router, network PC, peer device, or other common network node, and typically many or all of the elements previously described with respect to the computer 110. Only the memory storage device 181 is shown in FIG. The logical connections shown in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but other networks can also be included. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

  When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or network adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which can be internal or external, can be connected to the system bus 121 via the user input interface 160, or other suitable mechanism. In a networked environment, the program module (s) shown in connection with the computer 110, or portions of the program module (s), can be stored in a remote memory storage device. By way of example, and not limitation, FIG. 1 shows that remote application program (s) 185 are present on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used. In particular, the computer 110 preferably includes a wireless networking interface or wireless card that operates in accordance with the IEEE 802.11 protocol.

  In an embodiment of the present invention, the system consists of several components as shown in FIG. The diagnostic client (DC) 202 is software executed on the wireless client machine 204. A diagnostic AP (DAP) 206 is executed on the access point 208. A diagnostic server (DS) 210 runs on the organization's back-end server 212.

  In some embodiments of the invention, the diagnostic client module 202 monitors the RF environment and traffic flows from neighboring clients (s) 214 and APs (s) 216. During normal activity, the client's wireless card is not in promiscuous mode. The DC 202 performs local fault diagnosis using the collected data. Depending on the individual fault detection mechanism, this summary of data is preferably transmitted to the DAP (s) 206 and DS (s) 210 at regular intervals. In addition, the DC 202 is programmed to accept commands from the DAP 206 or DS 210, for example, to switch to promiscuous mode, analyze nearby client performance issues, and perform on-demand data collection. If the wireless client 204 is disconnected, the DC 202 logs the data to a local database / file. This data can be analyzed by DAP 206 or DS 210 at some point in the future when the network connection is resumed.

  The diagnostic AP 206 accepts diagnostic messages from the DC (s) 202, merges these messages with their own measurements, and sends a summary report to the DS 210. Some embodiments of the present invention do not include a diagnostic AP 206. The DAP 206 reduces the work burden from the DS 210. Some embodiments of the invention include a mixture of legacy APs 220 and DAPs 206, and monitoring of APs when the AP is a legacy AP 220 (eg, an AP that is not running a diagnostic AP). The function is performed by the DC (s) 202 and the AP summarization function and inspection is performed in the DS 210.

  Diagnostic server 210 accepts data from DC (s) 202 and DAP (s) 206 and performs appropriate analysis to detect and diagnose various faults. The DS 210 also has access to a database 221 that stores the location of each AP 208. The network administrator can balance the load by deploying a plurality of DSs 210 in the system and, for example, hashing the MAC address of each AP to a specific DS 210. In some embodiments, the diagnostic server 210 interacts with other network servers (such as a Radius 230 server and a Kerberos 232 server) to obtain client permissions and user information.

  The exemplary system described with reference to FIG. 2 supports both reactive and proactive monitoring. In proactive monitoring, the DC (s) and DAP (s) continuously monitor the system, and if an anomaly is detected by DC, DAP, or DS, an alert is issued for the network administrator to investigate . The reactive monitoring mode is used when the support staff wishes to diagnose user complaints. The staff can issue directives to collect and analyze data for diagnosing problems from one DS of the DS (s) to a particular DC.

  A typical system imposes negligible overhead on power management. Both the proactive and reactive technologies described below consume very little bandwidth, CPU, or disk resources, and as a result, both proactive and reactive technologies are negligibly small in battery consumption. It only affects. The exemplary system architecture shown in FIG. 2 supports several functions in embodiments of the present invention by using DC (s), DAP (s), and DS (s). Some of the supported features include locating disconnected clients, assisting disconnected clients, isolating performance issues, and detecting rogue access points.

  In some embodiments of the present invention, the DAP 206 is a software change of the AP 208, allowing for better scalability and allowing the AP performance to be analyzed. Since no hardware changes are required, the obstacle to deploying this embodiment is low.

  Client machine 204 and access point 208 preferably have the ability to control beacons and probes. In addition, the client machine 204 preferably also has the ability to initiate an infrastructure network on its own (ie, become an AP), or initiate an ad hoc network (ie, computer-computer), Currently supported by a number of wireless cards available. Some embodiments of the present invention utilize the presence of nearby clients or access points. Exploiting nearby client (s) and access point (s) with software “sensors” may reduce deployment costs.

  The backend server 212 preferably uses a database to maintain the location of all access points in the network. Such location database (s) are preferably maintained by a network administrator.

  The exemplary system shown in FIG. 2 can scale to the number of clients and APs in the system. The system includes two shared resources: DS (s) and DAP (s). In order to prevent a single diagnostic server from becoming a potential bottleneck, additional DS (s) are preferably added as the system load increases. Further, some embodiments allow each individual DS to reduce the work burden by sharing the diagnostic burden with DC (s) and DAP (s), where DC is DC ( ) And DAP (s) are unable to diagnose the problem, and the analysis is global perspective, and additional data (eg, from multiple DAPs to find disconnected clients) Used only when requesting acquired signal strength information (may require signal strength information).

  Similarly, because DAP is a shared resource, having DAP do extra work can potentially compromise the performance of all associated clients. In order to reduce the load on the DAP, some embodiments of the present invention do not perform an active scan when there are clients associated with the AP, and the associated clients (s) Use optimization techniques to perform those actions, if necessary. The AP continues to perform passive monitoring activities that have a negligible impact on the performance of the AP. If there are no associated clients, the AP is idle and can perform their monitoring operations. This approach ensures that most of the physical area around the AP is monitored without compromising the performance of the AP.

  In one embodiment, the interaction between DC, DAP and DS is secured using an EAP-TLS certificate issued via IEEE 802.1x. An authorized certification authority (CA) issues certificates to DC (s), DAP (s), and DS (s), which authenticate all communications between these entities to each other Used to ensure that it is done. One embodiment includes known techniques for detecting malicious behavior by legitimate users.

  Turning to FIG. 3, a “client conduit” mechanism is shown that allows disconnected wireless clients to communicate information to network administrators and support staff, according to an embodiment of the present invention. If the wireless client 302 cannot connect to the network 304, the DC 305 residing on the client 302 logs the problem in the DC 305 database. When the client 302 later connects (eg, via a wired connection), this log is uploaded to the DS 306, which performs a diagnosis to determine the cause of the problem. However, sometimes the client 302 can be in the range of other connected client (s) and the client 302 is slightly outside the range of any AP. Or being disconnected due to authentication problems. In this situation, it is desirable to perform fault diagnosis immediately using the DS 306 and correct the problem if possible.

  The IEEE 802.11 standard does not allow clients to be connected to two networks simultaneously. For this reason, it is not possible to have a disconnected node 302 simply send a message to a connected neighbor 308 using existing technology. Since the connected node 308 is already associated with the infrastructure network 304, it cannot simultaneously connect to the ad hoc network with the disconnected client 302 and wants to receive messages from the disconnected client 302 If so, node 308 must first disconnect and then join the ad hoc network initiated by client 302. This is inefficient and unfair to connected clients that are functioning properly. Some embodiments may use multiple radios on a connected client 308 (a client dedicated to diagnostics on an ad hoc network) or MutiNet (a client may have a single radio card on multiple networks). By using a single wireless card (as above) or by having the connected client 308 periodically scan all channels (eg, After entering promiscuous mode and detecting a distress signal from a disconnected client), solve this problem. Unlike these approaches, the client conduit mechanism used in embodiments of the present invention imposes no overhead in the general case where there are no clients disconnected in the neighborhood.

  In accordance with an embodiment of the present invention, the client conduit mechanism allows a disconnected client 302 to be diagnosed by the DS 306 via one of the nearby connected clients 308. The client conduit avoids penalizing connected client (s) by taking advantage of two operational facts regarding IEEE 802.11. First, even if client 308 is associated with AP 310, client 308 continues to receive beacons at regular intervals from neighboring APs or ad hoc networks. Second, the connected client 308 can send a directed probe request or a broadcast probe request without disconnecting from the infrastructure network 304.

  Referring to FIG. 4, a client conduit method for a scenario in which a disconnected client D is in the vicinity of a connected client C is shown. In step 402, the DC on disconnected client D configures the machine to operate in promiscuous mode. The DC scans all channels and determines in step 404 whether there are nearby clients connected to the infrastructure network. If the DC detects such a connected client on the channel, at step 406, the DC initiates a new infrastructure network or ad hoc network on the channel on which it detected the client's packet. Preferably, the client D may switch the mode to become an AP and start an infrastructure network, or alternatively, the client D may start an ad hoc network. Client D preferably determines whether the data packet is part of the infrastructure network and is being sent to / from the AP by examining the ToDS and FromDS fields of the IEEE 802.11 data frame.

  In step 408, the newly formed AP in D broadcasts a beacon having an SSID of the form “SOS HELP <num>” as if it were a normal AP, where num It is a 32-bit random number that distinguishes a disconnected client. Alternatively, D can send a broadcast packet instead of a beacon. The beacon or broadcast packet acts as a distress signal to notify nearby clients.

  In step 410, the DC on connected client C detects the SOS beacon of this new AP. At that point, C informs D that D's request has been heard using an acknowledge in the following manner. If C attempts to connect to D, he will need to disconnect from the infrastructure network, compromising the performance of C's application (s). Instead, client C uses the “active scan” mechanism of the IEEE 802.11 network. That is, C sends a probe request in the form of “SOS ACK <num>” to D in step 412. The probe request is preferably sent with a different SSID than that advertised by the AP running on D. This approach allows any other nearby client not involved in the client conduit protocol to send a probe request to D (as part of that client's normal test to detect new APs in that client's environment). ) Transmission by accident is prevented. Alternatively, C can send a broadcast packet with its own message as an acknowledgment rather than an 802.11 probe request.

  When D hears this probe request (and possibly other requests), it stops being an AP and becomes a station again at step 414. Further, in response to a probe request received from C, at step 416, a probe response is sent by D, and client C knows that at that point, no further probe request needs to be sent (client C has In any case, when D's beacon stops, transmission of the probe request is stopped). More importantly, D's probe response indicates whether D wants to use client C as a hop to exchange diagnostic messages with DS. This response mechanism ensures that if multiple connected clients attempt to support D, only one of those clients will be selected by D to set up a conduit for the DS. To.

  In step 418, D initiates an ad hoc network, and in step 420 C joins the network via MultiNet. Further details regarding MultiNet according to embodiments of the present invention are filed on May 2, 2003, and are co-pending (eg, patent documents) incorporated by reference for all teachings, without excluding any part. 1) Seen by reference. The steps performed up to this point are called the “connection setup” phase. At this point, C becomes a conduit for D's message and the “data transfer” phase in which D can exchange diagnostic messages with DS via C begins.

  Through the use of the method as shown in FIG. 4, embodiments of the present invention using a client conduit protocol ensures that connected clients do not experience unnecessary overhead during normal operation. Make sure. Further, some embodiments use a client conduit mechanism to bootstrap the client. For example, assume that a client attempts to access a wireless network for the first time, does not have an EAP-TLS certificate, but has other credentials such as Kerberos credentials. Embodiments of the present invention use a client conduit mechanism to authenticate users / machines to the backend Radius / Kerberos server (s). A new certificate is then installed on the client machine, or a certificate whose client has expired is refreshed without requiring a wired connection. Client D is in the range of the AP and can be disconnected due to IEEE 802.1x authentication issues. Some embodiments use a client conduit mechanism if the connected client is also in range. If no such client exists, the AP can be dynamically configured to the backend DS (or to the RADIUS server (s) that can forward to the DS via an uncontrolled port). D) diagnostic messages can be enabled.

  Embodiments of the present invention manage security risks that may be introduced through the use of client conduit mechanisms. For example, some embodiments may be malicious / nothing by requesting the connected client to allow disconnected client packets to be exchanged only with the DS or backend authentication server (s). Ensuring that authorized clients do not gain any access to the network. Other security and performance risks are similarly managed as described below.

  If the connected client C assists a disconnected client via a client conduit, in some embodiments it is preferable to ensure that the performance of C's application (s) is not adversely affected. To that end, for example, during the connection setup described in connection with FIG. 4, the connected client C processes the beacon message and / or the transmit / receive probe message and forwards it by C on behalf of the disconnected client. There is no message to be sent. These steps not only consume negligible resources on C, but do not result in any security breach or compromise on C. In addition, C can rate-limit or stop executing those steps if it notices that disconnected clients are making them perform those steps frequently. .

  Once the connection is established and data transfer begins, embodiments manage possible security and denial of service attacks. There is a risk that a malicious client can waste the resources of the connected client C by unnecessarily putting the connected client C into the MultiNet mode and consuming bandwidth. In order to prevent this problem, as shown in FIG. 5, prior to data transfer, preferably the following authentication step is performed, and only legitimate clients are allowed to connect via client C. Make sure. After the connection setup phase, client C switches to MultiNet mode at step 502 to perform authentication. In order to prevent denial of service (DoS) attacks where C is forced to repeatedly enter the MultiNet mode, C preferably limits the number of times per minute that C performs such authentication steps. As part of the authentication step, client C checks in step 504 whether D has an EAP-TLS machine certificate. If so, C obtains its certificate from the disconnected client at step 506 and validates the certificate at step 508 (to ensure mutual authentication, client D is also preferably , Perform those steps). If the disconnected client has no certificate at all, or if the disconnected client's certificate has expired, then in step 510, client C performs the desired authentication protocol. Acting as an intermediary, for example, C can help D perform Kerberos authentication from backend Kerberos servers and obtain relevant tickets. In step 512, C checks with DS whether D has been authenticated. If the disconnected client D is still unable to authenticate, C asks C to send the last few kilobytes (eg, 10 kilobytes) of D's diagnostic log to C in step 514, where C The log is transferred to the DS. In order to prevent possible DoS attacks where a malicious client repeatedly attempts to send its unauthenticated logs (eg, spoofing different MAC addresses), the connected client is preferably Limit the total amount of unauthenticated data that is transmitted within a predetermined period of time, for example, C tells it to send no more than 10 kilobytes of such data every 5 minutes.

  Embodiments of the present invention allow a connected client C to limit the amount of resources it wishes to allocate to a disconnected client D, even when supporting a legitimate client during a MultiNet transfer. To further manage security risks. A software “knob” is provided that allows the client to limit the percentage of time spent on the ad hoc network compared to the infrastructure network, and client C limits this utilization, Battery power can also be saved.

  An additional security risk addressed by embodiments of the present invention relates to unauthorized or “rogue” access points. An attacker who wants to set up an unauthorized AP and want to remain unaware may attempt to take advantage of the characteristics of the client conduit. That is, the attacker AP is set up to beacon using the SOS SSID. Embodiments distinguish between the case where the beacon device is a legitimate client and the case where the beacon device is actually a rogue AP. In a client conduit, when a disconnected client becomes an AP or initiates an ad hoc network and initiates beaconing during connection setup, the client transmits or receives data packets. Not at all. For this reason, if the DC is beaconing the SOS SSID and detecting an AP (or a node in ad hoc mode) transmitting / receiving a data packet, the DC will Set the flag immediately as a device. Furthermore, as yet another form, if the assisting client hears a probe response with the client conduit protocol described with reference to FIG. You can know that there is no. For this reason, when the support side client hears the SOS beacon after several seconds, the support side client sets a flag as a distinguished rogue device in the device.

  Turning to FIG. 6, details of one embodiment of the implementation are shown. The basic architecture consists of a DC daemon, DAP daemon, and DS daemon running on the client (s), access point (s), and server (s), respectively. The system can be implemented, for example, on a MICROSOFT WINDOWS® operating system using a standard commercial 802.11b card. On the DS, the daemon process accepts information from the DAP (s). The DS reads a list of valid APs from a file or database. The structure of the code on the DC or DAP preferably includes a user level daemon 602 and kernel level drivers 604 and 606. These pieces are structured so that code is added to the kernel drivers 604 and 606 only if the functionality cannot be reached in the user level daemon 602 or if the performance penalty is too high.

  In a typical system, there are two kernel drivers, the miniport driver 604, and an intermediate driver (IM driver) 606, such as the native Wi-Fi driver in the MICROSOFT WINDOWS® operating system. The miniport driver 604 communicates directly with the hardware and provides basic functions such as sending / receiving packets and setting channels. Driver 604 exposes sufficient interface (s) to allow functions such as association, authentication, etc. to be handled in IM driver 606. The IM driver 606 supports several interfaces (exposed via IOCTLs) for querying various parameters such as current channel, transmission level, power management mode, SSID. In addition to allowing parameters to be set, the driver 606 allows user level code to request an active scan, associate with a particular SSID, and capture a packet. In general, driver 606 provides considerable flexibility and control over user level code.

  Although many operations already exist in IM driver 606, embodiments of the present invention have used modifications to expose some functionality and improve the performance of certain protocols. . Miniport driver 604 is preferably minimally modified to expose certain types of packets to IM driver 606. In IM driver 606, the following support is preferably added. That is, capturing packet headers and packets, storing RRSI values from received packets, recording AP information, and kernel event support for protocol efficiency. Next, the above changes will be described in more detail.

  Capturing packet headers and packets: Embodiments of the present invention allow, for example, specific MAC addresses, packet types, packet subtypes (management packets and beacons) so that only some packets or packet headers are captured. Filter (s) based on etc.) can be set.

  Storing RSSI values from received packets: Embodiments of the present invention obtain RSSI values for all received packets and RSSI values from each neighbor (indexed on the MAC address). A table called a NeighborInfo table is kept. The exponential weighted average is held with the new value given, for example, a weighting factor of 0.25.

  Recording AP information: In the NeighborInfo table, embodiments include the channel on which a packet from a particular MAC address was heard, the SSID information (from the beacon), and the device is an AP or station Take a record of whether

  Kernel event support for protocol efficiency: Events shared between the kernel and user level code are preferably added. The kernel triggers this event when an “interesting” event occurs, which allows part of the protocol to be interrupt driven rather than poll based. In one embodiment, the kernel sets this event whenever a SOS beacon is heard from a disconnected client during a client conduit, resulting in lower protocol latency.

  In addition, some ioctls are preferably added that perform the acquisition and deletion of the information described above.

  In embodiments of the present invention, a diagnostic daemon 602 runs on the device, collects information, implements the various mechanisms described above, and executes, for example, client conduits. If the device is an AP, it communicates diagnostic information to the DS and DC (s), and if it is only DC, it communicates with the associated AP to transmit diagnostic information. The diagnostic daemon on the DC obtains the current NeighborInfo from the kernel 608 at regular intervals, for example every 30 seconds. If any new node is found, or if the existing data has changed significantly (eg, the client's RSSI value has changed more than twice), it is sent to the DAP Is done. The DAP also preferably maintains a similar table indexed on the MAC address. However, the DAP only sends information about the disconnected clients and APs to the DS, otherwise the DS will get updates for all clients in the system. And make DS less scalable. The DAP sends new or changed information about the AP (s) to the DS periodically (eg, every 30 seconds). In addition, if the DAP has any pending information about the disconnected client D, it immediately informs the DS so that the disconnected client can be serviced in a timely manner. All messages from DC to DAP and from DAP to DS are preferably sent as XML messages. The sample message format from the DC is shown below (time stamps are removed):

  As the sample message indicates, the DC sends information about other connected clients, AP (s), and disconnected clients (s). For each such class of entity, the DC sends the machine's MAC address along with the RSSI, SSID, and a channel bitmap that indicates the channel over which that particular device was overheard.

  In view of the large number of possible embodiments to which the principles of the present invention may be applied, the embodiments described herein in connection with the drawings are intended to be illustrative only, and It should be recognized that it should not be construed as limiting the scope of the invention. For example, those skilled in the art will recognize that the configuration and details of the illustrated embodiments can be changed without departing from the spirit of the invention. Although the present invention has been described in terms of software module (s) or software component (s), the software module (s) or software component (s) can be replaced in equal form by hardware component (s). However, those skilled in the art will recognize. Accordingly, the invention described herein contemplates all such embodiments that can be included within the scope of the appended claims and their equivalents.

FIG. 2 is a simplified schematic diagram illustrating an exemplary architecture of a computer used in accordance with an embodiment of the present invention. 1 illustrates an exemplary wireless network for using client conduits according to an embodiment of the present invention. FIG. FIG. 3 illustrates communication between a connected computer and a disconnected computer, according to an embodiment of the present invention. 3 is a flow diagram illustrating a method for facilitating communication from a disconnected computer to a wireless network, in accordance with an embodiment of the present invention. 6 is a flow diagram illustrating a method for detecting performance degradation of a supporting client, according to an embodiment of the present invention. FIG. 3 is a schematic diagram of software components used to locate disconnected clients and rogue access points, according to embodiments of the present invention.

Explanation of symbols

120 processor 121 system bus 122 memory cache 130 system memory 134, 144 operating system 135, 145 application program 136, 146 other program modules 137, 147 program data 140 non-removable non-volatile memory interface 150 removable non-volatile memory interface 160 user Input interface 161 Mouse 162 Keyboard 170 Network interface 171 Local area network 172 Modem 173 Wide area network 180 Remote computer 185 Remote application program 190 Video interface 195 Output peripheral interface 196 Printer 197 Speakers 202, 305, 3 8 Diagnostic Client 206 diagnostic access points 208,310 access points 210,306 diagnostic server 220 legacy access point 602 diagnostic daemon

Claims (25)

Computer readable comprising computer executable instructions for facilitating communication between an infrastructure network and a first wireless computing device disconnected from the network via a second wireless computing device connected to the network A medium, wherein the instructions are executed on the first wireless computing device;
Enabling promiscuous mode on the first wireless computing device to monitor wireless traffic on a plurality of channels;
Inspecting traffic packets of the second wireless computing device to verify that the second wireless computing device is connected to the infrastructure network;
Creating a new wireless network on a channel corresponding to the second wireless computing device;
Broadcasting a distress signal over the new wireless network;
Ending the distress signal in response to receiving an acknowledgment from the second wireless computing device;
Initiating an ad hoc wireless network for connection by the second wireless computing device.   The computer-readable medium of claim 1, further comprising transmitting an acknowledgment to the second wireless computing device prior to the initiating step.   The computer-readable medium of claim 1, further comprising transmitting authentication information to the second wireless computing device to authenticate to the infrastructure network.   The computer-readable medium of claim 1, further comprising the step of sending a diagnostic message to the infrastructure network via the second wireless computing device.   The creating step includes causing the first wireless computing device to initiate an ad hoc network or to act as a wireless access point, and the distress signal conforms to a known wireless protocol. The computer-readable medium of claim 1, comprising a beacon.   The computer-readable medium of claim 5, wherein the beacon includes a random number.   The computer-readable medium of claim 1, wherein the distress signal includes a broadcast packet configured in accordance with a public protocol or a proprietary protocol. Computer readable comprising computer executable instructions for facilitating communication between an infrastructure network and a first wireless computing device disconnected from the network via a second wireless computing device connected to the network A medium, wherein the instructions are executed on the first wireless computing device;
Receiving a distress signal from the first wireless computing device;
Transmitting an acknowledgment of the distress signal to the first computing device;
Receiving a response to the acknowledgment from the first wireless computing device;
Causing the second wireless computing device to participate in an ad hoc network initiated by the first wireless computing device so that the second wireless computing device is substantially both in the ad hoc network and the infrastructure network; A computer readable medium comprising the steps of:   The computer-readable medium of claim 8, wherein the second wireless computing device participates in the ad hoc network via a multi-net mode.   The computer-readable medium of claim 9, wherein the computer-executable instructions further cause the second wireless device to enter the multi-net mode as a result of receiving the response.   The second wireless computing device includes two or more wireless adapters, and the second wireless computing device is connected to the infrastructure network via one wireless adapter and via another wireless adapter. The computer-readable medium of claim 8, wherein the computer-readable medium is connected to the first wireless computing device.   The computer-readable medium of claim 8, wherein the computer-executable instructions further cause a step of scanning periodically for a distress signal from a wireless computing device disconnected from the infrastructure network. .   9. The computer-readable medium of claim 8, wherein the distress signal includes a network identification label, and the acknowledgment includes a network identification label that is different from the identification label.   The computer-readable medium of claim 8, wherein the acknowledgment is an 802.11 probe request. Receiving authentication information from the first wireless computing device;
The computer-readable medium of claim 8, further comprising the step of transmitting the authentication information to the infrastructure network. Receiving credentials from the infrastructure network regarding the first wireless computing device;
The computer-readable medium of claim 15, further comprising: transmitting the credential information to the first wireless computing device.   The computer-readable medium of claim 16, wherein the transmitted credentials enable the first wireless computing device to wirelessly connect directly to the infrastructure network. Receiving a diagnostic message from the first wireless computing device;
9. The computer-readable medium of claim 8, further comprising the step of transmitting the diagnostic message to the infrastructure network via the second wireless computing device.   The computer-readable medium of claim 9, wherein time allocation for the connection to the infrastructure network and the connection to the ad hoc network in multi-net mode is controlled via configurable settings. Continuing to receive the distress signal from the first computing device after receiving the response;
The computer-readable medium of claim 8, further comprising the step of identifying the first computing device as a rogue device. A system for enabling a disconnected wireless computing device to communicate with an infrastructure network via a wirelessly connected wireless computing device, comprising:
On the disconnected wireless computing device that detects the presence of the wirelessly connected wireless computing device, causes a distress signal to be transmitted, and creates an ad hoc wireless network on the disconnected wireless computing device A first diagnostic client program executed in
Receiving the distress signal and connecting to the ad hoc wireless network on the disconnected wireless computing device while maintaining a substantially simultaneous connection to the infrastructure network And a second diagnostic client program running on the wireless computing device.   The system according to claim 21, wherein the second diagnostic client program connects to the ad hoc network after entering a multi-net mode.   A diagnostic server program executed on a network server on the infrastructure network, wherein the program is disconnected by the second diagnostic client program executed on the wirelessly connected wireless computing device; 24. The system of claim 21, receiving authentication information transmitted on behalf of a wireless computing device.   The diagnostic server program facilitates authentication of the disconnected wireless computing device, and through the second diagnostic client program executed on the connected computing device, the disconnected wireless computing 24. The system of claim 21, wherein credential information about the device is transmitted. The system according to claim 21, wherein the second diagnostic client program receives diagnostic information from the first diagnostic program and transfers the diagnostic information to the diagnostic server program.

Images