Bug 113525

I confirm this bug.
Another thing, the msn client of the person I was sending a file to showed the name of the transferred file with an additional lead character (shown as a "?") and several trailing characters. It started to happen after last svn commit to the msn module 4 days ago.

I confirm it too, using KDE 3.5 beta 1

I *think* it may have to do with MSN 7.5, as I can get files perfectly from a contact with MSN 7.0 but not from two friends with MSN 7.5

Upload always seems to work though

I confirm this bug too, using latest svn kopete version.

*** This bug has been confirmed by popular vote. ***

doing an lsof|grep kopete shows hundreds of open streams pointing to the file and also if i cancell this transfer, kopete crashes

Created attachment 12990 [details]
problem mentioned in comment #2

I can confirm this bug with the latest svn version.
I also can confirm the problem mentioned in comment #2. See the attached image.

Confirmed - using SVN version...

I am using the current SVN versions of kopete and kdelibs - I get this problem too. As in #2, I too, have received correctly from 7.0 users, and seem to get this with 7.5 users.

Just another me too.
And if the file transfer works with the 7.0 clients is it relayed over the MSN proxies? The filetransfer is really slow and I think it's not a direct connection is it?

Confirmed with latest svn and msn 7.5. 

*** Bug 116950 has been marked as a duplicate of this bug. ***

confirmed this and still no fix from todays svn version

Confirmed using Kopete 0.11 (KDE 3.5.0) when receiving files from Mac Messenger 5.0.

Confirmed using kopete 0.11 and KDE3.5. Sender was someone using the official MSN client @ windows.

This does not happen with Kopete 0.10.3. I know the code has been heavily refactored between 0.10.x and 0.11.x , but it may be worthwile to try to revert back to the old MSNP2P code until developers find what has changed.

From what I heard, the developer that coded the MSN plugin isn't working on it any more, so I wouldn't hold my breath while waiting for a fix... Unless someone else out there knows about the MSN protocol...

SVN commit 491170 by goossens:

Do not send the file name with a byte order marker, MSN Messenger does not like that. This fixes the issue with strange characters in the file name.

CCBUG:113525
This does not fix the "empty file" bug...


 M  +1 -1      dispatcher.cpp  


--- branches/KDE/3.5/kdenetwork/kopete/protocols/msn/dispatcher.cpp #491169:491170
@@ -139,7 +139,7 @@
 	writer << (Q_INT32)1;
 	// Write the file name in utf-16 to the stream.
 	QTextStream ts(header, IO_WriteOnly);
-	ts.setEncoding(QTextStream::Unicode);
+	ts.setEncoding(QTextStream::RawUnicode);
 	ts.device()->at(20);
 	ts << path.section('/', -1);
 	// NOTE Background Sharing base64 [540..569]

In response to comment #16:

I haven't looked at any code, but it would seem that the problem lies in the saving of the data. The transfer seems to be working (although slowly), the only problem is saving the data in the right file. If this is so, then hopefully it won't require anyone with knowledge of the MSN protocol, just someone with knowledge of saving a stream of data to a file.

CodingSlave - I am the dev that works on this code.  I have implemented a fully working p2p api that supports direct file transfers and file preview along with other features.  The only problem that I have is that there is a bug that causes kopete to crash when using p2p therefore there is not point to commit my code until I can find and fix the bug.  I have isolated the problem to UDI requests.  I am not sure why the new code causes kopete to crash but I am almost positive that it is not my new code.

Gregg: it doesn't seem to work with a up-to-date kopete svn branch. how is the status of your new code? (btw it's good to hear you're workin' on it!)

I can confirm this bug with Kopete 0.11 on KDE 3.5. Any news on a resolution?

I can confirm the "0 bytes" bug. Althogh SOME of those bytes seem to be there after a restart of KDE, so - if there is an image somebody's sending to me, I can restart KDE and have a look at the top of the image (first couple of 100kbs or something). Anyone else noticed this "some-bytes-of-the-file-are-there-anyway-after-KDE-restart"-bug?

