Server waits forever on receiving next(c.p) about go-xmpp HOT 11 CLOSED

I'm having the same issue, did you ever figure it out @boopathi ?

from go-xmpp.

cc @mattn

from go-xmpp.

What the server do you use?

from go-xmpp.

I'm trying to use it with OpenFire

from go-xmpp.

This is my output

<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="127.0.0.1" id="REDACTED" xml:lang="en" version="1.0">
<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="http://jabber.org/features/iq-auth"/></stream:features>
<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="127.0.0.1" id="REDACTED" xml:lang="en" version="1.0"><stream:features><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism><mechanism>CRAM-MD5</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><auth xmlns="http://jabber.org/features/iq-auth"/></stream:features>
<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">REDACTED</challenge>
<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl">REDACTED</success>
</stream:stream>

Then everything stops and it never gets to the go function to read the talk.Recv

from go-xmpp.

Can confirm this, I made some changes in my fork[1], but I am not ready to PR yet.

[1] dullgiulio@07352ce

from go-xmpp.

Is anyone working on this bug?

It looks to me like the io.EOF error from func (*xml.Decoder) Token (indicating end of XML stream) is ignored. It should probably trigger connection re-initiation, or at least cause c.Recv to return io.EOF so it can be handled outside the package.

https://github.com/mattn/go-xmpp/blob/8a80c8abe319ccc0e61b63684158bffd1a61ca5a/xmpp.go#L540

from go-xmpp.

Sorry, we stopped using OpenFire and I can't reproduce this any longer.

But wouldn't that line end up in panic(unreacheable) is an EOF is received there?

from go-xmpp.

https://play.golang.org/p/9FiXqI8F0b

I'm afraid not. Since the type switch below don't catch it (the token t is nil), it will simply continue looping forever.

@mattn - Any interest in accepting a pull request that would expose this error to the c.Recv() caller? I can't understand how ignoring that io.EOF could lead to anything but an unrecoverable failure, but I may of course be missing something here.

@dullgiulio - Out of curiosity, do you know if OpenFire implements XMPP Ping? After enabling this on our ejabberd instance, it looks like we're getting io.UnexpectedEOF instead of a non-responsive Recv() call when the connection is broken.

from go-xmpp.

Your patch seems good for me.

from go-xmpp.

I'm sorry. I was looking at (and linking to) an old blob that.

Commit 9dd92e1 changed the behaviour of this function, so my playground example is no longer valid.

Although the patched version behaves as I suggested (https://play.golang.org/p/FAP7Wa8hll), I still suggest that we remove the err != io.EOF statement. It appears misleading, and may still cause issues (depending on the xml package's behaviour).

I'm sending you a PR in a couple of minutes.

from go-xmpp.