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
Very TNX Rob. I conceptually understood the possible scenarios and I'll seek the method to force the 192.168.x.x or the 10.x.x.x towards the repeater...
However it seems to me that the BGP routing of the 44.x.x.x IPs remains the best and clean solution for any kinda problems.
So, coming back to the original item on the subject: if, at least, my main server IPs 44.134.32.240 and 44.134.32.233 were full published and routed over the internet by UCSD any problems here should magically solved :)
73, gus
On 05/31/2016 11:34 AM, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
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
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Tue, May 31, 2016 at 06:11:26PM +0200, 'Gustavo Ponza' wrote:
So, coming back to the original item on the subject: if, at least, my main server IPs 44.134.32.240 and 44.134.32.233 were full published and routed over the internet by UCSD any problems here should magically solved :)
They are, in fact, published and routed by UCSD, but there are two problems with doing Echolink over that connection: one is that the gateway is in San Diego, so packets from Italy have to travel to the USA and back again to go a few km, and also the gateway at UCSD is not a high bandwidth device, so there is considerable delay and jitter in packets going through it. These delays and jitter are insignificant for things like SMTP and other non-interactive uses, but cause disruption on time-critical connections like VOIP. - Brian
So, coming back to the original item on the subject: if, at least, my main server IPs 44.134.32.240 and 44.134.32.233 were full published and routed over the internet by UCSD any problems here should magically solved :)
They are, in fact, published and routed by UCSD, but there are two problems with doing Echolink over that connection: one is that the gateway is in San Diego, so packets from Italy have to travel to the USA and back again to go a few km, and also the gateway at UCSD is not a high bandwidth device, so there is considerable delay and jitter in packets going through it. These delays and jitter are insignificant for things like SMTP and other non-interactive uses, but cause disruption on time-critical connections like VOIP.
- Brian
Very clear, TNX!
73, gus
On 5/31/2016 2:23 PM, 'Gustavo Ponza' wrote:
So, coming back to the original item on the subject: if, at least, my main server IPs 44.134.32.240 and 44.134.32.233 were full published and routed over the internet by UCSD any problems here should magically solved :)
They are, in fact, published and routed by UCSD, but there are two problems with doing Echolink over that connection: one is that the gateway is in San Diego, so packets from Italy have to travel to the USA and back again to go a few km, and also the gateway at UCSD is not a high bandwidth device, so there is considerable delay and jitter in packets going through it. These delays and jitter are insignificant for things like SMTP and other non-interactive uses, but cause disruption on time-critical connections like VOIP. - Brian
Very clear, TNX!
73, gus
two ways to solve this as well.
1. NAT the 44. address out the public internet. That is what I am doing here. 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.
73 leon WA4ZLW
So, coming back to the original item on the subject: if, at least, my main server IPs 44.134.32.240 and 44.134.32.233 were full published and routed over the internet by UCSD any problems here should magically solved :)
They are, in fact, published and routed by UCSD, but there are two problems with doing Echolink over that connection: one is that the gateway is in San Diego, so packets from Italy have to travel to the USA and back again to go a few km, and also the gateway at UCSD is not a high bandwidth device, so there is considerable delay and jitter in packets going through it. These delays and jitter are insignificant for things like SMTP and other non-interactive uses, but cause disruption on time-critical connections like VOIP. - Brian
Very clear, TNX!
73, gus
two ways to solve this as well.
- NAT the 44. address out the public internet. That is what I am
doing here. 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.
73 leon WA4ZLW
TNX Leon!
Unfortunately I tried both methods in the recent past but without success. One (or the only) of the major handicaps is due to the fact that several examples appeared are on the format of debian/ubuntu platforms, and so they're not recognized on my slackware platform and, perhaps for my scarce skill, I couldn't address the right setups here.
73, gus
-
'Gustavo Ponza' -
Brian Kantor -
Leon Zetekoff -
Rob Janssen