Yeah I can confirm that I do get some of the bytes from the beginning of the file after a kde restart.

I can confirm, too!

That would point to a problem with KIO ?

No, it wouldn't point to a problem in KIO, it would point to a problem in the MSN protocol. Nothing in Kopete uses KIO to actually download the data, we just use a hacky way to display the KIO progress dialog. (AFAIK)

Yes, I can see images before they reach 100%, you can even tail -f the file to see the progress.
I belive the bug is kind of trivial, something is erasing file's content when it reaches 100%. Don't get angry on me.. but it's provally just a matter of placing a IF on the right place.

The data gets written in chunks and periodically get back to 0.

Matt, what I was meaning is that maybe there is some kind of bad interaction between the hacky way to display the KIO progress dialog and KIO itself might be causing the issue.
If things reappears after a KDE restart, and I'm quite sure it doesn't happen for just quit/restart of kopete, it has to be touched by something outside Kopete scope, and KIO is the only thing I can think of..

But the new MSN protocol is the P2P?
And what protocol is kopete using now?

Gregg: at what point is your code?

Just another confirmation:
Kubunt5.10 & Kopete 0.11.1 & kde 3.5.1 & buddy msn 7.5.311.0

Reveiving and sending often don't get started, and when they do proceed the receiver always end up with a 0 Bytes file.

*** Bug 121334 has been marked as a duplicate of this bug. ***

Confirmed with kopete 0.11.1 (in KDE 3.5.1)

Also confirmed with kopete 0.11.1 w/ KDE 3.5.1

*** Bug 117014 has been marked as a duplicate of this bug. ***

Confirmed with 0.12 SVN as well

*** Bug 122039 has been marked as a duplicate of this bug. ***

Created attachment 14961 [details]
Fix (or workaround) for MSN file transfer

The attached patch fixes MSN file transfer with MSN 7.5 for me.

According to some debug output I added, what happens during a file transfer is
the following:

MSN 7.5 initiates the connection, sends an INVITE and about 20kB of data. Then,
it sends a new INVITE and another 20kB of data. It keeps going like that until
the entire file has been transferred.

Kopete on the other hand expects an INVITE to be sent once per transfer, at the
very beginning. An INVITE triggers a file open operation, which, if the file
exists already, truncates it to zero size. And this is exactly what happens
when the INVITE appears during a transfer - the file gets truncated.

The attached patch is a one-liner. It simply checks whether a file is being
transferred already and if so, refrains from reopening the file. The good news
is that this fixes file reception for me; I tried with a small ~ 100kB file and
a large 20MB one.

The bad news is that file transfer is unbelievably slow. Each time 20kB have
been sent, MSN 7.5 stalls for a few seconds before sending the INVITE and more
data. It looks like it's waiting for some kind of intermediate acknowledge. The
ack never comes, so MSN times out at some point, resets the connection, sends
the INVITE and a bit more data. All the online resources I found claim there is
only one ack at the end. Maybe MSN 7.5 introduced something extra that Kopete
(and others) are missing? Unfortunately, my knowledge of the MSN protocol is
precisely zero, so I don't know what this ack could look like. Also, I don't
have two machines running Windows between which I could sniff a transfer from
say MSN 7.5 to MSN 6.x.

Maybe this quick hack can be committed to at least fix the dataloss for 0.12
and someone else can pick it up from here?

Created attachment 14962 [details]
Fix (or workaround) for MSN file transfer

Here's the same patch again with paths relative to the Kopete's base directory
in SVN.

SVN commit 516056 by mlarouche:

BUG: 113525

Workaround fix about zero-sized MSN file transfer bug.
Patch by Bartosz Fabianowski, thank you dude.



 M  +17 -10    incomingtransfer.cpp  


