Introduction

January 22, 2011 at 13:10, updated on January 25 at 04:00

The Perseus software has been improved in order to allow to use a remote unit via an IP network, either private (LAN based) or Internet.
Of course you will need two computers, the first, conventionally named server henceforth, has to be linked to a Perseus receiver as usual, the second, the client, is where the user sits down at. The simplest installation is when both client and server are linked on the same LAN: in this case, because there are no active layer 3 devices in the middle, the setup works without any hassle. Anyway, you are suggested to test first you setup in this simpler environment.

The client side, in order to get the control of a server, needs to create a new connections (using the TCP protocol that is the main connection oriented layer 4 protocol of TCP/IP stack) towards the server. The connection is shown here

as a blue arrow. This connection is opened when you press the pushbutton OK in the map (see the Mikcrotelecom refernece manual for details).

What does it happen next ? The server executes some security control, just to be sure that some intruder is not attempting to get in, and after begins to send the audio and spectrum information back to the client.
These informations are borne over a stream of packets (the red arrow), originated by the server, using a different protocol, the UDP. There is a well thought technical reason behind this choice: the data of audio stream needs to be delivered as soon as possible, without any delay; using TCP here would cause troubles, for instance in the case of retransmission, due to sophisticated checks that has been implemented in TCP to assure that no data is lost. If few packet are lost or garbled, all that you hear is a click or noise: if the rate of losses of the path between client and server is low enough, everything is fine.

Now, let advance to the network diagram we have when client and server don't anymore are linked on the same LAN (subnet).

In this case, usually, there are two devices in the middle, usually named router or firewall; those device are in charge for several jobs:

1. disallow creation of session from Internet to the internal network
2. translate the IP addresses when a packet is forwarded
3. disallow that packets are not forwarded, unless they are found related to some session already established

The first functionality is very important in the today' Internet environment, not so many machine will survive (even those equipped with an internal firewall) if they are exposed to the Internet without some filter.

The schema above applies to majority of home Internet connections; just for sake of completeness, I want to show a more general architecture:

here you see that the router functionality are in charge of a router appliance (icon with red spot), whilst the firewall is shown as usual. In this case, from our point of view, the router is not relevant because no security rules are defined inside it (anti-spoofing access lists aside, but, again, for our purposes are not an issue).

Back to the business: all guys with some electronics expertise already have noted the diode symbol over the firewall icon: if you think of connections as flows of (positive) currents, you have a good analogy on what is happening in such devices.

The modern firewalls today are not simple stateless packet filter, where the decision if discard a packet is taken just looking into the network layer 3 and l4 elements of those packet and comparing them to a fixed set of rules.

Rather a firewall is a stateful devices: it maintains a table of each session (flow) crossing the device. A packet is forwarded only if is acknowledged as owned by a session or is the first one of a new session and this new session is allowed from the security policies configured into the devices.

Moreover, the firewalls are built with the concept of security zone embedded: in an home class device, usually, the outside zone (less secure) is that where the WAN interface resides, the inside zone (more secure) hosts the LAN interface.

Per default the sessions (flows) originated from the inside zone are permitted, those from the outside are banned.

Of course, as you can see in the diagram below both the firewall are expected to manage a flow coming in a wrong direction. Therefore, both the firewall needs some configuration in order to permit the software work.

Moreover, if a site is playing, at the same time, both the client and server roles, the local firewall will to be configured to allow both TCP and UDP connections. Look at the followinf diagram:

the router of site "My SITE" (on the right) has to allow:

1. a flow towards port udp/8015 bearing the audio flow from Server X, because we have a local client using that server
2. a command flow toards port tcp/8014 because we are running a local server used from a Remote Client

There is a more complex case, though, it is when you have more than a client running on the same machine.
Let's suppose, for example, you want to going to link with two remote receiver in order to compare the antennas they have.
You start and connect as usual the first instance of Perseus client, dubbed Client X, to the Y server; the troubles arise when you try to connect the second instance (Client Y) the other remote server: Really we have two issues:

