Differential D16654
IPv6 transport for bsnmp Authored by harti on Aug 10 2018, 9:44 AM. Tags None Referenced Files
Details
This patch adds a new table begemotSnmpdTransInetTable that uses the InetAddressType textual convention and can be used to create listening ports for IPv4, IPv6, zoned IPv6 and based on DNS names. It also supports future extension beyond UDP by adding a protocol identifier to the table index. In order to support this gensnmptree had to be modified. This needs testing one more realistic IPv6 environments. Especially the ipv6z and dns address types need some testing.
Diff Detail
Event TimelineComment Actions 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.
Comment Actions Hi, Harti, while I was on the vacation, you made the patch :) Comment Actions The definition for InetAddressType comes from RFC4001 and I decided to use that instead of rolling our own. Since we have nothing like ipv4z, its not supported in the new table. ipv6z is. Sure the interface index is not the best thing in a config file, but this is how all the interface-related stuff in SNMP works. The primary key is the interface index. As far as I understand it was once supposed to be constant even through reboots, but this is obviously not the case anymore. I see several options to make this more useable:
The near term plan would be to implement the config functions. There is some mechanism in mibII to make interface indexes constant during operation by using the MAC address as a key. This makes operating system interface indexes and SNMP interface indexes differ, and I don't like the complexity of this. I also doubt that it is useful and have a plan to not implement this in a new version of mibII. Comment Actions Hi Andrey, yeah, I completly forgot about the client side. Adding a new SNMP syntax is probably not the best thing to do because clients will not understand it. Making an extra table for IPv6 is surely an option, but then I thought that with the RFC4001 stuff one gets even more functionality (the dns-type addresses). If its ok, I integrated some of your client-side stuff? Regards, Comment Actions Hi Andrey, some comments on your comments :-)
Comment Actions
Comment Actions I thought to use only following form of IPv6 addresses in config file: +begemotSnmpdInet6PortStatus.[$(host)].161 = 1 +begemotSnmpdInet6PortStatus.[::1].161 = 1 +begemotSnmpdInet6PortStatus.[fe80::1%igb0].161 = 1 +begemotSnmpdInet6PortStatus.[2002::dead:c0de::1].161 = 1 But this variant only expects IPv6 addresses for begemotSnmpdInet6PortStatus. In your case I think we can check if it is IPv4 addres, then if it IPv6 address, and then if it is host name.
Comment Actions Use memcpy() in some places.
Comment Actions So, I finally found the cause of strange behavior. It is due to the route caching. Reverting of this change makes it working https://svnweb.freebsd.org/base/head/sys/netinet6/udp6_usrreq.c?r1=304545&r2=304713 The problem is that when several packets are sending, after first packet inpcb caches the route via loopback interface and then uses rt_ifp as ifp. --- a/sys/netinet6/ip6_output.c +++ b/sys/netinet6/ip6_output.c @@ -83,6 +83,7 @@ __FBSDID("$FreeBSD$"); #include <sys/socketvar.h> #include <sys/syslog.h> #include <sys/ucred.h> +#include <sys/sbuf.h> #include <machine/in_cksum.h> @@ -582,6 +583,27 @@ again: * The outgoing interface must be in the zone of source and * destination addresses. */ + { + char ip6buf[INET6_ADDRSTRLEN]; + struct sbuf *sb; + + sb = sbuf_new_auto(); + sbuf_printf(sb, "%s: src %s, ", __func__, + ip6_sprintf(ip6buf, &ip6->ip6_src)); + sbuf_printf(sb, "dst %s, ", + ip6_sprintf(ip6buf, &ip6->ip6_dst)); + sbuf_printf(sb, "ifp %s", ifp->if_xname); + if (ro->ro_rt) + sbuf_printf(sb, ", rt_ifp %s", + ro->ro_rt->rt_ifp->if_xname); + if (inp) + sbuf_printf(sb, ", ro %p, inp_route6 %p", + ro, &inp->inp_route6); + sbuf_putc(sb, '\n'); + sbuf_finish(sb); + sbuf_putbuf(sb); + sbuf_delete(sb); + } origifp = ifp; src0 = ip6->ip6_src; The result: 01: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffff80104203300, inp_route6 0xfffff80104203300 02: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffff801309f9300, inp_route6 0xfffff801309f9300 03: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp lo0, rt_ifp lo0, ro 0xfffff80104203300, inp_route6 0xfffff80104203300 snmpd[891]: send*: No route to host 04: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp lo0, rt_ifp lo0, ro 0xfffff801309f9300, inp_route6 0xfffff801309f9300 Note, lo0 has scopeid 0x3, and ix0 has scopeid 0x1. In the line_01 ip6_output does first route lookup that is saved in inpcb, in the line_03 the cached route is used and the result is scope zone violation with EHOSTUNREACH error. With reverted change in udp6_usrreq.c I got this result: Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe104938e4d8, inp_route6 0xfffff801149f2cf0 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe10492da4c8, inp_route6 0xfffff80114a2d4a8 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe104938e4d8, inp_route6 0xfffff801149f2cf0 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe10492da4c8, inp_route6 0xfffff80114a2d4a8 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe104938e4d8, inp_route6 0xfffff801149f2cf0 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe10492da4c8, inp_route6 0xfffff80114a2d4a8 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe104938e4d8, inp_route6 0xfffff801149f2cf0 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe10492da4c8, inp_route6 0xfffff80114a2d4a8 Aug 30 14:20:08 test15 kernel: ip6_output: src fe80:1::225:90ff:fef9:3c92, dst fe80:1::225:90ff:fef9:3c92, ifp ix0, rt_ifp lo0, ro 0xfffffe104938e4d8, inp_route6 0xfffff801149f2cf0 # tcpdump -ni lo0 udp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes 14:27:42.084482 IP6 fe80::225:90ff:fef9:3c92.25206 > fe80::225:90ff:fef9:3c92.161: C="aish117" GetNextRequest(24) .1.3.6.1.2.1.25.1 14:27:42.097568 IP6 fe80::225:90ff:fef9:3c92.161 > fe80::225:90ff:fef9:3c92.25206: C="aish117" GetResponse(29) .1.3.6.1.2.1.25.1.1.0=52022 14:27:42.110651 IP6 fe80::225:90ff:fef9:3c92.25206 > fe80::225:90ff:fef9:3c92.161: C="aish117" GetNextRequest(26) .1.3.6.1.2.1.25.1.1.0 14:27:42.123738 IP6 fe80::225:90ff:fef9:3c92.161 > fe80::225:90ff:fef9:3c92.25206: C="aish117" GetResponse(37) .1.3.6.1.2.1.25.1.2.0=07_e2_08_1e_0e_1b_2a_01_2b_00_00 14:27:42.136825 IP6 fe80::225:90ff:fef9:3c92.25206 > fe80::225:90ff:fef9:3c92.161: C="aish117" GetNextRequest(26) .1.3.6.1.2.1.25.1.2.0 14:27:42.149912 IP6 fe80::225:90ff:fef9:3c92.161 > fe80::225:90ff:fef9:3c92.25206: C="aish117" GetResponse(27) .1.3.6.1.2.1.25.1.3.0=0 14:27:42.162999 IP6 fe80::225:90ff:fef9:3c92.25206 > fe80::225:90ff:fef9:3c92.161: C="aish117" GetNextRequest(26) .1.3.6.1.2.1.25.1.3.0 # dtrace -n 'fbt::nd6_output_ifp:entry {printf("%s %s", args[0]->if_xname, args[1]->if_xname);}'
dtrace: description 'fbt::nd6_output_ifp:entry ' matched 1 probe
CPU ID FUNCTION:NAME
19 40912 nd6_output_ifp:entry lo0 ix0
16 40912 nd6_output_ifp:entry lo0 ix0
19 40912 nd6_output_ifp:entry lo0 ix0
16 40912 nd6_output_ifp:entry lo0 ix0
19 40912 nd6_output_ifp:entry lo0 ix0
16 40912 nd6_output_ifp:entry lo0 ix0
19 40912 nd6_output_ifp:entry lo0 ix0
16 40912 nd6_output_ifp:entry lo0 ix0
Comment Actions So, local TCP communications using IPv6 link-local addresses also affected by routing caching. Note, should be used addresses that are configured on non-loopback interfaces. # ifconfig ix0 | grep scopeid inet6 fe80::225:90ff:fef9:3c92%ix0 prefixlen 64 scopeid 0x1 # netstat -sp ip6 | grep "scope rules" 22 packets that violated scope rules # nc -l -6 fe80::225:90ff:fef9:3c92%ix0 5678 second console: # nc -6 fe80::225:90ff:fef9:3c92%ix0 5678 TEST TEST2 # dtrace -n 'fbt::ip6_output:return {printf("%d", arg1);}'
dtrace: description 'fbt::ip6_output:return ' matched 1 probe
CPU ID FUNCTION:NAME
12 27904 ip6_output:return 65
12 27904 ip6_output:return 65
0 27904 ip6_output:return 65
0 27904 ip6_output:return 65# netstat -sp ip6 | grep "scope rules" 35 packets that violated scope rules Comment Actions I believe I understand the issue with route caching. in6_selectroute_fib checks for loopback,and substitutes the interface with the local address. ip6_output doesn't need to know that interface, it should just skip the scope check in that case. I'll email a possible kernel patch to Andrey and Harti.
Comment Actions 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? Comment Actions Hi Andrey, yes this would be very helpful. Now that I'm back from vacation I should be able to finish this work. Comment Actions Hi Andrey, unfortunately I'm completely busy with the kick-off of a large project taking place this week in the last weeks:-/. If somebody could help... harti | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||