The present invention is directed toward management of the devices and services hosted on a network. Various aspects of the invention are particularly suitable for assisting a network device setup utility or a network management tool in configuring or managing a device in a network.
Computing devices have become commonplace tools in modern society, and even many small businesses and families now have one or more computing devices. In a small business, for example, multiple employees may use a computer, such as a desktop computer, laptop computer, personal digital assistant or “smart” wireless telephone. When a family shares a single residence, one or more family members may have a computer. Further, both businesses and personal residences may additionally employ one or more various computing appliances that incorporate or otherwise interact with computers. For example, a family member may use a digital music player, a printer, a refrigerator, a “Voice over Internet Protocol” telephone, a digital music server, a digital camera, or even an environmental control system that includes or otherwise interacts with a computer.
In order to optimize the use and flexibility of these computing devices, a business or family may link them together to form a small private network. Typically, each of the computing devices is connected to a router through a network adapter. The router then “routes” packets of data to and from each computing device. With this type of small private network, the router can in turn be connected to one or more larger private or public networks, such as the Internet. By sending and receiving messages through the router, each networked computing device may then communicate with computing devices outside of the private network. In this arrangement, the router serves as a “gateway” device that provides a gateway to outside of the private network.
While this type of small or “home” network can provide enhanced utility for its member computing devices, even a small network can be very difficult for a non-technical person to set up and maintain. Accordingly, various software developers have created tools to assist novice users in setting up or managing a small network. Conventionally, these tools were embedded in a larger software product, such as an operating system or a utility application. More recently, however, Pure Networks of Seattle, Wash. has developed a dedicated software application tool for managing small networks. This software application tool, available from Pure Networks under the name NETWORK MAGIC, is described in detail in U.S. Provisional Patent Application No. 60/634,432, filed Dec. 7, 2004, entitled “Network Management” and naming Steve Bush et al. as inventors, and U.S. patent application Ser. No. 11/297,809, filed on Dec. 7, 2005, entitled “Network Management” and naming Steve Bush et al. as inventors, which applications are incorporated entirely herein by reference.
While these tools provide varying degrees of assistance, their usefulness is influenced by the amount of information that they can obtain regarding computing devices in the network. For example, if the NETWORK MAGIC software application can accurately determine that a networked computing device is a network camera, it can open the appropriate ports on a small network's router to make the network camera accessible via the Internet, or present an appropriate user interface to manage the network camera or display the camera's video feed.
Currently, however, the amount of information that can reliably be obtained from a network device varies from device to device and from vendor to vendor. No reliable means exists to accurately identify the features and capabilities of a network device. For example, most small network routers conventionally host a Web page that lists various information for itself, such as its make, model, and manufacturer. This Web page typically will also allow a network administrator to view details about the router or control the operation of the router. Thus, this Web page may allow a network administrator to change the password the router uses for authentication. Other types of network devices, however, such as cameras, printers, network-attached storage devices, digital media adapters, and VoIP telephones, provide no formal uniform mechanism for obtaining information regarding the device.
Instead, each network device manufacturer has its own custom interface for accessing information regarding its network device. As a result, the NETWORK MAGIC tool, for example, must employ a variety of heuristics to determine information regarding each network device in a small network. The heuristics attempt to infer the type and capabilities of the network device. This methodology of device detection occasionally may be unreliable, as user modifications or software upgrades to the network device may invalidate the heuristics.
Various examples of the invention relate to a network device management tool that allows a client service or “client” running on a remote computing device to reliably obtain information about and the capabilities of the network device hosting the network device management tool. With some examples of the invention, the network device management tool may alternately or additionally permit a client running on a separate computing device to reliably obtain information about the network device hosting the network device management tool, and then configure the network device for use on the network. For example, according to some embodiments of the invention, the network device management tool may permit a network management tool (or other suitable tool), running on a separate computing device, to deliver information to the network device such as instructions to control the operation of the network device. With still other embodiments of the invention, the network device management tool may alternately or additionally exchange information with a device setup utility designed to assist a user in configuring the network device hosting the network device management tool.
Overview
Some examples of the invention relate to a network device management tool that provides information in response to requests from a client service, such as a network management tool or device setup utility, hosted another computing device a. Still other examples of the invention will alternately or additionally receive information from a client service hosted on another computing device. This received information may include, for example, instructions or data for configuring the network device hosting the network device management tool.
As will be appreciated by those of ordinary skill in the art, some examples of the invention may be implemented by preconfigured analog or digital circuitry. More typically, however, examples of the invention may be implemented by a programmable computing device executing software instructions. In particular, various examples of the invention may be embodied by modules implemented by a programmable computing device executing software instructions for exchanging information according to a communication protocol such as, e.g., the Simple Object Access Protocol (SOAP). The computing device may be any type of computer or computing appliance that is incorporated in a network device. For example, as will be discussed in more detail below, various examples of the invention may be implemented as a component of a computer, a router (also known as a gateway or residential gateway), digital photo hardware, a video camera, a media adapter, or a printer.
Network Environment
As previously noted, various examples of the invention may be employed within a small network.
The network appliances in the network 101 will typically include a gateway device 105, through which each of the networked devices 103 communicates, either directly or indirectly. In turn, the gateway device 105 typically will communicate with one or more devices outside of the network 101. For example, the gateway device 105 may communicate with another private network, a public network, such as the Internet 107, or both. Thus, the gateway device 105 is a device that can direct electronic data from one network to another network. Typically, the gateway device 105 serves as a common node on two different networks (e.g., networks that use different communication protocol formats), and, where necessary, it will convert data from one network's communication protocol format into the other network's communication protocol format. As used herein, the term “small network” refers to a network made up of networked devices 103 that each employ the same network address to communicate with a single gateway device 105, together with the gateway device 105 itself.
The network devices 103 may be connected to the gateway device 105 using any suitable communication medium. For example, in the illustrated network 101, the desktop computers 103B are connected to the gateway device 105 through a hard-wired connection 109A (such as an Ethernet cable), while the laptop computer 109B is connected to the gateway device 105 through a IEEE 802.11 wireless connection and the personal digital assistant 103C is connected to the gateway device 105 through a Bluetooth wireless connection.
It should be appreciated that, as used throughout this application, the term “connect” and its derivatives (e.g., connection, connected, connects) include both direct and indirect connections. Thus, with the network illustrated in
Typically, the gateway device 105 will be a router. As will be appreciated by those of ordinary skill in the art, a router routes data packets from the networked devices 103 to one or more device outside of the network 101, and vice versa. With some networks, however, the gateway device 105 alternately may be a computer performing router functions, a hub, a bridge, or a “layer-3” switch. As will also be appreciated by those of ordinary skill in the art, the computing devices or “nodes” making up the network 101 will communicate with the gateway device 105 using one or more defined communication protocols, such as the Transmission Control Protocol (TCP) and the Internet Protocol (IP).
With these communication protocols, each computing device 103 and gateway device 105 in the network 101 will be assigned a logical address. For example, if the network 101 is connected to the Internet 107 through an Internet service provider, the Internet service provider will assign the gateway device 105 a logical Internet Protocol (IP) address. The Internet service provider may also provide the gateway device 105 with a block of logical Internet Protocol (IP) addresses for the gateway device 105 to reassign to each network device 103. Alternatively, the gateway device 105 can itself assign a range of logical Internet Protocol (IP) addresses to each network device 103, and then use a translation operation (e.g., a Network Address Translation (NAT) operation) to route data packets that it receives to the appropriate network device 103. This type of logical address typically is unrelated to the particular computing device to which it is assigned. Instead, a logical address identifies the relationship of that computing device to other computing devices in the network.
In addition to a logical address, each network device typically also will have a physical address. For example, most computing devices capable of communicating over a network, including routers, employ a network adapter with a media access control (MAC) address. This type of physical address is assigned to a network interface of a computing device, referred to as a “network adapter,” according to standards set forth by the Institute of Electrical and Electronic Engineers (IEEE) (referred to as “Project 802” or simply “802” standards, which are incorporated entirely herein by reference). More particularly, these standards define a 48-bit and 64-bit physical address format for network devices. The first 14 bits of the address are assigned by the IEEE Registration Authority, and uniquely identify the manufacturer of the network adapter. The remaining bits are then assigned by the manufacturer to uniquely identify each network adapter produced by the manufacturer. Consequently, the physical address of a network adapter is unique across all networks unless manually changed by the user. The physical address is unique to the network adapter, and is independent of a computing device's relationship to other computing devices in a network. Thus, the physical address does not change over time or between uses in different networks.
Network Devices
A network may include both virtual devices and physical devices. Physical network devices will then incorporate a computer, a computing appliance, or both. As previously noted, a “computer” may generally be characterized as a multipurpose device that can be programmed to perform a number of different, unrelated functions. Examples of computers will thus include personal computers, such as desktop computers and laptop computers. In addition, programmable media-purposed computers (e.g., “media adapters and servers”), network-attached storage devices, programmable entertainment-purposed computers (e.g., video game consoles), some programmable personal digital assistants and some telephones (such as wireless “smart” telephones) may be characterized as computers in a network. A “computing appliance” then may generally be characterized as a device that is limited to primarily performing only specific functions. Examples of a computing appliances may thus include, for example, printers, cameras, telephones that exchange voice information in data packets (sometimes generically referred to as “Voice over Internet Protocol (VoIP) telephones or telephone adapters), digital video recorders, televisions, voice over Internet protocol (VoIP) adapters, print servers, media adapters, media servers, photo frames, data storage servers, routers, bridges and wireless access points.
As will be appreciated by those of ordinary skill in the art, however, there may be no clear defining line between whether a network device is a “computer” or a “computing appliance.” For example, a sophisticated print server may be programmed to additionally or alternately function as a data storage server, while a programmable media-purposed computer or programmable personal digital assistant may have restricted functionality due to limited memory, its input devices, or its output devices. Accordingly, the term “computing device” is used herein to include both computers and computing appliances.
With conventional networks located in a home, small office, or other local environment, a network management tool that may be used in conjunction with various embodiments of the invention may be implemented on a programmable personal computer, such as a desktop or laptop computer. Similarly, a network device management tool according to various examples of the invention may be implemented on a computer. A general description of these types of computing devices will therefore now be described.
An illustrative example of such a computer 201 is illustrated in
The processing unit 205 and the system memory 207 are connected, either directly or indirectly, through a bus 213 or alternate communication structure to one or more peripheral devices. For example, the processing unit 205 or the system memory 207 may be directly or indirectly connected to additional memory storage, such as the hard disk drive 215, the removable magnetic disk drive 217, the optical disk drive 219, and the flash memory card 221. The processing unit 205 and the system memory 207 also may be directly or indirectly connected to one or more input devices 223 and one or more output devices 225. The input devices 223 may include, for example, a keyboard, touch screen, a remote control pad, a pointing device (such as a mouse, touchpad, stylus, trackball, or joystick), a scanner, a camera or a microphone. The output devices 225 may include, for example, a monitor display, television, printer, stereo, or speakers.
Still further, the computing unit 203 will be directly or indirectly connected to one or more network interfaces 227 for communicating with a network. This type of network interface 227, also sometimes referred to as a network adapter or network interface card (NIC), translates data and control signals from the computing unit 203 into network messages according to one or more communication protocols, such as the Transmission Control Protocol (TCP), the Internet Protocol (IP), and the User Datagram Protocol (UDP). These protocols are well known in the art, and thus will not be discussed here in more detail. An interface 227 may employ any suitable connection agent for connecting to a network, including, for example, a wireless transceiver, a power line adapter, a modem, or an Ethernet connection.
It should be appreciated that one or more of these peripheral devices may be housed with the computing unit 203 and bus 213. Alternately or additionally, one or more of these peripheral devices may be housed separately from the computing unit 203 and bus 213, and then connected (either directly or indirectly) to the bus 213. Also, it should be appreciated that both computers and computing appliances may include any of the components illustrated in
It also should be noted that, while a general description of a programmable personal computer was provided above, various embodiments of the invention may be implemented on any desired device capable of supporting the invention. For example, with some embodiments of the invention, the network management tool may be implemented on special-purposed programmable computers, such as a programmable media or entertainment-purposed computers, or personal digital assistants. Accordingly, the above description of a programmable personal computer should be understood as illustrative rather than limiting.
A computing appliance may have any combination of the components of the computer 201 discussed above. More typically, however, a computing appliance will be simpler to optimize the performance of a specific function, and thus may have only a subset of these components. For example, a computing appliance may have only a computing unit 203, an input device 223 or an output device 225, and a network interface 227. As will be apparent from the following description, however, a computing appliance will have sufficient computing resources to implement a desired embodiment of the invention in order to provide information to or receive information from a client operating on a separate computing device.
Network Management Tool
As previously discussed, various examples of the invention may be particularly beneficial for use with a network management tool for managing a small network. Accordingly, the operation of an example of such a tool, the NETWORK MAGIC software application available from Pure Networks of Seattle, Wash., will briefly be described to provide a better appreciation of the operation of various embodiments of the invention. As also previously discussed, the NETWORK MAGIC network management tool allows a user to monitor the status of devices on an electronic network, such as a network employing the Ethernet protocol, located in a home or small business. The NETWORK MAGIC network management tool may also allow a user to administer various tasks associated with the network, services in the network, or devices in the network.
As seen in
As also seen in
Network Device Configuration Tool
As previously discussed, various examples of the invention also may be particularly useful to a network device setup utility or other configuration tool. Accordingly, the operation of an example of one such tool, a router setup utility, will be briefly described to provide a better appreciation of the operation of various examples of the invention. It should be noted that various examples of this type of router setup utility are discussed in more detail in a U.S. patent application entitled “Network Device Setup Utility,” naming Brett Marl et al. as inventors and being filed concurrently with the instant patent application, which concurrently filed patent application is incorporated entirely herein by reference.
The router setup utility assists a user in configuring a network router for use on a small network. More particularly, the router setup utility assists a user with the process of correctly connecting the network cables, configuring the router with the settings appropriate to the desired network arrangement, and validating that the router can successfully connect to the Internet. In some instances, the router setup utility may be capable of configuring any router that hosts an implementation of a network device management tool according to various embodiments of the invention. Thus, by incorporating a network device management tool according to various examples of the invention into their devices, router manufacturers may avoid the need to develop a custom device configuration tool for every router they produce.
For example, the router setup utility may communicate with a network device management tool hosted on a router, in order to retrieve or designate settings of the router. The router setup utility may then assist a user in configuring the router for network access. For example,
It should be appreciated that, while a router setup utility specifically has been discussed above, various examples of the invention may implement a network device management tool capable of cooperating with a device setup tool for any desired type of network device. Accordingly, a manufacturer of a network device need not provide a special-purpose configuration tool to allow a user to properly configure its device. Rather, the manufacturer can employ an implementation of the network device management tool according to an example of the invention that is capable of receiving and implementing instructions received from a setup tool generic to network devices of its type.
Overview of a Network Device Management Tool
As will be discussed in further detail below, a network device management tool according to various examples of invention may be implemented using the Simple Object Access Protocol (SOAP) version 1.1, a lightweight, Extensible Markup Language (XML)-based messaging protocol. As will be appreciated by those of ordinary skill in the art, this protocol allows the network device management tool to work with readily-available tools, including Microsoft Visual Studio.NET, Apache, PHP, JSP, and the like. The Simple Object Access Protocol (SOAP) is incorporated entirely herein by reference. Of course, still other examples of the invention may employ any desired alternate messaging protocol, such as a Representational State Transfer (REST) protocol or the Remote Procedure Call (RPC) protocol, documented in RFC 1831, which is incorporated entirely herein by reference.
As will be discussed in more detail below, the network device management tool 701 can access these setting values. More particularly, the network device management tool 701 can retrieve data from memory employed by the computing device 703, such as settings associated with the network device. With various embodiments of the invention, the network device management tool 701 may alternately or additionally add new data to the memory employed by the computing device 703, or change the values of existing data in the memory. Thus, the network device management tool 701 may add or change setting values associated with the network device 705. Still further, the network device management tool 701 may implement instructions to have the computing device 703 control the network device 705 to perform one or more operations.
The network device 705 in turn communicates, through a network 101, with a client 707 hosted by another computing device 709. As previously noted, the client 707 may be a network management tool, a network device setup tool, or any other desired operational component that may need to retrieve information from or send information to the network device 705.
The operation of the network device management tool 701 will now be described with reference to
Accordingly, with some implementations of the invention, the client 707 may not use an authenticated SOAP action to make the initial request to discover if the network device 705 hosts a network device management tool 701. Instead, the client 707 may use a HTTP GET request without authentication to a pre-established URL. Therefore, the detection phase of whether or not a network device hosts a network device management tool 701 may use a standard HTTP GET request which all network devices should be able to handle properly. As will be described in further detail below, all non-detection requests to the network device management tool 701 then use the SOAP protocol.
More particularly, with various examples of the invention, the initial request is an HTTP GET to a web server hosted on the network device that may use, for example the following URL: http://<device_IP>/HNAP1/(e.g. http://192.168.1.1/HNAP1/). If the network device does not host a network device management tool (see step 802), the network device will fail to respond to the request, or respond with a “file not found” type error condition (see step 803). Upon failure, the client 707 will assume the network device does not host a network device management tool 701 (see step 804). If the network device 705 hosts a network device management tool 701 according to various embodiments of the invention (see step 802), the network device management tool 701 will respond with the results of the request (see step 806). More particularly, with various examples of the invention, the HTML response will provide the same results that are provided by a method call to GetDeviceSettings, which will be discussed in more detail below.
For all subsequent, non-detection requests, as shown in
If the network device hosts a network device management tool 701, it processes the request. More particularly, in step 902, the network device management tool 701 responds to the request by returning an XML block to the client 707 containing the specified information as a series of tagged values. In step 903, the client 707 updates its data to include the information provided in the response from the network device management tool 701. With various implementations, the client 707 may maintain its data in an XML file. This arrangement allows the client 707 to easily assimilate the information provided in an XML block by the network device management tool 701.
Each request recognized by the network device management tool 701 can be independent and stateless. A network device 705 may thus support multiple requests from different IP addresses on the local network 101, as different instantiations of a client 707 may be simultaneously running on multiple computers in the network 101. Further, each request from a client 707 may further be atomic. Because some communications between the client 707 and the network device management tool 701 may use a get/set pattern of commands, it is possible to lose settings that were made by a different client 707 in between a get and a set instruction. This may be avoided by coordination of operations between multiple clients 707.
Discussing the operation of the network device management tool 701 in more detail, the client 707 issues an authenticated POST on <device_ip>/HNAP1/, as previously noted. This POST may have the following syntax:
where the [method_name] and [method_specific_body] are replaced with the specific method call. A method call may be a request to obtain information (e.g. a method call such as GetDeviceSettings, which will be discussed in more detail below) or an instruction to employ specified information (e.g., a method call such as SetWanSettings, which also will be discussed in more detail below). The SOAPAction HTTP header defines the specific method call, while the XML fragment enclosed in the <soap:Body> tags contains the specific parameters for that method.
The network device management tool 701 implemented on the network device 705 then responds to requests on the URL /HNAP1/. The expected response from the device informs the client 707 that the device 705 supports requests and instructions from the network device management tool 701. If the network device processed the request, it returns an XML-encoded SOAP response specific to the request made. With various examples of the invention, the response may be in the following format:
where [method_specific_response_body] are replaced with the specific response XML fragment for the operation in question.
According to various examples of the invention, the network device management tool 701 will return a well formed SOAP response to all methods. Each SOAP response contains a method specific result tag (e.g., SetWanSettingsResult) that contains a string value of the results. Table 1 shows the possible values for this string that might be employed by various examples of the invention.
An example of a communication flow between a client 707 and a network device management tool 701 follows, where the client 707 is designated as the client by the C: line prefix, and the network device management tool 701 is designated as the server as indicated by the S: line prefix.
As previously noted, the network device management tool 701 according to various examples of the invention also will provide requested information or change the specified data values used by the network device 705, such one or more operational values. For example, in response to a GetDeviceSettings request or “call” (which will be discussed in more detail below), the network device management tool 701 returns base information for its associated hardware device. Thus, any network device 705 returning a successful response to a GetDeviceSettings call will be accepted by the client 707 as a supported network device 705 implementing a network device management tool 701 according to an embodiment of the invention. Also, as will be discussed in more detail below, basic information for the device 705 may be described in the returned fields (for example, <Vendor Name> and <ModelName>).
Similarly, in response to a SetWanSettings instruction or “call,” the network device management tool 701 will change the data fields identified in the call to the field values specified in the call. With various examples of the invention, this type of instruction call will overwrite the current field values. More specifically, if a parameter is passed as a null string, it clears the field (rather than leaves the current contents). Table 2 shows an example of a SetWanSettings call to a router for setting the DHCP mode. In the DHCP mode, the router uses DHCP to request an IP address from the network connected to the WAN side of the router (typically from an Internet Service Provider (ISP) if the router is directly connected to the Internet). In response to this call, the network device management tool 701 will update the DNS entries of the router, clear the IPAddress and SubnetMask on the WAN side of the router, and request a new IP address from the network connected to WAN side of the router (which typically is from an ISP, as noted above).
With various examples of the invention, the client 707 can detect instantiation of the network device management tool 701 by, for example, sending a GetDeviceSettings POST to the URL “/HNAP1/”. As noted above, however, this may cause some network devices, such as routers, to undesirably reboot. Accordingly, with various examples of the invention, the network device management tool 701 will support receiving a GET on a URL, such as the URL “/HNAP1/”, with no authentication, and then respond with the exact same response as the GetDeviceSettings call. As discussed in detail above, client devices can use this type of GET request to more safely detect the use of a network device management tool 701 according to various implementations of the invention.
With some examples of the invention, the network device management tool 701 may obtain data from or set data into data fields that are specific to one or more supported devices. Thus, with some implementations of the invention, the network device management tool 701 may support one or more of the specific device types listed in Table 3, in addition to a “generic” device type that may be employed for any type of network device.
Some configuration changes on a network device 705 can require the device hardware to reboot itself in order for the changes to take effect. When a device reboots, it can take considerable time (for example, from 15-60 seconds) to return to a normal operating status. Until the device 705 is in its normal operating state, its hosted network device management tool 701, will not processes any other requests. In some cases, a client 707 might choose to execute multiple configuration commands in sequence, in order to perform a batch operation. If one of these commands were to cause a reboot, the subsequent commands in the batch would fail to execute.
Accordingly, with various examples of the invention, the network device management tool 701 will communicate with the client 707 that its network device 705 will be unavailable for a period of time while it is rebooting. More particularly, if the network device 705 is going to need to reboot, the network device management tool 701 will respond to a message specifying a configuration change with a REBOOT result (instead of the OK or ERROR results noted above), and ensures that the HTTP response is completed before the reboot. When the network device 705 then reboots, the network device management tool 701 will ensure that it does not respond to the call IsDeviceReady with an OK result until the reboot or reboots are completed. The network management tool 607 may then enter a phase during which it periodically polls the network device management tool 701 (e.g., every second) to determine if the network device management tool 701 has returned to its normal operating status as indicated by an OK response to the IsDeviceReady call. With various examples of the invention, the network device management tool 701 will not respond to any HNAP/HTTP requests until any required reboots are finished.
With various examples of the invention, the network device management tool 701 may employ one or more structures for use in responding to calls to the network device management tool 701. For example, some embodiments of the invention may employ the following structures: the ConnectedClient structure, shown in Table 12; the DNSSettings structure, shown in Table 13; the PortMapping structure, shown in Table 14; the NetworkStats structure, shown in Table 15; the TaskExtension structure, shown in Table 15; and the MACInfo structure, shown in Table 16.
Each of these structures will be described with reference to Tables 12-15, respectively, in more detail below.
The various call methods that were discussed above will now be described in more detail. It should be noted that any of these methods can be employed with any device type as specified above.
For each method described, a pseudo short-hand notation will be used for convenience and ease of understanding to describe the input and output parameters requires for each SOAP action. It should be noted that the short-hand notation is serialized as XML when used as part of the protocol. The pseudo notation is in the following format:
[return_type] [method_name] ([method_arguments])
Where [method_arguments] contains a comma separated list of parameters describing their name as serialized in XML and their type. Each parameter also has a direction modifier prefix—either “out” or “in.” The presence of the “in” modifier indicates that the parameter is to be supplied as part of the request data. The presence of the “out” modifier on the parameter indicates that the parameter should be returned by the network device management tool 701 as part of a response. If the direction modifier is omitted, it should be assumed to be an “in” parameter.
For each method invocation, a request is formed in SOAP by the client 707 may take the following form:
where [inbound_method_arguments] is an XML serialized list of inbound parameters from the method_arguments list.
Once the network device management tool 701 processes the request, it returns a response in the following form:
where [outbound_method_arguments] is an XML serialized list of outbound parameters from the method_arguments list, and the <[method_name]Result> element contains the result of the operation as defined by the type specified in [return_type].
For example, the short hand notation for the GetLanSettings call is described as:
This call would be serialized in SOAP as follows:
It should be noted that, in all of the above examples, all XML namespace information has been removed for clarity and ease of understanding.
The following methods may be employed to obtain or set various devices settings:
The following methods may be used by non-router devices to configure how they connect to the local area network:
The following methods may be used for routers to set how they provide services to the LAN.
The following methods may be used for any device that supports local wireless network (WLAN).
Each of the methods that may be employed by various embodiments of the network device management tool 701 will now be discussed in more detail, together with a detailed representation of each method. As used herein, all protocol elements are case-sensitive (for example, SOAPAction values, XML elements, and parameters such as the device Type and WAN connection Type), but with various examples of the network device management tool 701, hexadecimal values, such as in MAC addresses or in WEP keys, may be in either, upper or lowercase. Also, in the methods described below, requests and responses should include a content length, to better give an idea of how much data will be transferred. With various examples of the invention, the format of this content length will conform to the appropriate RFC standard for HTTP messaging.
The GetDeviceSettings method may be used to discover device capabilities. Typically, any device implementing the network device management tool 701 will implement the GetDeviceSettings method. With various examples of the invention, the network device management tool 701 will support this method without authentication by default when requests are received from the local LAN/WLAN. This method is used for device detection and often a client will make this request before it has received authentication credentials.
Sample GetDeviceSettings Request:
Sample GetDeviceSettings Response:
The SetDeviceSettings method may be used to set a new name for the device, as follows:
Sample SetDeviceSettings Request:
Sample SetDeviceSettings Response:
The IsDeviceReady method may be used to verify a user's credentials in certain circumstances (for example, when a user types his or her administrative user name and password to make sure logging in works correctly). Because IsDeviceReady does this, the method should be setup to require authentication.
Sample IsDeviceReady Request:
Sample IsDeviceReady Response:
The Reboot method may be used for either of the following:
Sample Reboot Request:
Sample Reboot Response:
The RenewWanConnection method may be used to renew the router's WAN connection. If the router is configured for DHCP, RenewWanConnection renews the DHCP lease. If the router is configured for PPPoE, RenewWanConnection renews the PPPoE connection. Optionally, this method can be used to restart the internal WAN driver. Typically, the router should make every attempt possible to fix its upstream connection without disturbing the LAN side at all. It should be noted that this method should stay distinct from Reboot( ). The RenewWanConnection method keeps all LAN DHCP information intact and has a smaller impact on the device than the Reboot method typically will.
Sample RenewWanConnection Request:
Sample RenewWanConnection Response:
The SetRouterLanSettings method may be used to set the router's LAN-side IP address, gateway address, and DHCP server status.
Sample SetRouterLanSettings Request:
Sample SetRouterLanSettings Response:
The GetConnectedDevices method may be used to obtain information about which devices are connected to this router. The GetConnectedDevices method includes a port name for the type of connection the device is using.
Sample GetConnectedDevices Request:
Sample GetConnectedDevices Response:
The GetNetworkStats method may be used to read network statistics about ports on the router.
Sample GetNetworkStats Request:
Sample GetNetworkStats Response:
The GetWLanSettings24 method may be used with wireless (Wi-Fi) routers and access points that operate on the 2.4 GHz frequency (802.11b, -g, or -n). The GetWLanSettings24 method obtains the settings on the 2.4 GHz wireless interface (for example, the SSID). The settings obtained are the last settings configured It should be noted that these settings might not be the current, active settings.
Sample GetWLanSettings24 Request:
Sample GetWLanSettings24 Response:
The SetWLanSettings24 method may be used with wireless (Wi-Fi) routers and access points that operate on the 2.4 GHz frequency (802.11b, -g, or -n). The SetWLanSettings24 method obtains the settings on the 2.4 ghz wireless interface (for example, the SSID).
Sample SetWLanSettings24 Request:
Sample SetWLanSettings24 Response:
The GetWLanSecurity method may be used to obtain the security settings for wireless connections. These settings apply to both the 2.4 GHz and 5.4 GHz frequencies.
The SetWLanSecurity method may be used to set the security settings for wireless connections. These settings apply to both the 2.4 GHz and 5.4 GHz frequencies.
Sample SetWLanSecurity Request:
Sample SetWLanSecurity Response:
The GetMACFilters2 method returns a MAC address filters for the network device. A MAC address filter allows a network device to allow or deny access to a network based on the MAC address of the network device attempting to access the network.
Sample GetMACFilters2 Request:
Sample GetMACFilters2 Response:
The SetMACFilters2 method allows a network device to set MAC Address filtering policy in the network device. A MAC Address filter entry determines whether or not a network device with a given MAC address is allowed or denied access to the network.
Sample SetMACFilters2 Request:
Sample SetMACFilters2 Response:
The GetPortMappings method returns one entry on the PortMapping[ ] array for each enabled port mapping currently defined in the router. The concept is that this is the same list of mappings that are created by AddPortMapping and removed by DeletePortMapping. Other mappings defined in the router but which are not “enabled” will not be effected by these APIs.
Sample GetPortMappings Request:
Sample GetPortMappings Response:
The AddPortMapping method may be used to set port forwarding on the router to enable applications to connect in through the firewall. When this method is called, it adds a new port forwarding entry to the port forwarding table in the router. It should be noted that, if the client 707 intends to map both UDP and TCP for a given port, it will require two separate PortMapping records.
Sample AddPortMapping Request:
Sample AddPortMapping Response:
The DeletePortMapping method may be used to delete a previously set port forwarding entry on the router. More particularly, when this method is called, it removes any existing port forwarding entry that matches from the port forwarding table in the router.
Sample DeletePortMapping Request:
Sample DeletePortMapping Response:
The GetWanSettings method returns the current network settings for the WAN connection of a router. This method may be also used to return the previous static IP address used by the router.
Sample GetWanSettings Request:
Sample GetWanSettings Response:
The SetWanSettings method sets the WAN connection information for a router. The WAN connection information is used to connect the WAN network adapter to another network.
Sample SetWanSettings Request:
Sample SetWanSettings Response:
The SetAccessPointMode method can be used to switch the mode of a router from a gateway mode to an access point mode. In gateway mode, the router will respond as a DHCP server using NAT to assign IP addresses to devices connecting on the LAN or WLAN segments. In the access point mode, the router will act as a simple bridge moving data between the WAN and LAN ports. Thus, the SetAccessPointMode method will allow a client 707 to set the mode of operation of a wireless gateway. This can be useful in the case where a router setup tool is attempting to install the router on a new network. If the network to which it is being installed already has a gateway (e.g., an embedded gateway often found in combination DSL modems), then configuring the router in the gateway mode would result in a double-NAT situation. This type of double-NAT situation can make it difficult to successfully network applications together. By detecting this situation at install time and switching the router into access point mode, this situation can be avoided.
Sample SetAccessPointMode Request:
Sample SetAccessPointMode Response:
From the foregoing description, it should be appreciated that various examples of the invention provide a protocol for retrieving information from and sending information to a network device. Further, this communication protocol can be employed by any desired client. In this manner, a client, such as a network device setup utility or network management tool, can obtain information about a network device hosting a network device management tool according to an embodiment of the invention. Further, a client can send information to a network device management tool according to an embodiment of the invention. With some implementations of the invention, this information may include both new setting values for the network device hosting the network device management tool, and instructions to employ those setting values in the future operation of the network device.
While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention as set forth in the appended claims.
This application claims priority to U.S. patent application Ser. No. 11/297,809 filed on Dec. 7, 2005, entitled “Network Management” and naming Steve Bush et al. as inventors, which application in turn claims priority to U.S. Provisional Patent Application No. 60/634,432, filed Dec. 7, 2004, entitled “Network Management” and naming Steve Bush et al. as inventors, which applications are both incorporated entirely herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
5383178 | Unverrich | Jan 1995 | A |
5396485 | Ohno et al. | Mar 1995 | A |
5768483 | Maniwa et al. | Jun 1998 | A |
5774667 | Garvey et al. | Jun 1998 | A |
5974237 | Shurmer et al. | Oct 1999 | A |
5978568 | Abraham et al. | Nov 1999 | A |
6006272 | Aravamudan et al. | Dec 1999 | A |
6023723 | McCormick et al. | Feb 2000 | A |
6456306 | Chin et al. | Sep 2002 | B1 |
6530018 | Fleming | Mar 2003 | B2 |
6584074 | Vasamsetti et al. | Jun 2003 | B1 |
6631118 | Jones | Oct 2003 | B1 |
6678250 | Grabelsky et al. | Jan 2004 | B1 |
6778505 | Bullman et al. | Aug 2004 | B1 |
6801941 | Stephens et al. | Oct 2004 | B1 |
6892245 | Crump et al. | May 2005 | B1 |
6954785 | Martin et al. | Oct 2005 | B1 |
6965614 | Osterhout et al. | Nov 2005 | B1 |
6980556 | Vimpari | Dec 2005 | B2 |
7020701 | Gelvin et al. | Mar 2006 | B1 |
7020720 | Donahue et al. | Mar 2006 | B1 |
7080141 | Baekelmans et al. | Jul 2006 | B1 |
7111054 | Lo | Sep 2006 | B2 |
7155493 | Weber | Dec 2006 | B1 |
7177957 | Vance | Feb 2007 | B2 |
7200551 | Senez | Apr 2007 | B1 |
7240106 | Cochran et al. | Jul 2007 | B2 |
7269653 | Mentze et al. | Sep 2007 | B2 |
7283517 | Yan et al. | Oct 2007 | B2 |
7319873 | Zhang et al. | Jan 2008 | B2 |
7337910 | Cartmell et al. | Mar 2008 | B2 |
7340512 | Cochran et al. | Mar 2008 | B2 |
7388839 | Chafle et al. | Jun 2008 | B2 |
7392310 | Motoyama et al. | Jun 2008 | B2 |
7421466 | Haines | Sep 2008 | B2 |
7457737 | Patiejunas | Nov 2008 | B2 |
7460546 | Anderson, IV | Dec 2008 | B2 |
7475133 | Nuggehalli | Jan 2009 | B2 |
7499999 | Ocepek et al. | Mar 2009 | B2 |
7509415 | Baekelmans et al. | Mar 2009 | B2 |
7545762 | McConnell et al. | Jun 2009 | B1 |
7565418 | Marl et al. | Jul 2009 | B2 |
7581039 | Martinez et al. | Aug 2009 | B2 |
7603710 | Harvey et al. | Oct 2009 | B2 |
7657612 | Manchester et al. | Feb 2010 | B2 |
20010039580 | Walker et al. | Nov 2001 | A1 |
20020004935 | Huotari et al. | Jan 2002 | A1 |
20020010866 | McCullough et al. | Jan 2002 | A1 |
20020026503 | Bendinelli et al. | Feb 2002 | A1 |
20020026505 | Terry | Feb 2002 | A1 |
20020112076 | Rueda et al. | Aug 2002 | A1 |
20020116544 | Barnard et al. | Aug 2002 | A1 |
20020147938 | Hamilton et al. | Oct 2002 | A1 |
20020161865 | Nguyen | Oct 2002 | A1 |
20020161867 | Cochran et al. | Oct 2002 | A1 |
20020174207 | Battou | Nov 2002 | A1 |
20020196463 | Schlonski et al. | Dec 2002 | A1 |
20030005112 | Krautkremer | Jan 2003 | A1 |
20030033402 | Battat et al. | Feb 2003 | A1 |
20030041238 | French et al. | Feb 2003 | A1 |
20030061336 | Van Den Bosch et al. | Mar 2003 | A1 |
20030069947 | Lipinski | Apr 2003 | A1 |
20030078999 | Lund et al. | Apr 2003 | A1 |
20030086425 | Bearden et al. | May 2003 | A1 |
20030115298 | Baker | Jun 2003 | A1 |
20030115314 | Kawashima | Jun 2003 | A1 |
20030195937 | Kircher et al. | Oct 2003 | A1 |
20030200303 | Chong | Oct 2003 | A1 |
20030200318 | Chen et al. | Oct 2003 | A1 |
20030229688 | Liang | Dec 2003 | A1 |
20040003292 | Kato | Jan 2004 | A1 |
20040030620 | Benjamin et al. | Feb 2004 | A1 |
20040040023 | Ellis et al. | Feb 2004 | A1 |
20040155899 | Conrad | Aug 2004 | A1 |
20040162986 | Metzger | Aug 2004 | A1 |
20040193709 | Selvaggi et al. | Sep 2004 | A1 |
20040199647 | Ramarao et al. | Oct 2004 | A1 |
20040236759 | Young | Nov 2004 | A1 |
20050018241 | Azami | Jan 2005 | A1 |
20050050189 | Yang | Mar 2005 | A1 |
20050063350 | Choudhury et al. | Mar 2005 | A1 |
20050078681 | Sanuki et al. | Apr 2005 | A1 |
20050086197 | Boubez et al. | Apr 2005 | A1 |
20050091504 | Shirogane | Apr 2005 | A1 |
20050114490 | Redlich et al. | May 2005 | A1 |
20050125527 | Lu et al. | Jun 2005 | A1 |
20050149626 | Manchester et al. | Jul 2005 | A1 |
20050184852 | Lee et al. | Aug 2005 | A1 |
20050198274 | Day | Sep 2005 | A1 |
20050229238 | Ollis et al. | Oct 2005 | A1 |
20050234568 | Chung et al. | Oct 2005 | A1 |
20050234683 | Graves et al. | Oct 2005 | A1 |
20050235227 | Martineau et al. | Oct 2005 | A1 |
20050240758 | Lord et al. | Oct 2005 | A1 |
20060036847 | Bush et al. | Feb 2006 | A1 |
20060037036 | Min et al. | Feb 2006 | A1 |
20060101109 | Nishio | May 2006 | A1 |
20060106918 | Evert et al. | May 2006 | A1 |
20060120293 | Wing | Jun 2006 | A1 |
20060129664 | Reimert et al. | Jun 2006 | A1 |
20060153080 | Palm | Jul 2006 | A1 |
20060168195 | Maturana et al. | Jul 2006 | A1 |
20060168263 | Blackmore | Jul 2006 | A1 |
20060280189 | McRae et al. | Dec 2006 | A1 |
20060291443 | Harrington et al. | Dec 2006 | A1 |
20070022185 | Hamilton et al. | Jan 2007 | A1 |
20070058567 | Harrington et al. | Mar 2007 | A1 |
20070076621 | Malhotra et al. | Apr 2007 | A1 |
20070106768 | Frietsch et al. | May 2007 | A1 |
20070111568 | Ferrari et al. | May 2007 | A1 |
20070133569 | Lee et al. | Jun 2007 | A1 |
20070204150 | Jokela et al. | Aug 2007 | A1 |
20070268506 | Zeldin | Nov 2007 | A1 |
20070268515 | Freund et al. | Nov 2007 | A1 |
20070268516 | Bugwadia et al. | Nov 2007 | A1 |
20080037552 | Dos Remedios et al. | Feb 2008 | A1 |
20080049779 | Hopmann et al. | Feb 2008 | A1 |
20080052384 | Marl et al. | Feb 2008 | A1 |
20080065760 | Damm et al. | Mar 2008 | A1 |
20080070603 | Mao | Mar 2008 | A1 |
20080134164 | Stich et al. | Jun 2008 | A1 |
20090017832 | Tebbs et al. | Jan 2009 | A1 |
20090019141 | Bush et al. | Jan 2009 | A1 |
20090019147 | Ahlers et al. | Jan 2009 | A1 |
20090019314 | Younger et al. | Jan 2009 | A1 |
20090052338 | Kelley et al. | Feb 2009 | A1 |
20090055514 | Tebbs et al. | Feb 2009 | A1 |
20100020694 | Jones | Jan 2010 | A1 |
Number | Date | Country |
---|---|---|
2001-222497 | Aug 2001 | JP |
2001-352328 | Dec 2001 | JP |
2004-0047209 | Jul 2004 | KR |
10-2005-0031175 | Apr 2005 | KR |
2005-0078541 | Aug 2005 | KR |
20050094247 | Sep 2005 | KR |
WO 2008156898 | Dec 2008 | WO |
WO 2009011962 | Jan 2009 | WO |
WO 2009011963 | Jan 2009 | WO |
WO 2009-011964 | Jan 2009 | WO |
WO 2009011965 | Jan 2009 | WO |
WO 2009011966 | Jan 2009 | WO |
Number | Date | Country | |
---|---|---|---|
20070130286 A1 | Jun 2007 | US |
Number | Date | Country | |
---|---|---|---|
60634432 | Dec 2004 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11297809 | Dec 2005 | US |
Child | 11457783 | US |