1. there is a clash on the port, you cannot have two process listening on the same port and protocol and, at the same time, keep well separate the two flows
2. anyway the router would be unable to disambiguate the packets coming from two different server with the same destination port (please remember that we are assuming to have into the router one only exterior IP address fully routable on Internet)

As already demonstrated during the beta test phase, the client allows to cope with this situation: it is possible, in the second instance of client, configure (Menu Network settings) the UDP port where the client is expecting the audio stream back. In the diagram above port 8016 was selected: of course an additional port forward rule has to be added into the router accordingly.
Similar consideration applies when one of two server is that managing the local Perseus Receiver.

Lastly, when you have a setup based on two computer with two client running at the same time, one for each computer, you anyway have to configure the clients on two different UDP ports, defining the port forward accordingly.

Please note that here we are using port 8018 on the second computer.

How to use a remote Perseus Server

January 21, 2011 at 22:00 · ,

In this modality you can use another Perseus hardware in a remote location.
The Perseus client software (perseus.exe) is really an much improved version of the classic Perseus software. Of course can be used on a receiver directly connected to the computer as usual or as pure client if you don't yet have the real receiver or if the receiver is already managed from a server.

In the network setting panel, aside identification data, there is a value that is critical for a correct working: the Client UDP port.
This is the UDP port on which your client excpects back the audio/spectrum stream from the server.
Because this stream is unidirectionally generated from the server towards your client, you have to configure the router so it permits the packets to flow and, at the same time, does the necessary Network Address Translations.
For reasons that will be clear later, it is preferable you change the port value to 8015 (or whatever you prefer).
Running the client you achieve a complete window but with no audio and spectrum.
To select a remote server to which connect, open the page of Perseus map on Internet and click on a server marked as Free. A window show with the fields already filled in.

Troubleshooting connection to a remote Perseus server

January 21, 2011 at 22:00 · ,

The connection is not established

1. double check the server name/ip address and the server port on the Perseus map
2. open a command line shell (Start...Run...cmd...Return) and submit the following command:

   telnet server_ip_or_name port

   for instance:

   telnet perseus.montefusco.com 8014

   if you see a bunch of strange characters, the server is reachable. Otherwise, if the telnet stays trying or you get the connection refused message there are problems on the remote firewall or the server process is down or there is a temporary network outage between you and the server

The connection is established but you have neither audio nor spectrum

If the server you are using is reported working well and is able to pass the previous tests, check your router configuration, pay attention to the udp port you have configured into the port forwarding rule. If the rule sounds right, double check that the IP address you specified for you PC is yet the same: the DHCP could have changed it under the cover.

The connection is established, you have audio and spectrum but the audio is not smooth

1. if the server you are using is reported working well, check that your Internet connectivity is at least as large as those of server
2. check that the Mode of server is suitable for the Internet link, i.e. avoid to configure the server in LAN Mode if you have only an ADSL link.

How to publish a Perseus receiver on Internet

January 21, 2011 at 22:00 · ,

In this modality you permit to other users to use your Perseus hardware from a remote location.
First of all, check the computer you selected for server installation is able to reach the Perseus map on Internet . Next, connect the receiver at your computer as usual and start the server program (perseussrv.exe). A black window will open, followed from the Server Settings dialog box, where you are requested to fill in your data.

Server mode

this subpane is for specify the bandwidth that the server is going to use for the outgoing stream (audio and spectrum): less the bandwidth, less smoothly will be the spectrum flowing. Select the mode more suitable for your Internet connection.

Server configuration

insert your nickname (maybe the call sign is a good choice if you are an OM or an SWL); just for start, leave the port and other parameters at the default value.

Identification on the Server Perseus Directory

for a reliable positioning on the Perseus's map, of course, is critical that you write down the correct Longitude and Latitude data.

Such data are generally available to every one: otherwise you can obtain it from Google Map, filling in you street address or searching manually you location on the map.
Please note the port number: it defaults to tcp/8014 (more on that later).

After you close the Settings windows (that is anyway available clicking on the Microtelecom icon) the server must show the

"2011/01/20 23:01:01 Server started"

