search

mftaha / jabber-net

Automatically exported from code.google.com/p/jabber-net
Other
0 stars 0 forks source link

Unable to login - No server response #112

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Trying to login to jabber server with Jabber built to x64 or AnyCPU using 
VS2010 on x64 Win7. 
3. Protocol tracing with Wireshark shows ok until the following request packet 
is sent to the server - <iq id="JN_47" type="" to="demo.mydemo.com">...the 
server responds only with ACK and nothing else...
What is the expected output? What do you see instead?
Expecting login to continue, that is, a response packet like this:
<iq id='JN_47' type='result'><bind 
xmlns='urn:ietf:params:xml:ns:xmpp-bind'><jid>112@demo2.switchvox.com/mySuite</j
id></bind></iq> and more afterwards but nothing folllows the ACK packet.

What version of the product are you using? On what operating system?
JabberNet-2.1.0.710 built as x64 or AnyCPU on Win7 x64.

Please provide any additional information below.
Identical 32-bit build (x86) works fine with the same Jabber server.

Is there any known problems with 64Bit builds? Why the 'type' property is "" 
instead of "set" in the request packet that is issued by Jabber? Sshould it be 
"set"?

Original issue reported on code.google.com by leonthea...@gmail.com on 20 Apr 2011 at 7:36

GoogleCodeExporter commented 9 years ago 
Answering my own question here:

Last night I managed to consistently login to the remote jabber server, but it 
only worked in Debug mode no matter what kind of excercises I tried...
So today I discovered the following code in Jabber:

        public static string ToString(object value)
        {
            Type t = value.GetType();
            if (!t.IsEnum)
                throw new ArgumentException("Type must be enum");

            if ((int)value == -1)
                return null;

            Dictionary<object, string> map = GetStringHash(t);
            string val = null;
            Debug.Assert(map.TryGetValue(value, out val));
            return val;
        }

This obviously a bug in a very commonly-used function, which makes me wonder 
how the whole thing works even with 32-Bit...
As you can imagine, statement like that has a problem in Release mode since it 
returns the parameter through 'out val'...

So, removing the Debug.Assert and leaving the TryGetValue fixes the login 
problem in a heart beat...Hope it is going to make it in whatever the next 
version is.

Original comment by leonthea...@gmail.com on 21 Apr 2011 at 9:01

GoogleCodeExporter commented 9 years ago 
Unable to read the data from transaport connection. and connection forcibly 
closed. while login

Original comment by kalpen1...@gmail.com on 27 Mar 2012 at 6:04