Re: On the nature of backward comparability

Wes, Thank you for taking the time to put the history of Net-SNMP's codebase to paper. I feel that it puts why the codebase is the way it is in its proper perspective. After reading this very insightful essay, I feel that Net-SNMP being the "de-facto SNMP stack" also means that it's the

Re: Textual name of Object in SNMP Packet

Hi Robert, Thanks for your valuable reply. On Mon, May 14, 2018 at 11:38 PM, Robert Story wrote: > On Mon, 14 May 2018 15:28:31 +0530 Anandaprabu wrote: > AV> As per my project requirement I was requested by the NMS to > AV> send Textual Object name in a column of a Table.

Re: [PATCH 00/15] Clean up Net-SNMP public header files

Robert Story writes: > Unfortunately I don't really see any backwards compatibility fixes > here. It all looks like cleanup, which doesn't meet the criteria > for patches at this point in the release process. The Cygwin build > fix is a possible exception, so I'll +1 that

Re: On the nature of backward comparability

Bart Van Assche writes: >> A) write a configure test for any struct/api/feature/etc that wasn't >> portable across all platforms. >> >> B) failing the ability to do that, see if you could determine it at >> runtime (see agent/auto_nlist as a reference point). >> >> C)

Re: On the nature of backward comparability

Thanks Wes for the elaborate write-up. On 05/14/18 14:07, Wes Hardaker via Net-snmp-coders wrote: The struggle with all of this, of course, is that the code begins to look a little crusty in spots while we try to maintain support for so many operating systems that we don't even have the ability

On the nature of backward comparability

[hopefully mostly coherent rambling below?] This is more of a "history of where we are and how we got here" than a directive. But it's important we consider how we got here before making major changes to the code base, especially surrounding changes that break backward compatibility. Long long

Re: Summary of meeting between NET-SNMP devs and ICEI

That is a very useful list. What I would recommend though is we should finish dealing with the #ifdef hell and replacing autotools with cmake first. That way if we have to onboard new people to the project they are dealing with the "cleaned-up" code base. On Sun, May 13, 2018, at 6:37 PM,

Re: RFC: fix clientaddr for 5.8

Den 14-05-2018 kl. 20:05 skrev Robert Story: +1 on both counts (commit it, but use cherry-pick). +1 (and I wouldn't mind the OpenBSD part getting merged too) /Niels -- Niels Baggesen - @home - Århus - Denmark - n...@users.sourceforge.net The purpose of computing is insight, not numbers ---

Re: Textual name of Object in SNMP Packet

On Mon, 14 May 2018 15:28:31 +0530 Anandaprabu wrote: AV> As per my project requirement I was requested by the NMS to AV> send Textual Object name in a column of a Table. AV> AV> Like after adding the Managed device to NMS, the device should AV> make a queue of updated objects in a table (let's

Re: Suggested patch to support NetBSD 8

On Mon, 14 May 2018 08:45:54 -0700 Bart wrote: BVA> On 05/14/18 05:29, Niels Baggesen via Net-snmp-coders wrote: BVA> > The patch that went into 5.7-patches is not sufficient for BVA> > NetBSD 8 on 5.8 BVA> > BVA> > The following patch to 5.8.RC1 is required. BVA> > BVA> > May I solicit some

Re: RFC: fix clientaddr for 5.8

On Mon, 14 May 2018 08:44:19 -0700 Bart wrote: BVA> > https://sourceforge.net/p/net-snmp/code/ci/3defab66a7aee60ba582a8254412abd2e630c321/ BVA> > BVA> > It turns out that when you specify a clientaddr, the steps BVA> > the function takes are: BVA> > BVA> > - zero out addr_pair BVA> > - store

Re: Suggested patch to support NetBSD 8

On 05/14/18 05:29, Niels Baggesen via Net-snmp-coders wrote: The patch that went into 5.7-patches is not sufficient for NetBSD 8 on 5.8 The following patch to 5.8.RC1 is required. May I solicit some votes? diff --git a/agent/mibgroup/mibII/at.h b/agent/mibgroup/mibII/at.h index

Re: RFC: fix clientaddr for 5.8

On 05/14/18 08:00, Bill Fenner wrote: I've committed the following fix to the 5.7-patches branch: https://sourceforge.net/p/net-snmp/code/ci/3defab66a7aee60ba582a8254412abd2e630c321/ It turns out that when you specify a clientaddr, the steps the function takes are: - zero out addr_pair -

RFC: fix clientaddr for 5.8

I've committed the following fix to the 5.7-patches branch: https://sourceforge.net/p/net-snmp/code/ci/3defab66a7aee60ba582a8254412abd2e630c321/ It turns out that when you specify a clientaddr, the steps the function takes are: - zero out addr_pair - store the remote address in addr_pair -

Suggested patch to support NetBSD 8

The patch that went into 5.7-patches is not sufficient for NetBSD 8 on 5.8 The following patch to 5.8.RC1 is required. May I solicit some votes? diff --git a/agent/mibgroup/mibII/at.h b/agent/mibgroup/mibII/at.h index 1676cb6..e89b966 100644 --- a/agent/mibgroup/mibII/at.h +++

Textual name of Object in SNMP Packet

Hi Coders, As per my project requirement I was requested by the NMS to send Textual Object name in a column of a Table. Like after adding the Managed device to NMS, the device should make a queue of updated objects in a table (let's say configUpdateTable) which will be queried by the NMS if the