message. If you inserted the right coordinate after a couple of minute you should see the icon of your perseus shown at the right positon on the map. [the timestamp is UTC]. If your server is not appearing on the map, please check that the date on your server PC to be properly set. The PSD (Perseus Directory Server) checks the messages it receives from the Perseus servers and refuses messages labelled with an odd time/date as a network security countermeasure.

Now click on your icon and check that the data you inserted are right. You find a data that you didn't inserted, the public IP address assigned to your router from the Internet provider. The Microtelecom server is able to deduce this information from the connection that the server process automatically creates.
Please note that the icon has to be shown, even if you have no router configuration done yet, because the server process in your computer is able to send UDP messages (port 8010) towards the Microtelecom server and usually the home border routers permit any connection from the private internal network towards any Internet destination; The opposite way, instead, is not allowed per default.
Now click on your icon and check that the data you inserted are right. You find a data that you didn't inserted, the public IP address we already mentioned, that is assigned to your router from the Internet provider. The Microtelecom server is able to infer this information from the connection that the server process running in your PC automatically creates.
However, until you not properly configure the router, no one will be able to really use your server (see How to configure your router section).
At this point, if all is going well, the external Perseus clients should be able to reach your server and start a connection. You can see the incoming connections looking at the Perseus window; after a short delay, the rate of outbound stream (in bits/sec) is displayed in to lower right corner of the window. The rate is dependent from the bandwidth you selected in network setting window: nominal values are about 64 kb/s for GPRS and 128 kb/s for ADSL.
However please keep in mind that, because the audio and spectrum data are emitted from the server as an unidirectional udp stream, you have no certain that any audio is really received and reproduced at the client end (please refer to the Client troubleshooting section).

How to configure your router

January 21, 2011 at 22:00 · ,

The configuration we need has to allow connection from external network (Internet) to the internal network on the port tcp/8014 (as per default server networ setting), and on udp/8015 port (as per the client network settings).

In the same time the route has to do the necessary network address translation (NAT). Indeed, as you can read with running the ipconfig command on a Windows command shell, the IP addresses used on your LAN are assigned from a network in the some private range (for example 192.168/16), in other words they are private addresses. You can find the same addresses used everywhere in the world, because the IANA defined into the RFC 1918 such class of addresses (technically named 'prefixes' in the Internet specialist jargon) for use in private network. IANA created this concept in order to attempt to delay the early depletion of IPv4 address space.

Because of this ubiquitous deployment, packets with those address are usable only in the private networks and therefore, in order to connect the machines using it to Internet, need to be translated in a public address guaranteed unique in the the global Internet.

[really IETF dedicated three class of address to private use: 10/8, 172.16/12 and 192.168/16] This job is in charge to the router that terminates the physical link that connect your LAN to the Internet.

This kind of configuration is usually named port forwarding because the router have the capability to translate not only the destination address of IP packet incoming but the destination port too: in such way you can use the public IP address to publish several servers at different ports

So, open the router configuration panel (usually available thorough an embedded web server) and search for the Port forwarding panel. Alas the router configuration, even only of the main vendors, differs too much to allow to describe here a procedure valid in general.

Note that in order to make work both the client and the server, you have to define at least two port forwarding: in some more sophisticated device you have to define two port forwarding rule.

Anyway the parameters that you will have to insert are as follows:

1. external (public) IP address: because this address is usually dinamically assigned to you from provider, and can be changed without warning, you have to specify the name of the interface that terminates the link to the Internet
2. destination protocol and port:
   • Server: the protocol is anyway TCP whilst the port is that you specified in the server Network settings panel (default: 8014)
   • Client: the protocol is anyway UDP whilst the port is that you specified in the client Network settings panel (default: 8015)
3. translated (or NATted port, or forwarded port): use the same values (as above)
4. PC IP address on your LAN: you have to read it using the ipconfig command on the PC where the Perseus server is running (some more user friendly router will propose you a list of all IP address active on your LAN)

Troubleshooting

How one can reassure itself that the port forwarding is really in place and the Perseus server is reachable from everywhere on Internet ?

