> 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.
>> A previous poster proposed HamachiVPN. 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.
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.
Thanks for clarifying that. I'll keep that in mind 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.
>>> A previous poster proposed HamachiVPN. 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.
> 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.
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.
On 24 Dec, 19:51, "Rick Karlquist" <rich...@karlquist.com> wrote:
> Thanks for clarifying that. I'll keep that in mind > 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
> Paul Christensen wrote:
> >>> A previous poster proposed HamachiVPN. 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.
> > 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- Hide quoted text -- Show quoted text -
Dave -- G0BWX --- For information on IRB, please take a look at 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:
> > 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.
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!
> 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
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.
> 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.
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.
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)
> 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!
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.
That is a lot of work when you have hundreds + potential users. 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.
> 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.
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..
Excellent assessment, but I think that ham radio should stick with 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.
> 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..
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.
The TS480 remote panel does not use the CAT interface, In fact the 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.
> 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.
Sorry for the inconvenience. I may not get to this for a while due to lots of other stuff going on. May be TS2000 and, if so, that is a big issue. But let's wait until I find out.
