locked
P2P file sharing only working one way RRS feed

  • Question

  • Hi

    In our lab deployment, I seem to be the only user who can receive files shared from other users. Any file I send out, and any file another user sends to yet another user seem to get stuck. Since we're all in the same subnet and all have our firewalls disabled, that seems to make little sense.

    Is there anything that can be done to trace this problem to the root or has anybody already experienced it and knows a way to resolve it?

     Regards

    Stephan

     

    P.S.

    Note that all users are connected via edge server during these tests.
    When I remain connected to the edge and we move one of the other users
    to the internal network, then there's no file sending whatsoever.
    Sending files between two internal users works though. Note that
    external users have no trouble talking to internal users and we can
    also have live meetings with users on both sides of the edge (though
    if a user on the edge side uploads a file, only other users on the
    edge side can see it.. internal users won't see it.. the other way
    around works though).

    Friday, January 30, 2009 4:22 PM

All replies

  • Stephan,

    File sharing in OCS is notoriously difficult to get working due to the fact that it's a simple P2P sharing connection between end users.  The OCS servers don't proxy any of the communications so end-user's locations and potential multiple NAT traversals make it difficult to even get working.  Since you have some of it working between external users then it may be as simple as configuring your firewall to allow that traffic (6891-6901).
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, February 3, 2009 12:09 PM
    Moderator
  • Jeff

    The thing is.. there's no NAT and no firewalls. This is an R2 lab deployment where both internal and external networks are actually part of the corporate LAN. Due to routing limitations (somebody forgot to set it up all the way but it comes to our advantage) we still have communication limited so that we run MOC on our productive laptops and they have no way to connect to the internal network other than going through the edge server.

    In all the tests, all clients on the "external" net were on the same LAN subnet and had their firewall disabled.

    Regards
    Stephan

    P.S. Is there no proxying either in case of an edge server when an internal and an external user exchange files?
    Tuesday, February 3, 2009 12:16 PM
  • Stephan,

    Correct, no proxing it all, so an internal<to>external connection would simply be peer to peer for file transfer.  But in your test environment none of this would appear to apply.  Time to fire up Network Monitor or Wireshark and see what's going on in those connection attempts.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Tuesday, February 3, 2009 12:58 PM
    Moderator
  • Jeff

    We looked at Wireshark and there's nothing going on between the two hosts if a transfer does not succeed. That makes me think the transfer setup is done via edge.. but since that communication is encrypted I can't really see what is going on..

    So I thought maybe the etl Files created by MOC would be useful but I seem to be unable to open them. ocslogger.exe won't even let me select that file, so I logged on the server instead (not sure which component so I went for S4) which works, but then analyzing the content won't work.. I installed the R1 SDK since there's no R2 and the snooper.exe crashes upon attempting to open the file.. so essentially I cannot even view traces anymore with R2 and I'm at the end of my rope.

    Any ideas?

    Regards
    Stephan
    Thursday, February 5, 2009 10:28 AM
  • Stephan,

    The .ETL log files are specifically for MS PSS to read and the Snooper tool does not handle those files.  You can peak into them with a plain text editor but it's difficult to pull any useful information from them.  The 'reader' for those files is not publicly available.  There is an R2 Resource Kit coming which will resolve the snooper issue.



    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Thursday, February 5, 2009 11:55 AM
    Moderator
  • Where does that leave us with tracing that problem down? do you have any other ideas than looking at those logs?
    Thursday, February 5, 2009 12:09 PM