Well that's an embarrassing one! Thanks for reporting this.
Luckily the 2.4 modular transport code has a method to check if a transport address is multicast or unicast, and a callback for that, which lets the protocol code to perform some action on the payload depending if it's destined fo mcast or ucast.
Regards,
Wojciech
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, it should still be able to survive the 0x7F anywhere, as a special case. I brought this up with the 1588 WG multiple times though - I see no benefit in the 0x7F value in table 24. For example it's always set to logAnnounceInterval for Announce messages, but has transport-dependent values for sync/fup and delayresp. What's the benefit? I can't see any, it's a burden if anything. If you're running G8265.1 for example, then you should use your granted intervals - but surely they would match what's in logMessageInterval.
I also wanted to push this at least in the Enterprise profile ("hybrid") but to no avail either. If you ask me, the field should always be logMinDelayReqInterval for DelayResp. What's the point of it being 0x7F in Hybrid DelayResp? <facepalm></facepalm>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Running ptpd in hybrid master mode, if the slave sends a multicast delay request,
ptpd sends a multicast delay response, but with logMessageInterval=0x7F.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey RICHARD,
Well that's an embarrassing one! Thanks for reporting this.
Luckily the 2.4 modular transport code has a method to check if a transport address is multicast or unicast, and a callback for that, which lets the protocol code to perform some action on the payload depending if it's destined fo mcast or ucast.
Regards,
Wojciech
You are welcome.
(The 0x7F triggered an integer overflow bug in ptp4l ;)
Well, it should still be able to survive the 0x7F anywhere, as a special case. I brought this up with the 1588 WG multiple times though - I see no benefit in the 0x7F value in table 24. For example it's always set to logAnnounceInterval for Announce messages, but has transport-dependent values for sync/fup and delayresp. What's the benefit? I can't see any, it's a burden if anything. If you're running G8265.1 for example, then you should use your granted intervals - but surely they would match what's in logMessageInterval.
I also wanted to push this at least in the Enterprise profile ("hybrid") but to no avail either. If you ask me, the field should always be logMinDelayReqInterval for DelayResp. What's the point of it being 0x7F in Hybrid DelayResp? <facepalm></facepalm>
Here is another (related?) ptpd bug:
Running ptpd in hybrid master mode, if the slave sends a multicast delay request,
ptpd sends a multicast delay response, but with logMessageInterval=0x7F.
Yep. Fixed in the last commit, thanks. Right now it will react based on the PTP_UNICAST flag in the delay request that came in.