Re: Any progress on gmail.com dialback issue?
Alex Vandiver wrote: On Thu, 2009-03-26 at 20:19 -0400, Philip Gladstone wrote: Is anyone still looking at the problem, or does someone have the ideal solution? Attached is _my_ ideal solution to the problem. :) - Alex This seems reasonable. Thanks for taking the time to write up the reasoning. Given that the spec says that this is correct behavior and we've been unable to determine what broken implementation (if any) prompted that hack in the first place, I'm happy enough with this fix and I've checked it in.
Re: Any progress on gmail.com dialback issue?
Philip Gladstone wrote: I notice that there was a flurry of activity on the gmail.com dialback issue some time ago, but it never seemed to get resolved. Is anyone still looking at the problem, or does someone have the ideal solution? Having reviewed that discussion, it looks like DJabberd is in the wrong here, but I'd like to see some clear reasoning for why djabberd is wrong (based on what the spec says), what it should be doing instead, and what is broken (if anything) by the change. As far as I can tell from the previous discussion, we aren't really sure what implementation that hack was added for.
Re: Any progress on gmail.com dialback issue?
Peter Saint-Andre wrote:
What is the hack in question?
Also, please note that there were generalized issues with s2s to Google
Talk a while back, caused by some modifications on the Google side. Most
or all of those have been fixed by Google. Are there still problems
between djabberd installations and Google Talk?
Peter
As far as I can tell -- yes. If I am connected to google talk, and I try
and add as a contact someone on my DJabberd server, then the dialback
fails. For me, this is quite reproducible.
It appears that google sends a 'not-authorized' in response to DJabberd
sending the 'stream:features/stream:features' stanza. Indeed, from a
packet capture, this looks as though it is exactly what is happening.
The packet flow is:
TX: ?xml version=1.0 encoding=UTF-8?stream:stream to='gmail.com'
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server'
xml:lang='en' xmlns:db='jabber:server:dialback' version='1.0'
RX: stream:stream from=gmail.com id=51FC8F15EDF601B9 version=1.0
xmlns:stream=http://etherx.jabber.org/streams; xmlns=jabber:server
xmlns:db=jabber:server:dialbackstream:featuresdialback
xmlns=urn:xmpp:features:dialback//stream:features
TX: stream:features/stream:features
RX: stream:errornot-authorized
xmlns=urn:ietf:params:xml:ns:xmpp-streams//stream:error
TX: db:result to='gmail.com'
from='tx.pskreporter.info'i-de81e9e942031eb19e0b3aa0910810d37b2970b4/db:result
RX: /stream:stream
TX: /stream:stream
10787 DEBUG DJabberd.Delivery.S2Ss2s delivery
attempt for philip.gladst...@gmail.com
10787 DEBUG DJabberd.Queue Queuing stanza
(DJabberd::Presence=ARRAY(0x8f5d9c0)) for
10787 DEBUG DJabberd.Queue .. pushing queue
item.
10787 DEBUG DJabberd.Callback
$callback-delivered( ) has been called from
/usr/lib/perl5/site_perl/5.8.1/DJabberd/Delivery/Local.pm:36
10787 DEBUG DJabberd.DNS DNS socket
IO::Socket::INET=GLOB(0x8155340) became readable for 'srv'
10787 DEBUG DJabberd.DNS DNS socket
IO::Socket::INET=GLOB(0x8155340) for 'srv' found stuff, now doing
hostname lookup on xmpp-server.l.google.com
10787 DEBUG DJabberd.DNS DNS socket
IO::Socket::INET=GLOB(0x8ebc02c) became readable for 'a'
10787 DEBUG DJabberd.Queue.ServerOut Resolver callback
for 'gmail.com': [DJabberd::IPEndPoint=HASH(0x8ea7668)]
10787 DEBUG DJabberd.Queue Starting connection
10787 DEBUG DJabberd.Connection.ServerOutNew connection '21'
from undef
10787 DEBUG DJabberd.Connection.ServerOutConnecting to
'209.85.201.125' for 'gmail.com'
10787 DEBUG DJabberd.Queue Set connection for
queue to 'gmail.com' to connection '21'
10787 DEBUG DJabberd.Connection.XML.ServerOut21 ?xml
version=1.0 encoding=UTF-8?stream:stream to='gmail.com'
xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber :server'
xml:lang='en' xmlns:db='jabber:server:dialback' version='1.0'
10787 DEBUG DJabberd.Connection.ServerOutWe got a stream
back from connection 21!
10787 DEBUG DJabberd.Connection.ServerOutConnection 21
supports dialback
10787 DEBUG DJabberd.Connection.ServerOut21 sending
'stream:features/stream:features'
10787 INFO DJabberd.DialbackParams Generating dialback
result for vhost tx.pskreporter.info
10787 DEBUG DJabberd.DialbackParams Generated dialback
result 'i-943ed83cb0418bda534dfdb3eedcd1269b46198d' using secret(of
handle 'i')='0.04732086797012160.13565853855344
70.1457952183362890.9075679498738470.2177336623192260.8758091022577370.0628607367050.5635862747686350.231101005128160.4286760888640120.2214270472847350.9095990008557030.57575470886356
30.7550563768889770.1736854451641530.5955004488794020.02450323087547450.1811562417291730.165928613504960.608589929046897',
params='1EDD5525A32C8444|gmail.com|tx.pskreporter.info'
10787 DEBUG DJabberd.Connection.ServerOut21 sending res
'i-943ed83cb0418bda534dfdb3eedcd1269b46198d'
10787 DEBUG DJabberd.Connection.XML.ServerOut21 features
xmlns='http://etherx.jabber.org/streams'dialback
xmlns='urn:xmpp:features:dialback'//features
10787 DEBUG DJabberd.Connection.XML.ServerOut21 error
xmlns='http://etherx.jabber.org/streams'not-authorized
xmlns='urn:ietf:params:xml:ns:xmpp-streams'//error
Unknown/handled stanza: {http://etherx.jabber.org/streams}error on
connection (21), DJabberd::Connection::ServerOut
10787 DEBUG DJabberd.Queue connection error
for queue
10787 DEBUG DJabberd.Queue .. match
10787 ERROR DJabberd.Queue.ServerOut Connection error
while connecting to gmail.com, giving up
10787 DEBUG DJabberd.Callback$callback-error(
connection failure ) has been called
Re: Any progress on gmail.com dialback issue?
On Thu, 2009-03-26 at 17:31 -0700, Martin Atkins wrote: Having reviewed that discussion, it looks like DJabberd is in the wrong here, but I'd like to see some clear reasoning for why djabberd is wrong (based on what the spec says), what it should be doing instead, and what is broken (if anything) by the change. The RFC says ( http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.6 ): If the initiating entity includes the 'version' attribute set to a value of at least 1.0 in the initial stream header, the receiving entity MUST send a features/ child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any stream-level features that can be negotiated (or capabilities that otherwise need to be advertised) In this case, djabberd is the _initiating_ entity, and as such, no features/ element is expected. True, it never explicitly states that servers initiating connections MUST NOT or SHOULD NOT send features/ elements, but it is heavily implied that the only context in which they are expected is when the receiving server is declaring what features it supports. Since the iniator of the connection starts tls, etc, the receiving entity doesn't particularly care what features it supports. As far as I can tell from the previous discussion, we aren't really sure what implementation that hack was added for. It was part of the initial commit which added s2s support. As such, I regard it as slightly suspect. - Alex
