Troubleshooting MTArsWatcher
Posted: Sun Apr 03, 2022 9:24 am
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!
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!