--- branches/kopete/0.12/kopete/protocols/msn/incomingtransfer.cpp #516055:516056
@@ -256,19 +256,26 @@
 			{
 				// NOTE The sending client can ask for a direct connections
 				// if one was established before.
-				QFile *destionation = new QFile(m_transfer->destinationURL().path());
-				if(!destionation->open(IO_WriteOnly))
+				if(!m_file)
 				{
-					if(m_transfer){
-						m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
-						m_transfer = 0l;
+					QFile *destionation = new QFile(m_transfer->destinationURL().path());
+					if(!destionation->open(IO_WriteOnly))
+					{
+						if(m_transfer){
+							m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
+							m_transfer = 0l;
+						}
+						
+						error();
+						return;
 					}
-					
-					error();
-					return;
+				
+					m_file = destionation;
 				}
-			
-				m_file = destionation;
+				else
+				{
+					// TODO
+				}
 			}
 			
 			m_state = DataTransfer;

SVN commit 516060 by mlarouche:

Backport to KDE 3.5.2 of:

Workaround fix about zero-sized MSN file transfer bug.
Patch by Bartosz Fabianowski, thank you dude.

CCBUG: 113525



 M  +17 -10    incomingtransfer.cpp  


--- branches/KDE/3.5/kdenetwork/kopete/protocols/msn/incomingtransfer.cpp #516059:516060
@@ -256,19 +256,26 @@
 			{
 				// NOTE The sending client can ask for a direct connections
 				// if one was established before.
-				QFile *destionation = new QFile(m_transfer->destinationURL().path());
-				if(!destionation->open(IO_WriteOnly))
+				if(!m_file)
 				{
-					if(m_transfer){
-						m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
-						m_transfer = 0l;
+					QFile *destionation = new QFile(m_transfer->destinationURL().path());
+					if(!destionation->open(IO_WriteOnly))
+					{
+						if(m_transfer){
+							m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
+							m_transfer = 0l;
+						}
+						
+						error();
+						return;
 					}
-					
-					error();
-					return;
+				
+					m_file = destionation;
 				}
-			
-				m_file = destionation;
+				else
+				{
+					// TODO
+				}
 			}
 			
 			m_state = DataTransfer;

Created attachment 14979 [details]
*Real* fix for MSN file transfer

Ladies and gentlemen...
After a whole night of logging, packet sniffing, cursing and coding, I present
you... a patch that actually fixes the *real* bug in MSN file transfers.

The real problem was that for a file transfter, the connection INVITE must
*never* be acknowledged or replied to with a 200 OK. It should simply be parsed
for information and then discarded. I know this is documented differently on
websites dealing with the MSN protocol, but this is what the MSN client does
and expects. MSN 7.0 might swallow the 200 OK, MSN 7.5 does not. It starts
sending more INVITEs with increasing port numbers, apparently waiting for a
direct connect or something.

Once the above was fixed, a second problem surfaced. On the first file transfer
between two clients, session and transfer INVITEs must be sent. But on
subsequent connections, the second INVITE may (or must) be omitted. Kopete was
waiting for the second INVITE and although data was being received, it was not
being saved to anywhere. This meant that after only one file transfer per peer
would work. The data received in all later transfers would just get discarded.

Both problems are fixed in the attached patch, which also removes my curde hack
from the previous patch. I have taken great care to affect file transfers only.
Buddy icons seem to be unaffected and transfer fine for me. Webcam I cannot
test due to lack of hard- and software. It could be, of course, that similar
changes are required there at some point.

This patch is dedicated to Phil B who helped me with logging all night. And
it's also dedicated to the unknown lady whose pink boots served as a test jpg
for our file transfers :).

I forgot to mention that the patch has been tested with file transfers from:
* MSN 7.0
* MSN 7.5
* Gaim 2.0 Beta
All files transfer fine (though very slow because they are going through the server)

w00t! it worked for me, from a 7.5 user. he said "holy crap that was
fast for this connection" :)
but, one other user says it failed when sending from amsn... so we
might want to test more...

When I get a chance, I can try logging a file transfer session from amsn to see what's wrong. But this won't be until next weekend. If anybody has time before, be my guest. Just send any file (about 100kB of data is perfect) from amsn to:

a) any client where the transfer succeeds
b) Kopete where the transfer fails

