Summary:	ASTERISK-12928: IAX2 qualify problems between 1.6 and 1.4 boxes
Reporter:	Jared Smith (jsmith)	Labels:
Date Opened:	2008-10-17 12:34:56	Date Closed:	2009-06-29 16:32:52
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_iax2
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) capture-1.4.22-iax2-reload.pcap ( 1) capture-1.6.1.pcap ( 2) capture-1.6.1-iax2-reload.pcap
Description:	I have two boxes... one is running 1.4.22 and the other is running 1.6.0.  Both are sending IAX2 POKEs to the other (as part of the qualification process), but neither seems to be responding correctly to the other.  On Tilghman's advice, I upgraded the 1.6.0 box to the 1.6.1 branch in SVN (r150606), and am seeing the same thing. I'm attaching two captures... the first is simply a packet capture of all port 4569 traffic on the 1.6.1 box.  The second is the same thing, but with both an "iax2 reload" and a "restart now" thrown in for good measure.
Comments:	By: Jared Smith (jsmith) 2008-10-17 13:29:55 I've rolled the 1.6 box back to 1.4.22, and it's still exhibiting the same symptoms... lots of POKEs, no PONGs or ACKs. Any other ideas? By: Tilghman Lesher (tilghman) 2008-10-17 13:34:19 The PCAPs show PONGs, though, just no ACKs. By: Jared Smith (jsmith) 2008-10-17 14:28:19 Changing both boxes to say "auth=md5" instead of "auth=md5,rsa" fixed the problem.  Anybody want to venture a guess as to why this would make any difference on IAX2 qualifies? By: Tilghman Lesher (tilghman) 2008-10-20 11:35:06 No idea whatsoever. By: Jared Smith (jsmith) 2008-12-17 08:50:10.000-0600 Any update on this bug? By: Leif Madsen (lmadsen) 2008-12-17 09:25:00.000-0600 Hmmm... funny enough I've been seeing the same thing on another customers box. Not that it helps, but I assumed it was just his network, so I turned qualifies off, but it seems like the same issue here. By: Leif Madsen (lmadsen) 2008-12-17 09:25:24.000-0600 Changing status to acknowledged since there are no patches attached to this issue. By: Florian Floimair (ffloimair) 2008-12-17 09:34:12.000-0600 Does not really explain that the fix with rsa is working, but otherwise to me it seems it is associated with the bug report I filed a few weeks ago (http://bugs.digium.com/view.php?id=13918). Version 1.4.22 does not have the fix for that unless you patch it (http://bugs.digium.com/file_download.php?file_id=20761&type=bug) manually while 1.6.1 in SVN certainly does have this fix included. From the issues described this certainly has the same observable characteristics that I have encountered before the fix. By: Leif Madsen (lmadsen) 2009-01-20 13:21:50.000-0600 jsmith: any chance of getting another test of this with the latest 1.4 and 1.6.1 branches?  Perhaps the issue from 13918 solved your issue? By: Jared Smith (jsmith) 2009-01-20 13:25:20.000-0600 I can certainly give it a shot sometime in the next couple of weeks.  I don't have immediate access to the hardware in question, but will try to schedule some time and test it out again. By: John Covert (jcovert) 2009-01-21 18:07:05.000-0600 Jared, Are you getting INVALs back in response to the POKEs?  This could be related to issue ASTERISK-13185. /john By: Leif Madsen (lmadsen) 2009-05-12 19:55:22 Talked to Jared on IRC, and he is going to try and reproduce tomorrow, and if he can't get around to it, will assign to me to test sometime before I die :) By: David Vossel (dvossel) 2009-06-19 17:19:46 I believe my patch for https://issues.asterisk.org/view.php?id=15361 may have to do with this. From what I understand, PONGS should contain the timestamp of the POKE just like an ACK.  In the packet captures above, the PONG's TS is 0ms which is not correct.  Issue ASTERISK-14342 resulted from converting the TS for a RX:POKE message to host byte order using ntohs() rather than ntohl() (TS in a Full Frame is a 32bit field requiring network to host long function).  On x86 systems this usually results in a 0ms TS depending on the TS's size, on Power PC systems this results in the first 2 bytes being truncated which kind of masks the issue until the TS grows larger. Not sure if this resolves anything, but It may have something to do with it. By: Russell Bryant (russell) 2009-06-29 16:32:20 I think dvossel's patch that he referred to was the cause of this.  If you still have a problem, please let us know!