Opened at 2011-12-20T19:08:48Z
Closed at 2014-02-07T16:13:36Z
#875 closed defect (duplicate)
Disconnected when trying to initialize a conversation (OTR)
| Reported by: | Owned by: | pesco | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | OTR | Version: | devel |
| Keywords: | openfire otr | Cc: | |
| IRC client+version: | Client-independent | Operating System: | Linux |
| OS version/distro: | Ubuntu, not sure of version |
Description
OpenFire: 3.7.1
BitlBee: 3.0.4+devel+852-1
Whenever I try to start a new conversation with someone on my contact list I get disconnected. The OpenFire server gets a "Disallowed character" exception. If they instead initialize the conversation with me, we can chat without problem.
[15:32] <joe> ping? [15:32] jane is away, reason: Away (I'm not here right now) [15:32] *** jane quit (openfire.server.se openfire.server.se)
As soon as I send the "ping?" I get disconnected.
[15:32] <@root> jabber - Error: Error while reading from server [15:32] <@root> jabber - Signing off.. [15:32] *** jane quit (openfire.server.se openfire.server.se) [15:32] <@root> jabber - Reconnecting in 5 seconds.. [15:32] <@root> otr keygen for joe@openfire/jabber complete [15:33] <@root> jabber - Logging in: Connecting [15:33] <@root> jabber - Logging in: Connected to server, logging in [15:33] <@root> jabber - Logging in: Authentication finished [15:33] <@root> jabber - Logging in: Authenticated, requesting buddy list [15:33] <@root> jabber - Logging in: Logged in [15:33] *** jane (jane@openfire) joined
Turning off OTR (set otr_policy never) solves the problem.
Attachments (0)
Change History (4)
comment:1 Changed at 2011-12-20T19:13:19Z by
| Component: | Jabber → OTR |
|---|---|
| Owner: | changed from wilmer to pesco |
comment:2 Changed at 2012-05-02T22:57:09Z by
I can reproduce the same bug (probably) but with different conditions.
I'm connecting to jabberd2 2.2.14 server. I have two bitlbee 3.0.5 clients. In OTR opportunistic mode with xmlconsole enabled I get disconnected with a similar error:
[testing] hello <xmlconsole> TX: <message type="chat" to="testing@jabber.server/BitlBee"><body>hello</body></message> <xmlconsole> RX: <stream:error xmlns:stream="http://etherx.jabber.org/streams"><xml-not-well-formed xmlns="urn:ietf:params:xml:ns:xmpp-streams"/><text xmlns="urn:ietf:params:xml:ns:xmpp-streams">not well-formed (invalid token)</text></stream:error> <root> jabber - Error: Stream error: xml-not-well-formed: not well-formed (invalid token) <root> jabber - Signing off.. -:- SignOff testing [testing@jabber.server]: &bitlbee (bitlbee.localhost jabber.server) <root> jabber - Reconnecting in 5 seconds..
If I turn off opportunistic mode, all works as expected:
<presi> set otr_policy manual <root> otr_policy = `manual' [testing] hellooo <xmlconsole> TX: <message type="chat" to="testing@jabber.server/BitlBee"><body>hellooo</body></message>
Without xmlconsole all works fine. So I think there is a strange interaction with magic characters of oportunistic mode with some servers and with jabber module too as xmlconsole triggers it.
comment:3 Changed at 2012-12-15T16:31:43Z by
I am hitting this too with current BitlBee dev on ejabberd 2.1.11. Only with xmlconsole true and otr_policy opportunistic.
comment:4 Changed at 2014-02-07T16:13:36Z by
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
goto #1111
pesco, I'm pretty sure something funky is going on in the OTR module.
We managed to get a log fragment from the Jabber server eventually, showing what data it received from BitlBee:
wilmer@peer:/tmp$ xxd -r -c 256 < wtf | hd 00000000 f0 17 57 25 09 65 65 13 c6 95 2f a0 97 56 3a 76 |..W%.ee.../..V:v| 00000010 eb 60 33 68 57 7e f8 bb b9 48 dd 9f 13 3a 9e 5c |.`3hW~...H...:.\| 00000020 4f a6 dd d9 3e d4 eb f3 e4 5f 4b 49 08 87 ef 2a |O...>...._KI...*| 00000030 8b 65 c2 8c 59 46 d4 f8 6a 2f 5c c2 e4 66 e2 e4 |.e..YF..j/\..f..| 00000040 39 23 ae db ae 3f 2d 1a df e9 9d 03 e5 60 23 c9 |9#...?-......`#.| 00000050 9a fe c4 91 4f 96 f1 97 56 a3 22 a2 d8 e8 f7 cf |....O...V.".....| 00000060 26 8b 75 53 58 70 c2 1c 45 e3 d2 fa cb 6d 6f c8 |&.uSXp..E....mo.| 00000070 26 78 cd b7 d7 05 d8 7d e7 ab 32 0c 91 fc e9 c6 |&x.....}..2.....| 00000080 91 71 09 8e 1f c5 60 d5 28 1a b6 6f 0c 6d bf a9 |.q....`.(..o.m..| 00000090 d5 7d 07 51 63 81 1a a2 e4 20 24 c6 13 c9 d9 e8 |.}.Qc.... $.....| 000000a0 27 fd ea 6f ae 58 12 fb f2 37 5d 52 2f ac 1a a6 |'..o.X...7]R/...| 000000b0 54 db 61 79 a6 55 7d 64 5d a6 3d db 4d 29 fb b7 |T.ay.U}d].=.M)..| 000000c0 ef 34 f3 49 13 07 6b d7 81 00 00 00 00 00 00 00 |.4.I..k.........| 000000d0 88 52 fb 87 e3 7f 00 00 88 52 fb 87 e3 7f 00 00 |.R.......R......| 000000e0 4f 57 6b 54 49 54 61 36 2f 6e 64 77 4a 34 35 6a |OWkTITa6/ndwJ45j| 000000f0 2f 74 70 4d 4a 45 6e 6f 69 53 63 51 6c 62 65 30 |/tpMJEnoiScQlbe0| 00000100 53 36 31 4b 6b 67 73 77 47 68 45 57 47 68 58 45 |S61KkgswGhEWGhXE| 00000110 54 37 66 77 41 41 41 41 67 4b 64 4c 4b 49 66 6b |T7fwAAAAgKdLKIfk| 00000120 55 69 4b 4d 67 5a 47 64 2b 37 61 42 39 76 6e 48 |UiKMgZGd+7aB9vnH| 00000130 57 4a 77 35 44 63 39 4b 69 52 78 67 69 6e 54 63 |WJw5Dc9KiRxginTc| 00000140 80 00 00 00 00 00 3c 6d 65 73 73 61 67 65 20 74 |......<message t| 00000150 79 70 65 3d 22 63 68 61 74 22 20 74 6f 3d 22 78 |ype="chat" to="x| 00000160 72 79 64 6a 65 6e 40 6f 70 65 6e 66 69 72 65 2f |rydjen@openfire/| 00000170 38 63 34 34 34 63 33 34 22 3e 3c 62 6f 64 79 3e |8c444c34"><body>| 00000180 64 69 73 63 6f 6e 6e 65 63 74 3f 20 09 20 20 09 |disconnect? . .| 00000190 09 09 09 20 09 20 09 20 09 20 20 20 09 20 09 20 |... . . . . . | 000001a0 20 09 20 20 20 09 09 20 20 09 20 3c 2f 62 6f 64 | . .. . </bod| 000001b0 79 3e 3c 2f 6d 65 73 73 61 67 65 3e |y></message>| 000001bcSome weird corruption going on there. Some poking with gdb showed more:
Of course it could be anything at this point, but the problem definitely did go away after disabling OTR. Also, I've never before seen this problem anywhere and this Jabber I/O code is five years old..