Then email me the ethereal logs so I can figure out what's wrong.

On 3/6/06, Chanika <chanika@gmail.com> wrote:
> w00t! it worked for me, from a 7.5 user. he said "holy crap that was
> fast for this connection" :)
> but, one other user says it failed when sending from amsn... so we
> might want to test more...
>


confirmed with Yagami - when he applies the patch, he can't send or
receive any files at all. but with the first hack he could.
but... I can't see anything he did differently than me. and it all
works fine for me.

after more testing... it seems I can send/receive with friend using
7.5, can send to friend using trillian but can't receive. can't find
anyone else awake.

and I was about to commit this, too. *sigh* evil MS.

Really, I need ethereal logs to do something about this...
I removed a 200 OK packet from the chain which some clients might be desperately waiting for. If that's the case, we have a bit of a problem as we will need to behave differently based on what client the other side is using. Maybe a dirty hack like waiting for a second or two and if nothing happens sending a 200 OK would work.

> ------- Additional Comments From freebsd chillt de  2006-03-06 16:23 -------
> When I get a chance, I can try logging a file transfer session from amsn to see what's wrong. But this won't be until next weekend. If anybody has time before, be my guest. Just send any file (about 100kB of data is perfect) from amsn to:
>
> a) any client where the transfer succeeds
> b) Kopete where the transfer fails
>
> Then email me the ethereal logs so I can figure out what's wrong.


well, it turns out it wasn't specific to amsn at all (he couldn't get
or send files from msn users, or from me, or anyone).
what ports does msn use for filetransfers? if I let ethereal capture
everything it gets way too much garbage.

--
This insane ranting was brought to you by evyl bananas, and the number 3.
www.chani3.com

MSN uses ports in the 1000-2000 range from what I can tell. But it doesn't really matter. For future reference, here is what I need:

Run ethereal and capture all the connections in your network. Doesn't matter how many there are. Then, look at the Ethereal output and look for packets of type MSNMS. Either that, or use Ethereal's search feature and look for packets containing the string "INVITE". Then, right-click on any of the packets and select "Follow TCP Stream". Save the stream as a Hex Dump (this is really important) and email it to me. This way, I will get the data sent by MSN only. The tool I have written for analyzing packets uses Ethereal hex dumps for input, so this is the perfect format for me.

also, I can send to a gaim user fine, and receive, except it stops at
100% and never closes the transfer when I'm receiving. o.0
...and I forgot to run ethereal for that one, but I did for the next
one with a different person... and it looks as if the start of the
file is missing. weirdness. uhoh, late for work, will send you
ethereal stuff later if you want.

If anybody sends me logs, please make sure to include a description what was being sent from where to where and with what results. Also, attach the file you were transferring please.

SVN commit 516426 by chani:

CCBUG: 113525
better fix for msn filetransfers. much faster receiving from 7.5 users, but might have issues with trillian n'stuff.
Thanks to Bartosz Fabianowski for this great patch :)



 M  +26 -31    incomingtransfer.cpp  


--- branches/kopete/0.12/kopete/protocols/msn/incomingtransfer.cpp #516425:516426
@@ -99,9 +99,24 @@
 		case Invitation:
 				// NOTE UDI: base identifier acknowledge message, ignore.
 				//      UDI: 200 OK message should follow.
-				if(m_type == File){
+				if(m_type == File)
+				{
 					// FT: 200 OK acknowledged message.
-					// Direct connection invitation should follow.
+					// If this is the first connection between the two clients, a direct connection invitation
+					// should follow. Otherwise, the file transfer may start right away.
+					if(m_transfer)
+					{
+						QFile *destination = new QFile(m_transfer->destinationURL().path());
+						if(!destination->open(IO_WriteOnly))
+						{
+							m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
+							m_transfer = 0l;
+							
+							error();
+							return;
+						}
+						m_file = destination;
+					}
 					m_state = Negotiation;
 				}
 			break;
@@ -249,38 +264,18 @@
 					"Hashed-Nonce: {00000000-0000-0000-0000-000000000000}\r\n"
 					"\r\n";
 			}
