inicio mail me! sindicaci;ón
ghpsdr3-alex on Internet
Andrea Montefusco - IW0HDV

Introduction

From the “ghpsdr3-alex wiki:”

The ghpsdr3-alex is a fork of the excellent Software Defined Radio (SDR) software by John Melton [G0ORX/N6LYT].
The original software by John is called ghpsdr3: the fork was meant to extend to the Softrock SDR hardware the software. More hardware were later added, till to cover almost all hardware platoform today available for OMs (UHFSDR, Microtelecom Perseus, RF-SPACE SDR-iq, HiQSDR, Ettus Research USRP and rtl-sdr DVB-T dongles).

Since of its inception, the ghpsdr3 was thought as a truly distributed client server system.

Of course, in order to exploit this feature, one will need two computers; the first, conventionally named server henceforth, has to be linked to the real SDR hardware, lets suppose Softrock, as usual, the second, the client, is where the user sits down at and runs the GUI (Graphical User Interface), the QtRadio program. The simplest installation is when both client and server are linked on the same LAN: in this case, if there are no active layer 3 devices in the middle, the setup works without any hassle. So, it is strongly adviced to test first the setup in this simpler environment.

It is worth to mention that, thanks to the portable nature of GUI, the operating system of the client machine might be different from server one: this opens interesting scenarios where the server is run over an embedded platform whils the client runs on a standard PC. Moreover, an Android GUI, albeit yet with some limitation, does exist.

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) toward the server. The session is shown here

as a blue arrow. This session (also known as socket, even if more properly a socket is the local data structure in computer memory that maintains statu information on the connection) is opened when you press the 'C' in the main window or when press the pushbutton Connect in server list.

What does it happen next ? The server accepts the incoming connection and after begins to send the audio and spectrum information back to the client.
These informations are borne over a stream of packets (the rblue arrow pointing left), originated by the server, owned by the same TCP session.

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; these 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 forwarded, unless they are found related to some session already established
The first functionality is very important: indeed in the today' Internet environment, not so many machines 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 (ip addresses) and layer 4 (protocol and port) 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 or socket) crossing the device. A packet is forwarded only if

  1. it is acknowledged as owned by a session
    or
  2. it 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 only the server side firewall is expected to manage a flow coming in a wrong direction. Therefore, that 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 inbound TCP connections being the outbound one implicitly allowed. Look at the following diagram:

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

  1. an outbound flow toward port tcp/8000 bearing the control session to Server X, because we have a local GUI (client) using that server
  2. an inbound control flow toward port tcp/8000 because we are running a local server used from the Remote Client

How to use a remote server

In this modality you can use another hardware in a remote location.
The client software (QtRadio) is really an improved version of the classic ghpsdr3 software.

The quickiest way to connect to a renmote server is pressing teh key 'L' : a list of available servers will appear, selecting one and pressing the Connect button, the client attempts to connect.

If the server is yet active (the list gets refresh every 60 second, in the meantinme the server could have been stopped) and the remote router is well configured, the spectrum shows into the bottom pane and audio starts.

In case all stay silent, looking to the title bar of the windows usually a message shows: the most common reason of ill behaviour is "server refused connection" or "server disconnected"; that is due to some misconfiguration in the remote router.

How to configure your router

The configuration we need has to allow connection from external network (Internet) to the internal network on the port tcp/8000 (as per default server network setting).

In the same time the route has to do the necessary network address translation (NAT). Indeed, as you can read running the ifconfig on Unix 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 Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
RFC 1918 defines such classes of addresses (technically named 'prefixes' in the Internet specialist jargon) for use in private network. IANA created this concept in an attempt (very successfull indeed) 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, that breaks the first rule of IP routing: the IP address uniqueness.
So, in order to connect the machines using them to Internet, the IP addresses inside the packates need to be translated in a public address, guaranteed unique in the the global Internet.

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 even referred to as 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.

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 notice, usually you have to specify the name of the interface that terminates the link to the Internet, instead of the public IP address
  2. destination protocol and port:
    • the protocol is anyway TCP and the port is 8000
  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 ifconfig command on the PC where the dspserver 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 dspserver is reachable from everywhere on Internet ?

Aside that asking, on the mailing list, to some other guy, there are in place few public web sites that, on request, can test if your server is reachable on port tcp/8000.

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

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

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

Troubleshooting connection to a remote dspserver

The connection is not established
  1. double check the server ip address and the server port on the server list, lets suppose you connect to IW0HDV server, below in yellow, you note the IP address, 94.39.60.31:
  2. open a command line shell (Start...Run...cmd...Return in Windows, ) and submit the following command:

    telnet 94.39.60.31 8000

    if you see a bunch of strange characters, the server is reachable.

    If you see the following message (Linux), again the server is reachable:

    $ telnet 174.17.56.23 8000
    Trying 174.17.56.23...
    Connected to 174.17.56.23.
    Escape character is '^]'.
    

    (In Windows the telnet's screen becomes black).

    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 you could have some local audio problem, refer to the wiki in order to solve that.

When is it not possible publish dspserver on Internet ?

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

Debugging complex configurations

Usually the typical SOHO network setup is made by a single border router (with firewall cababilities) and a ethernet switch embedded. Maybe the same device can host a WiFi Access Point and so you ghet the best of the two world.

But, what when do you have a more complex configuration ?

Lets take as example a firewall plus router configuration where the border router has, as internal connectivity, a wireless LAN.

The journey of a packet

Now consider a packet emitted from the righmost computer, that with IP 10.20.200.139. For sure this packet reach the inside router but here the router has to forward it: the forwarding depends on which is the destination address: if that is an Internet destination, the router needs an instruction in order to so. That instruction is called 'route', in our case is a static route, i.e. a route manually configured that says: in order to reach any destination (0.0.0.0/0) please send the packet to 192.168.0.1.

You can see (in the right green box) the so called routing tale of the interior router. This kind of route is also called default route or last resort route.

When this packet arrives on the bourder router, this one has a default route installed, probably assigned to it by the DHCP protocol or PPP-LCIP that the router speaks with the ISP router (not shown here).

Of course, before to be forwarded, the router applies a source NAT (really a PAT, more on that later), i.e. changes the source address of the packet from 10.20.200.139 to that of the exterior interface of the border router (90.54.37.234 in the figure). When the answer packet comes in from the remote site, it has as destination address 90.54.37.234, so the exterior router translates that again in 10.20.200.139 and try to forward it.

But where ? Again, we need to insert a static route, this time pointing to interior subnet (10.20.200.0), using as gateway the IP 192.168.0.100, that is the interior router IP address on the wireless LAN.

How to expose on Internet a dspserver running on the PC on the interior LAN