I think snmp_send_port() was use by the ILMI daemon for ATM to proxy the ILMI tree (which was visible only between the two ILMI instances over the ATM) link into the regular tree visible via UDP. Since ILMI is long dead (R.I.P.) there should be no problem fixing these things.

Good catch.

I think the line wrapping in line 289 is still not correct. Otherwise it looks fine.

Nice catch.

Looks good.

Find for me.

Looks good to me.

Reduce code duplication.
Update kqueue.2.

This looks good to me. Good catch.

For me this looks good. In the middle term (next year) I have a plan to get rid of static data in the library.

In D16654#376845, @ae wrote:

Hi, Harti, it is good time to commit the IPv6 support into head/ :)

In D16654#367736, @ae wrote:

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?

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.

Hi Andrey, some comments on your comments :-)

In D16654#353982, @ae wrote:

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.

In D16654#353961, @bz wrote:

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.

In D16459#349483, @avg wrote:

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:
http://irobert.info/display/IRINFO/Understanding+ifDescr%2C+ifName+and+ifAlias

Ah, thanks. This looks fine. Then we really could go for 64-bit counters for all interfaces.

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.

In D15112#318283, @ae wrote:

Maybe better solution is just provide 64-bit counters for all interfaces? It seems net-snmpd does so.