-
-			acknowledge(message);
-
-			if(m_transfer)
+			
+			m_state = DataTransfer;
+			
+			if (m_type != File)
 			{
-				// NOTE The sending client can ask for a direct connections
-				// if one was established before.
-				if(!m_file)
-				{
-					QFile *destionation = new QFile(m_transfer->destinationURL().path());
-					if(!destionation->open(IO_WriteOnly))
-					{
-						if(m_transfer){
-							m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
-							m_transfer = 0l;
-						}
-						
-						error();
-						return;
-					}
+				// NOTE For file transfers, the connection invite *must not* be acknowledged in any way
+				//      as this trips MSN 7.5
 				
-					m_file = destionation;
-				}
-				else
-				{
-					// TODO
-				}
+				acknowledge(message);
+				// Send 200 OK message to the sending client.
+				sendMessage(OK, content);
 			}
-			
-			m_state = DataTransfer;
-			// Send 200 OK message to the sending client.
-			sendMessage(OK, content);
 		}
 		else if(body.startsWith("BYE"))
 		{

SVN commit 516513 by mlarouche:

Backport to KDE 3.5.2:

CCBUG: 113525

better fix for msn filetransfers. much faster receiving from 7.5 users, but might have issues with trillian n'stuff.
Thanks to Bartosz Fabianowski for this great patch :)



 M  +26 -31    incomingtransfer.cpp  


--- branches/KDE/3.5/kdenetwork/kopete/protocols/msn/incomingtransfer.cpp #516512:516513
@@ -99,9 +99,24 @@
 		case Invitation:
 				// NOTE UDI: base identifier acknowledge message, ignore.
 				//      UDI: 200 OK message should follow.
-				if(m_type == File){
+				if(m_type == File)
+				{
 					// FT: 200 OK acknowledged message.
-					// Direct connection invitation should follow.
+					// If this is the first connection between the two clients, a direct connection invitation
+					// should follow. Otherwise, the file transfer may start right away.
+					if(m_transfer)
+					{
+						QFile *destination = new QFile(m_transfer->destinationURL().path());
+						if(!destination->open(IO_WriteOnly))
+						{
+							m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
+							m_transfer = 0l;
+							
+							error();
+							return;
+						}
+						m_file = destination;
+					}
 					m_state = Negotiation;
 				}
 			break;
@@ -249,38 +264,18 @@
 					"Hashed-Nonce: {00000000-0000-0000-0000-000000000000}\r\n"
 					"\r\n";
 			}
-
-			acknowledge(message);
-
-			if(m_transfer)
+			
+			m_state = DataTransfer;
+			
+			if (m_type != File)
 			{
-				// NOTE The sending client can ask for a direct connections
-				// if one was established before.
-				if(!m_file)
-				{
-					QFile *destionation = new QFile(m_transfer->destinationURL().path());
-					if(!destionation->open(IO_WriteOnly))
-					{
-						if(m_transfer){
-							m_transfer->slotError(KIO::ERR_CANNOT_OPEN_FOR_WRITING, i18n("Cannot open file for writing"));
-							m_transfer = 0l;
-						}
-						
-						error();
-						return;
-					}
+				// NOTE For file transfers, the connection invite *must not* be acknowledged in any way
+				//      as this trips MSN 7.5
 				
-					m_file = destionation;
-				}
-				else
-				{
-					// TODO
-				}
+				acknowledge(message);
+				// Send 200 OK message to the sending client.
+				sendMessage(OK, content);
 			}
