Re: question about net-snmp

On 15/08/07, Mike Ayers <[email protected]> wrote:
> On Behalf Of Brian A. Seklecki
>
> > are we talking about time_t being a 64bit integer ?
>
>         No.  The year 2038 problem occurs with 32 bit integers which count seconds
> and start in 1970.  SNMP uses a 32 bit timestamp, but it is referenced only from
> when the engine is booted, so v1 and v2c engines do not suffer from the year
> 2038 problem, but must be rebooted at least once every 68 years.  SNMPv3
> introduced a 31 bit engine boot counter which extends the potential uptime
> without reboot significantly.  Yes, sad to say, SNMPv3 suffers from the year
> 146,135,513,385 problem.  Will we ever learn?


That's the situation w.r.t the SNMP protocols, certainly.
But I suspect that Nagata was asking about the status of the Net-SNMP code.

In which case, Brian has identified the main issue here - the reliance on
'time_t' and related API calls to hold and manipulate "time-since-the-Epoch"
values.

The status here is similar to that regarding the Y2K issue.
The Net-SNMP code predominately relies on the underlying O/S
libraries for most of this processing.   If the O/S is susceptible to
the 2038 problem, then the Net-SNMP applications will be too.

As soon as it becomes clear how Unix and similar O/Ss will address
this problem (unsigned 32-bit or 64-bit t_time, etc), then we can
check whether the Net-SNMP code needs any special attention.

Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users