#49 "unicast" capability

v2.3.1
closed
None
5
2015-06-08
2013-07-22
Bjoern Dick
No

When using the unicast-switch ("-u") within a simple two machines master-slave-configuration no sync can be accomplished (at least for me).
Additionally according to George Neville-Neil no pure unicast communication is possible in IEEE-1588. Nevertheless the help message of ptpd2 ("-u ADDRESS Unicast mode: send all messages in unicast to ADDRESS") suggests such a mode.

Proposal: At least clarify the help message, i.e. that only a subset of the messages will be sent by unicast instead of multicast.

Discussion

  • George Neville-Neil

    This has been fixed for 2.3 by adding a clarifying comment in the help output.

     
  • George Neville-Neil

    • status: open --> pending
    • assigned_to: George Neville-Neil
     
  • Wojciech Owczarek

    "Additionally according to George Neville-Neil no pure unicast communication is possible in IEEE-1588." - I don't understand this one, pure unicast communication is by all means possible!

    Furthermore I've just found an issue in ptpd with the forced loopback of sync packets to deliver follow-up for unicast-only mode. Those packets are being sent to INADDR_LOOPBACK - this doesn't seem to work, they're not being picked up. Instead of 127.0.0.1, they must be sent to the NIC's current IP address, that works fine. I'm syncing two Raspberry Pi boxes with ptpd-svn over some 1300 miles via unicast - seems to work OK.

     
  • Jan Breuer

    Jan Breuer - 2013-10-01

    It also works for me replacing htonl(INADDR_LOOPBACK) by netPath->interfaceAddr.s_addr.

    I have additional issue with unicast. It still registers to multicast group so it uses better multicast master instead of forced unicast one.

    After disabling multicast in netInit and netRefreshIGMP, it starts working for me.

    Is there some reason to join multicast groups in unicast mode?

     
  • Wojciech Owczarek

    Jan,

    No, I can't see any reason why we would join the mcast groups in unicast mode - unless this is a combination of P2P and unicast - not sure if this is even possible.... I need to refer to the standard to double check. If it is possible, then we need to join only the P2P groups.

    Anyway, with my latest commit, unicast works OK. Multicast operation should be unchanged. I need to make the unicast destination optional for unicast mode - surely you can pick up the GM's IP once you get the first announce.

    Anyway the way the "looping" is done for unicast is guaranteed to give you crap results... Only if we combine this with libpcap, then the results will be semi good.

    Regards
    Wojciech

     
  • Wojciech Owczarek

    • status: pending --> closed
    • assigned_to: George Neville-Neil --> Wojciech Owczarek
    • Group: v1.0_(example) --> v2.3.1
     
  • Wojciech Owczarek

    2.3.1 introduces fully-featured unicast operation: slave with multiple unicast masters, master with multiple unicast slaves and Telecom Profile - signaling.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks