Summary:	ASTERISK-13052: DUNDi queries/lookups from 32-bit to 64-bit machine fails; 64-bit to 32-bit operations OK
Reporter:	A. Karl Kornel (akkornel)	Labels:
Date Opened:	2008-11-11 19:39:49.000-0600	Date Closed:	2009-01-13 12:09:04.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	PBX/pbx_dundi
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) dundi_lookup_32to64_32viewpoint.txt ( 1) dundi_lookup_32to64_64viewpoint.txt
Description:	I have three machines: KORNEL-3503A, KORNEL-3503B, and NPBUBT.  KORNEL-3503A is running the i686 architecture on a 32-bit Pentium CPU (the i386 build of Ubuntu).  KORNEL-3503B and NPBUBT are running the x86_64 architecture on 64-bit AMD Opteron CPUs (the amd64 build of Ubuntu).  For testing purposes, all three machines are peered with each other, and the same key is in use on all three machines. I have a SIP hardphone plugged into KORNEL-3503B.  If I dial an extension on KORNEL-3503A or on NPBUBT, the call is connected.  However, if I am plugged into KORNEL-3503A, all my attempts to dial extensions on KORNEL-3503B and NPBUBT fail.  The messages on the remote console indicate that KORNEL-3503A (the 32-bit machine) is unable to find any of the extensions that live on KORNEL-3503B or on NPBUBT (the 64-bit machines). I see the same behavior with the `dundi lookup` command:  When I am on KORNEL-3503B or NPBUBT, if I try to lookup an extension that lives on any other machine, I get a result.  When I am on KORNEL-3503A, all of attempts to lookup extensions on the other machines fails.  The same thing happens with the `dundi query` command:  From a 64-bit machine, I can query the other 64-bit machine or the 32-bit machine and get details in return.  From the 32-bit machine, all queries fail. The `dundi show peers` command, when run from any of the three machines, shows the other peers as status OK.  If I pick a random machine and shut it down, the other two eventually notice and report the peer as UNREACHABLE. ****** ADDITIONAL INFORMATION ****** KORNEL-3503A and NPBUBT are running Ubuntu Linux 6.06 LTS, with all updates.  KORNEL-3503B is running Ubuntu Linux 8.04 LTS, with all updates.  All machines are running Asterisk 1.4.22, which I checked out from Subversion (tag 1.4.22, last changed revision 145354).  In addition to Asterisk, I am also using Zaptel version 1.4.9.2, which I also checked out from Subversion (tag 1.4.9.2, revision 3912).  I am only using the ztdummy module, all other modules are commented out.  Finally, I also checked out libpri version 1.4.7 from Subversion (tag 1.4.7, last changed revision 615). In the extensions configuration, I have set up each machine under the premise that each machine existed in a different office.  There are internal extensions, which are six digits long:  KORNEL-3503A has internal extension 870301; KORNEL-3503B has internal extension 870101; NPBUBT has internal extension 870501.  Each of the above extensions is the start of an IVR menu tree.  My tests consisted of connecting a SIP hardphone into one machine, and dialing the exension of another machine. The dundi.conf and extensions.conf files are virtually identical across all three machines.  The differences are mainly in the IP addresses, extension numbers, and DUNDi Entity IDs.  The keys are not password-protected.  When I run `keys list` after Asterisk start, I see both the public and private keys are already loaded.  The key checksums match across machines.
Comments:	By: A. Karl Kornel (akkornel) 2008-11-11 19:56:32.000-0600 Hello again!  I have attached two files showing what the Asterisk remote console displays when I run the command `dundi debug` and then try to a lookup from the 32-bit machine. For reference, the entity ID of the 32-bit machine is 00:d0:b7:1b:53:6b.  I am trying to look up extension 870101, which lives on the 64-bit machine with entity ID 00:14:4f:f3:b2:74.  The '...32viewpoint.txt' file contains the output from the 32-bit machine; the '...64viewpoint.txt' file contains the output from the 64-bit machine. There is another 64-bit machine in little DUNDi peer group; it has entity ID 00:50:56:a2:74:70, but doesn't have extension 870101.  I didn't capture it's output. By: Tilghman Lesher (tilghman) 2008-12-11 11:39:47.000-0600 Please turn on debugging with: core set debug 3 pbx_dundi.c and try this again.  The resulting DEBUG level messages are useful.  Note that you may need to enable debug output in logger.conf. By: Russell Bryant (russell) 2008-12-11 15:02:58.000-0600 I just labbed this up between 32 bit and 64 bit machines and was not able to reproduce the error.  Both machines are running Ubuntu 8.04.  One is running the i386 version, and the other is running the amd64 version.  I tested using the latest Asterisk 1.4 code. I'm going to need some assistance getting this reproduced.  If someone can get this problem to occur on a test environment that I can log in to and work on, I would be more than happy to look at it further. By: Digium Subversion (svnbot) 2008-12-12 08:40:45.000-0600 Repository: asterisk Revision: 163511 U   branches/1.4/pbx/pbx_dundi.c ------------------------------------------------------------------------ r163511 | russell | 2008-12-12 08:40:45 -0600 (Fri, 12 Dec 2008) | 5 lines Specify uint32_t for variables storing a CRC32 so that it is actually 32 bits on 64-bit machines, as well. (inspired by issue ASTERISK-13052) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=163511 By: Russell Bryant (russell) 2008-12-12 08:41:26.000-0600 Give the latest 1.4 code a try with that change.  It was one thing I noticed in the code that was not ideal for a 64-bit machine.  It could have been the cause of your problem. By: Tilghman Lesher (tilghman) 2009-01-09 18:23:29.000-0600 Is this still an issue with the SVN 1.4 branch code? By: Leif Madsen (lmadsen) 2009-01-13 12:09:04.000-0600 I'm going to go ahead and close this issue for now. If the reporter is still having this issue, please find a bug marshall on the IRC network irc.freenode.net and join room #asterisk-bugs, and request a bug marshall to reopen this issue for you. Thanks!