gPTP - SLAVE only mode announce and sync timers

[andrew-elder]

See pull request #635 and comments

I was wondering what the expected behavior is in the following scenario:
A slave-only (P1 = 255) device comes online on a network which currently does not have a 802.1as GM. It enters PTP_SLAVE mode since it is 255, and the GM clock ID is initialized to all zeroes. After the announce_receipt_timeout, it will enter this code path and just return true.
So, until a new 802.1as GM comes online on the network, does it remain in PTP_SLAVE with the GM Clock ID set to all zeroes (and never being set to its clock ID)?
Secondly, in a subsequent scenario, the slave only device is now synchronizing to an 802.1as GM. So, the port_state is PTP_SLAVE and the GM Clock ID is set to that of the 802.1as GM.
If the GM goes offline, does the slave-only device retain the GM Clock ID till a new GM comes online?

and

I was a bit uncertain about things still, and the questions @vvacharya asked prompted me to dig deeper into 802.1AS for answers. I still think this patch is an improvement over the previous state and probably fixes a serious bug, but there may still be some issues to clean up later.
Technically, the GM clock ID should never be all 0's, and the port role should be MASTER_PORT if it hasn't received an ANNOUNCE. However, if it is not GM-capable, the spec says it should not set the gmPresent flag, which gates it from sending SYNCs as a master would, and tells it to get time information from its LocalClock.
This is based on 10.3.12.1.4, the updtRolesTree() function of the PortRoleSelection state machine. It runs unconditionally after initialization and again if "reselect" is set in the PortAnnounceInformation state machine (10.3.11), which happens upon entry to the "Aged" state, which happens as soon as the port is enabled, has gPTP enabled, and becomes asCapable.
Once we get better GM info than our own (i.e. any info from a GM-capable system) we start the AnnounceReceiptTimeout timer. If it goes off after that point, or if we get a SyncReceiptTimeout while gmPresent is true, then we transition back to "Aged" which should run updtRolesTree() again, which should set our role back to MASTER_PORT and clear gmPresent since we are not GM-capable.
I don't think that's precisely what we were doing before, nor what we're doing now. The effect was close enough to pass the certification tests before, but I'm not sure about now. We should definitely give them another run whenever someone who has access gets a chance. There could be behavioral differences around the info we put in Announce messages before we hear from a real GM, especially once multi-port behavior is fully implemented.
To really follow the spec, we'll need something like the "gmPresent" flag, and we'll have to switch to MASTER_PORT when we get timeouts regardless of our GM-capable status. It doesn't make much difference when we've only got one port and we'll never be GM, though.
Another thing that's odd is that we're resetting the sync and announce receipt timers when they go off. That's not in the spec at all; they only get reset when you receive a valid SYNC or ANNOUNCE, respectively. Not sure what the purpose is, but there may be some reason.