Hi Will,
I recently downloaded MTArsWatcher to try to get some insight on ARS requests on my radio network, and it's not behaving the way I might expect it to, hoping you can offer some insight. Specifically, the application never seems to see any reply traffic from the radio network no matter what I try.
I consistently get the message "EArsStartFails" when I start the ARS listener, whether or not "Run as ARS Server" is checked. This log message is making me think that the listener is failing consistently, but I don't have a sense as to why that may be. I get the same log notice whether or not I run the application as Administrator.
It seems that no matter what settings I change in the tool, the tool will generate ARS packets while I have "ARS Listen" set active, but does not appear to see the reply from the radio network and populate the active subscriber table. I have confirmed this by using Wireshark to observe the network interface. Here is what I see happen on the wire when I use MTArsWatcher to generate an ARS query response from a radio:
- I set the correct ARS Listen Server IP and port. I do (or don't; same result) check "Run as ARS Server". I click "ARS Listen". The log shows two log lines, first is the ARS Listen starting on the selected IP/port, second line is the "EArsStartFails" message.
- I populate the Radio ID, click "ID 2 IP" to generate the radio's IP. Then I click "Query" to send an ARS query.
- MTArsWatcher will generate a query packet, and the destination radio does reply back to the network with its status. So the ARS packet does seem to reach the radio. The Motorola DDMS application logs confirm that it sees the radio's ARS acknowledgement come back, so other applications on this system are able to see the reply traffic, but MTArsWatcher does not seem to see it. MTArsWatcher is watching on the same port that the DDMS sees the ARS traffic on.
I did take the additional troubleshooting step of confirming that Windows Firewall allows MTArsWatcher to receive all TCP/UDP traffic from all sources in the Inbound Rules, just in case the firewall was interfering. Allowing inbound traffic from NAT sources was also set. This does not seem to have made a different in MTArsWatcher's ability to receive radio replies and populate the ARS subscriber table.
Any advice you could offer would be fantastic. Thank you for making these diagnostic tools available to the community, they are a lifesaver when you need them!
Troubleshooting MTArsWatcher
-
- Posts: 3
- Joined: Sun Apr 03, 2022 8:45 am
Re: Troubleshooting MTArsWatcher
Quick update here. After having to write out the problem description, I realized that there might be some contention on port 4005 with the Motorola DDMS application and MTArsWatcher. It now looks like this may indeed be the case. When I killed the DDMS and stopped the service, MTArsWatcher was able to succeed when starting up the ARS listener, both in and out of server mode.
Then I tried letting MTArsWatcher run first, as a listener only, and then brought up DDMS after that in active mode, so it is fulfilling the ARS server function. This combination seemed to work as expected, for a couple of minutes. At first I saw the DDMS doing what I expect it to in the logs, and MTArsWatcher was able to start the listener successfully and see registrations come across the wire. But then after about five minutes elapsed, I saw via Wireshark that radios on the system were starting to send and repeat ARS registrations approximately every minute, and the reason they kept doing this is because they were not receiving ACKs from the DDMS ARS server. As soon as I closed MTArsWatcher, DDMS was able to send ACKs to the radios. So it appears that even in listen only mode, there is contention on port 4005 between DDMS and MTArsWatcher, regardless of startup order.
Are there any diagnostics I can run to see if this is the Motorola software behaving badly with the port registration, or do you think there might be changes that could be made to MTArsWatcher so that it can run successfully in listen only mode when another application already has port 4005 bound? In my system, DDMS is currently the ARS server, and is always going to start in active mode on startup, which means MTArsWatcher won't be able to "get there first" to listen cleanly. But based on my testing, it doesn't look like MTArsWatcher can even listen cleanly without impeding the DDMS ARS server's ability to send traffic back to the radio network.
Thanks for taking the time to read all of this![Smile :)](./images/smilies/icon_e_smile.gif)
Then I tried letting MTArsWatcher run first, as a listener only, and then brought up DDMS after that in active mode, so it is fulfilling the ARS server function. This combination seemed to work as expected, for a couple of minutes. At first I saw the DDMS doing what I expect it to in the logs, and MTArsWatcher was able to start the listener successfully and see registrations come across the wire. But then after about five minutes elapsed, I saw via Wireshark that radios on the system were starting to send and repeat ARS registrations approximately every minute, and the reason they kept doing this is because they were not receiving ACKs from the DDMS ARS server. As soon as I closed MTArsWatcher, DDMS was able to send ACKs to the radios. So it appears that even in listen only mode, there is contention on port 4005 between DDMS and MTArsWatcher, regardless of startup order.
Are there any diagnostics I can run to see if this is the Motorola software behaving badly with the port registration, or do you think there might be changes that could be made to MTArsWatcher so that it can run successfully in listen only mode when another application already has port 4005 bound? In my system, DDMS is currently the ARS server, and is always going to start in active mode on startup, which means MTArsWatcher won't be able to "get there first" to listen cleanly. But based on my testing, it doesn't look like MTArsWatcher can even listen cleanly without impeding the DDMS ARS server's ability to send traffic back to the radio network.
Thanks for taking the time to read all of this
![Smile :)](./images/smilies/icon_e_smile.gif)
- Administrator
- Site Admin
- Posts: 381
- Joined: Mon Jul 21, 2014 5:48 am
Re: Troubleshooting MTArsWatcher
Hi TrboTester,
Ensure MCDD - Multi Channel Device Driver is not running!
IIRC DDMS performs the same service as MTArsWatcher.
All the Motorola Digital services use UDP/IP - so although either app can transmit on the nominated UDP port - only 1 x App CAN receive the responses.
cheers
Ensure MCDD - Multi Channel Device Driver is not running!
IIRC DDMS performs the same service as MTArsWatcher.
All the Motorola Digital services use UDP/IP - so although either app can transmit on the nominated UDP port - only 1 x App CAN receive the responses.
cheers
Geriatrics Generate Methane.
Grafitti Clifton Hill 1974
Living proof 2021
Grafitti Clifton Hill 1974
Living proof 2021
-
- Posts: 3
- Joined: Sun Apr 03, 2022 8:45 am
Re: Troubleshooting MTArsWatcher
Thanks for the reply. I confirmed that MCDD does not appear to be installed or running on this machine. I have NAI Data entitlements available on the repeater so we use MNIS to tunnel packets to/from the radio network, obviating the need for control stations or MCDD for data.
Am I correct in presuming that MTArsWatcher does not implement the Watcher Interface functionality? I wouldn't necessarily expect it to do this, since it's just intended as a test utility. I'd also be curious to know if the full TransTRBO software does implement the watcher interface.
Thank you again for the help!
I believe the Motorola DDMS agent is a superset of the ARS functions, it implements ARS for radio subscribers but it also mediates subscribing applications (like MNIS) via a "Watcher Interface" on port 3000, per the DDMS help files.Administrator wrote:IIRC DDMS performs the same service as MTArsWatcher.
Am I correct in presuming that MTArsWatcher does not implement the Watcher Interface functionality? I wouldn't necessarily expect it to do this, since it's just intended as a test utility. I'd also be curious to know if the full TransTRBO software does implement the watcher interface.
Thank you again for the help!