Hi Richard,
This issue hits us over and over again. Are you sure we don't want to protect
us better?
BTW, 802.3 doesn't specify the content value of padding, as I know.
Thanks,
Vincent
-----Original Message-----
From: Richard Cochran <[email protected]>
Sent: Thursday, October 3, 2019 5:33 PM
To: RAVEENDRA M <[email protected]>
Cc: [email protected]
Subject: Re: [Linuxptp-devel] ptp4l port 1: bad message
On Thu, Oct 03, 2019 at 10:48:13AM +0000, RAVEENDRA M wrote:
> As per pcap following is the hex dump of 64 byte ethernet packet (Delay Req).
>
> 0000 00 a0 a5 d4 44 80 00 0a 35 00 22 01 88 f7 01 02
> 0010 00 2c 18 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0020 00 00 00 0a 35 ff fe 00 22 01 00 01 01 b9 01 7f
> 0030 00 00 00 00 00 00 00 00 00 00 20 2d 35 36 32 33
padding (should be zero) ........... ^^^^^ garbage
.................................. ^^^^^^^^^^^
> Last four bytes are CRC. I am not clear about TLV in PTP Delay request packet.
No it isn't. It is garbage. The frame should be 58 bytes long.
The source MAC address says Xilinx. That device is generating bad PTP packets.
HTH,
Richard
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
--- Begin Message ---
Yes, the ethernet padding is according to standard, which doesn't specify
the padding content. I think we might have a bug here.
-----Original Message-----
From: Geva, Erez <[email protected]>
Sent: Thursday, January 31, 2019 3:21 PM
To: Vincent Li X <[email protected]>
Subject: RE: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
The PAD is on the Ethernet packet not in the PTP protocol.
As I remember, padding Ethernet frames is allowed.
In this case it is mandatory in order to meat the minimum of 64 octets of a
Ethernet packet.
However if you wish to pad the UPD, then you have to follow the UDP
protocol.
It is important where you PAD!
Erez
________________________________________
From: Vincent Li X [[email protected]]
Sent: 31 January 2019 14:17
To: Miroslav Lichvar
Cc: Mats Bergman H; Richard Jönsson; Jiri Benc;
[email protected]
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
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 could contain any
value.
-----Original Message-----
From: Miroslav Lichvar <[email protected]>
Sent: Wednesday, January 30, 2019 12:55 PM
To: Vincent Li X <[email protected]>
Cc: Jiri Benc <[email protected]>; Mats Bergman H
<[email protected]>; Richard Jönsson
<[email protected]>; [email protected]; Anders
Selhammer <[email protected]>
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
On Wed, Jan 30, 2019 at 11:23:45AM +0000, Vincent Li X wrote:
>
> Ok. Thanks Jiri!
> How do you think about our case? We run 1.6 on raw ethernet. This is a
> normal FOLLOW-UP received with one-zero padding of 6 octets. Then
> ptp4l take the padding as TLV.
One-zero padding sounds like beginning of another frame. I'm not sure why a
follow up message would need some special padding.
What NIC do you use? Can you show us a tcpdump -xx output? And do you see it
also on other NICs, i.e. is such packet actually transmitted by the master?
--
Miroslav Lichvar
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
