Adium

Opened 14 years ago

Closed 12 years ago

#2528 closed defect (fixed)

OTR endless loop trying to resend long message

Reported by: trac-adiumx-otr-loop@g.gshapiro.net Owned by: evands
Milestone: Adium 1.3 Component: OTR
Version: Severity: normal
Keywords: Cc:
Patch Status:

Description (last modified by Chris Forsythe)

If you try to send a long message with OTR (485 bytes/15 lines in my example), it will report:

?OTR Error: You transmitted a malformed data message
The last message to foo_at_bar_or_baz was resent.

Unfortunately, the resend fails for the same reason (size) and tries to resend again and again in what appears to be an endless loop. Unfortunately, it also sends the bogus data to the remote side which gives an error as well bothering both sides of the conversation. Closing the window doesn't help (reopens for further resends). The only recourse is to quit Adium.

Change History (9)

comment:1 Changed 14 years ago by Chris Forsythe

Description: modified (diff)

Removing name at submitters request.

comment:2 Changed 14 years ago by trac-adiumx-otr-loop@…

I did some research and this is a libotr problem. From the otr-users mailing list:

From: ian@cypherpunks.ca (Ian Goldberg)
Date: Sat, 17 Dec 2005 13:04:07 -0500
Subject: [OTR-users] Making a distribution of Gaim with OTR preinstalled
Message-ID: <20051217180406.GL4463@smtp.paip.net>

On Sat, Dec 17, 2005 at 05:41:35PM +0000, Shane M. Coughlan wrote:
> Now, an issue we've noticed during our OTR test conversations is that
> long messages passing through Yahoo! (and possibly other networks)
> sometimes generate a loop.  Gaim complains its a badly formed message,
> and it attempts (infinite loop) to resend the message.  It's a little
> annoying, and does not occur when OTR is not enabled.

The "right" way to solve this is with fragmentation.  gaim-otr-3.0.0
included support for assembling fragments, but not for generating them.

There are two hard parts of fragmenting long messages:

1. How do you know what size of fragment to use?
2. Some networks have a rate-limiter that trips when you try to send
   messages (i.e. fragments) too quickly.

The only plausible solution to #1 is icky (hard-code maximum sizes for
each known network, ugh).  The IM networks simply don't in general provide
enough information to determine the maximum size at runtime.

#2 is really a bug in gaim: it's already got code that's supposed to
automatically throttle outgoing messages, based on the networks'
reported rate limits, but, last I checked, it didn't work.  Maybe the
new gaim-2 has fixed it, though.

It's definitely something we're keeping in mind, though.  This is
discussed from time to time on the otr-dev list.

   - Ian

comment:3 Changed 14 years ago by Chris Forsythe

Milestone: Waiting on libotr

comment:4 Changed 13 years ago by Eric Richie

Anyone know is this have been fixed yet?

comment:5 Changed 12 years ago by chvo

This might be fixed in the new version (libotr-3.1.0):

from the dev mailing list:

[OTR-dev] libotr and pidgin-otr 3.1.0-preview1 available 
Ian Goldberg ian@cypherpunks.ca 
Tue, 24 Jul 2007 16:11:04 -0400 

Previous message: [OTR-dev] finished converstations a bad UI choice! 
Next message: [OTR-dev] libotr and pidgin-otr 3.1.0-preview1 available 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 

--------------------------------------------------------------------------------

Boy, has this been a long time coming.  See what happens when Real Life
gets in the way?  Luckily, I was recently able to get part of said life
to be working on OTR (along with an additional developer).

For the impatient:

http://otr.cypherpunks.ca/libotr-3.1.0-preview1.tar.gz
http://otr.cypherpunks.ca/pidgin-otr-3.1.0-preview1.tar.gz

[Also on sourceforge's cvs.]

The major changes:

- Added fragmentation support for large messages

- Added an option to turn off logging of OTR conversations

- Internationalization of the pidgin-otr part (but not yet the libotr
  part)

- Makefile.static builds pidgin-otr.so with libgcrypt.so linked
  statically to avoid the libgcrypt multiple-clients bug.  (At least on
  Linux; I can't vouch for how well that Makefile will work on other
  OSes.)

And the coolest one:

- Added the ability to authenticate your buddies without ever having to
  see the word "fingerprint", or an obnoxious string of hex chars.  The
  old "verify fingerprint" dialog is still available behind an
  "Advanced..." button, if needed (for communicating with old clients,
  say).

comment:6 Changed 12 years ago by phy1729

This has been fixed in 3.1.0: "Large messages are now fragmented transparently instead of failing" http://www.cypherpunks.ca/otr/

comment:7 Changed 12 years ago by Eric Richie

Milestone: Waiting on libotrNeeds dev review
Patch Status: None
pending: 0

comment:8 Changed 12 years ago by Evan Schoenberg

Milestone: Needs dev reviewAdium X 1.3
Owner: changed from nobody to Evan Schoenberg
Status: newassigned

comment:9 Changed 12 years ago by Evan Schoenberg

Resolution: fixed
Status: assignedclosed

(In [23282]) OTR.framework 3.1.0 and associated changes. Large messages are now automatically fragmented instead of failing. This also adds support for SMP, the Socialist Millionaire's Protocol, but does not implement the UI for it yet (so we continue to use fingerprints, which work as before, for contact verification). Fixes #2528. Fixes #7485.

Note: See TracTickets for help on using tickets.