> Then when Manager side send request, agent will return with new engineboot,
> then manager side will send request again with new engineboot and time.
> I thought this time, agent will think its in sync with manager side.

Yes - that should be what happens.
It's probably worth checking this - try running the agent with packet
dumps turned on
(either '-d' or '-Ddump'), and compare the values in the (first) Report packet
with those in the (second) Request packet

<<<<<Barclay
For example, Manager side send request to agent, SNMP agent send report with 
engineboot=1,Manager then request with engineboot=1. When SNMP agent 
re-started, got request from Manger, the enginetime will not match,as SNMP 
agent restarts reset the enginetime. Agent will response error with 
not-in-time-window.
What I did is to store the engineboot somewhere else from Agent, when agent 
restarts will read the last engineboot and increase 1, and response with new 
engineboot=2, Mnager side then send request with new engineboot=2, Agent will 
think it's sync with manager side and proceed the request normally.
>>>>>

-----Original Message-----
From: dave.shi...@gmail.com [mailto:dave.shi...@gmail.com] On Behalf Of Dave 
Shield
Sent: 2013年1月6日 1:56
To: Zheng, Wenjie (Barclay)
Cc: net-snmp-cod...@lists.sourceforge.net; net-snmp-users@lists.sourceforge.net
Subject: Re: SNMP Agent engineboot

On 5 January 2013 13:21, Zheng, Wenjie (Barclay)
<barclay.zh...@alcatel-lucent.com> wrote:
> I try to use  set_enginetime() by set the engineboots to a value stored in 
> out side of agent.

I don't understand what you are trying to do here.
Is this call to 'set_enginetime' in the agent, or in the manager?

You shouldn't need to touch the engine boot information in the agent.
The boot count and time values are handled automatically by the
Net-SNMP library.
They will be updated when the agent re-started, and maintained as the
agent runs.
You shouldn't need to meddle with them.

I'm also not entirely sure why you are trying to re-implement an agent
in the first place?
Why not simply use the standard Net-SNMP agent - which we know works!


> Then when Manager side send request, agent will return with new engineboot,
> then manager side will send request again with new engineboot and time.
> I thought this time, agent will think its in sync with manager side.

Yes - that should be what happens.
It's probably worth checking this - try running the agent with packet
dumps turned on
(either '-d' or '-Ddump'), and compare the values in the (first) Report packet
with those in the (second) Request packet


> But unfortunately, seems usm_check_and_update_timeliness() will still return 
> error,
> it will compare the the static engineBoots stored in agent with the new 
> engineboots
> value. boots_uint != myBoots

And which one is right?
What are the two values, and how do they compare with the value in the
Report message
(and with the engineBoot value from before the agent was restarted) ?


> myBoots is get from snmpv3_local_snmpEngineBoots:
>         snmpv3_local_snmpEngineBoots(void)
>         {
>                 return engineBoots;
>         }
>
> Seems I can not set this static engineBoots?

No - it's maintained by the library code, and updated automatically
when the agent restarts.   You shouldn't need to change it directly.

I'm actually wondering whether the manager software is updating
the boot count value correctly - or whether it's using the same value
for both requests?

Dave
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to