Problem #1
I’m getting this continuous stream of warnings in the ASL log:
[2025-03-24 09:01:12.988] WARNING[5166]: app_rpt/rpt_manager.c:317rpt_manager_do_xstat: Channel USRP/192.168.0.245:34001:32001 does not exist, cannot access variables
[2025-03-24 09:01:13.694] WARNING[5166]: app_rpt/rpt_manager.c:317rpt_manager_do_xstat: Channel USRP/192.168.0.245:34001:32001 does not exist, cannot access variables
I have researched for days, and can’t figure out why. The 192.168.0.245 IP is DVswitch, and the ports are correct.
I don’t know if this is related to an initial connection problem I’m having, or just a red herring.
Problem #2
My connection problem seems like a simple config setting problem, but I can’t find it. I am doing this: ASL → DVswitch → YSF and vice versa.
This works perfectly if, and only if, the ASL PTT happens first. The communications work perfectly in both directions. …but after IDLE for a few minutes, a PTT from YSF does not play on ASL. If I key ASL, it seems to wake up, then the YSF communication comes through. I verified that the transmission from YSF → DVswitch → “the ASL raspberry pi” is making it there, but ASL is not taking the traffic. (using ASL3)
I have already ruled out DVswitch being the problem. The communication from DVswitch is making to the ASL computer, but the ASL software isn’t talking the call, until I PTT ASL, then the communication works flawlessly in both directions.
My understanding was the nodes (1995) rxchannel is supposed to connect to the target application, which is DVswitch on 192.168.0.245. Am I wrong about that?
The error message Channel USRP/192.168.0.245:34001:32001 does not exist,
is telling you that the set path for the connection can not be reached.
Config error or network issue depending on your setup.
I would have no clue as to what is correct because you have not stated where these components are in relationship to each other.
This I why I am not sure if problem # 1 and 2 are related. If I have ASL, DVswitch, YSF connection configuration problems, it would never work. It currently all works in both directions, if initiated by an ASL PTT.
This is my component setup:
192.168.0.244: YSF Refector
192.068.0.243: ASL
192.168.0.245: DVswitch
All ports are open and able to communicate through at all times. It’s just that ASL is not answering after a few minutes of idle time. Wireshark, running in the ASL RaspPi is telling me the communication from the DVSwitch analog bridge is making it in. ASL is just not answering until keyed.
Sounds like the target is not receiving/replying to request.
is the firewall on that box open to those ports? It’s not an internal inbound address.
should allow anything within your NAT, inside your NAT anyway.
allow 192.168.0.0/24
In any case, you need to look at analog bridge setup on that dvswitch computer.
That is what USRP is connecting to, or trying to.
Perhaps start with the AB log to see if it is receiving the request and then the error.
Make sure the port numbers are correct. TX>RX - RX>TX
You have a communication issue between usrp and dvswitch AB.
I hope you do know that only one communication with one usrp port can happen.
You can’t share a usrp connection. Start another instance.
But you could use ‘analog reflector’.
I have no firewalls running at all. EDIT: Wrong. Just found the built-in one controllable through the local ASL3 web portal. Problem Solved.
I have “tail -f” every log in ASL and DVswitch
I have verified all the ports and paths
I have used Wireshark to verify the actual network traffic. I can see the traffic from DVswitch making into the ASL pi, but the ASL app is not answering, until ASL is PTT’s, then it accepts all of the traffic from DVswitch’s Analog_Bridge.
I was wrong.
I had several times checked for every linux firewall I have ever heard of, but just found the one in the ASL3 local web portal. I don’t think I have ever been in that web portal, possibly during the initial setup, something rings a distant bell about it. I opened port 32001 and the communication works.
I’m still having that rxchannel warning message flood in the asterisk log, but the important stuff works.
Folks often overlook the idea of opening ports on external called servers because for the most part, when connecting internal, you don’t need to.
The easiest way is to allow all ports to each machine within/from your NAT.
allow 192.168.0.0/24 (in your instance)
This just allows access between machines that are behind the router on any port.
But you need to set it on all machines behind the router.
It does not change external exposure.
There were some updates to usrp I think in later asl revisions so I would make sure you are up-to-date. Not sure if that other error was related.
I have two nodes on the server. One is the repeater node (62320), the other is the node (1995) I use for the DVswitch hub (with the rxchannel/USRP connection)
Supermon was monitoring both nodes. I haven't had the time to figure out exactly what communications under the hood of that is the root problem, but I appears supermon monitoring the node with the USRP channel causes the warnings. Somebody with more experience may know why this happens. I'll research.
The firewall on the ASL3 appliance is the standard Firewalld system. The Cockpit web interface is standard to Cockpit and manipulates the Firewalld system. The firewall is also manageable with the firewall-cmd. You can see the "final" configuration using nft list table inet firewalld.
Thank you. I didn’t notice the Linux splash screen mentioning firewalld until late in the game. I deal with so many Linux systems every day I’ve got into the habit of ignoring the splash screens with logos and whatever else. I haven’t dealt with firewalld in so many years, I completely forgot about that one, when I was searching for firewalls.