TReKiE / msnp-sharp

Automatically exported from code.google.com/p/msnp-sharp
0 stars 0 forks source link

Bind on a specific IP for connections #208

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. The servers has multiple IPs / network interfaces

What is the expected output? What do you see instead?
It connects with one (random ?) ip, but it would be great to be able to choose 
which network interface should connect to MSN servers.

What version of the product are you using? (MSNPSharp, OS, Mono etc.)
MSNPSharp 3.1.2 Beta with Mono on Debian Lenny

Is your code check out from SVN or download from our download site?
From the download page

Please provide any additional information below:
I have not seen this option in the source code or so, may be I missed it. If 
not, it's a feature request :) Thanks.

Original issue reported on code.google.com by davtj1@gmail.com on 3 Aug 2010 at 6:58

GoogleCodeExporter commented 9 years ago
Do you mean you want to select a MSN server for MSNPsharp to conected to? 
That's not a good idea because the MSN server is choosen by microsoft when 
MSNPSharp begin its login procedure.

Original comment by freezing...@gmail.com on 3 Aug 2010 at 12:22

GoogleCodeExporter commented 9 years ago
No when I refer to the server, I mean my server, not MSN server.
In my linux server, I have for example 4 IP addresses on 4 network interfaces 
(eth0 , eth0:0 , eth0:1 , eth0:2). I think it's almost the same on Windows.

If possible, I would like to choose one of these network interface (or the IP 
address assigned to it) when the TCP connection is made to MSN servers.

Please tell me if I'm not still clear enough. Thanks.

Original comment by davtj1@gmail.com on 3 Aug 2010 at 1:28

GoogleCodeExporter commented 9 years ago
Hi,
I've added this feature in r1672. Please check out the code in trunk. Set 
messenger.ConnectivitySettins properties.

Original comment by freezing...@gmail.com on 7 Aug 2010 at 9:07

GoogleCodeExporter commented 9 years ago
I have built the latest DEV library to test this revision, but I think I have a 
problem with the latest DEV on Mono, it says this when I launch my program:

Error: WebServiceBindingAttribute is required on proxy class 
'MSNPSharp.SecurityTokenServiceWrapper'.

This was not here on 3.1.2beta.

To make some more tests, I have integrated the diff of r1672 in the 3.1.2beta 
library and rebuilded it.

The new connectivitysettings properties are working, I can see that the IP I 
choose is used, but it semms it's not used for all connections, some 
connections are made with the choosen IP, and some others with an other random 
IP, may be this behavior would not be there is I have the last DEV, not sure.

If you know how to fix the proxy class error on mono I could move forward on 
these tests.

Thanks

Original comment by davtj1@gmail.com on 10 Aug 2010 at 12:20

GoogleCodeExporter commented 9 years ago
Hi,
I am sorry for the late reply. I've moved to USA 10 days ago and the place I 
lived does not have network access. Now I am looking for your issue. Please 
wait for good news :)

Original comment by freezing...@gmail.com on 19 Aug 2010 at 4:09

GoogleCodeExporter commented 9 years ago
How about current DEV version? Could you please check it out and take a look?

Original comment by freezing...@gmail.com on 20 Aug 2010 at 10:40

GoogleCodeExporter commented 9 years ago
Here are my results, I hope I made them correctly.
Compiled on VS2010 and launched on Mono like before.

1) current DEV still give me the error:
Error: WebServiceBindingAttribute is required on proxy class 
'MSNPSharp.SecurityTokenServiceWrapper'.

2) r1674 integrated (almost completly since files differences with latest DEV) 
in 3.1.2BETA still seems to have some connections made by an other IP than the 
one choosed.

So apparently the last revision did not change something.

If I look correctly to tcpdump, the first connection is correctly made with the 
choosen IP, but when it switch to an other MSN server (for the auth or 
switchboard or so I suppose) the IP used is not the fixed one.

Should I open an other ticket for 1) ?
I think it may help to have to latest dev working on Mono before making more 
tests on this feature, integrating latest revision manually on an older release 
is a bit weird  and I may do this incorrectly for the tests.

Original comment by davtj1@gmail.com on 21 Aug 2010 at 9:56

GoogleCodeExporter commented 9 years ago
Hi,

Yes, you can open a new issue for the first problem. But before doing that, 
please make a test for me, I relly appreciate your help!

Add a line above the definition of SecurityTokenServiceWrapper class, the new 
definition should look as follows:

    [WebServiceBindingAttribute(Name = "SecurityTokenServicePortBinding", Namespace = "http://schemas.microsoft.com/Passport/SoapServices/PPCRL")]
    public sealed class SecurityTokenServiceWrapper : SecurityTokenService
    {
             .....
    }

Then try to compile it in Mono.

Thanks!

Original comment by freezing...@gmail.com on 22 Aug 2010 at 1:38

GoogleCodeExporter commented 9 years ago
BTW, the class is in SecurityTokenServiceWrapper.cs, an add a refer to 
System.Web.Services at the beginning of the file.

Original comment by freezing...@gmail.com on 22 Aug 2010 at 1:40

GoogleCodeExporter commented 9 years ago
I made these changes, the error changed and is now:

Error: There was an error reflecting type 
'MSNPSharp.MSNWS.MSNSecurityTokenService.RequestMultipleSecurityTokensType'.

Original comment by davtj1@gmail.com on 22 Aug 2010 at 2:37

GoogleCodeExporter commented 9 years ago
Hi,

