Electrical computers and digital data processing systems: input/ – Input/output data processing – Peripheral configuration
Reexamination Certificate
2000-05-09
2003-03-04
Gaffin, Jeffrey (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Peripheral configuration
C710S015000, C710S019000, C709S220000, C709S224000
Reexamination Certificate
active
06529965
ABSTRACT:
FIELD OF THE INVENTION
The present invention pertains generally to the field of computer networking. More particularly, the present invention pertains to software applications used for configuring networking hardware installed on a computer system.
BACKGROUND OF THE INVENTION
Computer networks can be arranged in numerous configurations and in a variety of network types. Some of the most popular types of networks are Ethernet (coaxial cable or twisted-pair cable), token ring, Fiber Distributed Data Interface (FDDI), Frame Relay, Integrated Services Digital Network (ISDN), X.25, and Synchronous Data Link Control (SDLC). Typically, these networks are arranged in local area networks (LANs) and wide area networks (WANs). Usually, LANs are distinguished from WANs based upon the geographical area they cover and sometimes the number of users connected to the network. For example, a group of personal computers (PC) in a home or single business site (location) usually communicate with each over a LAN. Groups of PCs that are at remote locations from one another, such as those in different homes, different companies, or different branch offices of the same company, typically communicate with each other over a WAN. Most WANs typically require significant resources to provide service to a large number of users spread over a vast geographical area causing a WAN to be relatively expensive to build and maintain.
Some users utilize the Internet for virtual private networking to avoid the costs of a true private WAN network and/or paying for long distance communication bills. In essence, virtual private networking entails encrypting and decrypting IP packets for transport across the Internet. In some virtual private networks (VPNs), the payload portion of an IP packet is encrypted for transport across the Internet. The header information is left intact so that routers can forward the packet as it traverses the Internet. In other VPNs, an entire IP packet is encrypted and then encapsulated into new IP packets for transport across the Internet.
One use of the VPN is that it allows a mobile computer system (e.g., a laptop) to be connected to a remote LAN. Typically, a user of the mobile computer system initiates a local call to an Internet Service Provider (ISP) and establishes an Internet session. Then, the mobile computer system sends an Internet message via the Internet to the remote LAN. The mobile system and the remote LAN then engage in a security protocol or handshaking to verify the user is an authorized user permitted to have access to the LAN. Once it is established the user is authorized to have access to the second LAN, a VPN is established, allowing the user and the remote computer system to access data stored within the LAN.
Windows 95® and Windows 98® operating systems, however, do not provide native support for several types of VPNs. Therefore, a VPN software package is typically required to be installed in a system to provide for such specialized networking needs. “Virtual” network interface cards (NICs) are often installed as part of a VPN software package. By way of background, “real” NICs are those associated with one or more pieces of hardware installed on the computer. They include PCI NIC cards, ISA NIC cards, PCMCIA NIC cards, USB NIC cards, etc. A “virtual” NIC is one that is not associated with any hardware. Some examples of “virtual” NICs include “Dial-Up Networking,” “Internet Connection Sharing,” and “VPN.” Virtual NICs are well known in the art and are a common way of providing specialized networking support.
When a VPN client is installed under Windows 95® or Windows 98®, it redirects a NIC's TCP/IP bindings, sometimes using one or more software virtual NICs. This redirection is done in the Windows™ System registry. Since the various VPN clients use slightly different methods for redirecting the TCP/IP bindings, it becomes difficult for a software application to reliably detect the TCP/IP binding for a particular NIC. To make matters worse, when a VPN is installed, the standard detection scheme for determining where the TCP/IP settings for each NIC are located in the registry no longer works.
Therefore, what is needed is a software application that allows an administrator or end-user to more easily modify the network settings associated with the Network Interface Cards (NICs) installed on a computer, whether or not a VPN client is installed.
SUMMARY OF THE DISCLOSURE
Accordingly, the present invention provides a method for detecting TCP/IP (Transmission Control Protocol/Internet Protocol) bindings for Network Interface Cards (NICs) installed on Windows 95® and Windows 98® operating systems with a VPN (Virtual Private Network) client present. More particularly, the present invention provides a method for parsing the Windows™ system registry to detect TCP/IP bindings for network interface cards installed within a host computer system. One embodiment of the present invention provides a DriverCheck function and a HardwareCheck function that can be implemented as parts of a computer software that detects TCP/IP bindings for installed network interface cards.
In accordance with one embodiment of the present invention, in order to determine whether a NIC (Network Interface Card) is bound to TCP/IP, the “Net” registry key for the NIC must be known. This is the key representing the NIC that is located under the “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\Net” registry key. Using the key as an input, the DriverCheck function and the HardwareCheck function of the present embodiment will return TRUE if the NIC is bound to TCP/IP, and FALSE otherwise. If TRUE is returned, the DriverCheck function of the present embodiment will also return the registry key location for the TCP/IP binding for that NIC.
In one embodiment, the DriverCheck function receives a value representing a registry key under the tree “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class”, and opens an “Ndi” subkey of the registry key. DriverCheck then extracts a “DeviceID” string value from the “Ndi” subkey. Thereafter, DriverCheck searches all the registry keys under the “HKEY_LOCAL_MACHINE\Enum” key for a hardware key that matches the “DeviceID” string value. If it is found, DriverCheck calls a HardwareCheck function with the first hardware key as input. HardwareCheck may return the TCP/IP registry key location. If so, the DriverCheck process could terminate.
If HardwareCheck does not return the TCP/IP registry key location, DriverCheck extracts a “MacName” string value from the registry key, and searches all the registry keys under the “HKEY_LOCAL_MACHINE\Enum” key for a second hardware key that matches the “MacName” string value. If a matching hardware key exists, DriverCheck calls HardwareCheck with the second hardware key as input. Again, if HardwareCheck returns the TCP/IP registry key location, the DriverCheck process could terminate.
If HardwareCheck still fails to return the TCP/IP registry key location, DriverCheck opens a “Ndi\Compatability” subkey of the registry key, and extracts an item from a “RequireAll” string value found therein. DriverCheck then searches all the registry keys under the “HKEY_LOCAL_MACHINE\Enum” key for a third hardware key that matches the item; and calls the HardwareCheck with the third hardware key as input if such a matching key can be found. If HardwareCheck returns the TCP/IP registry key location, the DriverCheck process could terminate.
In furtherance of one embodiment of the present invention, the HardwareCheck function receives a hardware key and opens a “Bindings” subkey under the hardware key. HardwareCheck enumerates every string value name under the “Bindings” subkey. For every string value name enumerated, HardwareCheck creates a first variable BindingName representative of the string value name and a second variable BindingPath representative of a concatenation of a string “HKEY_LOCAL_MACHINE\Enum\Network\” and BindingName. HardwareCheck then determines i
Smith Ronald D.
Thomsen Brant D.
3Com Corporation
Gaffin Jeffrey
Perveen Rehana
Wagner , Murabito & Hao LLP
LandOfFree
Method of detecting TCP/IP bindings of installed network... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method of detecting TCP/IP bindings of installed network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method of detecting TCP/IP bindings of installed network... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3061257