Note: Descriptions are shown in the official language in which they were submitted.
CA 02781178 2012-06-18
1
Method, Storage Medium and Hosting Device for supporting a statically
configured
Guest Device
FIELD OF THE INVENTION
The present invention relates generally to network communications and more
specifically, to a method, a system, and a device for supporting statically
configured devices on
a foreign network.
BACKGROUND OF THE INVENTION
In the past few years, a plethora of devices equipped with wireless
communication
means have emerged, and particularly means for wired and wireless internet
access. Many
such devices are mobile devices including, but not limited to, cell phones,
smart phones,
tablet computers, portable computers, game consoles, and the like. Many such
devices use
communication protocols which enable the user to easily connect to a foreign
network.
Indeed, although these devices may be configured to access a "home" network,
in
the sense of a base network (which could be a home but could also be an
office, a store,
etc.), often these devices are mobile and as such they are susceptible to be
used in a new
location where wired or wireless Internet services are offered by the
property. This is
hereinafter a "foreign network". Examples of foreign networks are wired and
wireless
networks present in hotels, convention centers, restaurants and condos.
Nowadays, mobile devices are generally provided with means to automatically
configure a communication path between the foreign network and the mobile
device, for
example using DHCP (Dynamic Host Configuration Protocol).
However, there exist many devices which are, for example, configured with a
static
IP address, have a locked IP configuration, such as corporately-owned and
controlled
devices, or are otherwise lacking in capability to easily connect to a foreign
network. Such
devices may require deep knowledge to configure the mobile device for
communication,
CA 02781178 2012-06-18
2
which is outside the reach of most users. In other cases, the user cannot
reconfigure the
device due to company policies.
Therefore, various solutions for enabling communication have been tried. One
such
solution is the one proposed by Nomadix, Inc., as described in US patent no.
7,554,995.
This patent describes a system for connecting a user device to a network where
the user
device settings, the network settings, or both are unknown. Request packets
transmitted by
the user device are intercepted and a response packet is forged in response to
the request
from the user device. While this solution allows the user device to
communicate with the
foreign network, it requires the hosting system to send a response to a
request that was not
addressed to it.
It is believed that there is still a need for a method, system, and device
which allows a
device that is statically configured to communicate on a foreign network. It
would also be
desirable for the method, system, and device to receive confirmation from the
guest device that
the communication has been established.
SUMMARY OF THE INVENTION
The present method provides a method performed by a hosting system, to allow a
guest device
to communicate with a network via the hosting system. The guest device has a
static IP address
and a guest hardware address. The guest device is configured to communicate
through a guest
gateway having a guest gateway IP address and a guest gateway hardware
address. The
hosting system includes a hosting gateway having at least one interface
provided with a hosting
gateway IP address and a hosting gateway hardware address. The hosting gateway
IP address
is different than said guest gateway IP address. The method comprises the
following steps:
a) listening for ARP requests;
b) detecting from the ARP requests a first ARP request from the guest device,
requesting the guest gateway hardware address corresponding to the guest
gateway
IP address, said the ARP request including:
- the guest device IP address;
CA 02781178 2012-06-18
3
- the guest gateway IP address; and
- the guest device hardware address;
c) upon detection of the first ARP request of step a), broadcasting an ARP
packet
including at least:
- the guest gateway IP address; and
- the hosting gateway hardware address,
wherein destination and source IP addresses correspond to the guest gateway
IP address;
the ARP packet triggering in the guest device an update of an ARP table of the
guest
device, said update consisting of associating the hosting gateway hardware
address
to the guest gateway IP address; and
d) building a route allowing the hosting system to send network packets to the
guest
device.
The method thereby allowing the guest device to communicate with said network
via the hosting
system.
In one embodiment, the ARP packet broadcas in step c) is an announcement
packet.
In one embodiment, the method further includes a step of broadcasting a
gratuitous ARP
packet, requesting for the guest device hardware address corresponding to the
guest device IP
address, said gratuitous ARP packet including:
- the guest device IP address;
- the guest gateway IP address; and
- the hosting gateway hardware address;
said step being performed after step c).
In one embodiment, the ARP packet broadcast in step c) is a gratuitous ARP
packet, requesting
for the guest device hardware address corresponding to the guest device IP
address, said
gratuitous ARP packet further including:
CA 02781178 2012-06-18
4
- the guest device IP address.
In one embodiment, the method includes a step of receiving at the hosting
gateway an ARP
response from the guest device, the ARP response including
- the guest device IP address;
s - the guest device hardware address;
- the hosting gateway IP address; and
- the hosting gateway hardware address,
the ARP response allowing the hosting gateway to confirm proper update of the
ARP table, this
step being performed after step c).
1o In one embodiment, the step of building a route includes generating a first
routing table and
adding a first route linking the guest device IP address with the hosting
gateway IP address of
said first interface on which the first ARP request from the guest device was
received.
In one embodiment, the method comprises a step of associating in a storage
module the guest
device hardware address with the hosting gateway hardware address of said
first interface.
15 In one embodiment, the method comprises a step of monitoring packets
received from the guest
device, and when the packets are received on a different interface than said
first interface, the
method further comprises the steps of:
e) broadcasting a second ARP packet including:
- the guest gateway IP address; and
20 - the guest device hardware address;
f) updating the storage module by associating said different interface of the
hosting
gateway with the guest gateway.
In one embodiment, the method includes a step of deleting the first route from
said routing table;
and adding a second route in said routing table linking the guest device IP
address with an IP
25 address of said different interface of the hosting system.
CA 02781178 2012-06-18
In one embodiment, the method includes a step of receiving from the guest
device a network
packet other than an ARP request, the network packet including the hosting
gateway IP address
and the hosting gateway hardware address.
In one embodiment, the method comprises a step of receiving network packets
from other
5 devices external to the network, and exchanging these network packets with
said guest device.
The steps of the method can be performed via a wired or wireless link(s).
According to another aspect of the invention, a processor-readable storage
medium for a
hosting system is provided, for allowing a guest device to communicate with a
network. The
guest device has a static IP address and a guest device hardware address, the
guest device
being configured to communicate through a guest gateway provided with a guest
gateway IP
address and a guest gateway hardware address. The hosting system includes a
hosting
gateway having at least one interface provided with a hosting gateway IP
address and a hosting
gateway hardware address. The hosting gateway IP address is different than
said guest
gateway IP address. The processor-readable storage medium comprises
instructions for
execution by the processor to:
- listen to ARP requests,
- detect from the ARP requests, a first ARP request from the guest device,
requesting the guest gateway hardware address corresponding to the guest
gateway IP address, the first ARP request including:
- the guest device IP address;
- the guest gateway IP address; and
- a guest device hardware address;
instruct of a detection of the first ARP packet; and
generate and broadcast an ARP packet, including:
^ the guest gateway IP address; and
^ the hosting gateway hardware address;
said ARP packet triggering in the guest device an update of an ARP table of
the
guest device, said update consisting associating hosting gateway hardware
address to the guest gateway IP address; and
CA 02781178 2012-06-18
6
- build a route allowing the hosting system to send network packets to the
guest
device.
According to yet another aspect of the invention, a hosting device is
provided, for allowing a
guest device to communicate with a network. The guest device has a static IP
address and a
guest device hardware address. The guest device is configured for
communicating through a
guest gateway provided with a guest gateway IP address and a guest gateway
hardware
address. The hosting device has at least one interface provided with a hosting
gateway IP
address and a hosting gateway hardware address. The hosting gateway IP address
is different
than said guest gateway IP address. The device includes
- a memory;
- a listener module stored in the memory and including:
- listening means for listening to ARP requests,
- detecting means for detecting a first ARP request from the guest device,
requesting the guest gateway hardware address corresponding to the
guest gateway IP address, said first ARP request including:
= the guest device IP address;
= the guest gateway IP address; and
= the guest device hardware address;
- instructing means for instructing of a detection of the first ARP packet;
and
- a broadcaster module stored in the memory and including means for generating
and
sending a gratuitous ARP packet, upon being instructed by the instructing
means of
the detection of the first ARP request, the gratuitous ARP packet asking for
the
guest device hardware address corresponding to the guest device IP address,
said
gratuitous ARP packet including:
- the guest device IP address;
- the guest gateway IP address; and
- the hosting gateway hardware address;
CA 02781178 2012-06-18
7
- a route builder module, for building a route between said at least one
interface and
said guest device;
- a processor for executing the listener, the broadcaster and the route
builder
modules;
the hosting device thereby allowing the guest device to communicate on said
network.
In one embodiment of the hosting device, it further includes a storage module
including
entries associating said guest gateway with one of said several interfaces,
and preferably also
includes a clean-up module, for querying the storage module and deleting
entries which have
not been updated after a predetermined amount of time.
In the present description, a gratuitous ARP packet is a broadcast ARP packet
which
does require a reply from the client. An ARP announcement is a broadcast ARP
request packet
which does not include the IP address of the guest device in the target
address, and thus
requires no reply.
It will be appreciated that the present invention can be implemented either by
software,
is hardware, or a combination of both. The method can be performed by a
software application
stored in a memory and run by a processor, by custom made logical circuit
chips, such as
FPGAs, and the like.
A hosting system can include one or several devices, comprised in a single
enclosure or
distributed in several ones.
The invention will be better understood from a reading of the non-restrictive
description
that follows of a preferred embodiment thereof, and upon referring to the
appended drawings.
To the accomplishment of the above and related objects, this invention may be
embodied in
the form illustrated in the accompanying drawings, attention being called to
the fact,
however, that the drawings are illustrative only, and that changes may be made
in the
specific construction illustrated and described within the scope of this
application.
BRIEF DESCRIPTION OF THE DRAWINGS
CA 02781178 2012-06-18
8
Various other objects, features and attendant advantages of the present
invention
will become fully appreciated as the same becomes better understood when
considered in
conjunction with the accompanying drawings, in which like reference characters
designate
the same or similar parts throughout the several views, and wherein:
FIGURE 1 is a schematic view of a network device and a system within its
environment,
according to one embodiment of the invention.
FIGURE 2 is a block diagram illustrating components of the hosting system,
according to one
embodiment of the invention.
FIGURE 3A is schematic diagram, according to an embodiment of the invention.
FIGURE 3B is
1o schematic diagram illustrating according to one embodiment of the
invention.
FIGURE 4A is block diagram illustrating steps of the method, according to an
embodiment of
the invention. FIGURE 4B is another block diagram illustrating steps of the
method, according to
another embodiment of the invention.
FIGURE 5 is a flowchart illustrating a prior art network device.
i5 FIGURE 6 is a table showing partial network traces generated following the
method according
to one embodiment of the invention.
FIGURE 7 is a block diagram illustrating components of the hosting system,
according to
another embodiment of the invention.
FIGURE 8 is block diagram illustrating steps of the method, according to an
embodiment of the
20 invention.
DETAILED DESCRIPTION OF THE INVENTION
In this respect, before explaining at least one embodiment of the invention in
detail, it
is to be understood that the invention is not limited in its application to
the details of
construction or to the arrangements of the components set forth in the
following description
25 or illustrated in the drawings. The invention is capable of other
embodiments and of being
practiced and carried out in various ways. Also, it is to be understood that
the phraseology
CA 02781178 2012-06-18
9
and terminology employed herein are for the purpose of the description and
should not be
regarded as limiting.
The invention generally relates to network communications and static IP
support which,
in one embodiment, includes software running on a system such as a computer, a
server, a
router, or a specially designed network device provided with at least two
network interfaces.
Such system is referred to as a hosting system or hosting device. When in use,
the hosting
system listens for ARP request packets destined for foreign networks and
issues an ARP
request broadcast packet, causing the requesting device to insert an entry in
its internal ARP
table which results in a communication path between the originator, or
requesting device of
1o the foreign network, and itself.
One objective of the present invention is to provide a system and/or device
which
supports statically configured devices on foreign network(s). In other words,
the present
invention aims at supporting one or several guest devices in a foreign network
where the guest
devices do not support, or are not configured to use, standard network
protocols which
automatically configure devices to communicate on foreign networks.
Another objective is to provide a system, a method and/or a hosting device for
supporting statically configured devices on foreign networks that need to
connect to a TCP/IP
network but are either not compatible with the DHCP protocol or are not
configured to operate
with DHCP. In some cases, it may also be that devices configured for DHCP are
nevertheless
incompatible because of client DHCP restrictions, and fall back to IPV4 Link-
Local Addressing
(addresses set aside in the 169.254/16 range). The devices are typically
referred to as "guest"
computers, laptop, tablets, smartphones, or other TCP/IP enabled devices which
are not
permanently installed within the foreign network.
It should be noted that not all of the particular components, configurations,
and steps
2s described in the following detailed description of embodiments are
essential to the invention and
thus should not be taken in their restrictive sense, i.e. they should not be
taken as to limit the
present invention. It is to be understood, as also apparent to a person
skilled in the art, that
other suitable components and cooperations therein between, as well as other
suitable
configurations, organizations, and/or architectures may be used for the
system, network device,
3o and method according to the present invention, as will be briefly explained
herein and as can be
CA 02781178 2012-06-18
easily inferred herefrom, by a person skilled in the art, without departing
from the invention.
Moreover, the order of the steps provided herein should not be taken as to
limit the scope of the
invention, as the sequence of the steps may vary in a number of ways without
affecting the
scope or working of the invention, as can also be understood.
5 Furthermore, in the context of the present invention, the expressions
"laptop", "mobile
device", "game console", "tablet", "cellular phone", "mobile phone", "guest
device" and any other
equivalent expression and/or compound words thereof known in the art will be
used
interchangeably. Furthermore, the terms "host user" and "guest user" refer to
the user of the
host mobile or fixed device. The terms "hosting system" , "network device",
and "hosting device"
10 refer to a system through which the guest/user devices must connect in
order to communicate
with the local network (of the hotel, condo tower, etc.) or with other foreign
networks. A hosting
system can include many devices distributed in different enclosures, while the
hosting device is
typically a network gateway.
With reference to Figure 1, a network 10 is shown. The network 10 includes
different
is types of devices: communication devices 12; a hosting device 14, for
example a gateway
appliance; guest devices 16, that are connected to the network, such as
laptops, mobile
phones, tablets, and that are either properly configured or use the DHCP
protocol; and other
guest devices 18, which do not support DHCP, or are not configured to use
DHCP. In other
words, guest devices 18 are configured with static IP addresses.
The hosting device 14 includes a memory 20, a processor 22, and a first
network
interface 24 through which it can communicate with the communication device 12
and/or
directly with the guest devices. Stored in the memory 20 is a software
application which
includes different modules or functions, some of which allow guest devices 18
to
communicate with the network 10, even if they are configured to communicate
with a base
or home network that is different than the network 10. Network 10 can also be
referred to as
a "foreign network" when considered from the view point of the guest device.
The hosting
device 14 can be, for example, a computer, a server, a router, or any
specially designed
network device which includes at least a network interface 24 and preferably
another
network interface 25.
CA 02781178 2012-06-18
11
It is worth noting that it can be considered to include, within the hosting
device 14,
the communication capabilities of device 12.
In brief, the hosting device 14 listens on its network interface 24 for ARP
request
packets destined for foreign networks. The hosting device 14 will issue, on
the network
interface 24a, an ARP packet, which can be either one of an ARP announcement
or a
gratuitous ARP packet, to establish a communication path between the
originator of the
ARP request and itself, the originator being one of the guest devices 18. The
devices 16, 18
are connected to the communication device 12, wired or wirelessly, and the
communication
device 12 is in turn linked to the hosting device 14, also referred to as a
gateway appliance.
Of course, as mentioned previously, while in Figure 1 the communication device
12 and the
hosting device 14 are shown as two distinct apparatuses, they can also be
integrated in a
single enclosure.
Now, the steps of the method which allow the guest device 18 to communicate
with
the network 10 of Figure 1 will be explained by referring to Figures 2 to 4.
The guest device
18, which can also be referred to as a foreign device when considered from the
view point of
the hosting device, is configured with a static IP address and is provided
with a hardware
address, such as a MAC address (Media Access Control address). In the case
illustrated,
the guest device 18 is configured with a static IP address set to
192.168.40.15, a subnet
mask set to 255.255.255.0, a default gateway set to 192.168.40.1, and a MAC
address set
to AA:BB:CC:DD:EE:FF. The default gateway, also referred to as the guest
gateway, is the
network device through which the guest device generally communicates when
accessing
other networks from its base or home location.
The guest device 18 can be, for example, the laptop of a user which is set to
communicate with a home or base router. This router would thus be configured
with the
default or "guest" gateway IP address, in this case 192.168.40.1. Just as for
the guest
device, the home/base router has a hardware address, which is typically a MAC
address.
As it is well known to people skilled in IP networking, the Address Resolution
Protocol
(or ARP) is used to connect the Network Layer (OSI Layer 3) to the Data-Link
Layer (OSI Layer
2). In other words, the ARP is used to link IP addresses to Ethernet addresses
(or MAC
3o Addresses). For a first device to communicate with a second device on a
network, the first
CA 02781178 2012-06-18
12
device must know the Ethernet MAC address of that second device. If the second
device is not
on the LAN (Local Area Network), the first device needs to go through its
default gateway, which
is typically a router. In this case, the router will be the destination MAC
address that the first
device will communicate with.
As such, when the guest device 18 wants to communicate with other devices or
networks, it will first verify in its ARP table to see whether the MAC address
of the default
gateway is known. An ARP table allows to link an IP address with a MAC
address. Since the
content of the ARP table is only kept for a short period of time, and as long
as it is used, the
MAC address corresponding to the default gateway is unknown when arriving in
the location
of the new hosting network. In other words, the guest device 18 wants to speak
to its default
gateway but the MAC address of the default gateway is not listed in the ARP
table. The
guest device 18 thus sends a broadcast ARP request that says "who has
192.168.40.1 and
what is your MAC address?". The ARP request includes the guest device IP
address, the
guest gateway IP address, and the guest device hardware or MAC address.
The hosting device, also referred to as hosting gateway 14, is configured with
a
hosting gateway IP address and is provided with a hosting gateway hardware
address, such
as a MAC address. In this case, the IP address of the hosting gateway is set
to 10.10.1.1,
the subnet mask is set to 255.255.255.0, the default gateway is set to
10.10.1.254 and the
MAC address is set to Al:B1:C1:D1:E1:F1. The hosting gateway IP address is
thus different
than the guest gateway IP address, and the guest device would typically not be
able to
communicate through the hosting gateway without the invention, as best shown
in Figure 5.
Turning now to Figure 2, according to the invention the network device is
provided
with a listener module 26 which listens to ARP requests. When the listener
module 26
detects an ARP request from a foreign network, which can be referred to as the
first ARP
request 32, it drops the initial request, and the listener module 26 instructs
a broadcaster
module 28 to generate a gratuitous ARP packet, referenced by numeral 34. The
gratuitous
ARP packet 34 says "who has 192.168.40.15 and what is your MAC address?". In
other
words, the hosting device 14 creates gratuitous ARP broadcast packet to teach
the device
18 that the MAC address of the network device corresponds to the foreign
network default
gateway IP address.
CA 02781178 2012-06-18
13
As best shown in Figures 3A and 4A, the first ARP request 32 includes the
guest
device IP address, 192.168.40.15, the guest gateway IP address, 192.168.40.1,
and the
guest device hardware address, AA:BB:CC:DD:EE:FF. A tailored gratuitous ARP
packet 34
is sent from the hosting device 14 to the guest device 18. This gratuitous ARP
34 sent by
s the hosting device 14 includes the guest device IP address, 192.168.40.15,
the guest
gateway address,192.168.40.1, and the hosting gateway hardware address,
A1:B1:C1:D1:E1:F1.
Still referring to Figures 3A and 4A, after receiving the first ARP request
34, the
hosting device 14 will update its ARP table with the IP address and the
hardware address of
1o the guest device. Of course, this step can be performed either before,
after, or while sending
the gratuitous ARP packet 34.
When receiving the gratuitous ARP packet 34, the guest device 18 will
automatically
update its ARP table, thus associating the IP address 192.168.140.1 with the
MAC address
A1:B1:C1:D1:E1:F1. The guest device 18 will then be able to communicate with
the hosting
15 device 14 and access other devices or networks via the network device, the
network device
communicating with the guest device as if it were the guest gateway.
According to the ARP protocol, the guest device 18 will reply to gratuitous
ARP
packet 34 with the ARP response 36 which includes its IP and MAC address, and
the
hosting gateway IP and MAC address. The ARP response 36 essentially says
20 "192.168.40.15 is at AA:BB:CC:DD:EE:FF, and 192.168.40.1 is at
A1:B1:C1:D1:E1:F1".
The present method advantageously respects the ARP protocol, in the sense that
there is no "mangle" response sent to the first ARP request 32. It also allows
the hosting
device to receive a confirmation that the guest device 18 has indeed updated
its ARP table.
Many anti-virus programs monitor ARP responses and may drop mangled ARP
responses.
25 Since it is the gratuitous ARP packet 34 that is sent from the network
device/hosting
gateway, the requests are not monitored in such way, and the probabilities
that the
gratuitous ARP packet will be dropped are smaller than that for a mangled ARP
response.
Indeed, Request for Comments ( RFC) 5227 proposes an Internet standards track
protocol for the Internet community, noting that unsolicited ARP replies may
be dropped, but not
3o ARP requests.
CA 02781178 2012-06-18
14
Referring to Figures 3B and 4B, an alternate method consist of having the
hosting
device 14 to sending an ARP announcement packet once an ARP request from a
foreign/guest
device 18 has been detected. The ARP announcement packet includes the hosting
hardware
address, and the guest gateway IP address for both the source and destination
addresses.
When the guest device 18 will receive this ARP announcement, it will
automatically update its
ARP table, associating the IP address of its default gateway to the MAC
address of the hosting
device. In order to ensure that the guest device has updated its ARP table,
the hosting device
sends a gratuitous ARP packet including a request for the MAC address
associated to the IP
address of the guest device. The guest device will reply to this ARP request
with an ARP reply,
which provides the hosting device with a confirmation that the guest device 18
has indeed
updated its ARP table. After the ARP Announcement, the arp request of the
guest device is
optional, although preferable since the hosting system will receive a
confirmation from the guest
device.
Once the two devices are able to communicate with each other, the network
device
14 will receive network packets other than ARP requests, which will include
the hosting
gateway hardware address. The hosting gateway 14 will also receive network
packets
destined to the guest device 18, via its second network interface 25, and will
transmit these
packets to the guest device 18. The hosting device will then act as a
middleware, changing
the guest gateway IP address with his own IP address and exchanging network
packets with
the local or external network(s) 15 and the guest device 18.
Optionally, the hosting device 14 can include a route builder 30, to build a
route,
preferably a TCP/IP route, dedicated to the guest device 18. This route allows
communication from the hosting device 14, or server, back to the guest device
18. This
route will allow the guest device 18 to access external networks other than
network 10.
Of course, the first ARP request 32, the gratuitous ARP packet 34, the ARP
response
36 from the guest device 18, and the following network packets can be sent via
wired or
wireless links. While the hardware addresses are typically MAC addresses, the
use of
another hardware address format can be considered.
CA 02781178 2012-06-18
The following paragraphs describe in more detail the different modules of the
hosting system, and refer to Figures 1 to 4B. As explained previously, these
modules can
also be considered as elements, functions, or instructions stored on a
processor-readable
medium.
5 A. The Listener
The listener module or listener element monitors all packets on a network
interface
and identifies ARP requests for foreign networks. It comprises listening means
38, detecting
means 40, and instructing means 42. The listening means 38 listens for ARP
requests, the
detecting means 40 is able to detect ARP requests from foreign networks and
instead of
10 dropping them, it uses the information they contain to update its ARP
table. The instructing
means is linked to the detecting means. They inform the broadcaster module of
the ARP
request.
Foreign network ARP packets are ARP request packets that are issued by a
device
that is not in the same broadcast domain as the network interface listened on.
15 The Route Builder
The Route Builder module or element creates a TCP route on the hosting system.
The Route Builder element creates a TCP route on the hosting system that will
be
specifically used for the guest. The TCP route is used to return packets to
the guest device.
Since the guest device considers the gateway created as being in its local
network, no route is
needed outward from the guest device. However, one is needed for the hosting
system to
deliver packets back to the guest device. However, if the route builder
determines that the route
already exists from a previous communication with the guest, and that the
route is still valid, no new
route is created. If a route exists that is not valid, for any reason, that
route is deleted before creating
a new route.
The Route Builder is only part of a preferred embodiment of the hosting
system.
B. The Broadcaster
CA 02781178 2012-06-18
16
The Broadcaster module or element tailors a gratuitous ARP packet with
specific
information: it generates an ARP packet asking "who has the foreign IP address
owned by
the guest device, tell me".
The MAC address and IP address correspond to the IP address requested by the
guest device, whether this be a gateway, a dns, or any other devices the guest
device is
looking for.
The tailored gratuitous ARP broadcast packet is then transmitted on the
network 10.
The packet will be read by all devices on the network, including the guest
device 18,
causing it to reply to the gratuitous ARP packet and to provide its IP and MAC
information to
1o the hosting system. In doing so, the guest device will make an entry in its
ARP table with the
new information. Since this new information populates the ARP table of the
guest device
(ARP table) with an entry IP address entry matching the IP address requested
by the guest
device, it in turn learns how to speak with its default gateway and allows the
guest network
device and the hosting system to communicate as if both devices were on the
same TCP/IP
subnet.
The broadcaster module includes means 44 for generating and sending the ARP
request.
The main TCP/IP configuration (IP address, subnet mask, default gateway, DNS
servers) of the guest device has not been modified in this process, meaning
that there is no
need to manually reconfigure the guest device to allow for it to communicate
with the
hosting system. Advantageously, the packets transmitted from the guest device
to the hosting
system are not modified either, and no data has been modified. Only if packets
are sent to the
internet may they be modified by standard Network Address Translation (NAT)
methods.
The main TCP/IP configuration (IP address, subnet mask, default gateway, DNS
servers) of the hosting system also has not been modified in this process.
Connections of Main Elements and Sub-Elements of Invention
The Listener provides instructions to the Route Builder and the Broadcaster
modules.
CA 02781178 2012-06-18
17
Currently existing alternatives require the creation of ARP reply packets
which are
sent to a foreign device in reply to its ARP request.
Contrary to available solutions, the hosting system and/or network device of
the
present invention do not send modified ARP reply packets, but instead only
send gratuitous
ARP broadcast packets.
One advantage of the present invention over the existing solutions is that the
gratuitous ARP packet triggers a change in the ARP table of the guest device
by asking the
guest device to respond to an ARP request rather than by providing a fake ARP
reply
packet, which is subject to be considered as "mangled" packets by anti-virus
systems, for
example, which are able to prevent standard ARP poisoning techniques
resembling existing
alternatives.
Another advantage of the present solution is that a validation, in the form of
an ARP
response, is received from the guest device at the hosting system, confirming
to the hosting
system that the new gratuitous ARP packet created and sent by the hosting
system has
been properly received and learned. Yet another advantage may be that the
hosting system's
address is broadcast in the gratuitous ARP, and therefore other devices with
the same
requirement (for example several devices from the same guest, or several
guests from the
same company) will also be informed of the hosting gateway.
Referring now to Figure 6, an example of a network trace in a network
including a
guest/client device and a hosting device is shown. The guest device has MAC
address of
00:22:00:99:88; a static IP address of 192.168.10.10 and a subnet of
255.255.255Ø It is
statically configured for a default gateway of 192.168.10.2.
The hosting device has LAN MAC address set to 00:10:18:cO:d4:be and is on the
same
physical network segment as the guest device. The hosting device has a static
IP address of
172.168.40.1 and a subnet of 255.255.255.0, the hosting device being on a
different subnet
than the subnet of the guest device. There are no other devices connected to
the same physical
network segment, and one object of the hosting device is to provide Internet
access to devices
connected to its LAN port by providing NAT (Network-Address Translation)
towards its WAN
port. Typically, a client configured for DHCP would simply receive an IP
configuration in the
CA 02781178 2012-06-18
18
172.168.40.xxx network scope, allowing it to use this device as its default
gateway/router and
access the Internet, much like any common router with DHCP will do.
In this case, since the static configuration on the guest/client device does
not match the
subnet of the gateway device, the client device would normally not be able to
access the
Internet. Figure 6 represents a trace of the specific network activity,
allowing the hosting device
to detect this network situation and modify the MAC device table of the guest
device to allow the
necessary network routing to take place, and ultimately provide Internet
access to the client
device.
Still referring to Figure 6, and more specifically to line 1 of the table, the
guest device
sends an ARP request asking for the MAC address of its statically configured
default gateway:
Tell me who has 192.168.10.2. Then, as per the second line of the table, the
hosting system
does not respond to the initial request and instead responds only with a
gratuitous ARP packet:
Tell 192.168.10.2 who has 192.168.10.10. Finally, as per line 3, the guest
device responds that
192.168.10.10 [itself] is at 00:22:00:99:99:88. This is no longer a broadcast
packet because in
step 2, the client device saw that the source was 00:10:18:cO:d4:be. During
the process of
providing the answer, the client device automatically registers in its MAC
address table that
192.168.10.2 is at 00:10:18:cO:d4:be without having to be told that
information with a specific
separate ARP message.
It is worth noting that the table below is not a complete network trace but
highlights the
important packets necessary to demonstrate the main operation of the hosting
system.
It is becoming more common for hosting systems of the kind described here to
handle
more than one network interface, in particular interfaces that are segmented
via VLANs. An
embodiment of the invention in this environment necessitates additional steps.
When multiple
interfaces 24a, 24b etc. are present, they may be actual network interfaces,
residing on
microchips or on add-in cards, but they may also be virtual interfaces, dummy
interfaces, or
VLANs, or any similar incarnation of network interfaces.
With reference to Figure 7 and 8, in the case of multiple interfaces, the
invention is
extended by providing a complete set of modules 26, 28, 30 for each interface
24, so that if
there are 4 (four) interfaces, there will be 4 listeners, four broadcasters,
and 4 route builders, as
if there were four separate hosting systems. The initial transactions with a
guest device 18 that
CA 02781178 2012-06-18
19
has a fixed ip address are identical to the embodiments described above.
However, additional
steps are required if the guest device 18 is moved from one local area network
interface 24a to
another 24b. In this case, the guest device's gateway address may no longer be
valid.
An additional module is required, being a storage module 50 where each of the
individual broadcasters and route builders record their hosting gateways and
routes. In the
case of multiple interfaces 24a, 24b, etc, therefore, each of the broadcasters
and route builders
take the additional step of recording their respective information in the
storage module. The
storage module 50 provides a single instance of common storage, wherein each
instance of
broadcaster and builder sees exactly the same information.
The storage module 50 can provide storage which is stored in a variety of
mediums, for
example, host memory, flash memory, disk storage, even remote storage, as long
as this
memory is easily and rapidly accessible. The storage provided by the storage
module 50 need
not be persistent, with respect to the hosting device. If the hosting device
is restarted or re-
initialized, the storage may also be re-initialized, although this is not
necessary.
In addition to storing each guest device's hosting gateway and routing table
entry, the
storage module also stores a timestamp for each entry. This timestamp is
updated each time an
entry in the storage module is updated or confirmed.
The additional steps required to accommodate multiple interfaces are the
following: In
addition to any of the embodiments discussed earlier:
- Once a listener 26 has determined a request from a guest is a compatible ARP
request,
- The storage module 50 is queried for the guest device's hardware address, to
determine if any previous activity has resulted in a hosting gateway and a
route
table entry
- If not, this embodiment proceeds through the normal steps, but as a last
step,
provides the storage module 50 with the hosting gateway and routing
information
generated
- If yes, then
CA 02781178 2012-06-18
^ The broadcaster module 28 determines whether the new required hosting
gateway is different from that retrieved from the storage module,
= If not, the broadcaster 28 continues to broadcast the previous
hosting gateway, and requests the storage module to update its
5 time stamp, to confirm the hosting gateway validity
= If so, the broadcaster 28 must broadcast the new hosting gateway
and replace the hosting gateway in the storage module for the
guest device, which also updates the timestamp.
^ The route builder module 30 determines whether the new required route
10 is different from that retrieved from the storage module,
= If not, the route builder 30 rebuilds the route only if the route does
not already exist, and requests the storage module update its time
stamp, to confirm the guest device's route validity
= If so, the route builder 30 must remove the old route before
is building the new route, and subsequently update the storage
module, replacing the old route with the new route, which also
updates the time stamp.
Since multiple interfaces are involved, it may become necessary under certain
20 circumstances to expire certain routes. With the addition of a storage
module, an
additional module may be used to perform this task:
The cleanup module 52 periodically queries the storage module for stale
entries,
defined as entries that have not been updated in a pre-determined time. It may
also
query the hosting system to determine if a guest device considered stale has
had any
recent network activity, recent being within a time frame defined by the
cleanup module.
If a guest device is determined to be stale, the cleanup module may remove any
hosting
gateway entries, as well as request that the route builder remove existing
routes. Any
entries in the storage module for the guest device are then removed.
If necessary, during a hosting device restart, for example, the cleanup module
can
request the storage module to flush all entries.
CA 02781178 2012-06-18
21
If the guest device then subsequently re-initiates network access, the process
begins
anew, as though this guest device had never been seen before.
Generally stated, each listener/broadcaster/route builder is tied to a single
interface. Guest
devices may move from one interface to another, invalidating currently active
hosting
gateway associations and routes. When this happens, the invalidated gateway
associations
and routes must be replaced with the proper entries for the new, current
interface.
In one embodiment of the invention, the hosting system includes
Storage module (single instance)
Cleanup module (single instance)
In addition to existing modules:
Listener (per interface)
Broadcaster (per interface)
Route builder (per interface)
In this embodiment of the invention, the following additional steps are
performed :
Listener - none
Broadcaster: read guest device entry for gateway from storage module
Write guest device entry for gateway in storage module
Update timestamp for guest device entry for gateway in storage module
Route builder: read guest device entry for route from storage module
Write guest device entry for route in storage module
Update timestamp for guest device entry route in storage module
Remove invalid route
Storage module: Store guest device gateway
Store guest device route
Store guest device gateway timestamp
Store guest device route timestamp
Update guest device gateway timestamp
Update guest device route timestamp
Remove guest device gateway entry
Remove guest device route entry
CA 02781178 2012-06-18
22
Flush all entries
Cleanup module: Identify stale guest devices
Confirm (checking network use) stale guest devices
Remove stale guest devices via storage module
Remove stale routes via route builder
What has been described and illustrated herein is a preferred embodiment of
the invention
along with some of its variations. The terms, descriptions, and figures used
herein are set
forth by way of illustration only and are not meant as limitations. Those
skilled in the art will
recognize that many variations are possible within the invention in which all
terms are meant
in their broadest, reasonable sense unless otherwise indicated.