Is that a runtime error or a compile error? Can you give me more details? Or 
give me your makefile so that I can try by my own?

Original comment by freezing...@gmail.com on 24 Aug 2010 at 5:33

GoogleCodeExporter commented 9 years ago
It's a runtime error (like the "proxy class" error before), when I try to 
connect at the start of the program.
The same code is working great on 3.1.2beta .

The compilation of the MSNPSharp.dll is done on Visual Studio 2010 in Release 
mode and everything seems ok, and the compilation of the program is done with 
Mono, and there is also no error and no warning here.

Original comment by davtj1@gmail.com on 24 Aug 2010 at 8:32

GoogleCodeExporter commented 9 years ago
So running under .NET framework doesn't have this problem?

Original comment by freezing...@gmail.com on 25 Aug 2010 at 1:21

GoogleCodeExporter commented 9 years ago
Ok to make a full resume I made some more tests for you.

The MSNPSharp Library with latest DEV is compiled on Visual Studio 2010 (Win 
XP).

Then when my program is compiled on VS 2010:
- the run in Win XP is OK.
- the run in Linux give the "reflecting type" error above.

When my program is compiled on Mono:
- the run in Win XP is OK.
- the run in Linux give the "reflecting type" error above.

So the compilation is definitely not a problem I think.

Original comment by davtj1@gmail.com on 25 Aug 2010 at 7:06

GoogleCodeExporter commented 9 years ago
Hmmm....I compile the program under Mono 2.6.7 under my MacOSX with 
MonoDevelop, it throw runtime errors for all the image resources...

What's your Mono version?

Original comment by freezing...@gmail.com on 27 Aug 2010 at 5:57

GoogleCodeExporter commented 9 years ago
I have the version 1.9.1 since it's the latest available on Debian Lenny in 
stable.

You are talking about errors for image ressources, actually in my program I 
don't use image, it's just basically connect with the login/pass and retrieve 
contacts when connected, in console mode (since it's on a linux dedicated 
server, there is no window).

Original comment by davtj1@gmail.com on 27 Aug 2010 at 6:23

GoogleCodeExporter commented 9 years ago
ok, could you please check out the DEV version and test once more?

Original comment by freezing...@gmail.com on 28 Aug 2010 at 6:39

GoogleCodeExporter commented 9 years ago
The run of my program still return this error with last DEV:

Error: There was an error reflecting type 
'MSNPSharp.MSNWS.MSNSecurityTokenService.RequestMultipleSecurityTokensType'.

Original comment by davtj1@gmail.com on 30 Aug 2010 at 6:18

GoogleCodeExporter commented 9 years ago
Hi,

Now in the DEV, the 2nd issue has been fixed.

Original comment by freezing...@gmail.com on 5 Sep 2010 at 4:53

GoogleCodeExporter commented 9 years ago
The run of my program is now OK, there is not anymore the "reflecting type" 
error.
So I confirm this one is fixed.

For the bind IP feature, it seems there is still some connections made with 
random ip wich is not the one selected in connectivitysettings properties.

Thanks

Original comment by davtj1@gmail.com on 6 Sep 2010 at 11:11

GoogleCodeExporter commented 9 years ago
Are those IP for the http/https connections? I cannot control those local IP 
since they are created by Soapclient..

Original comment by freezing...@gmail.com on 7 Sep 2010 at 5:08

GoogleCodeExporter commented 9 years ago
I analyzed the network trafic and you are right, MSN trafic is done with the 
choosen IP address, but HTTPS trafic is done with an other random IP.

I'm not sure if this could help you or if it's definitly impossible to do, but 
may be there is some part of answer on this page:
http://www.yakkowarner.com/2008/11/calling-web-service-in-loop.html

If I understand well, it seems the override of the soap request is possible to 
give it a new ipendpoint.

Original comment by davtj1@gmail.com on 7 Sep 2010 at 8:32

GoogleCodeExporter commented 9 years ago
Thanks, I will have a try. Please wait for my good news.

Original comment by freezing...@gmail.com on 11 Sep 2010 at 10:02

GoogleCodeExporter commented 9 years ago
Hi,

Have a look at the current DEV, I think it's done.

Original comment by freezing...@gmail.com on 12 Sep 2010 at 5:31

GoogleCodeExporter commented 9 years ago
That was fast :) This seems to work great, msn and https trafic go through the 
choosen IP address.

There is only last thing, there is also some http trafic with the wrong IP. The 
program connect to byfiles.storage.live.com, I suppose it's for the retrieve of 
the display image or so.

I think it will be the last change for this ticket :)

thanks !

Original comment by davtj1@gmail.com on 12 Sep 2010 at 9:57

GoogleCodeExporter commented 9 years ago
Hi man,

Just try this, I think it is fixed now!

Original comment by freezing...@gmail.com on 13 Sep 2010 at 8:41

GoogleCodeExporter commented 9 years ago

Original comment by hepha...@gmail.com on 13 Sep 2010 at 4:08

GoogleCodeExporter commented 9 years ago
it works, http trafic is also going through the right IP.

thanks for all these fixes and features

Original comment by davtj1@gmail.com on 13 Sep 2010 at 9:38

GoogleCodeExporter commented 9 years ago
You are welcome man,haha!

Original comment by freezing...@gmail.com on 15 Sep 2010 at 12:50

GoogleCodeExporter commented 9 years ago
Thank you :) It is nice to see you again ;)

Original comment by hepha...@gmail.com on 16 Sep 2010 at 10:35