Wed, Apr 1
Tue, Mar 31
Oct 22 2018
Sep 20 2018
Hi, Harti, we have used IPv6 transport several weeks now, and it seems all works good. Do you want to see the full final patch that we use?
Aug 16 2018
Updated diff and marked comments as done.
Use memcpy() in some places.
Save and use the complete in6_pktinfo.
Check that link local addresses have a non-zero scope and produce a warning if not.
Add upd6 and ipv6 address format for server specification.
Factor out common creation code for ipv6 and ipv6z.
Fix a type in gensnmptree.
Aug 11 2018
Hi Andrey, some comments on your comments :-)
Hi, Harti, while I was on the vacation, you made the patch :)
You can take a look to what I did before the vacation https://people.freebsd.org/~ae/bsnmpd_ipv6.diff
It is incomplete, but I started to make it differently. Maybe you will find something interesting.
I've only scrolled through. I really don't get why ipv6z (needless to say ipv4z is defined but not used) needs to be special. The fact that we encode the interface index is unhelpful in a config file as that might change between boots or other operations, such as oder of vnet creation, order of interface creation, etc.
Aug 10 2018
Jul 27 2018
Well, the standard says (0 ..64) and that means from zero to 64.
Also, my impression is that, according to the RFC, ifAlias is something that should be settable over SNMP and it should be persistent.
I found this interesting link on the topic and I must admit that I know very little about it:
Jul 3 2018
May 8 2018
Ah, thanks. This looks fine. Then we really could go for 64-bit counters for all interfaces.
May 7 2018
How does it do that? The problem is whether a 64-bit increment or add is atomic with regard to a read from another CPU.
Apr 17 2018
Maybe better solution is just provide 64-bit counters for all interfaces? It seems net-snmpd does so.