Re: IP Sound over WAN problems (again)
Dave
Re...
> A previous poster proposedHamachiVPN. This is a non solution
> because it forwards traffic through a 3rd computer, increasing
> ovehead and latency. The whole idea of IP Sound is lean and mean
> and quick.
Not strictly true, thankfully. Hamachi uses a third party server,
the "Mediation Server" only to set the VPN tunnel up, by negotiating
with each end and probing their IP to find a way through firewall's
and routers etc. (NAT Traversal) Once the tunnel is up, it's true
point to point, or peer to peer as you like.
Sometimes you will find a node status goes "Yellow" but the link
continues to work, all that means is that the Mediation Servers
can't be reached, or have otherwise lost site of one end of your
tunnel.
The tunnel itself is secure (if you use one of Steve Gibson's long
random passwords, it's "Very" secure.) Plus, you get a securre
messaging service with it.
It's a very good tool to have, if just for the "Sledge Hammer"
solution to temporeraly setting up network shares, on a LAN! Much
easier than fiddling with network and firewall settings, and the
implications of all that.
I have had IP-Sound working over Hamachi for extended periods, but
there are some hidden issues.
Hamachi uses UDP as it's transport layer, and there are some
copoprate and Hotel firewall's (MS's ISA Proxy/Firewall for one)
that don't handle that very well, unless you can get access to the
ISA server and fully authorise Hamachi. Most people cannot sadly.
I'm in that situation at work, so for the most Hamachi is a non
flyer for that reason, and that alone.
I have also got a SSH based VPN, using Cygwin and PuTTY, that uses
TCP as it's transport, and that just goes right through the MS ISA
server with no problems whatsoever. But.. That currently needs the
applications at each end to use the "Localhost" address (127.0.0.1)
that I suspect IP-Sound is already using, as it just will ust not
connect over that VPN whatsoever (regardless of the ports and
tunnels made) Mind you, setting that up and making it work is not
for the faint of heart or technicaly challenged (no disrespect to
anyone, but there is a lot of reading to do!) Just getting Cygwin
working can be an experience, and PuTTY has it's "interesting
features" too....
I have yet to make Open VPN work, but that I suspect is my lack of
understanding, plus the usual "Open Source" issues regarding poor
and or out of date documantation. Hamachi out of interest seems to
be based on Open VPN, but with it well nailed down so it's a fully
automatic install and setup, very nicely done in fact.
OpenVPN can be set to use TCP btw, and as it provides a VirtualNIC
at each end (Like Hamachi) would be a lot easier to use for this
sort of thing, than the Cygwin/PuTTY solution. (That does run VNC
very well by the way, and HRD!) And as it can use TCP as the
transport, packet loss shouldn't be an issue, even if the app's at
each end actualy use UDP. I think?
UDP of course is not a garanteed transport, if there are "holes" in
the link, you will loose packets forever. TCP of course will
retransmit the missing ones if all is working well. It does seem
that IP-Sound is a bit "poor" in it's tolerance of UDP dropouts, and
sadly though we can mess with the port it uses, we can't tell it to
use TCP.
Here in the UK, I expect there to be a slow increase in interest in
remote shack operation, but purely so that the likes of me, can mess
with the shack from the office at lunchtimes (etc) or when stuck in
a hotel somewhere. Other than the one experimental HF station (I
forget the call) it's unlikely that any general access HF stations
will appear. However, recent license changes will make it much
easier for an individual to setup a "personal" remote station, be it
HF, VHF or whatever.
The issue with IP-Sound and the need to open ports (setup Port
Forwarding I suspect is realy the meaning) is common with all peer
to peer networks, that do not use a third party intermediary, either
to route the data through (As in Skype, eQSO etc, though Skype can
be true peer to peer too, if you enable it.) or to "probe and
mediate" the creatiion of a true end to end tunnel, such as Hamachi.
Echo-link of course uses a third party server to manage the link,
but any link is true end to end, hence the need to manualy setup
Port Forwarding, or otherwise poke holes in your firewall.
As to IRB, as yet I don't know what that is? (Another remote
control package from reading the forum I guess) Perhaps someone can
educate me? I have a TS-870S I'd like access to from my desk at
work of a lunchtime, as otherwise it's terribly booring to say the
least just poking about eBlag or whatever. RX only for the moment
would be good.
Oh yes, I have also used Shoutcast, to route audio from home to my
desk, the client end was Winamp. Very useful when someone who was
"bad mouthing me" thought that just because I was at work, and
outside our local repeater coverage, I couldn't hear what was going
on!... As it's sterei, you can have two audio streems too, if you
need. But, it's only one way of course.
73, and seasons greetings etc..
Dave G0WBX.
Paul Christensen
>> because it forwards traffic through a 3rd computer, increasing
>> ovehead and latency. The whole idea of IP Sound is lean and mean
>> and quick.
I was the original poster. As Dave points out, in nearly all Hamachi VPN
connections, the 3rd-party mediation server is only used to establish the
initial VPN tunnel. If you have all green indicators lit on the remote and
client end, you're NOT transferring data through the mediation server and
your data transfer is still lean, mean, and quick.
Since the time of my post, I have been using IP-Sound in conjunction with
Hamachi from well over one hundred public Wi-Fi hot spots, including cruise
ships where I cannot make a direct connect using IP forwarding to/from ports
4444, 47880, or any other combination. The problem when relaying on a
public Wi-Fi hot spot is that you have no control over IP port-forwarding of
the service provider's Wi-Fi router. If the service provider does not pass
data on the intended ports on you have not established a VPN tunnel, you're
SOL. In these instances, Hamachi has given me IP-Sound connectivity 100% of
the time.
Paul, W9AC
Rick Karlquist
if I am away from home. Meanwhile, at home, I found
that my problem was my ISP blocking port 4444, so
I just picked another port # and all is well.
Rick N6RK
G0WBX
Port 4444 was perhaps not a good choice by the author of IP-Sound (not
even sure if he chose it, as his work was based on others)
Doing a google search for "port 4444" throws up all sorts of potential
nasties so that's why some ISP's block it perhaps.
so I think it best to choose another number, up in the high region.
Such as.. from 49152 through 65535 As they are known as "Dynamic or
User" defined.
See http://www.iana.org/assignments/port-numbers for more details,
what may do what.
As for hot-spots, and other public access points, yes, the only way is
to use a VPN of some sort, and as Hamachi is free, and easy to deploy,
until somthing easier or very much better comes along, use that.
Anyone putting up a remote access station, even for their own private
use, would be well advised to read up on general PC security, especialy
if they use a cable modem with no router, relying on something like
XP's firewall. DSL users with USB modems I would also advise to go to,
Steve Gibson's site at www.grc.com would be an excelent place to
start. Especialy check out the audio podcasts (sorry "Net"casts) for
extreemly good background info on how the whole internet mess works
etc, in terms we can all understand.
He has the most useful "Shields Up!" port security test too. Very
enlightening to say the least, at times...
Merry Christmas, and/or Happy Holidays etc..
Cheers. Dave G0WBX.
> > Paul, W9AC- Hide quoted text -- Show quoted text -
Brad --K6WR
www.w7dxx.com website as well as w4mq website for basic IRB information
including articles publlished in QST in 2001 and 2002.
73, Brad K6WR
On Dec 24, 8:35 am, "Dave" <d...@g8kbv.demon.co.uk> wrote:
> Hi...
>
> Re...
>
> > A previous poster proposedHamachiVPN. This is a non solution
> > because it forwards traffic through a 3rd computer, increasing
> > ovehead and latency. The whole idea of IP Sound is lean and mean
> > and quick.Not strictly true, thankfully. Hamachi uses a third party server,
HB9AZT
I just tried a test setup with hamachi. Very interesting and elegant
solution for closed shop operation of an irb, just forget about all
port forwarding and nat-problems on silly routers!
Install the two clients, one at the home site and the other at the
remote site, create a new vpn-network and login on both stations. You
will find all your devices with internal ip-addresses. No more problems
with port forwarding, forgotten ports and ip-addresses. it's also a
very elegant solution to run two radios with two pc's via one
ip-address. even ip-sound worked, but i found sound quality poor
compared to irbsound or skype. hamachi is also a good way to operate
the w4mq-software out of high security environment, no more discussions
with system administrators about the risk of opened ports etc.. It's
really worth to try!
73 de Mark, HB9AZT
Rick Karlquist
Some DSL providers do not allow VPN unless you pay extra for business
class service, so this may not be a universal solution.
I was just comparing IP sound with Skype yesterday and, to me,
IP sound sounded better, as long as I was not trying to use
the lowest bandwidth settings, such as 11 kHz. At slightly
higher settings, it was definitely better than Skype, IMHO.
Rick N6RK
Paul Christensen
> IP sound sounded better, as long as I was not trying to use
> the lowest bandwidth settings, such as 11 kHz. At slightly
> higher settings, it was definitely better than Skype, IMHO.
Under almost all PCM settings down to the lowest bandwidth, PCM should sound
better than Skype with its lossy codec. One test that I routinely use to
gauge the quality of a codec is to run a sine wave through it -- such as a
CW side-tone. Under PCM, the sine wave is always pure, but as expected,
upper frequency response is a function of the sampling rate. When listening
to a sine wave under Skype, GSM, or G711 uLaw, always results in some
"dirtiness," but these codecs perform best when conditions are sub-optimal
or intermittent.
Also, unless you're running a dual Rx rig like an Orion or Icom 7800, it's
best to use PCM in the mono format rather than stereo in order to conserve
bandwidth. Stereo PCM consumes roughly twice the mono PCM bandwidth.
Paul, W9AC
W4MQ Stan
While VPN tunneling could be a potential implementation, it does open
another set of issues.
We are currently using VPN to access 'hardware only' remotes, i.e.
those with no host computer. But when there is a host computer (the
Hamachi approach), I get worried about giving others any direct
access to a server on my network. For one individual remoting their
own station and not planning to allow anyone else access ,it should
be fine. Current remoting software (TRX Manager, HRD, my IRBHost,)
do not allow any general access to the host machine, so they protect
your LAN, from intrusion thru the remote connection. I would never
give many people access to my LAN.
Re: the VoIP discussion here. Up to a couple of years ago, the uplink
from many broadband services was typically, limited to 64Kbs, a value
too low to dependably support PCM. Now that this is almost
universally up to 256kbps, PCM codecs are clearly an option and
IMHO , the preferred option. Hence I had the IP sound developed add
PCM to his software, my IRBSound2 provides PCM, and Gizmo provides a
great SIP PCM VoIP (used on hardware only stations, since SIP VoIP
is the only such solution in that environment). Not sure why anyone
with sufficient broadband uplink continues to use Skype, since it is
a CPU hog (~3x of Gizmo, IPSound and IRBSound2)
Cheers, Stan
G0WBX
Ordinarily yes. But the whole VPN aproach, is to kep people OUT of
your system that you don't want there. If you setup Hamachi to be
"open" then it's a problem. If you set it up as a closed system, with
a decent password then nowt else will get access to your system, unless
you give them, or they find the password. You would I guess still have
all the usual application log on protocol's, the VPN used just as a
transport layer.
For those who's ISP's say they block VPN's, try Hamachi, you may be
surprised. Or, change to a more accomodating ISP, after all, VPN's are
not exactly uncommon these days. (yes, I know the hassle of doing
that, especialy if your email accounts are in the ISP's domain)
If you are using Win XP as the host, you can selectively firewall
different NIC's, even the virtual NIC H' uses, so you can prevent
anyone using "inapropriate" protocol's, by blocking the common Windows
NetBios and file sharing ports. If I ever manage to get OpenVPN
running, then I believe one has direct control of what goes where
within that environment. The Cygwin/PuTTY approach, though limited at
present to using the loopback address at each end, only opens tunnels
on ports you specify, when starting up PuTTY, so in some ways, it's
even more secure, but a right faff to setup.. (Works very well though
for other things)
You are however right to be wary of any outside connections, be it
direct to a specific port, or via a VPN, however authorised. But, with
carefull planning, and deft tweaking of the system, you can button
things up as tight as you like, while allowing what you need. As in an
earlier post, I'd recomend a serious reading session at www.grc.com.
Lots of background informaion on general PC security, and networking in
particular.
As to PCM rates and broadband etc, yes, in one year here, I've gone
from 512/128 (download/upload) to 8192/512 (kbits/sec) all for free!
Well, at no extra cost anyway. OK, so I had to update the firmware on
my Router (Netgear DG834G, also a free download) but it works very
well. Even the few dialup connections I have access to, are reliable
these days at 52k. And before that, I was using EchoLink over a dialup
link at half that rate, and it just worked fine, no problems at all, so
long as I didn't allow multiple connects!.
One thing IP-Sound has going for it, is the GSM codec, that does a very
good job processing the data down to very manageable levels, after all,
most current mobile phones only use a 9600bd data backbone, and it has
to get the audio and management stuff down that thin pipe, that they do
rather well. Yes, even they are progressing, what with 3G and all
that, but at a cost (over here anyway). However, as yet I've only used
that for moving Received audio about, so what it sounds like when
transmitted, I've yet to find out.
I think that people use Skype for the audio link, as it's virtualy zero
configuration, load it and go! And it works, for most people. CPU's
are getting faster too, as well as broadband rates. I kow nothing of
SIP (other than it's translation, Session Initiatated Protocol, I
thnk?) Not heard of Gizmo (The Gremlin? or an X Girlfriends deceased
cat?) or IRBSound2, so I'm all ears. Skype of course also has other
uses!
I find I also need to re-organise the shack(somehow) in relation to the
physical locations of radios and PC's etc, then it should be much
easier to hook things up to experiment. And I've just found that the
HF ant' counterpoise is damaged, so more work to do... I'm also about
to go off and take a look at www.w7dxx.com as recomended.
Cheers All..
Dave G0WBX.
W4MQ Stan
Anything that gives access to ANY software or files other than those
immediately used for remoting is bad. Playing around with XP
permissions is a job for Windows 'geeks' and not your average ham
who wants to run a small remote operation.
Cheers, Stan
G0WBX
Yes, but it depends on what you want the remote control for. Here in
the UK, it's unlikely we'll get permission to put up systems like your
IRB sites *(I looked, nice, got the audio OK, but my PC security had a
hissy fit about the control applet!) So, most of us who are
interested, would probably just want to put up a "closed" system,
perhaps with one or two "authorised" other commanders... As per the
new license conditions we are getting. For that, the VPN route is
just fine.
As to exposing other resources, well, that's under you control as the
builder/installer of said VPN.
I'm not windows "geek" far from it! However, I strongly believe, that
if you play and use such technology, you should understand as much of
it as posible. After all, something about "self training" is in the
lisence conditions, here at least. Not all of us are "Appliance
operators" thankfully.
The IRB system offers a valuable resorce, and I take my had off to
those who developed it, for it's purpose, it's just fine. But for us
with more restrictive licenses, who on occasions would like to "play
radio" but are not able to be in the shack, or the shack is in another
electricaly "quiet" location, the close systems using VPN's are I
believe the way to go.
I can report some successfull tests with HRD, Hamachi and IP-sound, but
at the mo' RX only.
I and a licensed friend have prooved it all works just fine. I have
the ts870 hooked up to the PC (with a L o n g rs232 lead) running the
HRD Remote server applet, IP-Sound and Hamachi, and it all works
splendedly! Also very stable and reliable. We both have ADSL, and
it's been running like that for hours of a day with no problems at all.
What we did find, is that HRD V3.2, and 3.4 are not compatable, you
need the same version at each end, or it just doesnt work, the rig
control at least.
I have Windows 2000, the other end has XP of some flavour.
When I get the counterpoise fixed, and the auto ATU under rig control,
we'll try remote control (attended!) tests with TX too. I only have
the basic rig so 100W max pep out, but with a random wire, and a total
property size smaller than most Californian driveways (I've been there
for extended periods near Gilroy, so I know!) there could be some
interesting EMC issues to sort out.
For my use though, I still need to fully understand OpenVPN, to get
past my company firewall/proxy. One day.
Right, had the call for food (early) so enough from me..
Best 73 etc..
Dave G0WBX.
W4MQ Stan
radios and not computer screens. The remoting via computer screen is
only an interim approach until ham technology catches up. The newer
radios are starting to include separate radios and front panels, e.g.
FT480, IC7000, IC706. It is possible to take the front panel with you
and operate the system remotely without even a computer at the host
(station) end. Standalone VoIP is now available to provide the two
way quality voice. Indeed a setup like this (no computer at the host
station end) has been operational for a year or so and currently
remotes the FT480 front panel, so the remote operator can twirl the
knob, push the front panel buttons, etc vice clicking his mouse!!
Pretty neat technology. In a few years I would expect this to be the
norm to remote your radios.
Cheers, Stan
HB9AZT
That's also my oppinion and your new remote panel feature is a good
step in this direction. Just one question: I installed the betas with
this new feature, connected a ts-2000 to my client pc to try something
what is called the "synchronous mode" in HRD - did not work.
Synchronous mode means that the ts2000 at the client pc controls
another ts2000 at the remote server. Instead of the computer screen at
the control site you have a real ts2000 to send all the command (except
audio) to the remote site. Any chance to "abuse" the remote panel
feature for this mode, i think in this mode the cat-readouts of the
client ts2000 have just to be forwarded to the server in a transparent
mode and to be returned from the server to the client in the same way.
Or is it necessary to use the remote panel jack at the client-ts2000
for this feature? Unfortunately this jack and its protocol are not
described in the ts2000 manual.
73 de Mark, HB9AZT
W4MQ Stan
CAT interface works simultaneously with the front panel. This is
still needed to provide CW via the CAT interface. Panel interface is
currently 'transparent' but I want to interpret the interface. I have
some ideas and will try them in the upcoming months.
Stan
