[Home]

Summary:ASTERISK-21867: IAX Trunk Realtime - ipaddr gets set to (null) in iax_trunk table
Reporter:Silvio Pianese (silvio.pianese)Labels:
Date Opened:2013-06-06 00:04:15Date Closed:2018-01-02 08:30:28.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Addons/res_config_mysql Channels/chan_iax2
Versions:1.8.14.1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) Debug_ServerKo_1
( 1) DebugLog_ServerKo
( 2) DebugLog_ServerKo
( 3) DebugLog_ServerMaster
( 4) DebugLog_ServerMaster
( 5) iaxServerKo.conf
( 6) IaxServerKo.conf
( 7) iaxServerMaster.conf
( 8) iaxServerOk.conf
( 9) Log_13_06_2013_17_30_Afeter_Patch
(10) Log_17_06_2013_Applied_v2_Patch
(11) MyDebugLog_ServerOk
(12) NewLogDebugServerKo
(13) NewLogDebugServerKo
(14) rt_iax2_peer_update_fix_v2.diff
(15) rt_iax2_peer_update_fix.diff
(16) TableIAX_ServerKo.sql
(17) TableIAX_ServerOK.sql
Description:I have three systems connected via trunk in Asterisk iax, the configuration is the same in real time, the first two esegure register on Server A Server B and Server C.
On Server B, the operation appears to be correct and the command 'iax show peers' me correctly returns the value of the registration of Server A.
the problem is on Server C, although on Server A properly see through 'iax show registry' recording on Server C, the latter instead of using the command 'iax show peers' does not return a value, in the DB for a second field ipadd is filled with the ip of the Street Name Server A, and also the field regseconds has a value, but soon both fields back to zero.
the message I get from the console of the Server C, without enable debugging, is as follows:
WARNING [9572]: chan_iax2.c: 4409 realtime_peer: Failed to parse sockaddr '(null)' for ipaddr of realtime peer 'ipaddr'
Comments:By: Michael L. Young (elguero) 2013-06-11 09:36:01.458-0500

Please attach debug logs:

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Also, please attach your IAX configurations and the settings that are in the realtime db for each of the 3 peers.
By: Silvio Pianese (silvio.pianese) 2013-06-12 11:21:21.282-0500

Hi,
I'm sorry for the delay but are out of the office.
Please find attached all the logs in the system, I have divided this way:

Main Serer:
iax.conf = IaxServerMaster.conf
Log = DebugLogServerMaster

Serverclient (On this machine the recording is ok)
iax.conf = IaxServerok.conf
Log = MyDebugLogServerok
Table Mysql = TableIaxServerok.sql

Server Client (On this machine IAX connection ko)
Log = DebugLog_ServerKo
iax.conf = IaxServerKo.conf
Table Mysql = TableIAX_ServerKo.sql

I thank you a lot, let me know if you need more log / File.

Silvio
By: Michael L. Young (elguero) 2013-06-12 11:57:08.160-0500

Silvio,

For Server C (IaxServerKo.conf), you have rtautoclear turned on.  That is different than Server B (IaxServerok.conf).  That setting automatically clears out the realtime peer registration when it expires and waits until Server A registers again / makes a call.  That would explain why running "iax2 show peers" on Server C doesn't show any registration for Server A.

Now, why Server C is not allowing Server A to register to it again, I am not sure.  You would need to turn on full debugging on Server C.  The current debug log that you uploaded was not a full debug and has only verbose messages; I didn't see any debug messages.  We would need to see the debug logs from the beginning on Server C... when the peer registered, cleared out and then subsequent attempt to make a call.

So, I think you have two choices.  Turn off rtautoclear and see if that fixes it.  Or we debug Server C and see what is happening to the registration and why it is not allowing Server A to re-register.
By: Silvio Pianese (silvio.pianese) 2013-06-12 13:07:53.991-0500

Hi Michael,
I changed rightly the field you indicated in the annex to find the new file iax, but the result does not change.
in effect on the DB I still see a change in the field regseconds that is set to zero (registration not working).
Please find attached the new Debug, I hope that this time may contain some element to analyze the problem.
thanks
Silvio
By: Michael L. Young (elguero) 2013-06-12 13:16:03.156-0500

Silvio,

New logs look identical to the old ones.

Thanks
By: Silvio Pianese (silvio.pianese) 2013-06-12 13:24:58.583-0500

How do I set the log?
I set the logger.conf and brought to five the dedug and verbose and activated iax set debug on ..
Something wrong?
By: Silvio Pianese (silvio.pianese) 2013-06-12 14:10:17.130-0500

Hi Michael,

I again took the logs from the server ko, you can check if you can see something interesting.

thanks
Silvio
By: Michael L. Young (elguero) 2013-06-12 18:04:23.995-0500

Looks like you got it this time.  The log file is now different (new timestamp in the logs too :) ).

I think I may have pinpointed the error.

I am going to attach a patch that I would like for you to try out and see if that fixes your problem.
By: Michael L. Young (elguero) 2013-06-12 18:05:00.534-0500

Try this patch, [^rt_iax2_peer_update_fix.diff], and report back.

Thanks
By: Silvio Pianese (silvio.pianese) 2013-06-13 02:06:30.173-0500

Hi Michael,

I just installed the patch on the system, I rebooted all the logs, it seems that the problem persists because the DB field regseconds continues to go to zero (iax not registered).
Please find attached the new log in after installazine the patch.
thanks
Silvio
By: Michael L. Young (elguero) 2013-06-13 07:51:11.342-0500

Silvio,

