Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
P2P Issue Between Remote Networks RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    I've seen a couple threads and some bug submissions on issues relating to syncing P2P when systems are not on the same network.  I'm having the exact same issue.

    Sync works fine when the systems are on the same network.
    Sync works fine if the folder is synced to the Live Desktop.
    Sync only creates WLX files when the systems involved are not on the same network.
    The same problem occurs if multiple accounts are used with the systems on different networks (i.e. sharing my photos with family without putting on Live Desktop)

    I've submitted a bug, but it is similar to other bugs I see are closed, but no resolution is suggested.

    Any ideas?


    Here is my configurations:
    System 1:  Home PC.  Vista SP1
    Running McAfee Total Protection.  
    Firewall Exclusions are in place for Live Mesh Remote Desktop (wlcrasvc.exe), Mesh Operating Environment (moe.exe), and Moe Monitor (outbound only).  Current Antivirus.
    Sitting behind 2Wire router (NAT).

    System 2:  Work desktop, Vista SP1
    Running McAfee Antivirus
    Windows Firewall disabled.
    Behind corporate network, no proxy, fairly laxed internet access rules

    System 3: Work Laptop, Vista SP1
    Running McAfee Antivirus
    Secure Remote Firewall/vpn software.
    Windows Firewall disabled.
    Behind corporate network, no proxy, fairly laxed internet access rules
     
    System 4:  other family members, Windows XP sp3
    Behind NAT router
    Using different Live Mesh Accounts
    Initially was unable to sync my files, but once he made the following changes to the moe.exe.config sync was successful.  Unsure if it is still working on that system.
    Antivirus/FIrewall unknown
    <configuration>
      <microsoft.live.moe>
         <switches>
    <add name="VRRelayName" value="relay.data.edge.messenger.live.com"/>
         </switches>
      </microsoft.live.moe>
    </configuration>

    System 5:  other family members, Windows XP sp3
    Behind NAT router
    Using different Live Mesh Accounts
    Shared a folder with me, WLX files were created, but even after a week, no other files synced.  Edited moe.exe.config as above (and restarted MOE) and several days later, still no sync.
    Using McAfee Total Protection.

    Tuesday, February 17, 2009 1:22 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    Interesting.

    I disabled the firewall on both systems, and restarted MOE on mine, and shezam, it started syncing.

    Is there a list of what needs to be allowed by the firewall?  Both of the systems involved had Outbound connections allowed, and  MOE always got both directions allowed.
    Tuesday, February 17, 2009 2:31 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi Bozford,

    I'll try to attack the situation that you have control over - when people try to share a folder with you and you try to grab it via p2p:

    1. Have you made sure that Live Mesh is the latest version?
    2. Have you tried disabling Mcafee all together and then trying?
    3. Does your internet provider do any funky packet inspection in order to block things like bittorrent?
    4. What do your logs say? I imagine that they would have a lot to say about trying to initiate p2p sessions - and failing.

    What's the connect id of the bug that you submitted?

    Cheers
    Tuesday, February 17, 2009 1:46 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    In the words of Marla Singer, "Boy, you're fast!"  :)

    In answer to your questions: 

    Connect Feedback ID:
    https://connect.microsoft.com/LiveMesh/feedback/ViewFeedback.aspx?FeedbackID=414924

    1. Have you made sure that Live Mesh is the latest version?
    Yes.  I've been waiting for a fix since December, so I've been checking the blogs and verifying that I'm on the current version.
    2. Have you tried disabling Mcafee all together and then trying?
    I did on System 1 once upon a time (it didn't help) but will attempt it again.  On systems 2 & 3, I won't be able to disable the antivirus, as it's enforced by EPO.
    3. Does your internet provider do any funky packet inspection in order to block things like bittorrent?
    Not that I have seen.  I use AT&T UVerse with a mid tier bandwidth package, and have not heard any reports of traffic shaping.
    4. What do your logs say? I imagine that they would have a lot to say about trying to initiate p2p sessions - and failing.
    I did search in the log for P2P, and found the following block:

    2009-02-15 15:27:05.185,WARN,Moe,0,0,8,NativeTransports: Thread EF4 WindowsSocket::Error:534  WindowsSocket@074CEBA8: Async operation cancelled by failure 121
    2009-02-15 15:27:05.185,INFO,Moe,0,0,8,Session:Local:8b2ba144-9c0f-428f-b4ba-1b8d4288facc: No transports available
    2009-02-15 15:27:13.110,INFO,Moe,100,0,28,Comms: Processing notification Type:ResourceChanged, Watermark:7340.12882.0, ResourceLink:Devices/MBHHKZZAPNXUTG6JLEJIUE4XGA/DeviceConnectivityEntries, Reason:
    2009-02-15 15:27:13.110,INFO,Moe,107,0,28,Comms: Raising ResourceChanged event for resource     https://accounts.mesh.com/Devices/MBHHKZZAPNXUTG6JLEJIUE4XGA/DeviceConnectivityEntries. ResourceChanged received so far: 2040
    2009-02-15 15:27:13.110,INFO,Moe,100,0,28,Comms: 1 Notifications received from cloud. Acknowledging watermark:7340.12882.0
    2009-02-15 15:27:13.578,INFO,Moe,0,0,12,Session:Local:8b2ba144-9c0f-428f-b4ba-1b8d4288facc: Outgoing session establishment timed out (signaling=True, transport=False, security=True)
    2009-02-15 15:27:13.578,INFO,Moe,0,0,12,Session:Local:8b2ba144-9c0f-428f-b4ba-1b8d4288facc: Closing due to SessionError (error=Microsoft.Live.Moe.Communications.P2P.SessionTimeoutException: Session establishment timed out.)
    2009-02-15 15:27:13.578,INFO,Moe,0,0,8,NativeTransports: Transport shutdown callback after Close returned.
    2009-02-15 15:27:13.578,INFO,Moe,0,0,12,DeviceContext: RemoteDevice Devices/NY6TE7YZRSVUHMKNIIJWAM4JN4 - CloseChannel; isClientChannel:True
    2009-02-15 15:27:13.578,INFO,Moe,0,0,12,ChannelContext Id:620 RemoteDevice: ChannelType:Client-Dispose
    2009-02-15 15:27:13.578,INFO,Moe,0,0,12,Channel:Local:620: Abort calledConnect ID Bug:



    Tuesday, February 17, 2009 2:27 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Interesting.

    I disabled the firewall on both systems, and restarted MOE on mine, and shezam, it started syncing.

    Is there a list of what needs to be allowed by the firewall?  Both of the systems involved had Outbound connections allowed, and  MOE always got both directions allowed.
    Tuesday, February 17, 2009 2:31 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Awesome! Great to hear that the problem has been tracked down - the only problem is trying to fix it...

    This line from the logs:

    2009-02-15 15:27:13.578,INFO,Moe,0,0,12,Session:Local:8b2ba144-9c0f-428f-b4ba-1b8d4288facc: Closing due to SessionError (error=Microsoft.Live.Moe.Communications.P2P.SessionTimeoutException: Session establishment timed out.) 

    is a dead giveaway that the problem seems to be firewall related (or network).

    Do both of the machines have the VRRelayName fix? I know you mentioned that one of them does.

    Does your firewall log blocked connection attempts? I'm wondering if you could set it to log them all (if it doesn't) then attempt a P2P sync and see what process it is blocking (could it be MoeMonitor.exe instead of Moe.exe?) and on what ports?

    Also, I wonder if the problem is only on the other side - i.e. if you drop the firewall on one side will it still work? You'll have to drop it on each side sequentially to test.

    That's a lot of stuff to try out - so understandable if it isn't possible, thanks for the debugging anyway!

    Cheers,

    Oren
    Tuesday, February 17, 2009 3:08 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Yes, both systems have the VRRelayName fix.
     
    More testing (I don't mind, as I really want this to work!)

    As soon as I re-enable the firewall on the source system, sync stops dead.  ONce I disable the firewall on the source, and restart MOE, it picks right up where it left off.  I attempted disableing any DOS attach monitoring, and that didn't make a difference.  I've set the McAfee as low as it can go without disabling it, and still it kills the sync.  If the firewall is enabled on the target, it seems to kill the sync as well, but differently.  When enabling the sync on the source system, the sync continues for about 1/2 mb (i'm assuming what is still queued up on the Live servers), and then stops dead, and ends the sync (the arrow indicating a download in progress disappears along with the "x MB of X MB".  If you enable the firewall on the target system, the sync slows down, over the course of a MB, but never gives up.  It sits at the same # of MB, and the green arrow continue to indicate a transfer is in progress.

    Unfortunately, I"m not able to get robust logging, but have found the following:
    MOE.exe is doing the lion's share of the traffic, so I suspect that is at least the transport mechanism.  Whether or not MoeMonitor is the traffic cop setting up the sessions is another question I cannot answer.

    I am able to see each system's MOE.exe listening on various ports ranging from 21004 through 31030 (i suspect all the high level ports), and several outgoing 443 sessions..  I'm sure I'd see more ports if I watched longer, as the port number seemed to shift.

    And with that, I'm off to bed.

    Thanks for your help Oren!

    -Bozford
    Tuesday, February 17, 2009 3:48 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hey Bozford,

    I just noticed that you wrote that MoeMonitor is outgoing only, I don't think it would affect anything, but you could try allowing incoming connections to it as well.

    Apart from that I'm finding it hard to understand why it would still block the incoming / outgoings without notification. Can you set mcafee to ask you before blocking anything and see what happens (i.e. what it is asking to block) when the P2P starts?

    Good night!

    Oren
    Tuesday, February 17, 2009 4:37 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Note:  It appears that the Mesh connection is exposing the source IP address of the originating system, instead of allowing the NAT of the router to handle it.

    When looking at the logs of the "sending" system, I saw an incoming request from 192.168.1.102.  That was the IP of the receiving system.  I believe that the McAfee firewall is blocking this as a spoofed IP address, since it is considered non-routable.

    The exact message was:  "A computer at 192.168.1.102 has attempted an unsolicited connection to UDP port 3702 on your computer.  The source IP is a 'non-routable' IP."

    I believe that this may be the source of the problem here. If NATing the connection, that private IP address should never be exposed. 

    Just in case you were thinking it, no, there is no VPN involved at all.
    Wednesday, February 18, 2009 2:48 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Good information, Bozford.

    Can you file a bug on Connect for this? And provide whatever logs you can to show the activity you trapped.

    Please see this post for instructions on how to collect logs and submit a bug on Connect:

    http://social.microsoft.com/Forums/en-US/LiveMesh/thread/d52b350a-f3e0-41c6-8e78-d6378e566b9e

    Thanks,

    -steve

    Microsoft MVP Windows Live / Windows Live OneCare & Live Mesh Forum Moderator
    Wednesday, February 18, 2009 4:18 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Bug already submitted (see higher in the thread).  Updated with the info posted here.
    Thursday, February 19, 2009 12:43 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Bozford said:

    Bug already submitted (see higher in the thread).  Updated with the info posted here.



    Duh! You'd think I would have seen that as I scanned the thread again before posting! Thanks for the bug report and for updating it!
    -steve
    Microsoft MVP Windows Live / Windows Live OneCare & Live Mesh Forum Moderator
    Thursday, February 19, 2009 4:24 PM
    Moderator