| Author |
Message
|
| exerk |
 Posted: Mon Jun 11, 2012 1:47 am Post subject: Re: It's the exit |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| T.Rob wrote: |
| I posted an update to the Stack Overflow question on this. None of the normal WMQ configuration diagnostics apply when it is the exit that is killing the connection attempt. Either drop the exit (alter channel SCYEXIT to be blank) or figure out what the exit needs to work properly. |
The OP is using WMQ V7.1?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
 |
| T.Rob |
| Posted: Mon Jun 11, 2012 1:53 am Post subject: |
|
|
Acolyte
Joined: 16 Oct 2001
Posts: 56
Location: Charlotte, NC
|
Beats me. But the error log OP posted clearly stated that the channel connection request is being killed by the exit. Although I stated that the exit is non-IBM code and now that I think about it, it might actually be an IBM sample code. Hard to say until OP responds.
_________________
-- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
| Back to top |
|
|
| firelior |
| Posted: Mon Jun 11, 2012 2:42 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
I am using WMQ V7.1.
My security exit is empty:
By the way - with the exact same code I am able to connect and add messages to the queue manager that is hosted on my computer.
And able to connect using both client-connection and server-connection.
TRANSPORT_MQSERIES_CLIENT and TRANSPORT_MQSERIES_MANAGED |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jun 11, 2012 3:51 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Try looking at CHANNEL AUTHENTICATION RECORDS 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| T.Rob |
| Posted: Mon Jun 11, 2012 4:28 am Post subject: |
|
|
Acolyte
Joined: 16 Oct 2001
Posts: 56
Location: Charlotte, NC
|
OK, so I've been looking through the v5.3 Intercommunication manual. The error message reported is from the DCE service that was supplied with WMQ v5.3. I've not worked with DCE but this may be because the server is configured for DCE, or was at one time configured for DCE or the QMgr has been upgraded in place and has a history dating back to a v5.3 QMgr with DCE installed. In any case, *something* on that system is referencing DCE. The manual mentions a DCE Names service. If that is installed, it will show up in the QM.ini file. Can you post that file here?
_________________
-- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
| Back to top |
|
|
| firelior |
| Posted: Mon Jun 11, 2012 4:38 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
| Code: |
#*******************************************************************#
#* Module Name: qm.ini *#
#* Type : WebSphere MQ queue manager configuration file *#
# Function : Define the configuration of a single queue manager *#
#* *#
#*******************************************************************#
#* Notes : *#
#* 1) This file defines the configuration of the queue manager *#
#* *#
#*******************************************************************#
ExitPath:
ExitsDefaultPath=C:\Program Files (x86)\IBM\WebSphere MQ\exits
ExitsDefaultPath64=C:\Program Files (x86)\IBM\WebSphere MQ\exits64
InstanceData:
InstanceID=1339316607
Startup=1
#* *#
#* *#
Log:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=4096
LogType=CIRCULAR
LogBufferPages=0
LogPath=C:\Program Files (x86)\IBM\WebSphere MQ\log\QM_TEST\
LogWriteIntegrity=TripleWrite
Service:
Name=AuthorizationService
EntryPoints=14
ServiceComponent:
Service=AuthorizationService
Name=MQSeries.WindowsNT.auth.service
Module=amqzfu.dll
ComponentDataSize=0
TCP:
Port=1414
|
exerk - the Channel Authentication Records is empty(I emptied it) |
|
| Back to top |
|
|
| T.Rob |
| Posted: Mon Jun 11, 2012 5:21 am Post subject: |
|
|
Acolyte
Joined: 16 Oct 2001
Posts: 56
Location: Charlotte, NC
|
OK, if there are no API exits or non-standard name services, and if there are no channel exits, then the question becomes "where is it referencing DCE?" The exit you found is the Kerberos exit, but the channel would need to point to it for it to do anything. Just putting it in the exits directory has no effect.
Are there any errors or FDCs in the system-wide error directory? It's worth looking there.
Next step if the errors and FDCs don't point toh anything concrete is to run a trace.
_________________
-- T.Rob
Voice/SMS 704-443-TROB (8762)
https://t-rob.net
https://linkedin.com/in/tdotrob
@tdotrob on Twitter |
|
| Back to top |
|
|
| firelior |
| Posted: Mon Jun 11, 2012 7:13 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
hello again.
I have done some testing and compared the trace of the working queue manager(locally) with the remote one.
and what I see is that the remote qm stops the connection when he reads its config(I belive so).
I uploaded the trace file of the queue manager:(sorry its too big for a simple text uploader site)
http://depositfiles.com/files/t60vgu8rd
But I here is some of the trace that I think is critical:
| Code: |
01CC51D9 17:39:02.097460 3792.49 : ----} ccxParseIni (rc=OK)
01CC51DA 17:39:02.097463 3792.49 : ----{ cciLoadLibrary
01CC51DB 17:39:02.097466 3792.49 : -----{ cccGetMem
01CC51DC 17:39:02.097468 3792.49 : ------{ xcsGetMemFn
01CC51DD 17:39:02.097476 3792.49 : component:8 function:100 length:1944 options:0 cbmindex:-1 *pointer:00B68FC0
01CC51DE 17:39:02.097480 3792.49 : ------} xcsGetMemFn (rc=OK)
01CC51DF 17:39:02.097483 3792.49 : -----} cccGetMem (rc=OK)
01CC51E0 17:39:02.097490 3792.49 : -----{ cciTcpLoadDLLs
01CC51E1 17:39:02.097493 3792.49 : -----} cciTcpLoadDLLs (rc=OK)
01CC51E2 17:39:02.097496 3792.49 : ----} cciLoadLibrary (rc=OK)
01CC51E3 17:39:02.097499 3792.49 : ----{ xcsRequestThreadMutexSem
01CC51E4 17:39:02.097503 3792.49 : ----} xcsRequestThreadMutexSem (rc=OK)
01CC51E5 17:39:02.097507 3792.49 : Conversation count = 2
01CC51E6 17:39:02.097510 3792.49 : ----{ xcsReleaseThreadMutexSem
01CC51E7 17:39:02.097513 3792.49 : ----} xcsReleaseThreadMutexSem (rc=OK)
01CC51E8 17:39:02.097516 3792.49 : ---} ccxNetWorkInit (rc=OK)
01CC51E9 17:39:02.097518 3792.49 : ---{ ccxAcceptConv
01CC51EA 17:39:02.097522 3792.49 : ----{ cciTcpAcceptConv
01CC51EB 17:39:02.097525 3792.49 : -----{ ioctl
01CC51EC 17:39:02.097594 3792.49 : -----} ioctl (rc=OK)
01CC51ED 17:39:02.097614 3792.49 : !! - TCP/IP TCP_NODELAY active
01CC51EE 17:39:02.097618 3792.49 : -----{ cciTcpGetPeerName
01CC51EF 17:39:02.097623 3792.49 : ------{ cciTcpResolveAddress
01CC51F0 17:39:02.097627 3792.49 : serv_addr4
01CC51F1 17:39:02.097630 3792.49 : Data:-
01CC51F1 17:39:02.097630 3792.49 : 0x0121FD64 02 00 EF B7 C0 A8 32 37 00 00 00 00 00 00 00 00 : .....¨27........
01CC51F2 17:39:02.097636 3792.49 : -------{ inet_ntop
01CC51F3 17:39:02.097640 3792.49 : address family = 2
01CC51F4 17:39:02.097644 3792.49 : v4addr
01CC51F5 17:39:02.097647 3792.49 : Data:-
01CC51F5 17:39:02.097647 3792.49 : 0x0121FCC4 02 00 00 00 C0 A8 32 37 00 00 00 00 00 00 00 00 : .....¨27........
01CC51F6 17:39:02.097660 3792.49 : inet_ntop: getnameinfo returned 0, TCPERROR = 0
01CC51F7 17:39:02.097665 3792.49 : inet_ntop: dst returned
01CC51F8 17:39:02.097668 3792.49 : Data:-
01CC51F8 17:39:02.097668 3792.49 : 0x0121FD80 31 39 32 2E 31 36 38 2E 35 30 2E 35 35 00 00 00 : 192.168.50.55...
01CC51F8 17:39:02.097668 3792.49 : 0x0121FD90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
01CC51F8 17:39:02.097668 3792.49 : 2 lines suppressed, same as above
01CC51F9 17:39:02.097678 3792.49 : -------} inet_ntop (rc=OK)
01CC51FA 17:39:02.097682 3792.49 : AddrName: '192.168.50.55'
01CC51FB 17:39:02.097686 3792.49 : Hostname: '<NULL>'
01CC51FC 17:39:02.097689 3792.49 : ------} cciTcpResolveAddress (rc=OK)
01CC51FD 17:39:02.097692 3792.49 : -----} cciTcpGetPeerName (rc=OK)
01CC51FE 17:39:02.097700 3792.49 : -----{ cciTcpResolveAddress
01CC51FF 17:39:02.097704 3792.49 : serv_addr6
01CC5200 17:39:02.097707 3792.49 : Data:-
01CC5200 17:39:02.097707 3792.49 : 0x0121FDEC 02 00 05 86 C0 A8 32 36 00 00 00 00 00 00 00 00 : ...†.¨26........
01CC5200 17:39:02.097707 3792.49 : 0x0121FDFC 73 65 6C 65 63 74 00 00 00 00 00 00 : select......
01CC5201 17:39:02.097716 3792.49 : AddrName: '192.168.50.54'
01CC5202 17:39:02.097720 3792.49 : Hostname: '<NULL>'
01CC5203 17:39:02.097723 3792.49 : -----} cciTcpResolveAddress (rc=OK)
01CC5204 17:39:02.097727 3792.49 : Socket bound to address ''
01CC5205 17:39:02.097730 3792.49 : ----} cciTcpAcceptConv (rc=OK)
01CC5206 17:39:02.097760 3792.49 : Address of remote system (incoming): '192.168.50.55'
01CC5207 17:39:02.097767 3792.49 : ----{ ccxCheckConvBlocked
01CC5208 17:39:02.097772 3792.49 : -----{ rsxAccessCache
01CC5209 17:39:02.097775 3792.49 : ------{ lpiObtainQMDetails
01CC520A 17:39:02.097781 3792.49 : -------{ zutPreReadMachineIniFile
01CC520B 17:39:02.097785 3792.49 : ReadFlags(0x0)
01CC520C 17:39:02.097789 3792.49 : --------{ xcsRequestThreadMutexSem
01CC520D 17:39:02.097793 3792.49 : --------} xcsRequestThreadMutexSem (rc=OK)
01CC520E 17:39:02.097797 3792.49 : --------{ xcsReleaseThreadMutexSem
01CC520F 17:39:02.097800 3792.49 : --------} xcsReleaseThreadMutexSem (rc=OK)
01CC5210 17:39:02.097803 3792.49 : -------} zutPreReadMachineIniFile (rc=OK)
01CC5211 17:39:02.097805 3792.49 : ------} lpiObtainQMDetails (rc=OK)
01CC5212 17:39:02.097809 3792.49 : ------{ xcsInitialize
01CC5213 17:39:02.097812 3792.49 : -------{ xcsUpdateThreadUserDetails
01CC5214 17:39:02.097815 3792.49 : --------{ xcsGetNTOwnerSid
01CC5215 17:39:02.097825 3792.49 : --------} xcsGetNTOwnerSid (rc=OK)
01CC5216 17:39:02.097829 3792.49 : !! - Thread User Details
01CC5217 17:39:02.097833 3792.49 : UserName: MUSR_MQADMIN
01CC5218 17:39:02.097840 3792.49 : Sid: S-1-5-21-874611762-2927814014-3568106700-1005
01CC5219 17:39:02.097844 3792.49 : -------} xcsUpdateThreadUserDetails (rc=OK)
01CC521A 17:39:02.097847 3792.49 : -------{ xihCheckThreadList
01CC521B 17:39:02.097849 3792.49 : -------} xihCheckThreadList (rc=OK)
01CC521C 17:39:02.097852 3792.49 : -------{ xcsRequestThreadMutexSem
01CC521D 17:39:02.097855 3792.49 : -------} xcsRequestThreadMutexSem (rc=OK)
01CC521E 17:39:02.097858 3792.49 : -------{ xihAddQueueManager
01CC521F 17:39:02.097862 3792.49 : -------}! xihAddQueueManager (rc=Unknown(1))
01CC5220 17:39:02.097871 3792.49 : -------{ xcsInitGlobalSecurityData
01CC5221 17:39:02.097873 3792.49 : -------} xcsInitGlobalSecurityData (rc=OK)
01CC5222 17:39:02.097876 3792.49 : -------{ xcsCreateNTSecurityAtts
01CC5223 17:39:02.097879 3792.49 : -------} xcsCreateNTSecurityAtts (rc=OK)
01CC5224 17:39:02.097882 3792.49 : -------{ xcsGetEnvironmentString
01CC5225 17:39:02.097891 3792.49 : xcsGetEnvironmentString[MQS_IPC_HOST] = NULL
01CC5226 17:39:02.097895 3792.49 : -------}! xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
|
That above part I don't see in the local trace.
Thank you very much for your time and help! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 11, 2012 8:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| T.Rob wrote: |
OK, if there are no API exits or non-standard name services, and if there are no channel exits, then the question becomes "where is it referencing DCE?" The exit you found is the Kerberos exit, but the channel would need to point to it for it to do anything. Just putting it in the exits directory has no effect.
Are there any errors or FDCs in the system-wide error directory? It's worth looking there.
Next step if the errors and FDCs don't point toh anything concrete is to run a trace. |
The DCE reference is because of a "Kerberos" token which is supported in V7.1, if my memory is not too fuzzy tonight...
The OP did not specify if he put an MCA User into the SVRCONN channel.
That would be a first step towards troubleshooting the problem.
Also the channel may never start if the correct authorizations have not been given (channel access records and setmqaut commands)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jun 11, 2012 11:44 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| The OP did not specify if he put an MCA User into the SVRCONN channel. |
I'm still waiting for the OP to post the definition rather than a screenshot...
| fjb_saper wrote: |
| Also the channel may never start if the correct authorizations have not been given (channel access records and setmqaut commands) |
The OP has stated in an earlier post that Channel Authentication is off, or rather 'empty'. As regards an MCAUSER, see my previous comment.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| firelior |
| Posted: Tue Jun 12, 2012 2:28 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
exerk - what exactly do you want me to post?
the ccdt is a binary file..
where should I get what you want from?
and I don't have MCAUSER anywhere.
maybe it is because of this?
 |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 12, 2012 2:57 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| firelior wrote: |
exerk - what exactly do you want me to post?
the ccdt is a binary file.. |
Your definition of the SVRCONN and CLNTCONN, from a command console (runmqsc and display commands). The CLNTCONN definition is what is contained within the CCDT.
| firelior wrote: |
| where should I get what you want from? |
See above...
| firelior wrote: |
| and I don't have MCAUSER anywhere. |
Explicitly established now, good.
| firelior wrote: |
maybe it is because of this?
|
No. That's just telling WMQ to use the Windows security manager to check user names exist etc.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| firelior |
| Posted: Tue Jun 12, 2012 4:43 am Post subject: |
|
|
Apprentice
Joined: 31 May 2012
Posts: 28
|
I did the following commands, I hope that this will help you:
| Code: |
DISPLAY CHANNEL (QM.CONN)
AMQ8414: Display Channel details.
CHANNEL(QM.CONN) CHLTYPE(SVRCONN)
ALTDATE(2012-06-11) ALTTIME(16.38.41)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) DISCINT(0)
HBINT(300) KAINT(AUTO)
MAXINST(999999999) MAXINSTC(999999999)
MAXMSGL(4194304) MCAUSER( )
MONCHL(QMGR) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP)
DISPLAY CHLAUTH (*)
21 : DISPLAY CHLAUTH (*)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
|
Tell me if you need anything else..
BTW - I created a new queue manager that I put there only 1 connection - SVRCONN, 1 listener and no channel authentication records.
I still get the same results.
I am some how missing something I think.. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Jun 12, 2012 4:48 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| firelior wrote: |
| Tell me if you need anything else.. |
Where's the CLNTCONN definition? And why does the name of the channel in the screenshot differ from that in the display command?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 12, 2012 5:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| firelior wrote: |
| No I am not using SSL. |
Yes, yes you are.
That says "Nobody can connect to this channel UNLESS they are using SSL.
Your code, as shown, is not. And, you believe that it is not. |
|
| Back to top |
|
|
|
|
