Getting this message. (52883@radio-secure’ does not exist). In the AST Log, where should I look to fix this? Have a cloned image that has been reconfigured for another node (55588).
Thanks in advance for your help on where to look.
First,
could you say what node 52883 is to you.
A local node on the same server ?
A node on some other server you connect to ?
Trying to establish the source to know where to look.
If it is one of your own nodes the stanza is defined in the extension.conf…
[radio-secure]
exten => 1999,1,rpt,1999
So, I will add more background here. I am cloning a current rPi node (52883) and switching it to another node number (55588). I have updated, cleaned up all the *.conf files to reflect the new node number however, when I did some off air testing I get this message: “[Jan 8 15:55:04] NOTICE[402] chan_iax2.c: Rejected connect attempt from 47.184.184.35, request ‘52883@radio-secure’ does not exist”
I guess I need to grep the whole of the SD card to see if there is some other place I may have missed. The gsm was updated and reflects the new call sign for this rPi instantiation.
I was also going to download the source code and look at the chan_iax2.c file to see where the message gets its data from if there was not an easy answer of something I might have overlooked.
Thanks.
Can you paste a copy of your rpt.conf file of all entries under
[nodes]
and all entries under [radio-secure] in extensions.conf
and your entries in iax.conf for node registration (mask passwords)
Here you go Mike. I appreciate the assistance.
rpt.conf [nodes]
[nodes]
; Note, if you are using automatic updates for allstar link nodes,
; no allstar link nodes should be defined here. Only place a definition
; for your local (within your LAN) nodes, and private (off of allstar
; link) nodes here.
55588 = radio@127.0.0.1/55588,NONE
1999 = radio@127.0.0.1/1999,NONE
extensions.conf
[radio-secure]
exten => 55588,1,rpt,55588
exten => 1999,1,rpt,1999
[radio-secure-proxy]
exten => 55588,1,rpt,55588|X
exten => _0X.,1,Goto(allstar-sys|${EXTEN:1}|1)
iax.conf
register => 55588:yyyyyyyyyyyy@register.allstarlink.org
;register => xxxxx:yyyyyy@register.allstarlink.org
Thanks for putting all the info up I asked for. Makes this quicker and easier.
So, don’t see what I was looking for.
But, should have caught this in the beginning.
Since you ‘cloned’ your image, you cloned all temp entries and active PID references.
So, I am trying to figure out where those might be stored.
Never had to hit this one before. But I knew they existed.
You might try one thing while I think on it some more.
delete entries in /tmp and issue reboot immediately after
Doubting any other temps that asterisk uses would hold such info but not sure.
Don’t know how good you are with linux but looking at active processes may shed a clue
ps -aux | less
But I think we would have to look in a asterisk log for the info where the entry is located.
/var/log/asterisk/messages, -so take a peek
Perhaps someone who has a better answer will chime in.
I dumped the tmp directory, there really isn’t much in there. There is an asterisk_version file and an iplog.txt file then a system directory that contains a temp file. I did a recursive grep in the temp directory looking for 52883 as text and came up with nothing. However, that doesn’t mean that old node number isn’t stored as an integer to save some space. I did a capture of all the processes (see attached pdf). I will have to take the rPi back out to the shack and try again with the URIx I have out there with the repeater shooting in to a dummy load (that is how I am testing before I turn this SD card over to him to make sure things work).
processes.pdf (39.4 KB)
Thanks for helping.
Please post the AST log leading up to and after the error.
I would also grep the whole /etc/asterisk directory for 52883
I have grep’d all of etc/asterisk and found bupkiss now. Will do it again to double check.
I’ll post the full ast log after I run another test based on Mike’s recommendation of cleaning up too however, I probably won’t get a chance to do that until Wednesday.
Double checked my grep results (sudo grep -rn 52883 * . *) and it returned nothing.
Will retest with the URIx tomorrow afternoon, time permitting.
Thanks,
edited to show the star dot star since this forum tool only shows a dot for some reason when I didn’t have the spaces between the star and the dot like this .
For one other tmp section you can delete.
/var/spool/asterisk/tmp
It should likely be empty so delete it all and reboot after.
OR
Rename or move them so we can examine them later and reboot.
I have known that the system uses some kind of temp storage since 2014 when I was experimenting with various SSD’s on a couple of Atom PC boards and after cloning the drive, it would make connections that were made the last time it was running.
So I am a bit interested where this is actually hiding. But it may not be worth the time, as many of these things are often like that.
If you want to take the short cut, start with a new image and move files that you back-up beforehand. Mainly in the asterisk dir. And perhaps other setup files if you have installed other stuff, but i would do a fresh install of programs you want to add. When you move them back, you may need to set permissions and ownership depending on your methods. The issue is not likely in your setup files. But could be as it’s hard to envision every possibility.
Looking in the asterisk log would be the next step if you want an answer. I’m not sure we will find it but it is the next step. I am surprised that grep did not find that in the file unless you never set it to look there.
/var/log/asterisk
But you want to see entries that came before the call in question and some data just after.
Personally, I use winscp for sftp and it’s just easier to open the log and search within for me.
My typing skills have gotten bad as I type all the keys but they come out in the wrong order. Brain messed-up from age? LOL
Mike, I have chosen to spend this afternoon doing a new, clean image. I went through the setups and the only thing I copied were the simpleusb* conf files so I didn’t have to guess at that again, although I could have looked at my 52883 node documentation where I keep a snapshot of the Supermon SimpleUSB-Tune-Control.
I can’t test this clean image until Friday and will let you know. I should have done this from the start maybe. Oh well, I got to sharpen my linux cli skills some though 
I will post the results of my Friday hot test (using a dummy load on my repeater since the callsign/frequency allocation is different than the pair I have).
Mike, with a ‘clean image’ I no longer get the “chan_iax2.c: Rejected connect attempt from 47.184.184.35, request ‘52883@radio-secure’ does not exist”.
I know have another problem that I will search the community for before I post anything (being told that node 55588 is not a valid node , but it shows up on the active node list).
Thank you for the help.
Well, I would still call that progress -wink
Where are you seeing the message that it is not a valid node ?
Not sure you will find that one in search but don’t let me discourage you from it.
I am seeing it reg’s as
55588=radio@47.186.79.50:4569/55588,47.186.79.50
Should be connectable to the outside world if you have it ported through your router…
which brings to mind that you should not be running both Pi’s in the same network with the same iax port.
Why not change this one to 4570 and route it as well in your router (if you are running both Pi’s).
If two are answering for the same port, confusion and misrouting will occur.
(just guessing)
The invalid node is during the first part of calling the 763-230-0000 when the voice asks you to enter a node to connect to.
I didn’t think about port contention. Let me try that. Appreciate the help and sorry to be such a pest with these issues.
Thank you again.
Now that I think of it I am not running the two rPi’s at the same time when testing. I get that invalid node message on the phone even when my 52883 node is off line. I will still try changing the port though just to make sure there is nothing residual in my network causing issues.
OK… just catching up.
There are several things that need to be set in your files I think.
I don’t do this as I have my own did’s for my nodes. So looking at the files for a clue…
extensions.conf
; Comment-out the following clause if you want Allstar Autopatch service
[pstn-out]
exten = _NXXNXXXXXX,1,playback(ss-noservice)
exten = _NXXNXXXXXX,2,Congestion
; Un-comment out the following clause if you want Allstar Autopatch service
;[pstn-out]
;exten = _NXXNXXXXXX,1,Dial(IAX2/allstar-autopatch/${EXTEN})
;exten = _NXXNXXXXXX,2,Busy
Seems to me there was something else in another file but it escapes me. Try a look at this.
Perhaps that is the issue. Maybe someone who knows more will chime in on this if your still stuck, let us know.
I think the error was related to the allstar phone link.
That is why it was present on other clean installs.
The error as It appears, was the lack of a proper connection ASL-Phone> node. The node was not set-up for the connection. or yet ? It would come in on radio secure context.
We would have not found that the way we were looking. A look in the logs for the exact lines would have showed something I suppose.
A lesson learned for me as well.
Does that make sense to you now? I may not have said it very well.
A final follow up on this. I had implemented a completely new instantiation of Hamvoip for my friend. While testing in the repeater rPi I have access to I could see the node active on the node list, that was good. I was still getting the “52883@radio-secure’ does not exist” message in the logs. Knowing this was a clean installation, having never been associated with our club node, I began to wonder if there was some association at the main allstarlink server with my global IP 47.etc. I completed what testing I could locally and then delivered the SD cards to my friend. He installed in his rPi and everything came to life. He could connect to our 52883 to monitor and we tested connecting the two nodes for transmit successfully. Those successful tests bolster my theory of IP binding. It may be part of a TTL (Time To Live) factor at the server that I didn’t wait long enough before trying to do testing. Honestly, I don’t know thus me stating this as a theory because I don’t have data to prove anything.
The only thing left to troubleshoot with my friend is why when we dial in via phone we always get a busy signal.
I have learned a lot during this process for sure.