Greetings all.
I've been mucking about, trying to get PyMSNt working on with my
jabber server. It seems that if I try to use a shared secret of
longer than 15 characters, I always get an authentication
failure when the transport tries to connect to the router. (my
original shared secret was 20 characters long).
As long as the secret is shorter than 15 characters it works..
I think something is happening the the hash generation on the
longer shared secrets, but I haven't a clue what.
I'd love to report via a bug tracking mechanism, but I can't
remember where PyMSNt does it's bug tracking..
Interesting info:
Jabber server: Jabberd 2s10
Python version: 2.4.2
Twisted version: 2.1.0
Twisted Words: 0.1.0
Twisted xish: 0.1.0
Twisted Web: 0.5.0
OS: NetBSD
OS Version: 2.0G
Architecture: alpha (64 bit, little endian)
Thanks,
Eric
--
Eric Schnoebelen [EMAIL PROTECTED]
http://www.cirr.com
The meek shall inherit the earth -- they are too weak to refuse.
From [EMAIL PROTECTED] Wed Dec 28 00:06:07 2005
From: [EMAIL PROTECTED] (Lars T. Mikkelsen)
Date: Wed Dec 28 00:06:16 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Hi Eric,
On Tue, Dec 27, 2005 at 02:05:44PM -0600, Eric Schnoebelen wrote:
> I've been mucking about, trying to get PyMSNt working on with my
> jabber server. It seems that if I try to use a shared secret of
> longer than 15 characters, I always get an authentication
> failure when the transport tries to connect to the router. (my
> original shared secret was 20 characters long).
Apparently this is not a general issue. I've been using a 32 character
shared secret for as long as I've been using PyMSNt, and the
authentication is working great. Currently, I'm using jabberd 2.0s9,
Twisted 2.0, Linux 2.6.14.2, and x86 - my versions of Python, Words,
Xish, and Web are the same as yours.
Did you try several different secrets longer than 15 characters, or did
you only try variations of your or original 20 character secret?
> I'd love to report via a bug tracking mechanism, but I can't
> remember where PyMSNt does it's bug tracking..
I think this is the correct place to report bugs.
Best regards,
Lars
From [EMAIL PROTECTED] Wed Dec 28 01:03:12 2005
From: [EMAIL PROTECTED] (Eric Schnoebelen)
Date: Wed Dec 28 01:03:20 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: Your message of "Wed, 28 Dec 2005 01:06:07 +0100."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
"Lars T. Mikkelsen" writes:
- On Tue, Dec 27, 2005 at 02:05:44PM -0600, Eric Schnoebelen wrote:
- > I've been mucking about, trying to get PyMSNt working on with my
- > jabber server. It seems that if I try to use a shared secret of
- > longer than 15 characters, I always get an authentication
- > failure when the transport tries to connect to the router. (my
- > original shared secret was 20 characters long).
-
- Apparently this is not a general issue. I've been using a 32 character
- shared secret for as long as I've been using PyMSNt, and the
- authentication is working great. Currently, I'm using jabberd 2.0s9,
- Twisted 2.0, Linux 2.6.14.2, and x86 - my versions of Python, Words,
- Xish, and Web are the same as yours.
-
- Did you try several different secrets longer than 15 characters, or did
- you only try variations of your or original 20 character secret?
Yes, all the secrets were variations of the original
secret.
I just tried a random 20 character secret, and it failed
in the same fashion.
I suspect there is some interaction in the hash
generator that shows up on 64 bit systems. (note, I'm running on
an alpha, not an x86 machine. still little endian, but the
words are twice as long.. :)
Not knowing where the hash function is, I haven't a clue
where to send the blame..
FYI: using the 20 character secret worked just fine for
muc-jcr (the JCR implementation of the Multi User Conference
software.) That tends to point to something in the python code,
although I suppose it could be the case that the two C
implementations end up broken in the same fashion..
FYI2: I configured py-aim-t using the saslUsername and
secret, with a 20 character password, and it appears to connect
and maintain a connection just fine.
--
Eric Schnoebelen [EMAIL PROTECTED]
http://www.cirr.com
Now and then an innocent man is sent to the legislature.
From [EMAIL PROTECTED] Wed Dec 28 01:22:24 2005
From: [EMAIL PROTECTED] (Lars T. Mikkelsen)
Date: Wed Dec 28 01:22:32 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On Tue, Dec 27, 2005 at 07:03:12PM -0600, Eric Schnoebelen wrote:
> Not knowing where the hash function is, I haven't a clue
> where to send the blame..
As far as I was able determine, the hash function is SHA-1, used in
hashPassword() in twisted.xish.xmlstream. It should be fairly easy to
check if the SHA-1 implementation is working on your architecture:
$ python
>>> import sha
>>> sha.new("abcdefghijklmnopqrstuvwxyz").hexdigest()
'32d10c7b8cf96570ca04ce37f2a19d84240d3a89'
>>>
Best regards,
Lars
From [EMAIL PROTECTED] Wed Dec 28 04:43:22 2005
From: [EMAIL PROTECTED] (Eric Schnoebelen)
Date: Wed Dec 28 04:43:29 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: Your message of "Wed, 28 Dec 2005 02:22:24 +0100."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
"Lars T. Mikkelsen" writes:
- On Tue, Dec 27, 2005 at 07:03:12PM -0600, Eric Schnoebelen wrote:
- > Not knowing where the hash function is, I haven't a clue
- > where to send the blame..
-
- As far as I was able determine, the hash function is SHA-1, used in
- hashPassword() in twisted.xish.xmlstream. It should be fairly easy to
- check if the SHA-1 implementation is working on your architecture:
-
- $ python
- >>> import sha
- >>> sha.new("abcdefghijklmnopqrstuvwxyz").hexdigest()
- '32d10c7b8cf96570ca04ce37f2a19d84240d3a89'
- >>>
Thanks for the quick test case there..
According to the quick test, that appears to be ok..
thezew-> uname -srm
NetBSD 2.0G alpha
thezew-> python2.4
Python 2.4.2 (#1, Dec 25 2005, 14:45:15)
[GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sha
>>> sha.new("abcdefghijklmnopqrstuvwxyz").hexdigest()
'32d10c7b8cf96570ca04ce37f2a19d84240d3a89'
>>>
Hmm, now that's got me wondering if the C implementation used by
jabberd 2s10 and muc might be buggered.. (but I find that very
hard, but not impossible, to believe..)
Additional information: The error returned by the server
(router) is (wrapped for readability)
<stream:error xmlns:stream='http://etherx.jabber.org/streams'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
hash didn't match, auth failed
</text>
</stream:error>
(as gathered by tcpdump, the auth failure never being logged
anywhere..)
FYI: I'm a python newbie, although there's over 25 years
experience with other languages.. :)
--
Eric Schnoebelen [EMAIL PROTECTED]
http://www.cirr.com
"Memory is like an orgasm. It's a lot better if you don't
have to fake it." -Seymore Cray, on virtual memory
From [EMAIL PROTECTED] Wed Dec 28 04:58:33 2005
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Wed Dec 28 04:58:38 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Can you get a tcpdump of the whole authentication process, there might
be some tasty snippets in the base64 encoded data.
On 12/28/05, Eric Schnoebelen <[EMAIL PROTECTED]> wrote:
>
> "Lars T. Mikkelsen" writes:
> - On Tue, Dec 27, 2005 at 07:03:12PM -0600, Eric Schnoebelen wrote:
> - > Not knowing where the hash function is, I haven't a clue
> - > where to send the blame..
> -
> - As far as I was able determine, the hash function is SHA-1, used in
> - hashPassword() in twisted.xish.xmlstream. It should be fairly easy to
> - check if the SHA-1 implementation is working on your architecture:
> -
> - $ python
> - >>> import sha
> - >>> sha.new("abcdefghijklmnopqrstuvwxyz").hexdigest()
> - '32d10c7b8cf96570ca04ce37f2a19d84240d3a89'
> - >>>
>
> Thanks for the quick test case there..
>
> According to the quick test, that appears to be ok..
>
> thezew-> uname -srm
> NetBSD 2.0G alpha
> thezew-> python2.4
> Python 2.4.2 (#1, Dec 25 2005, 14:45:15)
> [GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import sha
> >>> sha.new("abcdefghijklmnopqrstuvwxyz").hexdigest()
> '32d10c7b8cf96570ca04ce37f2a19d84240d3a89'
> >>>
>
> Hmm, now that's got me wondering if the C implementation used by
> jabberd 2s10 and muc might be buggered.. (but I find that very
> hard, but not impossible, to believe..)
>
> Additional information: The error returned by the server
> (router) is (wrapped for readability)
>
> <stream:error xmlns:stream='http://etherx.jabber.org/streams'>
> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
> <text xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
> hash didn't match, auth failed
> </text>
> </stream:error>
>
> (as gathered by tcpdump, the auth failure never being logged
> anywhere..)
>
> FYI: I'm a python newbie, although there's over 25 years
> experience with other languages.. :)
>
> --
> Eric Schnoebelen [EMAIL PROTECTED]
> http://www.cirr.com
> "Memory is like an orgasm. It's a lot better if you don't
> have to fake it." -Seymore Cray, on virtual memory
> _______________________________________________
> py-transports mailing list
> py-transports@blathersource.org
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED] Wed Dec 28 05:19:58 2005
From: [EMAIL PROTECTED] (Eric Schnoebelen)
Date: Wed Dec 28 05:20:02 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: Your message of "Wed, 28 Dec 2005 06:58:33 +0200."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Norman Rasmussen writes:
- Can you get a tcpdump of the whole authentication process, there might
- be some tasty snippets in the base64 encoded data.
Sure, I've got several..
I just attempted to start a session, having reconfigured
using a random 20 character shared secret. (its
``Apot4AuTIA1iY95YsAkE'' if that'll make life any easier.)
There are 5 attempts in the file. All failed.
It's about 14k in size, so I'm putting it at
http://www.cirr.com/~eric/pymsnt-connect.txt.
Thanks!
Eric
--
Eric Schnoebelen [EMAIL PROTECTED]
http://www.cirr.com
"Memory is like an orgasm. It's a lot better if you don't
have to fake it." -Seymore Cray, on virtual memory
From [EMAIL PROTECTED] Wed Dec 28 07:31:15 2005
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Wed Dec 28 07:31:19 2005
Subject: [py-transports] PyMSNt problems with shared secrets longer than
15 characters
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
The tcpdumps look like the hash is being computed fine. (as my
reading of JEP-0114 goes).
My guess would be that jabberd2's implementation is broken. Perhaps
there's a newline being inserted somewhere during the hash
calculation, or the jabberd2 alpha/64/endian build is broken).
I'm not sure why jcr is working, can you get a tcpdump of /that/
connection attempt?
On 12/28/05, Eric Schnoebelen <[EMAIL PROTECTED]> wrote:
>
> Norman Rasmussen writes:
> - Can you get a tcpdump of the whole authentication process, there might
> - be some tasty snippets in the base64 encoded data.
>
> Sure, I've got several..
>
> I just attempted to start a session, having reconfigured
> using a random 20 character shared secret. (its
> ``Apot4AuTIA1iY95YsAkE'' if that'll make life any easier.)
>
> There are 5 attempts in the file. All failed.
>
> It's about 14k in size, so I'm putting it at
> http://www.cirr.com/~eric/pymsnt-connect.txt.
>
> Thanks!
> Eric
>
> --
> Eric Schnoebelen [EMAIL PROTECTED]
> http://www.cirr.com
> "Memory is like an orgasm. It's a lot better if you don't
> have to fake it." -Seymore Cray, on virtual memory
> _______________________________________________
> py-transports mailing list
> py-transports@blathersource.org
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
--
- Norman Rasmussen
- Email: [EMAIL PROTECTED]
- Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED] Wed Dec 28 10:09:55 2005
From: [EMAIL PROTECTED] (Alexey Nezhdanov)
Date: Wed Dec 28 10:10:12 2005
Subject: [py-transports] Problem with msn-transport
Message-ID: <[EMAIL PROTECTED]>
Hello
I have such a problem with msn transport:
have two msn contacts registered through a transport.
Contacts going online when I go online (after short pause like 2-5 seconds).
If I try to add one contact into other roster nothing happens.
If I try to send message from one contact to another then after some time I
get back message:
"This message could not be delivered. Please check that the contact is online,
and that their address on your contact list is correct."
(contacts are not authorised each other yet)
If I try to send message from the second contact to the first one then I'm
getting same error usually, but have tested it now and it worked.
Well... Now I'm checking it and messages appeared to successfully go forth and
back. But nethertheless problem was actual and I think it will come back
soon.
Anyways here is the additional info:
When I have logged out yesterday and logged back in today I have got
"subscribe" event on the contact that I were trying to add.
...
Just logged in with one additional contact and logged ioff second one.
So now I have:
1st contact, online. It were working with 2nd contact a minute ago
2nd contact, offline
3rd contact, online.
Tried to add 3rd contact into the roster of 1st. Nothing happened on the 3rd
contact. Messages between 1 and 3 are bounced with the same error message as
described above.
Logged 3rd contact off and then back on. Got subscription request. Messages
still not working.
What is the best strategy to overcome this? Where to start looking from?
--
Respectfully
Alexey Nezhdanov
