This fixes a misunderstanding by my side on ptpd's code. Timers are
not single-shots, but must be fired once every 'interval', where
interval is defined in timer_start. If one wants to stop it, a
timer_stop can be called
Signed-off-by: Aurelio Colosimo <aurelio@aureliocolosimo.it>

gPTP uses the peer multicast address for all packets
Signed-off-by: Eliot Blennerhassett <eblennerhassett@audioscience.com>

pass correct payload to state machine
check minimum packet size when receiving it

Signed-off-by: Eliot Blennerhassett <eblennerhassett@audioscience.com>

Signed-off-by: Eliot Blennerhassett <eblennerhassett@audioscience.com>

Then, both spec and bare-linux pre-set ETHERNET_MODE

This moves some constants from pptp.h to constansts.h and
adds DEFAULT_ETHERNET_MODE, so archs can activate it by default for them

Note that default management is awfully broken (we inherited from the
other ptpd). For example DEFAULT_INBOUND_LATENCY is not used, and if
you change it you have no effect.

The command line is not available in freestanding environments: move
it to lib/ so archs can pick it up (e.g. arch-gnu-linux does it)

So don't check it in startup.
Signed-off-by: Eliot Blennerhassett <eblennerhassett@audioscience.com>

This is still not working, but the patch makes no functional change,
only turns #ifdef into if() based on '-e' command line argument.

This adds the "-e" argument (ethernet frames), currently unused,
and catches some more errors in the command line.

The spurious "if (1) {" in there is to avoid reindenting it all,
as it would prevent easy revision of the changeset. I'll reindent
in a different commit.

used OPTS(ppi) everywhere instead of ppi->rt_opts
removed rt_opts as function parameter

We now use raw sockets as default. The choice, for gnu-linux arch,
can be done by defining PP_NET_UDP or PP_NET_IEEE_802_3.
New constant PP_ETHERTYPE=0x88f7 is defined in ieee1588_types.h,
as defined in IEEE specification.

This patch is due to the fact that the code did not correctly handle
the situation of "no incoming message". Since messageType 0 is a SYNC
message type, in those cases an empty message was tried to be handled as a SYNC
message, and led to FAULTY state. This patch seemed to me the least
invasive with respect to the current code.