I get all the way to the section where it says I need to run 'sudo
./findpass.sh', and it gives me output of 'Tunnel Socket: Setting
SO_BINDTODEVICE: No suck device'.
The instructions I am following are at:
http://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example#Setting_up_the_Tunne…
And I am to the section of ' Finding the password for AMPR-RIPD"
The only section that had an issue during this process is the
isc-dhcp-server will not start. I don't believe this should make any
difference, other than if I have a client on my Ham Network that needs
DHCP, but I plan to statically assign those devices.. so I believe that
point should be moot.
My installation is Ubuntu 14.04.4 LTS
I only have 2 interface.. eth0 (outside WAN address from ISP. One of my /29
allocations) and eth1 (inside 192.168.44.0/24)
I know enough to make my way around, but am not normally a linux guy!! Let
me know what other info would be helpful to share out, so we can get this
one going.
Thanks guys!!
--
Rod Ekholm
kc7aad(a)gmail.com
Thanks for the reply's guys. Lynnwood.. I have Ubuntu installed and working
on my network (outside address as to not have anything blocking right
now!!), but when it came time for the box to listen to the AMPR RIP
broadcasts, I never did see anything. The notes say to let it sit for a
little bit.. I let it sit for two days before I got back to it! :)
So.. I haven't been diligently working on it, that's on me. But something
seemed to go awry. Dangit. That's on me toooooo!! :(
I'll try and get back to it over the next few days, and report back again.
But if there are any ideas off the tops of ones heads.. Hit me with your
best shot.. Fire Away!!
Thanks.
--
Rod Ekholm
kc7aad(a)gmail.com
Yes, but since the machine is a standard Ubuntu Linux Server machine,
I'm not sure how an OVA will help you. You still have to assign your IP
addresses, turn on routing, etc. per the instructions in the Wiki.
In the time it would take you to transfer it the file, you could simply
have the same thing by running the ISO on a fresh VM.
Are you having issues with setup?
73,
Lynwood
KB3VWG
Has anyone built an OVA of a VM used for an AMPR Gateway yet? Or has anyone
Exported their local VM that they would be willing to share?
*Disclaimer:* Yes.. I realize it is easy to build a host(though my attempt
so far has failed). But If someone has already put in the work to build a
VM, I'm willing to piggyback in their expertise in what they've built.
Thank you!!
--
Rod Ekholm
kc7aad(a)gmail.com
> two ways to solve this as well.
> 1. NAT the 44. address out the public internet. That is what I am doing
> here.
That only works when you have made special arrangements (policy routing)
to make sure the Echolink traffic is ALWAYS sent to the NAT device and never
routed directly. See what I explained to Gustavo.
> 2. have the server have two NIC cards. One with a 44 address and the
> other a local non-routable which is then NATed ouot your public internet IP.
That does not require 2 cards (you can put 2 addresses on 1 card), and it is
basically the same as the policy routing method, in this case using the IP
address as the base for the policy routing.
In practice it can be more difficult to implement because you need to force
the Echolink application to bind to the correct card address. Fortunately
Svxlink can do that, but many other programs cannot.
Rob
> The fact is that, actually the repeater is networked to the EchoLink
> server and this can be obtained ONLY by using the commercial
> IP number, i.e. IP address 79.47.199.234.
Look at our repeaters, e.g. PI2NOS
It is registered on the Echolink system using its own address 44.137.72.130 (pi2nos.ampr.org).
Therefore this problem does not occur here.
> the incoming IP results 44.137.41.97; so I understand that the
> internet server act as the real gateway in a similar way as our
> ampr.org gateways. It function very OK!
Yes, for "normal traffic" it works OK. But not for Echolink.
This is because Echolink has a directory server that registers your repeater
by IP address, and this address does not match the actual address.
When you get connected by someone from plain internet, it works OK because the route
back is through the same NAT router, where you have defined port forwarding for the
5198 and 5199 ports, and the users sees the same translated address as the Echolink system
registered.
However, when I connect from my address 44.137.41.97, the repeater or another part of
the system thinks it is being clever and routes the traffic through a IPIP tunnel,
the address does not get translated, and the connection fails.
The quick way to solve it is to give your repeater some RFC1918 address (10.x.x.x, 192.168.x.x)
so its traffic is always forced through the NAT router. Alternatively, you can setup some
policy routing so the Echolink traffic is always sent to the NAT router, not routed directly.
Then you can still use AMPRnet on the same computer for other things.
The way we solved it here is by applying for BGP routing of our subnet, so our net-44 traffic
is routed directly on internet and it is no problem to run an Echolink repeater on it.
(the subject of this thread: will routing through UCSD cause problems with VoIP. yes it will,
but we don't route through UCSD so we don't have that problem)
Rob
> Subject:
> Re: [44net] AMPRNET katency in VOIP connections ?
> From:
> "'Gustavo Ponza'" <g.ponza(a)tin.it>
> Date:
> 05/30/2016 07:12 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> On 05/30/2016 05:55 PM, Rob Janssen wrote:
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>>> I don't know how they do the job... but as all of you can see,
>>> also iPAD/iPhone can do it by using my small ampr.org facility :)
>>
>>> 73, gus
>>
>> Which repeater is this log from? It is on an AMPRnet address?
>
> It is from IR0AAB (ER-IR0AAB). It is on (or better, it should be on)
> 44.134.32.240/44.208.58.1
Ok but it registers on Echolink using IP address 79.47.199.234
So there is some NAT between its 44-address and internet!
This is no problem as long as the repeater always routes its traffic via that NAT,
but in practice those operators often route 44-net traffic directly and then it does not work.
I have tried to connect it from my 44-address and indeed it fails!
I connect to the node on address 79.47.199.234 as directed by the Echolink server,
and I get replies from 44.134.32.240:
Spurious audio packet received from 44.134.32.240
So I cannot connect that repeater from AMPRnet.
Rob
> Subject:
> Re: [44net] AMPRNET katency in VOIP connections ?
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 05/30/2016 06:25 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> As far as I know there are no active AMPRNet users in Asia.
> - Brian
>
> On Mon, May 30, 2016 at 05:55:47PM +0200, Rob Janssen wrote:
>> >It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand)
>> >could setup another set of Echolink relays. This requires a Linux machine
>> >with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet.
A host somewhere in a datacenter with a /28../24 subnet would be OK as well.
There are a couple of Echolink proxies in the far east, e.g. from JH1PGO but I have been unable
to contact the operator.
Rob
> I don't know how they do the job... but as all of you can see,
> also iPAD/iPhone can do it by using my small ampr.org facility :)
> 73, gus
Which repeater is this log from? It is on an AMPRnet address?
Those 44.137.75.24x addresses are our Echolink relays that serve the
mobile users in this part of the world.
It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand)
could setup another set of Echolink relays. This requires a Linux machine
with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet.
When some 20-200 addresses are available, it can also run Echolink proxies.
A combined proxy/relay server written in C (1000 times more efficient than the
echolink.org Java version) is available on my site:
http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz
Bonus points when you find the race condition that makes it sometimes leak proxy
instances when it is rapidly scanned by a web proxy scanner :-)
Rob
