#40 Error in broadcasted grandmasterIdentity

v1.0_(example)
closed
None
2
2013-11-04
2013-02-15
No

In my ARM base environment, the last byte in the announce packet's grandmasterIdentity is corrupted.

In the routine msgPackAnnounce(), the line of code:

copyClockIdentity((buf + 53), ptpClock->grandmasterIdentity);

works fine, but the following line

*(UInteger16 *) (buf + 61) = flip16(ptpClock->stepsRemoved);

overwrites the location buf + 60. I believe this is due to a problem with writing 16-bit words to an odd byte aligned memory location.

I was able to fix this with:

unsigned char aubTemp[2];

/ Since we will be writing a 16 bit word to a byte aligned /
/ memory location, break it up ointo bytes before we write /
/ it. The original 16-bit write accidentally overwrote /
/ location buf + 60. /
(UInteger16 ) (aubTemp) = flip16(ptpClock->stepsRemoved);
(Enumeration8 ) (buf + 61 + 0) = aubTemp[0];
(Enumeration8 ) (buf + 61 + 1) = aubTemp[1];

Note: I have also replaced the odd byte aligned read in the routine msgUnpackAnnounce() with two byte reads.
unsigned char aubTemp[2];

/ Correct any word alignment problem that may arise. /
aubTemp[0] = (Enumeration8 ) (buf + 61 + 0);
aubTemp[1] = (Enumeration8 ) (buf + 61 + 1);
announce->stepsRemoved = flip16((UInteger16 ) (aubTemp));

Thank you,
Mike Skoog

Related

Bugs: #40

Discussion

  • George Neville-Neil

    Thanks for the report. I'm going to look into this a bit more deeply and then see if your fix is the one we want or if I simply need to do something more intelligent in flip16.

    Embedded systems (i.e. non X86) have a lot of fun alignment issues to look at.

    Can you tell me just what type of ARM processor you're using?

     
  • George Neville-Neil

    • status: open --> accepted
    • priority: 5 --> 2
     
  • Michael Skoog

    Michael Skoog - 2013-02-20

    Hi George,

    On ptpd:bugs #40:

    The ARM cpu we are using is the Marvell Feroceon 88FR131. The cpu
    Architecture is 5TE, variant = 0.02.

    I hopes that this will help you.

    Mike Skoog

    On 2/20/2013 10:38 AM, George Neville-Neil wrote:

    Thanks for the report. I'm going to look into this a bit more deeply
    and then see if your fix is the one we want or if I simply need to do
    something more intelligent in flip16.

    Embedded systems (i.e. non X86) have a lot of fun alignment issues to
    look at.

    Can you tell me just what type of ARM processor you're using?


    [bugs:#40] http://sourceforge.net/p/ptpd/bugs/40/ Error in
    broadcasted grandmasterIdentity

    Status: open
    Created: Fri Feb 15, 2013 10:20 PM UTC by Michael Skoog
    Last Updated: Fri Feb 15, 2013 10:20 PM UTC
    Owner: nobody

    In my ARM base environment, the last byte in the announce packet's
    grandmasterIdentity is corrupted.

    In the routine msgPackAnnounce(), the line of code:

    copyClockIdentity((buf + 53), ptpClock->grandmasterIdentity);

    works fine, but the following line

    (UInteger16 ) (buf + 61) = flip16(ptpClock->stepsRemoved);

    overwrites the location buf + 60. I believe this is due to a problem
    with writing 16-bit words to an odd byte aligned memory location.

    I was able to fix this with:

    unsigned char aubTemp[2];

    //Since we will be writing a 16 bit word to a byte aligned //
    //memory location, break it up ointo bytes before we write //
    //it. The original 16-bit write accidentally overwrote //
    //location buf + 60. //
    /(UInteger16 /) (aubTemp) = flip16(ptpClock->stepsRemoved);
    /(Enumeration8 /) (buf + 61 + 0) = aubTemp[0];
    /(Enumeration8 /) (buf + 61 + 1) = aubTemp[1];

    Note: I have also replaced the odd byte aligned read in the routine
    msgUnpackAnnounce() with two byte reads.
    unsigned char aubTemp[2];

    //Correct any word alignment problem that may arise. //
    aubTemp[0] = /(Enumeration8 /) (buf + 61 + 0);
    aubTemp[1] = /(Enumeration8 /) (buf + 61 + 1);
    announce->stepsRemoved = flip16(/(UInteger16 /) (aubTemp));

    Thank you,
    Mike Skoog


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/ptpd/bugs/40/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/prefs/

     

    Related

    Bugs: #40

  • Wojciech Owczarek

    The closest I can get to ARM is Raspberry Pi. There is probably going to be more fun with alignment than this :)

     
  • George Neville-Neil

    I have a Pi as well as a BeagleBone. Been meaning to put GPS on the latter and try out PTPd. Now that there is decent FreeBSD support on those boxes I'll be trying PTPd there, and I'm sure we'll find the problems soon after.

     
  • Jan Breuer

    Jan Breuer - 2013-09-16

    It is same bug as [bugs:#37]

    This is caused by memory alignment limitations of pre ARMv6
    architectures - XScale, ARM9, ARM7, ...

    All newer chips are ok - ARM11, Cortex (RaspberyPI, BeagleBoard, BeagleBone, ...)

    Problematic parts of code are lines

    *(UInteger16 *) (buf + 61) = flip16(ptpClock->stepsRemoved);
    announce->stepsRemoved = flip16(*(UInteger16 *) (buf + 61));
    

    and functions
    packClockQuality, unpackClockQuality because they are used misaligned in defaultDataSet and parentDataSet management messages

     

    Related

    Bugs: #37

  • Jan Breuer

    Jan Breuer - 2013-09-17
    • assigned_to: Jan Breuer
     
  • Jan Breuer

    Jan Breuer - 2013-09-17

    Resolved in SVN 371

     
  • Jan Breuer

    Jan Breuer - 2013-09-17
    • status: accepted --> pending
     
  • Jan Breuer

    Jan Breuer - 2013-11-04
    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks