[OTR-dev] Fwd: Re: pidgin-otr problems receiving packets

[Moritz Warning]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I discovered that you can put a file called otr.max_message_size (<protocol>\t<max_packet_size>\n)
in the .purple directory. That did the trick. :D

Thought, this is far from satisfying. This is quite some hassle and
users won't find this out easily without extensive search.
I think I've got this issue before a few years ago using pidgin and some
other protocol and never figured it out - and gave up.

Can something be done?

On 10/21/2013 09:54 PM, Moritz Warning wrote:
> I think this was intended to go to the list. :)
> 
> -------- Original Message --------
> Subject: Re: [OTR-dev] pidgin-otr problems receiving packets
> Date: Mon, 21 Oct 2013 21:47:32 +0200
> From: Moritz Warning <moritzwarning at web.de>
> To: Paul Wouters <paul at cypherpunks.ca>
> 
> On 10/21/2013 09:07 PM, Paul Wouters wrote:
>> On Mon, 21 Oct 2013, Moritz Warning wrote:
> 
>>>> That looks like a bug. OTR fragments start with "?OTR|", not "?OTR:"
>>>> So your first packet appears to be unfragmented according to the
>>>> protocol. The second message should also start with a "?OTR|" prefix.
>>>>
>>>> It looks like the message got fragmentated at another layer?
>>>>
>>>> Paul
>>>
>>> Ok, if I understand you correctly, then OTR fragments packages itself.
>>> But how does OTR know on what size/when to fragment the packets?
>>>
>>> I just get a big string, split it up and transmit it.
>>> On the other size both packets are received as independent messages.
>>>
>>> There is a way to tell the caller (OTR in this case)
>>> that the message is too long. That is I have to return -E2BIG.
>>> But that didn't seem to have an effect on the OTR plugin.
> 
>> Since OTR is protocol agnostic, the fragment size is someting you need
>> to tell OTR, as it depends on the transport used. IRC and SMS and XMPP
>> and MSN have different packet sizes.
> 
>> I assume pidgin-otr has these hardcoded per transport protocol, and just
>> informs libotr of these. You'd have to check the code.
> 
>> Paul
> 
> 
> I've poked around the otr-plugin code and found the table.
> These seem to be the supported protocols:
>  mmsPairs[] = {{"prpl-msn", 1409}, {"prpl-icq", 2346},
> 	{"prpl-aim", 2343}, {"prpl-yahoo", 799}, {"prpl-gg", 1999},
> 	{"prpl-irc", 417}, {"prpl-oscar", 2343},
> 	{"prpl-novell", 1792}, {NULL, 0}};
> 
> Won't it be possible to just reduce the message size as long
> the protocol sending function returns -E2BIG?
> I don't have much hope for my puny protocol to be included in
> the list above.
> 
> yup,
> mwarning
> 
> 
> Btw.: The code is a mix of tabs and spaces. :>
> Maybe apply something like this:
> astyle --lineend=linux --suffix=none --style=kr --indent=force-tab --formatted --recursive "*.c" "*.h"
> 
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJSZY7WAAoJECHrh56PP4wp8GMIAMpAIJdG7JSjNwHSPeZehP+m
0lIocJYVzx1p9Jr8Mfyr7GZxVyYhQsAZ4lF++QQgTEzT0EymAlcrR4uWdeo0Gfmu
xrQmjwZhPCRuaOt5iligj9gLjIgK/3W6MyLagCOJfR/pn3UXs93wwSEvUU4kCulf
h5fAZNIOHBnk8xwPWC+1YcaFr4kKn13BSDrkDb+xA4qrnBc9pohL8gTkIqYKCR+o
KrSV2twQTxsZImF9QhLIFALegq9aRrApl/Yd67UNg01HFx6B0FSv3CZv3kYarsyS
FykgdVQDD6O4Gygp+GY7BKw+uSEh0xAu05pLW2NZFgKMz83CZj41mvIRfJxC63U=
=+vJ0
-----END PGP SIGNATURE-----