[PHREAKNET-72] Incoming calls not progressing through IAX

Since rebuilding the server with all the required dependencies for Phreaknet, regenerating the keys and changing the API key I have not been able to receive calls for the Operator or between nodes. I have completed a Phreaknet verification which has determined that there is very little wrong that would stop the system from working. Please could you amend your records if necessary to reflect the new Server, which is using the same FQDN asteriskoc.ddns.net and the new IP is 216.144.233.142. I have completed the rebuild using the Phreaknet scripts available to me and notice that the verification.conf has the necessary changes about the RSA. I think it says that if I have used the Phreaknet script the other two changes will have been made. I have received this Warning about the incoming calls. NOTICE[822544]: chan_iax2.c:10360 socket_process_helper: Packet Decrypt Failed! If you are able to check my credentials are the same for you as for me I would be grateful. I noticed that since this morning some connectivity has been achieved like being able to get a different nodes DISA but it doesn't connect back to my switch. I have tried the DISA from C*Net and it also won't connect back to my server. Many thanks for your help with this. Paul

Comments

5/11/2026 12:26 PM — InterLinked

All the necessary changes that may be needed are self-service. Have you updated your server hostname if needed in the PhreakNet portal? (My Servers)

5/11/2026 3:02 PM — paulash134

Thank you for this information the server hostname on the server is the same, I changed the hostname to asteriskoc.ddns.net on the new server, I added it to the hosts list too. Is that where there may be a problem? I don't appear to be able to click on edit to change anything, which is why I added it to this message in case you needed to do anything.

5/11/2026 3:03 PM — InterLinked

That hostname resolves to 216.144.233.142, which you indicated is correct.
When did you change the hostname? Maybe it's DNS caching in play, what is the TTL on it?

5/11/2026 7:26 PM — paulash134

Many thanks for your response. I changed the hostname a couple of days ago. The TTL is only 60 seconds.
QUESTIONS:
asteriskoc.ddns.net, type = A, class = IN
ANSWERS:
-> asteriskoc.ddns.net
internet address = 216.144.233.142
ttl = 60

I turned on the IAX debug and got this from one of the calls

