This modifies all transports to use a new common address type, struct
address. This address is stored in a ptp_message for all received messages.
For sending, the "default" address is used with the default sending
functions, transport_send and transport_peer. The default address depends on
the transport; it's supposed to be the multicast address assigned by the
transport specification.
Later, a new transport_sendto function will be implemented that sends to the
address contained in the passed ptp_message.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
The callers of those functions are all using ptp_message. As we're going to
return more information (the address), let those functions just fill in the
ptp_message fields directly.
Some minor reshuffling needed to prevent circular header dependencies.
Signed-off-by: Jiri Benc <jbenc@redhat.com>
When there is a peer speaking PTPv1 in the network we want to silently ignore
the packets instead of flooding system log with error messages. At the same
time we still want to report malformed packets. For that we reuse standard
error numbers and do more fine-grained error reporting in packet processing
routines.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
These flexible TLVs don't need to be represented as a single packed
struct directly in the message buffer. Instead a separate struct
contains pointers to the individual parts of the TLV in the message
buffer. The flexible TLV can only be the last TLV in a message.
Signed-off-by: Geoff Salmon <gsalmon@se-instruments.com>
Some commercial 802.1AS switches do not feel obliged to set the two step
flag. When we try to synchronize to their apparent one step sync messages,
nothing good happens. This commit adds a global option to work around the
issue.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
An oversize incoming packet might overwrite the reference counter in a
message. Prevent this by providing a buffer large enough for the largest
possible packet.
This will also be needed to support TLV suffixes.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>