Thread: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
Menu
▾
▴
linuxptp-devel
|
From: Vincent Li X <vin...@er...> - 2019-01-29 16:48:17
Attachments:
smime.p7s
image001.jpg
|
On Mon, Feb 19, 2018 at 05:59:23PM +0200, Yan Yankovskyi wrote: > It seems now that VLAN driver isn't actually used in the system, and we use > a custom ethernet driver. This driver has skb_tx_timestamp(skb); call in > it's start_xmit() routine, and I implemented and registered get_ts_info() > function for ethtool. The interface now successfully passes ethtool check, > and as far as I understand there are timestamps in ethernet frames. The > only messages that don't contain timestamps are Announce messages, I guess > it is not important? Right. Those are not event messages and don't get a time stamp. > But I still got the problem: in suffix_post_recv() function call for Sync > messages (cnt = 50, pdulen = 44) I'm getting wrong tlv values (always 0 for > type, but some arbitrary values for length, e.g. 50666, 18066). Do you have > any idea what may go wrong? I don't understand is it some problems in our > driver, or in ptp4l. It is in your driver. Sync messages never have TLVs attached. Probably the packet length is too long. HTH, Richard ---------------------------------------------------------------------------- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
|
From: Sun, S. (N. - CN/Qingdao) <ste...@no...> - 2019-01-30 05:34:10
Attachments:
image001.jpg
|
Vincent,
We saw similar issue when co-work with Qulsar's PTP master clock. Qulsar master clock added 4 extra bytes after the PTP payload in UDP payload. Bad message error was reported by ptl4l which is running in slave mode. The difference is that we are using UDP4 unicast rather than ether multicast.
In our case, ptp4l takes the UDP payload length rather than PTP messageLength to process the messages. So any extra byte after PTP payload which length > 3 bytes will cause the "bad message" error.
I am not sure whether it's correct or not. Checked PTP and UDP specs but no clear definition for this.
Thanks,
Steven
From: Vincent Li X <vin...@er...>
Sent: Wednesday, January 30, 2019 12:48 AM
To: Lin...@li...
Cc: Mats Bergman H <mat...@er...>; Richard Jönsson <ric...@er...>
Subject: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
Hi,
We are running the old version 1.6.
1. This is a normal FOLLOW-UP received with one-zero padding of 6 octets.
[cid:image001.jpg@01D4B89E.CED276B0]
1. sk.c this line returns 64, including eth header size 14.
cnt = recvmsg(fd, &msg, flags);
1. msg.c, cnt is 50, pdulen 44.
m->tlv_count = suffix_post_recv(suffix, cnt - pdulen, &m->last_tlv);
1. msg.c, this func takes 0x80 from above padding as tlv->length and returns below EBADMSG.
static int suffix_post_recv(uint8_t *ptr, int len, struct tlv_extra *last)
{
...
if (tlv->length > len) {
return -EBADMSG;
}
1. It seems that eth standard doesn't say "padding must be 0". So it could be a bug of ptp4l? or has been fixed by later release?
Thanks,
Vincent
|
|
From: Vincent Li X <vin...@er...> - 2019-01-30 09:38:02
Attachments:
smime.p7s
image001.jpg
|
Hi Steven,
Do you run with latest release? I think the problem is ptp4l takes the
length as recvmsg() - carrierHeaderLen, instead of m->header. messageLength.
Or is it the drivers responsibility to remove padding before socket?
Thanks,
Vincent
From: Sun, Steven (NSB - CN/Qingdao) <ste...@no...>
Sent: Wednesday, January 30, 2019 6:34 AM
To: Vincent Li X <vin...@er...>;
Lin...@li...
Cc: Mats Bergman H <mat...@er...>; Richard Jönsson
<ric...@er...>
Subject: RE: ptp4l wrongly takes padding bytes as TLV?
Vincent,
We saw similar issue when co-work with Qulsars PTP master clock. Qulsar
master clock added 4 extra bytes after the PTP payload in UDP payload. Bad
message error was reported by ptl4l which is running in slave mode. The
difference is that we are using UDP4 unicast rather than ether multicast.
In our case, ptp4l takes the UDP payload length rather than PTP
messageLength to process the messages. So any extra byte after PTP payload
which length > 3 bytes will cause the bad message error.
I am not sure whether its correct or not. Checked PTP and UDP specs but no
clear definition for this.
Thanks,
Steven
From: Vincent Li X <vin...@er...
<mailto:vin...@er...> >
Sent: Wednesday, January 30, 2019 12:48 AM
To: Lin...@li...
<mailto:Lin...@li...>
Cc: Mats Bergman H <mat...@er...
<mailto:mat...@er...> >; Richard Jönsson
<ric...@er... <mailto:ric...@er...> >
Subject: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
Hi,
We are running the old version 1.6.
1. This is a normal FOLLOW-UP received with one-zero padding of 6
octets.
2. sk.c this line returns 64, including eth header size 14.
cnt = recvmsg(fd, &msg, flags);
3. msg.c, cnt is 50, pdulen 44.
m->tlv_count = suffix_post_recv(suffix, cnt - pdulen,
&m->last_tlv);
4. msg.c, this func takes 0x80 from above padding as tlv->length and
returns below EBADMSG.
static int suffix_post_recv(uint8_t *ptr, int len, struct tlv_extra *last)
{
if (tlv->length > len) {
return
-EBADMSG;
}
5. It seems that eth standard doesnt say padding must be 0. So it
could be a bug of ptp4l? or has been fixed by later release?
Thanks,
Vincent
|
|
From: Miroslav L. <mli...@re...> - 2019-01-30 10:34:36
|
On Wed, Jan 30, 2019 at 05:33:58AM +0000, Sun, Steven (NSB - CN/Qingdao) wrote: > Vincent, > > We saw similar issue when co-work with Qulsar's PTP master clock. Qulsar master clock added 4 extra bytes after the PTP payload in UDP payload. Bad message error was reported by ptl4l which is running in slave mode. The difference is that we are using UDP4 unicast rather than ether multicast. > > In our case, ptp4l takes the UDP payload length rather than PTP messageLength to process the messages. So any extra byte after PTP payload which length > 3 bytes will cause the "bad message" error. > > I am not sure whether it's correct or not. Checked PTP and UDP specs but no clear definition for this. As was pointed out here couple days ago, the PTP spec doesn't seem to allow a longer "checksum complement" than 2 octets. UDP certainly doesn't allow adding arbitrary data to the payload. That would break most protocols. If I understand it correctly, the PTP message lenght field was needed for Ethernet and other transports which allow padding. UDP is not one of them. Are there other vendors than Qulsar that do this? If it's a common issue, it might need to be specified. IIRC there are few other cases where the spec had to be adjusted to follow what existing HW was doing. -- Miroslav Lichvar |
|
From: Vincent Li X <vin...@er...> - 2019-02-01 10:17:07
Attachments:
smime.p7s
|
Hi Richard,
I mean the change of that two lines to like:
if (cnt < m->header.messageLength || m->header.messageLength <
pdulen) {
pr_debug("wrong length, cnt: %d messageLength: %hu pdulen
:%d",
cnt, m->header.messageLength, pdulen);
return -EBADMSG;
}
Thanks,
vincent
-----Original Message-----
From: Richard Cochran <ric...@gm...>
Sent: Friday, February 1, 2019 4:45 AM
To: Vincent Li X <vin...@er...>
Cc: Jiri Benc <jb...@re...>; Miroslav Lichvar <mli...@re...>;
Mats Bergman H <mat...@er...>; Richard Jönsson
<ric...@er...>; Lin...@li...
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
On Thu, Jan 31, 2019 at 04:28:30PM +0000, 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
|
|
From: Jiri B. <jb...@re...> - 2019-01-30 10:50:19
|
On Wed, 30 Jan 2019 11:34:25 +0100, Miroslav Lichvar wrote:
> Are there other vendors than Qulsar that do this? If it's a common
> issue, it might need to be specified. IIRC there are few other cases
> where the spec had to be adjusted to follow what existing HW was doing.
The Qulsar hardware violates the PTP spec and as such, they cannot claim
PTP support. If they do, it's false advertisement and it's a reason to
demand fix from the vendor and if they can't deliver a fix, have the
device refunded.
I don't see reason why linuxptp should put hacks in place to workaround
broken hardware that knowingly violates the spec. I don't even see a
reason why the standard should be changed to accommodate such hardware
with no real technical reasons ("we were lazy to implement the spec
correctly and we just decided to violate the spec" is hardly a reason).
Jiri
|
|
From: Richard C. <ric...@gm...> - 2019-01-30 16:04:39
|
On Wed, Jan 30, 2019 at 11:50:00AM +0100, Jiri Benc wrote:
> I don't see reason why linuxptp should put hacks in place to workaround
> broken hardware that knowingly violates the spec. I don't even see a
> reason why the standard should be changed to accommodate such hardware
> with no real technical reasons ("we were lazy to implement the spec
> correctly and we just decided to violate the spec" is hardly a reason).
+1
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2019-02-01 16:16:51
|
On Fri, Feb 01, 2019 at 10:16:53AM +0000, Vincent Li X wrote:
>
> Hi Richard,
> I mean the change of that two lines to like:
> if (cnt < m->header.messageLength || m->header.messageLength <
> pdulen) {
> pr_debug("wrong length, cnt: %d messageLength: %hu pdulen
The rule in communication is to be strict when sending, but generous
when receiving. This code generously allows incorrect messageLength.
That field is redundant, because all of the transports already provide
the packet length. Thus there is no need to check it.
If we were using a stream transport like TCP, then checking
messageLength would of course be essential.
Thanks,
Richard
|
|
From: Richard C. <ric...@gm...> - 2019-02-01 16:18:45
|
On Fri, Feb 01, 2019 at 08:16:41AM -0800, Richard Cochran wrote:
> On Fri, Feb 01, 2019 at 10:16:53AM +0000, Vincent Li X wrote:
> >
> > Hi Richard,
> > I mean the change of that two lines to like:
> > if (cnt < m->header.messageLength || m->header.messageLength <
> > pdulen) {
> > pr_debug("wrong length, cnt: %d messageLength: %hu pdulen
>
> The rule in communication is to be strict when sending, but generous
> when receiving. This code generously allows incorrect messageLength.
By "this" I mean the current linuxptp code, not the your example!
> That field is redundant, because all of the transports already provide
> the packet length. Thus there is no need to check it.
>
> If we were using a stream transport like TCP, then checking
> messageLength would of course be essential.
>
> Thanks,
> Richard
>
>
|
|
From: Vincent Li X <vin...@er...> - 2019-01-30 11:25:08
Attachments:
smime.p7s
eth-with-padding.jpg
|
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.
-----Original Message-----
From: Jiri Benc <jb...@re...>
Sent: Wednesday, January 30, 2019 11:50 AM
To: Miroslav Lichvar <mli...@re...>
Cc: Mats Bergman H <mat...@er...>; Richard Jönsson
<ric...@er...>; Lin...@li...
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
On Wed, 30 Jan 2019 11:34:25 +0100, Miroslav Lichvar wrote:
> Are there other vendors than Qulsar that do this? If it's a common
> issue, it might need to be specified. IIRC there are few other cases
> where the spec had to be adjusted to follow what existing HW was doing.
The Qulsar hardware violates the PTP spec and as such, they cannot claim PTP
support. If they do, it's false advertisement and it's a reason to demand
fix from the vendor and if they can't deliver a fix, have the device
refunded.
I don't see reason why linuxptp should put hacks in place to workaround
broken hardware that knowingly violates the spec. I don't even see a reason
why the standard should be changed to accommodate such hardware with no real
technical reasons ("we were lazy to implement the spec correctly and we just
decided to violate the spec" is hardly a reason).
Jiri
_______________________________________________
Linuxptp-devel mailing list
mailto:Lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
|
|
From: Miroslav L. <mli...@re...> - 2019-01-30 11:54:41
|
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 |
|
From: Vincent Li X <vin...@er...> - 2019-02-04 12:33:57
Attachments:
smime.p7s
|
Hi Richard,
That "generosity" seems not to be so right. For instance, you receive a gift
from you grandma living in another city, given below conditions:
1. The courier company opened the gift wrap and changed the wish-words in
the Xmas-card written by grandma. i.e. the header.messageLength is wrong.
2. The local office of courier company just replaced the pack box and
bubbled plastic padding. i.e. our case that ETH PHY replaces padding and
FCS.
3. Next year, grandma will send a gift of smaller size, but the shipment
company will pack it with a box of same size. i.e. smaller PTP messages in
future.
You would accept and say "thank you" to the delivery man in case #1, while
reject #2 and #3. Hopefully I don't make it less understandable. :)
Happy Chinese Spring Festival to all!
Vincent
-----Original Message-----
From: Richard Cochran <ric...@gm...>
Sent: Friday, February 1, 2019 5:19 PM
To: Vincent Li X <vin...@er...>
Cc: Jiri Benc <jb...@re...>; Miroslav Lichvar <mli...@re...>;
Mats Bergman H <mat...@er...>; Richard Jönsson
<ric...@er...>; Lin...@li...
Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV?
On Fri, Feb 01, 2019 at 08:16:41AM -0800, Richard Cochran wrote:
> On Fri, Feb 01, 2019 at 10:16:53AM +0000, Vincent Li X wrote:
> >
> > Hi Richard,
> > I mean the change of that two lines to like:
> > if (cnt < m->header.messageLength || m->header.messageLength <
> > pdulen) {
> > pr_debug("wrong length, cnt: %d messageLength: %hu pdulen
>
> The rule in communication is to be strict when sending, but generous
> when receiving. This code generously allows incorrect messageLength.
By "this" I mean the current linuxptp code, not the your example!
> That field is redundant, because all of the transports already provide
> the packet length. Thus there is no need to check it.
>
> If we were using a stream transport like TCP, then checking
> messageLength would of course be essential.
>
> Thanks,
> Richard
>
>
|
|
From: Richard C. <ric...@gm...> - 2019-02-05 04:14:44
|
On Mon, Feb 04, 2019 at 12:33:43PM +0000, Vincent Li X wrote: > You would accept and say "thank you" to the delivery man in case #1, while > reject #2 and #3. Hopefully I don't make it less understandable. :) I think your analogy is not on the mark... > Happy Chinese Spring Festival to all! In the spirit of the new year, imagine you order 4 kilograms of pork. When the delivery arrives, you find that the butcher gave you 3.5 kg of pork and 0.5 of packaging. Surely you would complain about the unwanted padding! Cheers, Richard |
|
From: Vincent Li X <vin...@er...> - 2019-02-05 15:45:05
Attachments:
smime.p7s
|
Hi Richard, In our case, it's not wrong FCS or unwanted padding, but PHY replaced original FCS with frame padding of random value. The thing is we should not try to decode any padding/bytes after PTP message body as TLV, because TLV is part of PTP message and total length is specified by the messageLength field. The description from 1588 is attached below: 13.3.2.4 messageLength (UInteger16) The value of the messageLength shall be the total number of octets that form the PTP message. The counted octets start with the first octet of the header and include and terminate with the last octet of any suffix or, if there are no suffix members with the last octet of the message as defined in this clause. NOTEThe message length does not include any padding bits specified in Annex D. Thanks, Vincent -----Original Message----- From: Richard Cochran <ric...@gm...> Sent: Tuesday, February 5, 2019 5:15 AM To: Vincent Li X <vin...@er...> Cc: Jiri Benc <jb...@re...>; Miroslav Lichvar <mli...@re...>; Mats Bergman H <mat...@er...>; Richard Jönsson <ric...@er...>; Lin...@li...; Anders Selhammer <and...@er...> Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV? On Mon, Feb 04, 2019 at 12:33:43PM +0000, Vincent Li X wrote: > You would accept and say "thank you" to the delivery man in case #1, > while reject #2 and #3. Hopefully I don't make it less > understandable. :) I think your analogy is not on the mark... > Happy Chinese Spring Festival to all! In the spirit of the new year, imagine you order 4 kilograms of pork. When the delivery arrives, you find that the butcher gave you 3.5 kg of pork and 0.5 of packaging. Surely you would complain about the unwanted padding! Cheers, Richard |
|
From: Jiri B. <jb...@re...> - 2019-02-05 16:07:07
|
On Tue, 5 Feb 2019 15:44:47 +0000, Vincent Li X wrote: > In our case, it's not wrong FCS or unwanted padding, but PHY replaced > original FCS with frame padding of random value. I very much doubt that. I bet the FCS was just stripped. I have yet to see a NIC that would replace FCS by a random value. Much more likely, there was (wrong and uninitialized = security problem) padding added by the sender, FCS was appended after it and stripped on the receiver side. What you see is the padding. > The thing is we should not try to decode any padding/bytes after PTP message > body as TLV, because TLV is part of PTP message and total length is > specified by the messageLength field. The description from 1588 is attached > below: > > 13.3.2.4 messageLength (UInteger16) > The value of the messageLength shall be the total number of octets that form > the PTP message. The > counted octets start with the first octet of the header and include and > terminate with the last octet of any > suffix or, if there are no suffix members with the last octet of the message > as defined in this clause. > NOTE—The message length does not include any padding bits specified in Annex > D. The only thing this says is it's wrong to add padding at the end by the sender (because that violates "the value of the messageLength shall be the total number of octets that form the PTP message"). It says nothing about what the receiver is supposed to do with a message in which messageLength is not the total number of octets. Specifically, it does not require the receiver to use messageLength; note that with correct messages it does not matter as both approaches (using messageLength vs. using real length) yield to the same result. Jiri |
|
From: Vincent Li X <vin...@er...> - 2019-02-05 17:00:35
Attachments:
smime.p7s
|
Hi Jiri, Our PHY engineers said that, we had no choice but to believe them, as we don't have time/approach to add sniffing machine in the middle to check the real packets over the media. How about #3, if in future new PTP message type(general) comes with smaller size than 44, our current code would reject it. It's not what we want, right? Thanks, Vincent -----Original Message----- From: Jiri Benc <jb...@re...> Sent: Tuesday, February 5, 2019 5:07 PM To: Vincent Li X <vin...@er...> Cc: Richard Cochran <ric...@gm...>; Miroslav Lichvar <mli...@re...>; Mats Bergman H <mat...@er...>; Richard Jönsson <ric...@er...>; Lin...@li...; Anders Selhammer <and...@er...> Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV? On Tue, 5 Feb 2019 15:44:47 +0000, Vincent Li X wrote: > In our case, it's not wrong FCS or unwanted padding, but PHY replaced > original FCS with frame padding of random value. I very much doubt that. I bet the FCS was just stripped. I have yet to see a NIC that would replace FCS by a random value. Much more likely, there was (wrong and uninitialized = security problem) padding added by the sender, FCS was appended after it and stripped on the receiver side. What you see is the padding. > The thing is we should not try to decode any padding/bytes after PTP > message body as TLV, because TLV is part of PTP message and total > length is specified by the messageLength field. The description from > 1588 is attached > below: > > 13.3.2.4 messageLength (UInteger16) > The value of the messageLength shall be the total number of octets > that form the PTP message. The counted octets start with the first > octet of the header and include and terminate with the last octet of > any suffix or, if there are no suffix members with the last octet of > the message as defined in this clause. > NOTE—The message length does not include any padding bits specified in > Annex D. The only thing this says is it's wrong to add padding at the end by the sender (because that violates "the value of the messageLength shall be the total number of octets that form the PTP message"). It says nothing about what the receiver is supposed to do with a message in which messageLength is not the total number of octets. Specifically, it does not require the receiver to use messageLength; note that with correct messages it does not matter as both approaches (using messageLength vs. using real length) yield to the same result. Jiri |
|
From: Vincent Li X <vin...@er...> - 2019-01-31 13:18:12
Attachments:
smime.p7s
non-zero-padding-followup4.pcap
|
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 <mli...@re...> Sent: Wednesday, January 30, 2019 12:55 PM To: Vincent Li X <vin...@er...> Cc: Jiri Benc <jb...@re...>; Mats Bergman H <mat...@er...>; Richard Jönsson <ric...@er...>; Lin...@li...; Anders Selhammer <and...@er...> 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 |
|
From: Miroslav L. <mli...@re...> - 2019-01-31 14:26:39
|
On Thu, Jan 31, 2019 at 01:17:56PM +0000, 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 information.
> According to 802.3, padding is done at tx/master side and could contain any
> value.
Ok, so the frame is padded with 6 bytes instead of 2. Maybe they
forgot to count the FCS? That is weird, but probably ok according to
the specs.
The ethernet transport in ptp4l should be fixed to trim that padding.
Can you please try this patch?
--- a/raw.c
+++ b/raw.c
@@ -259,6 +259,7 @@ static int raw_recv(struct transport *t, int fd, void *buf, int buflen,
unsigned char *ptr = buf;
struct eth_hdr *hdr;
struct raw *raw = container_of(t, struct raw, t);
+ struct ptp_message *msg;
if (raw->vlan) {
hlen = sizeof(struct vlan_hdr);
@@ -276,6 +277,10 @@ static int raw_recv(struct transport *t, int fd, void *buf, int buflen,
if (cnt < 0)
return cnt;
+ msg = buf;
+ if (cnt > ntohs(msg->header.messageLength))
+ cnt = ntohs(msg->header.messageLength);
+
if (raw->vlan) {
if (ETH_P_1588 == ntohs(hdr->type)) {
pr_notice("raw: disabling VLAN mode");
--
Miroslav Lichvar
|
|
From: Richard C. <ric...@gm...> - 2019-01-31 15:41:49
|
On Thu, Jan 31, 2019 at 01:17:56PM +0000, 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 > value. FWIW, Wireshark shows "Bad FCS" for this frame. Please fix it at the sender. Thanks, Richard |
|
From: Sun, S. (N. - CN/Qingdao) <ste...@no...> - 2019-03-05 06:34:00
|
Richard, It's my honor to reply the linuxptp grand master's email. I think the analogy should like this. Could you please kindly advise? Thanks. > In the spirit of the new year, imagine you order 4 kilograms of pork. > When the delivery arrives, you find that the butcher gave you 3.5 kg of pork and 0.5 of packaging. >Surely you would complain about the unwanted padding! I received a UPS package(UDP) and on the shipping tag, the shipping weight is 4.5Kg. When I opened the package, the packaging list sheet from the food company(PTP) indicate that the content is 4Kg of pork. It's better to eat the 4Kg of pork instead of eat all 4.5Kg include air bubble pack and ice then complain it's hard to bite. Best Regards, Steven -----Original Message----- From: Richard Cochran <ric...@gm...> Sent: Tuesday, February 5, 2019 12:15 PM To: Vincent Li X <vin...@er...> Cc: Mats Bergman H <mat...@er...>; Richard Jönsson <ric...@er...>; Lin...@li...; Jiri Benc <jb...@re...> Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV? On Mon, Feb 04, 2019 at 12:33:43PM +0000, Vincent Li X wrote: > You would accept and say "thank you" to the delivery man in case #1, > while reject #2 and #3. Hopefully I don't make it less > understandable. :) I think your analogy is not on the mark... > Happy Chinese Spring Festival to all! In the spirit of the new year, imagine you order 4 kilograms of pork. When the delivery arrives, you find that the butcher gave you 3.5 kg of pork and 0.5 of packaging. Surely you would complain about the unwanted padding! >> You received a USPS package(UDP) and on the shipping tag, the shipping weight is 4.5Kg. When you open the package, the package list sheet from the food company(PTP) indicate that the content is 4Kg of pork. It's better to eat the 4Kg of pork instead of eat all with carton and complain it's hard to eat. Cheers, Richard _______________________________________________ Linuxptp-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
|
From: Richard C. <ric...@gm...> - 2019-03-05 14:47:46
|
On Tue, Mar 05, 2019 at 06:33:46AM +0000, Sun, Steven (NSB - CN/Qingdao) wrote: > I think the analogy should like this. Could you please kindly advise? Thanks. My advice is: fix your hardware. Thanks, Richard |
|
From: Jiri B. <jb...@re...> - 2019-01-31 16:04:03
|
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. Wireshark has to guess and when it sees the packet being 6 bytes longer than the payload and 64 bytes in total, it's natural to guess it's 2 bytes padding and 4 bytes FCS to satisfy the Ethernet minimum length requirements. While in fact, I expect that the FCS got stripped and the frame was 68 bytes. The real FCS was most likely correct. Seeing the padding bytes not being zero, I cannot resist wondering what part of its memory is the sender leaking. Could the leak be used to gather some interesting data? ;-) In any case, this behavior is wrong on several levels. And with the likely security issue present, I don't think it's worth the time to consider this hardware seriously. Jiri |
|
From: Vincent Li X <vin...@er...> - 2019-01-31 16:28:56
Attachments:
smime.p7s
|
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); ==> err = suffix_post_recv(m, m->header.messageLength - pdulen); we might also need to check again m->header.messageLength is bigger than cnt. Ps. @Miroslav Lichvar <mli...@re...> what spam in your mail? Why always in junk box? :) -----Original Message----- From: Jiri Benc <jb...@re...> Sent: Thursday, January 31, 2019 5:04 PM To: Richard Cochran <ric...@gm...> Cc: Vincent Li X <vin...@er...>; Mats Bergman H <mat...@er...>; Richard Jönsson <ric...@er...>; Lin...@li... Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV? 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. Wireshark has to guess and when it sees the packet being 6 bytes longer than the payload and 64 bytes in total, it's natural to guess it's 2 bytes padding and 4 bytes FCS to satisfy the Ethernet minimum length requirements. While in fact, I expect that the FCS got stripped and the frame was 68 bytes. The real FCS was most likely correct. Seeing the padding bytes not being zero, I cannot resist wondering what part of its memory is the sender leaking. Could the leak be used to gather some interesting data? ;-) In any case, this behavior is wrong on several levels. And with the likely security issue present, I don't think it's worth the time to consider this hardware seriously. Jiri |
|
From: Geva, E. <ere...@si...> - 2019-01-31 16:50:10
|
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 there a problem? Is the PTP messaged parsed in a correct manner? Erez ________________________________________ From: Jiri Benc [jb...@re...] Sent: 31 January 2019 17:03 To: Richard Cochran Cc: Mats Bergman H; Richard Jönsson; Lin...@li... Subject: Re: [Linuxptp-devel] ptp4l wrongly takes padding bytes as TLV? 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. Wireshark has to guess and when it sees the packet being 6 bytes longer than the payload and 64 bytes in total, it's natural to guess it's 2 bytes padding and 4 bytes FCS to satisfy the Ethernet minimum length requirements. While in fact, I expect that the FCS got stripped and the frame was 68 bytes. The real FCS was most likely correct. Seeing the padding bytes not being zero, I cannot resist wondering what part of its memory is the sender leaking. Could the leak be used to gather some interesting data? ;-) In any case, this behavior is wrong on several levels. And with the likely security issue present, I don't think it's worth the time to consider this hardware seriously. Jiri _______________________________________________ Linuxptp-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxptp-devel |
|
From: Richard C. <ric...@gm...> - 2019-02-01 03:48:28
|
On Thu, Jan 31, 2019 at 04:22:20PM +0000, 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 event messages are carefully designed to all have the same length. You simply should not go tacking random stuff onto the end of frames. Thanks, Richard |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X