• To anyone looking to acquire commercial radio programming software:

    Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.

    If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.

    To obtain Motorola software see the Sticky in the Motorola forum.

    The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.

    For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).

    This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.
  • Effective immediately we will be deleting, without notice, any negative threads or posts that deal with the use of encryption and streaming of scanner audio.

    We've noticed a huge increase in rants and negative posts that revolve around agencies going to encryption due to the broadcasting of scanner audio on the internet. It's now worn out and continues to be the same recycled rants. These rants hijack the threads and derail the conversation. They no longer have a place anywhere on this forum other than in the designated threads in the Rants forum in the Tavern.

    If you violate these guidelines your post will be deleted without notice and an infraction will be issued. We are not against discussion of this issue. You just need to do it in the right place. For example:
    https://forums.radioreference.com/rants/224104-official-thread-live-audio-feeds-scanners-wait-encryption.html

IP Site Connect

Status
Not open for further replies.
Joined
Dec 2, 2016
Messages
11
Location
Kentucky
#1
New to the forums! I have a problem with an IP Site Connect setup that is driving me nuts. I have 2 sites. One site has the Master, and 1 Peer. The Peer is actually at another location, but is connected to the main site via a 5.i Ghz Microwave link. Essentially it is plugged into the same switch as the Master. Both Master and Peer are hooked into an HP 1920 switch. The switch is connected to the outside world via a 4G cellular modem. The other site is a Peer, and is sitting inside of a broadband connection. It has a static, public facing IP, as does the cell modem at main site. I have been over and over all of the IP related configurations, and cant find a flaw there. Right now the Master is sitting in a DMZ to eliminate any port forwarding issues until this is figured out. The issue is that the Peer at the end of the 5.8 link can talk to the Master just fine. The offsite Peer can talk to the Master as well. I can not get any Peer to Peer traffic. From the Master i can not see any information about the Peers that it is talking to. The Firmware on the Master and the Peer that are on the same LAN have an older firmware, but are the same. The offsite Peer has a newer problem. Am i dealing with a firmware issue? Possible a Bad Master? All repeaters are MTR3000. Anyone dealt with this symptom?
 
Joined
Dec 2, 2016
Messages
11
Location
Kentucky
#2
Sorry for the typos guys. Using phone only today. The part where my says "The offsite Peer has a newer problem" should say that the offsite peer has a newer firmware.
 

N1GTL

Member
Database Admin
Joined
Jun 14, 2005
Messages
706
Location
CT
#3
Have you used RDAC pointed at the master to ensure the peer is being recognized? A 2 site IPSC system is about as basic as it gets.


Sent from my iPad using Tapatalk
 
Joined
Dec 2, 2016
Messages
11
Location
Kentucky
#4
Yes sir. I actually just spent several hours RDACing remotely offsite, with a helper onsite with RDAC and CPS, trying configuration changes. I have exhausted manipulating networking related changes. We added an additional Peer at the Master location, because we couldn't easily make changes to the peer at the end of the 5.8 link. Through RDAC locally, it shows the Master and Both Peers that are on the same network. Remotely from my RDAC, I can only see the master. The Master just refuses to share what it knows about the Peers with anything outside the local network. I also added another offsite peer in another city. So, 2 differnet cities can see and talk to the Master, but not the Peers inside the network, nor can the 2 offsite peers talk to each other. I'm running out of options...
 
Joined
Aug 19, 2003
Messages
8
#5
Just thinkling out loud here, but things you need to check on each repeater is to make sure each peer has a unique UDP port. The master UDP has to be the same in all repeaters (see Link Establishment in CPS). And also make sure each repeater has a unique Radio ID (see General Settings in CPS)

Good Luck,
Bob
 
Joined
Dec 2, 2016
Messages
11
Location
Kentucky
#6
Thanks for the reply Bob, and you N1GTL. I have checked and re-checked all of those settings. Every repeater has unique UDP port, and radio ID. All peers point to the same Master UDP port. I am really thinking this issue is pointing @ the cell modem/NAT. I think it is altering the source IP and port information in the packets, but haven't been able to confirm.

N1GLT. I looked back at your thread from 2014, and it seems that my problem is almost the inverse of the problem you were having. The solution for you was pointing the Master IP on the Master itself at the WAN IP. I really thought that was going to fix the issue, but it did not. I am grabbing the cell modem from the site today so that i can set this whole thing up on the bench and replicate the exact onsite scenario. Im going to add a dedicated router behind the cell modem, and pass the WAN IP to it, relieving the cell modem of its NAT duties and see what happens. If anyone has any further ideas, or needs more info about the setup, I'm all ears.
 

N1GTL

Member
Database Admin
Joined
Jun 14, 2005
Messages
706
Location
CT
#7
Just thinkling out loud here, but things you need to check on each repeater is to make sure each peer has a unique UDP port. The master UDP has to be the same in all repeaters (see Link Establishment in CPS). And also make sure each repeater has a unique Radio ID (see General Settings in CPS)

Good Luck,
Bob
Not true. I have at least 6 IPSC installs where all ports are left at 50000 and they work perfectly. Big M tech support keeps giving different answers on the topic but I can tell you with certainty they all work with the same port. You are correct in that you can use different UDP ports but it is not required. The same is not the case with Linked Capacity Plus. In that case, the ports need to be different.

Going back to RDAC, I'm not sure if you are running on open internet, private network, vlan, etc. I can tell you that when you run RDAC, you point it to the master and make sure you're using a different radio ID than any of the repeaters. You computer will talk to the master and get a list of the peer repeaters. RDAC will then try to contact each repeater individually, NOT through the master!!! The computer you are running RDAC on must be able to communicate with each peer directly on the specified UDP port. I'm guessing this is why you see both peers at the masters location but not remotely.

The issue you refer to in 2014 was an LCP system, not and IPSC.
 
Joined
Dec 2, 2016
Messages
11
Location
Kentucky
#8
Thanks for the input guys. After another 2 days of troubleshooting this system on the bench with some port mirroring and Wireshark, the issue is clear. The $700 cellular modem that was employed does not, and will not handle NAT Loopback. The Peers local to each other learn from the Master how to contact each other. The Master doesn't know their local IP, only the WAN IP they came through. So if Peer 1 tries to contact the other local Peer 2, it sends its packets to the WAN IP. The cell modem is incapable of redirecting this traffic back into the local network. I confirmed this by running to Walmart at grabbing a $35 Netgear WNR2000 that I know supports NAT Loopback. Instant success!
 
Status
Not open for further replies.
Top