This could be that SBC and SBR are not on the same SN Data Center.

We're not currently having any steady (or rising) datacenter lag, so that shouldn't be an issue.  If the test happened to fail during a momentary lag spike while SBR and SBC were on separate datacenter, the PIN would become valid and work shortly afterwards (within 1 minute or so).

In any case, while we strive to correctly support it, SBR and SBC should *not* be connecting to separate datacenters under any normal conditions.  This should only happen in the wake of production issues or outages on our side.

When SN is healthy, if SBC and SBR are connecting to split datacenters, then something is wrong that needs to be fixed.  They should be retrieving the same address as served by our DNS servers.  If you can confirm split datacenters by looking at the TCP connections being made from each device, then the next step is to figure out the DNS discrepancy.  Are both devices using the same nameserver address (supplied by DHCP? or manually?).  Are they using OpenDNS? (I suspect OpenDNS may give inconsistent results under some conditions).

Other, deeper things to look at if this condition persisted and nothing above pointed out an obvious problem (perhaps not support): Is the device caching the results of DNS lookups?  It should never do so, unless it runs a full caching resolver, which I don't think any of our devices currently do.  Any time the device connects to a hostname, it should first ask the nameserver to do a lookup on that hostname, since it cannot know the correct TTL values.

Pin is a thing of the past...closing this bug as invalid now