On Thu, Jan 31, 2019 at 04:22:20PM +, Geva, Erez wrote:
> For me, the only question is, if the Ethernet frame does have padding and the
> PTP frame is proper.
> Is there a problem?
Yes, there is a problem. The length of the messages affects their
delay through network equipment. The PTP eve
On Thu, Jan 31, 2019 at 04:28:30PM +, Vincent Li X wrote:
> we might also need to check again m->header.messageLength is bigger than
> cnt.
What? We already have
if (cnt < pdulen)
return -EBADMSG;
in msg_post_recv();
Or did you mean something else?
Thanks,
Richard
Let's take a step back and consider the design. What you really want
is a new synchronization state. Something like:
enum servo_state {
SERVO_UNLOCKED,
SERVO_JUMP,
SERVO_LOCKED_ALPHA,
SERVO_LOCKED_
On Thu, 31 Jan 2019 16:28:30 +, Vincent Li X wrote:
> we might also need to check again m->header.messageLength is bigger than
> cnt.
This might not be a bad idea; if the packet length is inconsistent with
the PTP or 802.3 standard, a warning can be emitted and the packet
dropped and not proce
Since padding is permitable in Ethernet protocol, not limited by size or value
of padding.
Depend on having only 2 bytes, based on the minimum PTP PDU size and the fact
that most driver do not pad more then 64 bytes.
In my opinion it sound shaky and prone to be bug in future implementations.
Hi Erez,
In that case, we take padding as TLV if I read code correctly. Now it's
basically ok, only because the padding bytes can be maximum two bytes (64 -
14 - 4 FCS - 44 (smallest PTP PDU?)), we would not enter below while-loop as
TLV struct is of size 4.
But how about if future comes new small
As you feel, I don't care on the Ethernet frame.
Nor do I think we should try to fix it or criticize it.
If the packet pass the Linux kernel and received by the PTP daemon, we should
not care.
For me, the only question is, if the Ethernet frame does have padding and the
PTP frame is proper.
Is t
Thanks Jiri, Miroslav and Richard!
Ok, we see this is our sending NIC messes with FCS and receiving NIC didn't
drop it but passed on to application.
But we still think it's more safe to use header.messageLength instead of
socket count,
Msg.c
err = suffix_post_recv(m, cnt - pdulen);
==>
On Thu, 31 Jan 2019 07:41:38 -0800, Richard Cochran wrote:
> FWIW, Wireshark shows "Bad FCS" for this frame. Please fix it at the
> sender.
To be fair, this is just an artifact of Wireshark guessing wrong on the
packet structure. AFAIK there's no indication of the frames having FCS or
not in pcap
On Thu, Jan 31, 2019 at 01:17:56PM +, Vincent Li X wrote:
> Please see this attached FOLLOW-UP with 6 bytes of non-zero padding (64 - 14
> of eth header - 44 of PDU length). I don't know the HW NIC information.
> According to 802.3, padding is done at tx/master side and could contain any
> val
On Thu, Jan 31, 2019 at 01:17:56PM +, Vincent Li X wrote:
>
> Sorry Miroslav! I missed you message yesterday, don't know why it ended up
> in junk box.
> Please see this attached FOLLOW-UP with 6 bytes of non-zero padding (64 - 14
> of eth header - 44 of PDU length). I don't know the HW NIC i
Sorry Miroslav! I missed you message yesterday, don't know why it ended up
in junk box.
Please see this attached FOLLOW-UP with 6 bytes of non-zero padding (64 - 14
of eth header - 44 of PDU length). I don't know the HW NIC information.
According to 802.3, padding is done at tx/master side and co
12 matches
Mail list logo