It looks like you uploaded the wrong log file.  It is the same log as the last one that you uploaded.

Also, please make sure that you restart Asterisk after applying the patch, compiling and then installing.

Thanks


By: Silvio Pianese (silvio.pianese) 2013-06-13 09:40:44.713-0500

Hi Michael,

I installed the patch on the system:
patch-p0 <rt_iax2_peer_update_fix.diff
and then recompiled the kernel with make and make install
the result does not change, in the sense that the field regsecond on database continues to go to zero.
attached new log.

greetings
Silvio
By: Michael L. Young (elguero) 2013-06-13 10:15:37.903-0500

Silvio,

I am sorry but something just is not right with the debug logs you are posting.

NewDebugLogServerKo - was the one you posted yesterday for which I proceeded to write a patch based on something I saw.  The time in those logs are [Jun 12 20:58:18].

The debug log you just posted, DebugServerKo_1, has times of [Jun 12 20:55:18].

So, the log you just posted went backwards in time by about 3 minutes.  I need to see a current debug log of what is happening with the patch installed.

Thanks


By: Silvio Pianese (silvio.pianese) 2013-06-13 10:34:51.643-0500

no I'm sorry it's my fault, I made some mistakes with the logs from send.
Now I cleaned the situation has created a new log with date and time, at least do not make mistakes.
The patch should still be built and installed correctly.
I hope these logs are going well, the New File Log is "Log_13_06_2013_17_30_Afeter_Patch".
greetings
Silvio
By: Michael L. Young (elguero) 2013-06-14 11:42:39.195-0500

What version of Asterisk is Server C running?
By: Silvio Pianese (silvio.pianese) 2013-06-14 13:31:57.529-0500

Hi Michael,

the version Asterisk for Server C is 1.8.14-1


Silvio
By: Michael L. Young (elguero) 2013-06-14 14:57:58.256-0500

Okay, I see something I was missing.

Please try [^rt_iax2_peer_update_fix_v2.diff].

I have been working on something for chan_iax and it appears I had already made this change locally.  So, I thought it was already in the code base.  That is what was throwing me off a bit and I was wondering which version you were running.

Please reverse the last patch and apply this new one.  I hope that this will help solve your issue by updating the realtime table properly with the peer information when its registration expires.
By: Silvio Pianese (silvio.pianese) 2013-06-15 00:43:58.491-0500

ok,

I'll try this new solution immediately.
Can I ask you a question, how do I remove the old patch and then apply the new one?

thanks
Silvio
By: Michael L. Young (elguero) 2013-06-16 21:40:41.870-0500

Normally, if you try to apply the old patch, the program 'patch' will ask you if you want to reverse or un-apply the patch.  You can say yes.  Then apply the new patch.
By: Silvio Pianese (silvio.pianese) 2013-06-17 00:11:41.565-0500

Hello Michael,

I applied the patch V2, after eliminating the first patch (you were right enough revive the patch command), but the problem still persists recording.
The DB continues to clear the field regseconds.
find attached the new log called "Log_17_06_2013_Applied_v2_Patch."

thanks
Silvio
By: Michael L. Young (elguero) 2013-06-17 11:42:42.585-0500

Silvio,

I wonder if we have a cache problem.

It is okay for the registration to expire and then re-register.  What we don't want is for the ipaddr to be set to null.

Please try clearing out the cache.

Try the following:  "module unload chan_iax2.so"

Set the ipaddr and port to be empty ("") for napoli in your MySQL iax_trunk table.  

Also, check the cache in the asterisk database to see if there is an entry: "database show".  If there is an entry, remove it "database del IAX/Registry napoli".

Once that is cleared out, "module load chan_iax2.so"

Hopefully that helps to get things going again.  My patch, v2, is supposed to avoid having "(null)" written to the realtime database table.  That is what I am looking for in the logs.  There is only one function in chan_iax2 that does sends updates to the iax_trunk table.  So, I am a bit at a loss to see that with the patch applied asterisk is sending an update to the table setting the ipaddr to (null) which it should not be doing with the v2 patch.
By: Silvio Pianese (silvio.pianese) 2013-06-18 06:34:08.337-0500

Michael,


I tried as you described to clean the chache, but the problem persists.
The field of the DB regseconds continues to go to NULL (see the table in an update log IAX that puts the field to NULL).
I have also occurred in AstDB if there was any recording IAX, but nothing that is not even anything ....
I do not know what else to check ...
You some other server log?
Silvio
By: Matt Jordan (mjordan) 2013-07-07 19:59:58.820-0500

Please remember to hit the "Send Back" when the issue is in Waiting for Feedback. Otherwise, bug marshals may fail to see that you've provided feedback. Thanks!
By: Silvio Pianese (silvio.pianese) 2013-07-07 22:54:59.431-0500

I tried as you described to clean the chache, but the problem persists.
The field of the DB regseconds continues to go to NULL (see the table in an update log IAX that puts the field to NULL).
I have also occurred in AstDB if there was any recording IAX, but nothing that is not even anything ....
I do not know what else to check ...
You some other server log?

Do you have any news to suggest?

Silvio
By: Rusty Newton (rnewton) 2013-07-09 09:20:53.011-0500

Silvio, it doesn't sound likely that this problem is in the backend itself, but it might be worth a shot to try res_config_odbc vs using the res_config_mysql backend.
By: Joshua C. Colp (jcolp) 2017-12-19 07:15:48.348-0600

Have you experienced this under a current supported version of Asterisk as well?
By: Asterisk Team (asteriskteam) 2018-01-02 08:30:28.968-0600

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].
[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines