lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] lwIP 1.4.0 with SNTP Client


From: Tyrel Newton
Subject: Re: [lwip-users] lwIP 1.4.0 with SNTP Client
Date: Sat, 12 Nov 2011 16:41:09 -0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 11/11/2011 9:10 AM, Adams, David wrote:

I’ve recently started using lwIP with the STR912 processor.  This is my first experience with lwIP and I’ve managed to port this for my processor relatively easily with the Sockets API.  I’m wanting to use the SNTP client app, but modify it slightly to use the time the packet was received by Ethernet driver to calculate the time offset.  The current SNTP client just uses the transmit time in the SNTP message from the server to update the system time.

 

I’m thinking the best way would be to take a timestamp of the time when each ethernet packet is received and somehow pass this along with the packet to the SNTP application.

I have an application where I need to pass information generated at the netif/driver level up the stack as well. My solution is store this information "in front" of the link layer header (Ethernet in your example) in the pbuf payload. To make room for extra stuff before the link layer header, I simply increased the PBUF_LINK_HLEN option in lwipopts.h. This increases the number of bytes reserved for the link layer header each time a pbuf is allocated. In my netif driver, I simply "cover up" this extra stuff before passing it to ip_input. Upper layers can then uncover the headers until this extra information is uncovered. From a pbuf_header perspective, this extra information is essentially a frame header that sits below the link layer header whereas normally the link layer header is at the bottom (or front) of the pbuf payload.

 

As I’ve not used lwIP before I’m struggling to find a way to pass this timestamp to the SNTP routine and keep it reference to the SNTP packet.  I have considered storing this in the pbuf but I’m not keen on modifying the pbuf without a better understanding the implications of this.  I have also looked at adding this time to the end of the Rx buffer, then storing this in the pbuf but as this is passed through the ip_input routine the additional data is stripped from the buffer as its not part of the original packet.

 

Does anyone have any experience of implementing anything similar, or any ideas or tips of achieving this.

 


Tyrel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]