-			
-			m_state = DataTransfer;
-			// Send 200 OK message to the sending client.
-			sendMessage(OK, content);
 		}
 		else if(body.startsWith("BYE"))
 		{

well ... this *real fix* never worked for me.

and it even makes kopete crash when i cancel the file transfer in amsn.

dunno why this is backported , the earlier fix before ( the one that just tested to see if the file was already existed ) although slow , was working

Re comment #53: I know MSN file transfers are icky and I fully expected that this fix would require further tweaks for some corner cases. But as it gets us in line with what the official client does, I still consider it an improvement.

If at all possible, please send me a packet log of a transfer that makes Kopete crash. I can then see what packet Kopete dies on and should be able to fix this.

I've got Ethereal working properly now. If you're experiencing crashes or other problems with MSN file transfers, please add my MSN account bartoszfabianowski@hotmail.com to your contact list. I can then log a file transfer between our clients.

Note though that on my side, I have only Kopete available. If you are having problems with a transfer between say aMSN and Kopete, you will have to provide the aMSN side.

There is really *nothing* I can do without more input from others. The patch is working perfectly for me and as long as I have no way of reproducing the problems others are experiencing, I cannot fix them.

Phil B and me just did some logging with aMSN. The findings are not encouraging.

For starters, aMSN will not begin sending a file unless it receives the "200 OK" message that trips the official client. So it's either proper transfer to MSN 7.5 or to aMSN. My vote goes to MSN 7.5... it's much more widely distributed.

If I send aMSN the "200 OK", it will begin sending, but will stop after a single packet. It must be waiting for something, but I can't figure out what. Data packets should not be acknowledged. I added an acknowledge just to make sure, but it makes no difference. No idea how to get the transfer going.

aMSN switched to MSFTP as its primary file transfer protocol a while ago and it might just be that their MSNSLP support has been bitrotting for a while. It doesn't seem to behave in a sensible way - or I'm too dense and somebody else will beed to figure it out ;).

 > ------- Additional Comments From freebsd chillt de  2006-03-08 04:26 -------
> Phil B and me just did some logging with aMSN. The findings are not encouraging.
>
> For starters, aMSN will not begin sending a file unless it receives the "200 OK" message that trips the official client. So it's either proper transfer to MSN 7.5 or to aMSN. My vote goes to MSN 7.5... it's much more widely distributed.
>


maybe we need to be talking to developers of these other msn
clients... seems to me there's no way we can be properly compatible
with the latest protocol changes, without breaking filetransfers for
at least *some* older clients. it'd be better if we could get all the
popular ones updated together, combine our efforts to understand this
mess n'stuff.

*curses MS again* they just always have to be different, don't they? :P

--
This insane ranting was brought to you by evyl bananas, and the number 3.
www.chani3.com

> maybe we need to be talking to developers of these other msn
> clients...

Perhaps this is the most open minded thing someone said in this bug discussion. Bartosz's efforts are trully touching, but on the other hand an arrogant user could very easily make the obvious question: "Gaim is open source and MSN file transfer is working, isn't it ? Why don't you guys take a look at what gaim does and do the same in kopete ?"

Well, from the developer's point of view I know that this isn't as easy as it sounds, but at least you could seek help from someone that has implemented a working msn file trasnfer.

Sniffing a closed source client like MSN 7.5 and watching the network traffic in low level, face it, it's the hard way.

And why is the bug's status marked as resolved ? It's way far from that.
Please reopen it.

Re comment #58:

I have looked at GAIM's source. They have code for SLP (part of the file transfer protocol we are discussing here) in there, but it's hard to follow. Kopete's code is even worse. In both cases, the code is scattered around several files and there are complicated interactions in there such as state changes when certain packets or acknowledgements arrive. To make matters worse, in Kopete, file transfer, buddy icon transfer and webcam reception are all in the same code with lots of special cases where the three differ. I am *really* hoping that for KDE 4, those will be split into three separate classes in separate files. It's almost impossible to modify one of the three witout breaking the others.

I am not sure what GAIM gets right and what it doesn't. I only use Kopete. And as all of my MSN-using contacts are computer illiterate, it would be impossible for me to run experiments with them to capture logs even if I did install GAIM. All I can rely on right now are the likes of Phil B, Chanika and Yagami who kindly offered to help with logging.

Finally, if in some situtations other clients work while Kopete fails, the explanation is likely to be MSNFTP. As I mentioned before, this is the new file transfer protocol that was introduced by MSN 7.5 and which is not supported by Kopete (yet). Since aMSN implements MSNFTP, it can talk to the official client and to all other MSNFTP-aware clients using that protocol. Their SLP implementation is only used with "legacy" clients and is therefore likely to contain all sorts of hacks. Kopete can't afford to put any hacks into the SLP code as that would break compatibility with MSN 7.5. The only sane way out of this is for somebody with enough free time (that rules me out, unfortunately) to implement MSNFTP. Only then could we start hacking Kopete's SLP support to work with all sorts of legacy clients. Transfer to and from aMSN would certainly be fixed by this, as the clients would automatically switch to MSNFTP. The same might go for GAIM - if they support MSNFTP, which I am not sure about.

By MSNFTP, you mean Direct Transfer ?

I'll take that into account seperating P2P transfert context in my MSN plugin rewrite( /trunk/KDE/kdenetwork/kopete/protocols/messenger/).

No, I mean a completely different protocol. See:

http://www.hypothetic.org/docs/msn/client/file_transfer.php

The first half of that page describes MSNFTP, the second refers to the SLP based protocol currently used by Kopete. SLP supports both server-based and P2P connections. MSNFTP is P2P only as far as I can tell.

This documentation is wrong. MSNFTP is actually the old file transfer protocol. 

MSNSLP is the new one, it has can direct transfer which Kopete do not support yet.

With all the errors in the protocol docs floating around the net, I am not surprised. But what *does* surprise me is that aMSN's documentation claims it supports an "old" and a "new" protocol. When connected to the newest official client, MSN 7.5, aMSN will use MSNFTP. So it looks like for aMSN, MSNFTP is the "new" protocol. What a mess file transfers in MSN are...

Kopete supports MSNFTP as well (it's in msnfiletransfersocket.{cpp,h})
Or maybe it was removed, and you need to get theses files from previous versions.

You can know what client the other side is using with x-clientcap messages.
the client string is one property of the contact.

So you can act differently if the contact is some version of aMSN.
But one should ask aMSN developper to fix the bug in their client also.

btw, thanks for your work

It's good to know the client can be identified. I was looking for something like that.

I will dig into aMSN's code when I get the time to try and find out what their SLP implementation is waiting for before it starts sending packets. Maybe it's something little I can fix before 0.12.

I think that this fix should be temporary and that kopete should implement newer MSNFTP protocol.
Also it should be able to get the public IP from somewere so opening the right port on the router will allow us to send files with a P2P protocol instead of using MSN servers, that are slow.

Cheers

Having the option of using the MSN servers would be a Good Thing, for people who aren't in control of which ports on the router are open.

Don't worry. Nobody wants to remove the server-based transfer protocol. P2P transfers will be implemented *in addition* to what's already there. But it really is very, very unlikely to happen in the 0.12 timeframe. The MSN plugin will be rewritten for KDE 4 and it is to be expected that the new version will have P2P. The 0.12 code won't change much anymore.

Matteo wrote in comment #68:
> I think that this fix should be temporary and that kopete should implement
> newer MSNFTP protocol. 

the MSNFTP protocol is an *OLD* protocol and *IS* implemented in kopete since 2002

Kopete by default use the new SLP protocol to send file over MSN, an option to use MSNFTP instead should be trivial to add.
The implementation of the new SLP protocol is anyway partial, since it doesn't handle dirrect conexion yet
Coding Slave was working on a full implementation, but we have no news from him

*** Bug 123372 has been marked as a duplicate of this bug. ***

*** Bug 94340 has been marked as a duplicate of this bug. ***

*** Bug 124131 has been marked as a duplicate of this bug. ***

I have a problem when I receive one file from a gaim users

I have the same problem as #75 with Kopete 0.12.5

Other client is pidgin-2.2.1

What's strange too: The transfer never completes. It only works till 99.9 (~100%) and then stalls.