Aside that asking, on the Perseus list, to some other guy, there are in place few public web sites that, on request, can test if your Perseus is reachable on port tcp/8014 (or everything else you configured in the server).

Start your server, and, after the firewall setup, go to this page.

Write down the port and press the buttom to execute the check.

Whilst this is enough for the server, it leaves us alone for the client setup. In such case we need to check that an UDP stream incoming is permitted on our firewall and we cannot rely on the Perseus client as test program. Fortunately, there is another more powerful tool (downloadable here) that manages to fulfill our necessity. This utility

1. creates a process listening on the udp or tcp port selected
2. with the help of an external server, generates an incoming packet (or socket) and checks if this packet or session really reaches the computer

therefore is able to check if the whole chain is properly working.

More sophisticated routers implement several techniques in an attempt to avoid or limit kwnon attacks. The streams the Perseus server emits are similar to well known attack pattern, therefore those routers can erroneously block the stream or severely degrade the quality of the Perseus' stream. Follows a list of some of typical configuration parameters as found in common routers/firewall:

• SPI (stateful packet inspection)
• UDP Flood
• asymmetric (or partial done) UDP/TCP session
• denial of service

Moreover this features are worth disabling because are CPU hungry and could degrade the performance of the system.

Good informations on how to configure many routers can be found here.
Many thanks to eliocor for the suggestion.

How make a Perseus easier reachable

January 21, 2011 at 22:00 · ,

In order to make your Perseus easily reachable on the Internet, you should have an Internet connection that provides you with at least a fixed public (routable) IP address. However this kind of provision is not really common on the Internet offering available for Home or Small Office use.

There is though a viable solution: there are several service provider that for free can provide you a dynamic DNS service associating your IP address at the moment with a reliable FQN (Fully Qualified Domain Name). In such way, everybody on Internet is able to reach your Perseus Server through a name and not via an (ever changing) IP address.

When is it not possible use Perseus on Internet ?

January 26, 2011 at 03:00

The short answer is: when the border router is not under your control. This encompasses:

1. public WiFi access points with private addressing (Hotels, community),
2. home Internet connections when the ISP owns the router and/or retains full control over it.
3. when the provider assign to outside interface of the customer border router a private (RFC1918) address: in such unfortunate cases (take Fastweb in Italy as an example, see the diagram below) the provider manages a device (usually a big router or hardware firewall) that is in charge for the translations, therefore making the users border routers unaccessible for flows originated from outside of his network

Fastweb workaround

January 28, 2011 at 22:00

A major Italian provider (Fastweb) per default doesn't assign an routable IP address to WAN interface of the customers router.

However there exists a workaround: the Fastweb customers can require a temporary lease of a IP address for a specific machine of own internal network.

In order to aquire the IP, you have to follow a specific web-based procedure shown here. (Many thanks to Stefano IK0VCK for provide the screenshots of Fastweb registration site and for tests).

Once the procedure ends, the page shows the IP address.

Beware that adopting such workaround your machine is exposed without any filter to Internet. Albeit it makes easy to publish your Perseus on Internet, makes too the black hats discover your machine very quickly. You are strongly advised to implement in some way a firewall, hardware or software doesn't matter.

With software firewall the system dynamically ask you if you want open the port, whilst with hardware firewall you have to configure it as perinstructions found in previous sections.

Double router sites

January 24, 2011 at 02:00

In few cases the network infrastructure differs from those previously described. As displayed in below diagram these sites work with two routers, the first one, named outer router, is in charge to terminate the physical line and to provide connectivity services to the host in his LAN, the second one (that could be an integrated wireless access point/ethernet router) provides the same services on the LAN behind.

Alas, usually the security feature in the inner router are kept working (albeit this wouldn't need); therefore we have to configure port forwarding in both devices.
Consider the command TCP session: as usual on the outer router a port forwarding rule has to be configured in order to allow the flow to reach the Perseus server. However the outer router doesn't have direct visibility of the server, hence as internal address we will use the outside ip address of the inner router (192.168.0.254 in the diagram).

Into the second router, instead, we can make a standard configuration using the port forwarding in the same way than in the single router case, therefore using the real address of Perseus server machine.