[May 11 23:29:02] Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: NEW
[May 11 23:29:02] Timestamp: 00008ms SCall: 04403 DCall: 00000 18.188.48.248:4569
[May 11 23:29:02] VERSION : 2
[May 11 23:29:02] CALLED NUMBER : 9805111
[May 11 23:29:02] CODEC_PREFS : (ulaw|alaw)
[May 11 23:29:02] CALLING NUMBER : 4447925999
[May 11 23:29:02] CALLING PRESNTN : 0
[May 11 23:29:02] CALLING TYPEOFN : 0
[May 11 23:29:02] CALLING TRANSIT : 0
[May 11 23:29:02] CALLING ANI2 : 0
[May 11 23:29:02] CALLING NAME : LANgham Exchange via ARTNVAAXCG0
[May 11 23:29:02] LANGUAGE : en
[May 11 23:29:02] USERNAME : phreaknet
[May 11 23:29:02] ENCRYPTION : 32769
[May 11 23:29:02] FORMAT : 4
[May 11 23:29:02] FORMAT2 : ulaw
[May 11 23:29:02] CAPABILITY : 12
[May 11 23:29:02] CAPABILITY2 : Unknown
[May 11 23:29:02] ADSICPE : 2
[May 11 23:29:02] DATE TIME : 2026-05-11 22:29:02
[May 11 23:29:02] VARIABLE : clidverif=20
[May 11 23:29:02] VARIABLE : nodevia=2311111
[May 11 23:29:02] CALLTOKEN : Present
[May 11 23:29:02]
[May 11 23:29:02] Assigned (0x7f3e5400ae20)clidverif to (0x7f3e5400ae2a)20
[May 11 23:29:02] Assigned (0x7f3e5400b2c0)nodevia to (0x7f3e5400b2c8)2311111
[May 11 23:29:02] Tx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: CTOKEN
[May 11 23:29:02] Timestamp: 00008ms SCall: 00001 DCall: 04403 18.188.48.248:4569
[May 11 23:29:02] CALLTOKEN : 51 bytes
[May 11 23:29:02]
[May 11 23:29:02] Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX Subclass: NEW
[May 11 23:29:02] Timestamp: 00027ms SCall: 04403 DCall: 00000 18.188.48.248:4569
[May 11 23:29:02] VERSION : 2
[May 11 23:29:02] CALLED NUMBER : 9805111
[May 11 23:29:02] CODEC_PREFS : (ulaw|alaw)
[May 11 23:29:02] CALLING NUMBER : 4447925999
[May 11 23:29:02] CALLING PRESNTN : 0
[May 11 23:29:02] CALLING TYPEOFN : 0
[May 11 23:29:02] CALLING TRANSIT : 0
[May 11 23:29:02] CALLING ANI2 : 0
[May 11 23:29:02] CALLING NAME : LANgham Exchange via ARTNVAAXCG0
[May 11 23:29:02] LANGUAGE : en
[May 11 23:29:02] USERNAME : phreaknet
[May 11 23:29:02] ENCRYPTION : 32769
[May 11 23:29:02] FORMAT : 4
[May 11 23:29:02] FORMAT2 : ulaw
[May 11 23:29:02] CAPABILITY : 12
[May 11 23:29:02] CAPABILITY2 : Unknown
[May 11 23:29:02] ADSICPE : 2
[May 11 23:29:02] DATE TIME : 2026-05-11 22:29:02
[May 11 23:29:02] VARIABLE : clidverif=20
[May 11 23:29:02] VARIABLE : nodevia=2311111
[May 11 23:29:02] CALLTOKEN : 51 bytes
[May 11 23:29:02]
[May 11 23:29:02] Assigned (0x7f3e5001db10)clidverif to (0x7f3e5001db1a)20
[May 11 23:29:02] Assigned (0x7f3e5001dba0)nodevia to (0x7f3e5001dba8)2311111
[May 11 23:29:02] Tx-Frame Retry[-01] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: ACK
[May 11 23:29:02] Timestamp: 00027ms SCall: 06370 DCall: 04403 18.188.48.248:4569
[May 11 23:29:02] Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: AUTHREQ
[May 11 23:29:02] Timestamp: 00017ms SCall: 06370 DCall: 04403 18.188.48.248:4569
[May 11 23:29:02] AUTHMETHODS : 6
[May 11 23:29:02] CHALLENGE : \x34\x34\x39\x32\x36\x34\x32\x39\x34
[May 11 23:29:02] ENCRYPTION : 1
[May 11 23:29:02] USERNAME : phreaknet
[May 11 23:29:02]
[May 11 23:29:02] Rx-Frame Retry[ No] -- OSeqno: 214 ISeqno: 132 Type: (22?) Subclass: 10
[May 11 23:29:02] Timestamp: 3914416196ms SCall: 04403 DCall: 06370 18.188.48.248:4569
[May 11 23:29:02] RD-Frame Retry[ No] -- OSeqno: 025 ISeqno: 243 Type: (21?) Subclass: 244
[May 11 23:29:02] Timestamp: 1026721161ms SCall: 04403 DCall: 06370 18.188.48.248:4569
[May 11 23:29:02] TE-Frame Retry[000] -- OSeqno: 001 ISeqno: 001 Type: IAX Subclass: VNAK
[May 11 23:29:02] Timestamp: 00036ms SCall: 06370 DCall: 04403 18.188.48.248:4569
[May 11 23:29:02] Tx-Frame Retry[000] -- OSeqno: 028 ISeqno: 204 Type: (47?) Subclass: 241
[May 11 23:29:02] Timestamp: 1550625512ms SCall: 06370 DCall: 04403 18.188.48.248:4569
[May 11 23:29:04] Tx-Frame Retry[001] -- OSeqno: 000 ISeqno: 001 Type: IAX Subclass: AUTHREQ
[May 11 23:29:04] Timestamp: 00017ms SCall: 06370 DCall: 04403 18.188.48.248:4569
[May 11 23:29:04] AUTHMETHODS : 6
[May 11 23:29:04] CHALLENGE : \x34\x34\x39\x32\x36\x34\x32\x39\x34
[May 11 23:29:04] ENCRYPTION : 1
[May 11 23:29:04] USERNAME : phreaknet
[May 11 23:29:04]
[May 11 23:29:04] Rx-Frame Retry[ No] -- OSeqno: 255 ISeqno: 155 Type: (20?) Subclass: 98
[May 11 23:29:04] Timestamp: 1549431762ms SCall: 04403 DCall: 06370 18.188.48.248:4569
[May 11 23:29:04] NOTICE[23091]: chan_iax2.c:10360 socket_process_helper: Packet Decrypt Failed!

5/11/2026 11:25 PM — InterLinked

Is the old switch fully decomissioned at this point? If not, it could be creating a conflict.
If you didn't migrate the keypair from the old machine and the new one is not successfully rotating, that could also lead to this scenario.

5/12/2026 6:29 AM — paulash134

I hadn't fully decommissioned the old switch. I have now tried to migrate the keypair but the result is the same. I will keep trying to resolve the issue. I have used Phreaknet trace to provide the log of the Packet Decrypt Failed scenario. Is there anything else I can check?
https://paste.interlinked.us/ou09gtsaj0.txt

5/12/2026 9:30 AM — InterLinked

As long as they are both online, they will probably try to rotate the RSA keypair on top of each other. You need to stop that.
Unload res_phreaknet on the old system for now, I think that should do the trick.
You don't need to migrate the keypair, just rotate it on the new system, make sure it succeeds, and then try calling 231-1111 to see if it pulls your new keypair on the FIRST try and the call succeeds on the SECOND try.
Make sure the IAX2 secret is correct/unchanged as well.

5/13/2026 2:07 PM — paulash134

Finally the IAX secret is the password for the line, which I hadn't appreciated and confused with the API, I am unsure why. Apologies for the run around.
Will the operator calls come back too or is that something you need to check. Many thanks for your patience and help.

You must be logged in to leave a comment.