Re: sendmail vs ipv6 broken after upgrade to 9.1
In message <20130110002257.ga84...@anubis.morrow.me.uk>, Ben Morrow writes: > Yeah; I agree that the v4-mapped option is pretty useless (even when > using a stack which supports it). I suspect the IETF people were trying > too hard to account for the case of a v6-only stack talking to the v4 > Internet, when AFAIK there aren't any v6-only stacks yet, nor are there > likely to be for the forseeable future. That's why I think Sendmail > ought to be changed to pass 0 flags, so it doesn't see v4-mapped > addresses at all: after all, there's little point binding separate v4 > and v6 sockets if the v6 socket is just going to end up bound to a > v4-mapped address. Mapped addresses are for dual stack hosts and sockets with IPV6_ONLY turned off. They work much better when the IPv4 side of the stack has been upgraded to support all of the new features of IPv6 socket api like packet info so that the application doesn't need to remember if it is talking to a IPv4 or IPv6 destination. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sendmail vs ipv6 broken after upgrade to 9.1
Quoth Hajimu UMEMOTO : > Hi, > > > On Wed, 9 Jan 2013 16:29:00 + > > Ben Morrow said: > > ben> Where does it say that? All I can find (but I might be being stupid) is > ben> the bit in the description of AI_ALL where it says 'A query is first > ben> made for records and if successful, the IPv6 addresses are > ben> returned. Another query is then made for A records and any found are > ben> returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant > ben> to indicate the results are returned first in the list, just that > ben> both sets of results are included. > > It is the sentence you mentioned. It was not thought those days that > a query order and an order of the value to return were another. So, I > think that it implies the order of the value to return. OK. Since this is a legacy API, the real question is 'what do existing applications calling it expect?'. You may be right that they will expect to see IPv6 addresses first if there are any. > ben> Also, RFC 6724 (which is more recent), says 'we intend that > ben> implementations of APIs such as getaddrinfo() will use the destination > ben> address selection algorithm specified here to sort the list of IPv6 and > ben> IPv4 addresses that they return.'. AFAICS 'APIs such as getaddrinfo()' > ben> is supposed to include getipnodebyname and gethostbyname2, and the whole > ben> list of v4 and v6 addresses is supposed to be sorted by those rules. > > I thought so at the time when I implemented it. However, > getipnodebyname has IPv4-mapped addresses issue as compared with > getaddrinfo. > Since gethostbyname2 doesn't treat multiple families at once, it is > out of scope, IMHO. gethostbyname2 in FreeBSD doesn't obey > ip6addrctl. ip6addrctl does more than just order v4 vs v6: it also sorts the v6 addresses, in a way which can be quite important. IMHO both the v6 addresses returned from getipnodebyname and the addresses returned from gethostbyname2(AF_INET6) ought to be sorted according to ip6addrctl, even if getipnodebyname special-cases the v4-mapped addresses to appear last. > ben> However, given that FreeBSD disables the use of v4-mapped addresses on > ben> AF_INET6 sockets by default, it might be sensible to change the rules a > ben> little. An application making an AF_INET6 query is probably going to use > ben> the result with an AF_INET6 socket, so a v4-mapped address is going to > ben> be mostly useless. > > There is IPV6_V6ONLY socket option. Still, an application has two > choices: > - convert IPv4-mapped address to IPv4 address, or > - issue IPV6_V6ONLY socket option. > In anyway, I think it is important that an application conscious of > using the IPv4-mapped address. Yeah; I agree that the v4-mapped option is pretty useless (even when using a stack which supports it). I suspect the IETF people were trying too hard to account for the case of a v6-only stack talking to the v4 Internet, when AFAIK there aren't any v6-only stacks yet, nor are there likely to be for the forseeable future. That's why I think Sendmail ought to be changed to pass 0 flags, so it doesn't see v4-mapped addresses at all: after all, there's little point binding separate v4 and v6 sockets if the v6 socket is just going to end up bound to a v4-mapped address. > > I've just committed to disable it: > > > > http://svnweb.freebsd.org/base?view=revision&revision=245225 > > ben> I don't think that's the right answer. Even if the code should be > ben> changed to always return addresses from A records last, the IPv6 > ben> addresses from records should still be sorted according to > ben> ip6addrctl. Otherwise sites with multiple prefixes (say, a ULA prefix > ben> and a global prefix) won't be able to control their use properly. > > getipnodebyname was deprecated by RFC 3493 and appropriate time has > passed since then. So, it is low-priority, IMHO. Well, if important applications like Sendmail are still using it it's probably important it works consistently with the rest of the system's IPv6 support. I'd rather see it removed, or reimplemented as a wrapper around getaddrinfo, than left in a broken state. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zio_done panic on unadulterated FreeBSD Release 9.1
On Wed, Jan 09, 2013 at 08:03:38PM +, Po-Li Soong wrote: > Hi, > > My name is Po-Li Soong. I ran into a crash not long after installing the 9.1 > release on my home machine. I was performing a test run of file transfer with > samba server running on the FreeBSD installation. The transfer rate was about > 70-80 MB/sec. The core.txt is attached. If there are other crash dumps > needed, please let me know. > > I first discussed this panic with Justin Gibbs, a coworker of mine at Spectra > Logic. He referred me to this email address, suggesting that the information > should be relevant to you. Thanks for the help. > > Regards, > > Po-Li Soong > > maestoso dumped core - see /var/crash/vmcore.0 > > Sat Jan 5 19:53:24 MST 2013 > > FreeBSD maestoso 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 > 09:23:10 UTC 2012 > r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > panic: page fault > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0xfffb812815d8 > fault code= supervisor read data, page not present > instruction pointer = 0x20:0x80b50597 > stack pointer = 0x28:0xff80fa3bc8d0 > frame pointer = 0x28:0xff80fa3bc900 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (zio_write_intr_5) > trap number = 12 > panic: page fault > cpuid = 3 > KDB: stack backtrace: > #0 0x809208a6 at kdb_backtrace+0x66 > #1 0x808ea8be at panic+0x1ce > #2 0x80bd8240 at trap_fatal+0x290 > #3 0x80bd857d at trap_pfault+0x1ed > #4 0x80bd8b9e at trap+0x3ce > #5 0x80bc315f at calltrap+0x8 > #6 0x80b506f5 at vm_page_free_toq+0x45 > #7 0x80b4f276 at vm_object_page_remove+0x196 > #8 0x80b46b06 at vm_map_delete+0x316 > #9 0x80b46c11 at vm_map_remove+0x51 > #10 0x80b3a70a at uma_large_free+0x3a > #11 0x808d589a at free+0x5a > #12 0x8169b4ce at zio_done+0x2ee > #13 0x81699063 at zio_execute+0xc3 > #14 0x8092cf55 at taskqueue_run_locked+0x85 > #15 0x8092ded6 at taskqueue_thread_loop+0x46 > #16 0x808bb9ef at fork_exit+0x11f > #17 0x80bc368e at fork_trampoline+0xe > Uptime: 3h19m34s > Dumping 571 out of 3561 MB:..3%..12%..23%..31%..42%..51%..62%..73%..82%..93% > > Reading symbols from /boot/kernel/zfs.ko...Reading symbols from > /boot/kernel/zfs.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from > /boot/kernel/opensolaris.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/opensolaris.ko > #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > 224 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump (textdump=Variable "textdump" is not available. > ) at pcpu.h:224 > #1 0x808ea3a1 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0x808ea897 in panic (fmt=0x1 ) > at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0x80bd8240 in trap_fatal (frame=0xc, eva=Variable "eva" is not > available. > ) > at /usr/src/sys/amd64/amd64/trap.c:857 > #4 0x80bd857d in trap_pfault (frame=0xff80fa3bc820, usermode=0) > at /usr/src/sys/amd64/amd64/trap.c:773 > #5 0x80bd8b9e in trap (frame=0xff80fa3bc820) > at /usr/src/sys/amd64/amd64/trap.c:456 P > #6 0x80bc315f in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:228 > #7 0x80b50597 in vm_page_remove (m=0xfe00cd733ab0) > at /usr/src/sys/vm/vm_page.c:975 > #8 0x80b506f5 in vm_page_free_toq (m=0xfe00cd733ab0) > at /usr/src/sys/vm/vm_page.c:1872 > #9 0x80b4f276 in vm_object_page_remove (object=0x81281580, > start=477512, end=477539, options=Variable "options" is not available. > ) at /usr/src/sys/vm/vm_object.c:1899 > #10 0x80b46b06 in vm_map_delete (map=0xfe0002e8, > start=Variable "start" is not available. > ) > at /usr/src/sys/vm/vm_map.c:2739 > #11 0x80b46c11 in vm_map_remove (map=0xfe0002e8, > start=18446743525909626880, end=18446743525909737472) > at /usr/src/sys/vm/vm_map.c:2871 > #12 0x80b3a70a in uma_large_free (slab=0xfe0
Re: sendmail vs ipv6 broken after upgrade to 9.1
On Wed, 2013-01-09 at 23:42:10 +0900, Hiroki Sato wrote: > Ulrich Spörlein wrote > in <20130109142111.gl35...@acme.spoerlein.net>: > > > On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: > > > On 01/08/2013 23:33, Hiroki Sato wrote: > > > > Ulrich Spörlein wrote > > > >in <20130108184051.gi35...@acme.spoerlein.net>: > > > > > > > > uq> After setting this, it now looks like this: > > > > uq> root@acme: ~# ip6addrctl > > > > uq> Prefix Prec Label Use > > > > uq> ::1/128 50 00 > > > > uq> ::/0 40 10 > > > > uq> 2002::/16 30 20 > > > > uq> ::/96 20 30 > > > > uq> :::0.0.0.0/96 10 40 > > > > uq> > > > > uq> And even sendmail is happily finding the sockets to bind to. Thanks > > > > for the hint! > > > > > > > > I think this just hides the problem. If gshapiro@'s explanation is > > > > correct, no :::0.0.0.0/96 address should be returned if the name > > > > resolution works fine... > > > > > > > > -- Hiroki > > > > > > > > > > getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- > > > > > > If a host has both IPv6 and IPv4 addresses, both are returned. > > > The IPv4 address is presented as a mapped address. > > > The order in which the addresses are returns depends on the > > > address selection policy (_hpreorder in lib/libc/net/name6.c) > > > > Is this also supposed to work for selecting the source IP address for > > outgoing packets/sockets? And should it work for ping6? > > Yes. > > > Using a tunnel for IPv6, I have this transfer net configured on my > > router, but for ACL purposes I would like to have all connections come > > from my real prefix, not the transfer net. So I wrote my own policy, yet > > ping6 seems to ignore it. > > > As you can see, source prefix stays 2a02:2528:ff00, though I'd like it > > to be 2a02:2528:ff0d. > > This is because the prefix on the interface has the first priority. > Why don't you use an fe80::/10 address to route packets to the other > endpoint of tun0? I don't think I have a choice here. To clarify: the sendmail problem is on a server that has native IPv6 connectivity, here I setup my actual prefix as the first address, the address I need to talk to the router is configured as an alias. This works fine. The source address problem I'm now talking about is happening on my router at home, which has a Sixxs tunnel and needs to use AICCU of all things to talk to the outside world, sixxs-aiccu will create the tun(4) interface and set it up like this: tun0: flags=8051 metric 0 mtu 1280 options=8 inet6 fe80::230:5ff:fe77:e7a0%tun0 prefixlen 64 scopeid 0xd inet6 fe80::2428:ff00:1b:2%tun0 prefixlen 64 scopeid 0xd inet6 2a02:2528:ff00:1b::2 --> 2a02:2528:ff00:1b::1 prefixlen 128 nd6 options=21 Opened by PID 82756 and I'd like to have ipv6 connection originating from this host use 2a02:2528:ff0d::1%em0 instead of 2a02:2528:ff00:1b::2%tun0 as the outgoing address. That tun0 interface can come and go, btw, which complicates things. Is this possible? Or should I just switch to the one local DSL provide I have here that actually offers native IPv6 for home DSL users? Cheers, Uli pgp1mnFAoe1vP.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi, > On Wed, 9 Jan 2013 16:29:00 + > Ben Morrow said: ben> Where does it say that? All I can find (but I might be being stupid) is ben> the bit in the description of AI_ALL where it says 'A query is first ben> made for records and if successful, the IPv6 addresses are ben> returned. Another query is then made for A records and any found are ben> returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant ben> to indicate the results are returned first in the list, just that ben> both sets of results are included. It is the sentence you mentioned. It was not thought those days that a query order and an order of the value to return were another. So, I think that it implies the order of the value to return. ben> Also, RFC 6724 (which is more recent), says 'we intend that ben> implementations of APIs such as getaddrinfo() will use the destination ben> address selection algorithm specified here to sort the list of IPv6 and ben> IPv4 addresses that they return.'. AFAICS 'APIs such as getaddrinfo()' ben> is supposed to include getipnodebyname and gethostbyname2, and the whole ben> list of v4 and v6 addresses is supposed to be sorted by those rules. I thought so at the time when I implemented it. However, getipnodebyname has IPv4-mapped addresses issue as compared with getaddrinfo. Since gethostbyname2 doesn't treat multiple families at once, it is out of scope, IMHO. gethostbyname2 in FreeBSD doesn't obey ip6addrctl. ben> However, given that FreeBSD disables the use of v4-mapped addresses on ben> AF_INET6 sockets by default, it might be sensible to change the rules a ben> little. An application making an AF_INET6 query is probably going to use ben> the result with an AF_INET6 socket, so a v4-mapped address is going to ben> be mostly useless. There is IPV6_V6ONLY socket option. Still, an application has two choices: - convert IPv4-mapped address to IPv4 address, or - issue IPV6_V6ONLY socket option. In anyway, I think it is important that an application conscious of using the IPv4-mapped address. > I've just committed to disable it: > > http://svnweb.freebsd.org/base?view=revision&revision=245225 ben> I don't think that's the right answer. Even if the code should be ben> changed to always return addresses from A records last, the IPv6 ben> addresses from records should still be sorted according to ben> ip6addrctl. Otherwise sites with multiple prefixes (say, a ULA prefix ben> and a global prefix) won't be able to control their use properly. getipnodebyname was deprecated by RFC 3493 and appropriate time has passed since then. So, it is low-priority, IMHO. Sincerely, -- Hajimu UMEMOTO u...@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sendmail vs ipv6 broken after upgrade to 9.1
Ben Morrow wrote in <20130109154435.ga81...@anubis.morrow.me.uk>: be> So getipnodebyname is behaving correctly here: the host has both IPv4 be> and IPv6 addresses, and Sendmail is requesting both native and v4-mapped be> addresses be returned in all cases. The v4-mapped addresses are then be> sorted to the top of the list. be> be> On FreeBSD, where net.inet6.ip6.v6only is on by default, I believe this be> is incorrect, and Sendmail should be passing 0 for the flags argument, be> unless it's going to check or clear the IPV6_V6ONLY socket option. There be> is no point binding a socket to a v4-mapped address if the kernel isn't be> going to deliver IPv4 connections to it. Sendmail should also be binding be> to all the addresses returned, if it isn't already, rather than just the be> first: this would make the problem go away, since both v4-mapped and be> native IPv6 sockets would be bound, and the v4-mapped ones would simply be> never get any connections. I reread the RFC 2553 and realize your explanation is correct. gshapiro's explanation was a behavior in the case of (AF_INET6, AI_DEFAULT), not (AF_INET6, AI_DEFAULT|AI_ALL). I think sendmail should work regardless of net.inet6.ip6.v6only. Is just dropping AI_ALL enough for that? When RR is found, no v4-mapped address will return in that case. Is this correct? be> Fixing this by setting ipv6_prefer is not necessarily a good idea; this be> will cause IPv6 addresses to be preferred across the whole system, and be> unless your IPv6 connectivity is at least as good as your IPv4, that be> probably isn't what you want. Yes, I agree that ipv6_prefer is not a correct way to solve this specific issue. be> > Just curious, but is there any specific reason not to return an error be> > when Family=inet6 and no RR? be> be> In this case, Sendmail explicitly requested that v4-mapped addresses be be> returned in all cases... -- Hiroki pgp8oZFQaQ0r1.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
Quoth Hajimu UMEMOTO : > > On Wed, 09 Jan 2013 23:01:52 +0900 > > Hajimu UMEMOTO said: > > ume> I changed getipnodebyname to obey ip6addrctl in years past. I read > ume> RFC 2553 again, and realize that it mentions IPv6 addresses are > ume> returned 1st. So, my past change might be bad thing. X-( Where does it say that? All I can find (but I might be being stupid) is the bit in the description of AI_ALL where it says 'A query is first made for records and if successful, the IPv6 addresses are returned. Another query is then made for A records and any found are returned as IPv4-mapped IPv6 addresses.'. I don't believe that is meant to indicate the results are returned first in the list, just that both sets of results are included. Also, RFC 6724 (which is more recent), says 'we intend that implementations of APIs such as getaddrinfo() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return.'. AFAICS 'APIs such as getaddrinfo()' is supposed to include getipnodebyname and gethostbyname2, and the whole list of v4 and v6 addresses is supposed to be sorted by those rules. However, given that FreeBSD disables the use of v4-mapped addresses on AF_INET6 sockets by default, it might be sensible to change the rules a little. An application making an AF_INET6 query is probably going to use the result with an AF_INET6 socket, so a v4-mapped address is going to be mostly useless. > I've just committed to disable it: > > http://svnweb.freebsd.org/base?view=revision&revision=245225 I don't think that's the right answer. Even if the code should be changed to always return addresses from A records last, the IPv6 addresses from records should still be sorted according to ip6addrctl. Otherwise sites with multiple prefixes (say, a ULA prefix and a global prefix) won't be able to control their use properly. Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sendmail vs ipv6 broken after upgrade to 9.1
Quoth Hiroki Sato : > Gregory Shapiro wrote > in <20130108180920.gj36...@rugsucker.smi.sendmail.com>: > > gs> > How can I unstupid sendmail here? > gs> > gs> I don't think sendmail is being stupid here as it is doing what it has > gs> been doing under 8.x and 9.1 (the code is the same). I think > gs> something changed with the upgrade to 9.1. As far as tracking it > gs> down, the sendmail code does: > gs> > gs> getipnodebyname("acme.spoerlein.net", AF_INET6, AI_DEFAULT|AI_ALL, > gs> &err); > gs> > gs> This will only return an IPv4 mapped address if: > gs> > gs> 1. There are no IPv6 addresses configured on the interfaces. > gs> > gs> 2. The query for an record for acme.spoerlein.net failed. > gs> This is not quite right. AI_DEFAULT is AI_V4MAPPED | AI_ADDRCONFIG. AI_V4MAPPED says 'if there are no records, query for A records and return them as v4-mapped addresses'. AI_ALL is only valid with AI_V4MAPPED, and says 'always query for A records and return v4-mapped addresses'. AI_ADDRCONFIG says 'only query for records if there is at least one interface with an IPv6 address; only query for A records if there is at least one interface with an IPv4 address'. (Loopback explicitly doesn't count for this purpose.) The resulting list of addresses is sorted according to ip6addrctl. So getipnodebyname is behaving correctly here: the host has both IPv4 and IPv6 addresses, and Sendmail is requesting both native and v4-mapped addresses be returned in all cases. The v4-mapped addresses are then sorted to the top of the list. On FreeBSD, where net.inet6.ip6.v6only is on by default, I believe this is incorrect, and Sendmail should be passing 0 for the flags argument, unless it's going to check or clear the IPV6_V6ONLY socket option. There is no point binding a socket to a v4-mapped address if the kernel isn't going to deliver IPv4 connections to it. Sendmail should also be binding to all the addresses returned, if it isn't already, rather than just the first: this would make the problem go away, since both v4-mapped and native IPv6 sockets would be bound, and the v4-mapped ones would simply never get any connections. Fixing this by setting ipv6_prefer is not necessarily a good idea; this will cause IPv6 addresses to be preferred across the whole system, and unless your IPv6 connectivity is at least as good as your IPv4, that probably isn't what you want. > Just curious, but is there any specific reason not to return an error > when Family=inet6 and no RR? In this case, Sendmail explicitly requested that v4-mapped addresses be returned in all cases... Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi, > On Wed, 09 Jan 2013 23:01:52 +0900 > Hajimu UMEMOTO said: ume> I changed getipnodebyname to obey ip6addrctl in years past. I read ume> RFC 2553 again, and realize that it mentions IPv6 addresses are ume> returned 1st. So, my past change might be bad thing. X-( I've just committed to disable it: http://svnweb.freebsd.org/base?view=revision&revision=245225 Sincerely, -- Hajimu UMEMOTO u...@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi, > On Wed, 09 Jan 2013 23:42:10 +0900 (JST) > Hiroki Sato said: hrs> This is because the prefix on the interface has the first priority. hrs> Why don't you use an fe80::/10 address to route packets to the other hrs> endpoint of tun0? I don't like this policy. I think it reduce the availability of the policy table. So, I'm disabling it locally by applying the attached patch. Sincerely, Index: sys/netinet6/in6_src.c diff -u -p sys/netinet6/in6_src.c.orig sys/netinet6/in6_src.c --- sys/netinet6/in6_src.c.orig 2011-09-23 09:51:37.0 +0900 +++ sys/netinet6/in6_src.c 2011-10-08 20:44:31.583463740 +0900 @@ -369,10 +369,12 @@ in6_selectsrc(struct sockaddr_in6 *dstso */ /* Rule 5: Prefer outgoing interface */ - if (ia_best->ia_ifp == ifp && ia->ia_ifp != ifp) - NEXT(5); - if (ia_best->ia_ifp != ifp && ia->ia_ifp == ifp) - REPLACE(5); + if (!(ND_IFINFO(ifp)->flags & ND6_IFF_NO_PREFER_IFACE)) { + if (ia_best->ia_ifp == ifp && ia->ia_ifp != ifp) +NEXT(5); + if (ia_best->ia_ifp != ifp && ia->ia_ifp == ifp) +REPLACE(5); + } /* * Rule 6: Prefer matching label Index: sys/netinet6/nd6.h diff -u sys/netinet6/nd6.h.orig sys/netinet6/nd6.h --- sys/netinet6/nd6.h.orig 2011-09-23 09:51:37.0 +0900 +++ sys/netinet6/nd6.h 2011-10-08 20:46:47.972777802 +0900 @@ -86,6 +86,7 @@ #define ND6_IFF_DONT_SET_IFROUTE 0x10 #define ND6_IFF_AUTO_LINKLOCAL 0x20 #define ND6_IFF_NO_RADR 0x40 +#define ND6_IFF_NO_PREFER_IFACE 0x80 /* XXX: not related to ND. */ #define ND6_CREATE LLE_CREATE #define ND6_EXCLUSIVE LLE_EXCLUSIVE Index: usr.sbin/ndp/ndp.8 diff -u usr.sbin/ndp/ndp.8.orig usr.sbin/ndp/ndp.8 --- usr.sbin/ndp/ndp.8.orig 2011-09-23 09:51:37.0 +0900 +++ usr.sbin/ndp/ndp.8 2011-10-08 20:44:31.586462415 +0900 @@ -201,6 +201,15 @@ selection, see the .Pa IMPLEMENTATION file supplied with the KAME kit. +.It Ic no_prefer_iface +The address on the outgoing interface is preferred by source addess +selection rule. +If this flag is set, stop treating the address on the +.Ar interface +as special even when the +.Ar interface +is outgoing interface. +The default value of this flag is off. .It Ic disabled Disable IPv6 operation on the interface. When disabled, the interface discards any IPv6 packets Index: usr.sbin/ndp/ndp.c diff -u -p usr.sbin/ndp/ndp.c.orig usr.sbin/ndp/ndp.c --- usr.sbin/ndp/ndp.c.orig 2011-09-23 09:51:37.0 +0900 +++ usr.sbin/ndp/ndp.c 2011-10-08 20:44:31.588462742 +0900 @@ -1011,6 +1011,9 @@ ifinfo(ifname, argc, argv) #ifdef ND6_IFF_PREFER_SOURCE SETFLAG("prefer_source", ND6_IFF_PREFER_SOURCE); #endif +#ifdef ND6_IFF_NO_PREFER_IFACE + SETFLAG("no_prefer_iface", ND6_IFF_NO_PREFER_IFACE); +#endif SETVALUE("basereachable", ND.basereachable); SETVALUE("retrans", ND.retrans); SETVALUE("curhlim", ND.chlim); @@ -1088,6 +1091,10 @@ ifinfo(ifname, argc, argv) if ((ND.flags & ND6_IFF_PREFER_SOURCE)) printf("prefer_source "); #endif +#ifdef ND6_IFF_NO_PREFER_IFACE + if ((ND.flags & ND6_IFF_NO_PREFER_IFACE)) + printf("no_prefer_iface "); +#endif } putc('\n', stdout); #undef ND Index: sbin/ifconfig/af_inet6.c diff -u -p sbin/ifconfig/af_inet6.c.orig sbin/ifconfig/af_inet6.c --- sbin/ifconfig/af_inet6.c.orig 2011-09-23 09:51:37.0 +0900 +++ sbin/ifconfig/af_inet6.c 2011-10-08 20:55:17.871353069 +0900 @@ -511,6 +511,8 @@ static struct cmd inet6_cmds[] = { DEF_CMD("-prefer_source",-ND6_IFF_PREFER_SOURCE,setnd6flags), DEF_CMD("auto_linklocal",ND6_IFF_AUTO_LINKLOCAL,setnd6flags), DEF_CMD("-auto_linklocal",-ND6_IFF_AUTO_LINKLOCAL,setnd6flags), + DEF_CMD("no_prefer_iface",ND6_IFF_NO_PREFER_IFACE,setnd6flags), + DEF_CMD("-no_prefer_iface",-ND6_IFF_NO_PREFER_IFACE,setnd6flags), DEF_CMD_ARG("pltime", setip6pltime), DEF_CMD_ARG("vltime", setip6vltime), DEF_CMD("eui64", 0, setip6eui64), Index: sbin/ifconfig/af_nd6.c diff -u -p sbin/ifconfig/af_nd6.c.orig sbin/ifconfig/af_nd6.c --- sbin/ifconfig/af_nd6.c.orig 2011-09-23 09:51:37.0 +0900 +++ sbin/ifconfig/af_nd6.c 2011-10-08 20:57:46.484522687 +0900 @@ -58,7 +58,7 @@ static const char rcsid[] = #define MAX_SYSCTL_TRY 5 #define ND6BITS "\020\001PERFORMNUD\002ACCEPT_RTADV\003PREFER_SOURCE" \ "\004IFDISABLED\005DONT_SET_IFROUTE\006AUTO_LINKLOCAL" \ - "\007NO_RADR\020DEFAULTIF" + "\007NO_RADR\010NO_PREFER_IFACE\020DEFAULTIF" static int isnd6defif(int); void setnd6flags(const char *, int, int, const struct afswtch *); Index: sbin/ifconfig/ifconfig.8 diff -u sbin/ifconfig/ifconfig.8.orig sbin/ifconfig/ifconfig.8 --- sbin/ifconfig/ifconfig.8.orig 2011-09-23 09:51:37.0 +0900 +++ sbin/ifconfig/ifconfig.8 2011-10-08 20:53:47.050796897 +0900 @@ -690,6 +690,13 @@ .It Cm -prefer_source Clear a flag .Cm prefer_source . +.It Cm no_prefer_iface +Set a flag to not prefer address on the interface as candidates of the +source address for outgoing packets, even when the interface is +outgoing interface. +.It Cm -no_prefer_ifa
Re: sendmail vs ipv6 broken after upgrade to 9.1
Ulrich Spörlein wrote in <20130109142111.gl35...@acme.spoerlein.net>: uq> On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: uq> > On 01/08/2013 23:33, Hiroki Sato wrote: uq> > > Ulrich Spörlein wrote uq> > >in <20130108184051.gi35...@acme.spoerlein.net>: uq> > > uq> > > uq> After setting this, it now looks like this: uq> > > uq> root@acme: ~# ip6addrctl uq> > > uq> Prefix Prec Label Use uq> > > uq> ::1/128 50 00 uq> > > uq> ::/0 40 10 uq> > > uq> 2002::/16 30 20 uq> > > uq> ::/96 20 30 uq> > > uq> :::0.0.0.0/96 10 40 uq> > > uq> uq> > > uq> And even sendmail is happily finding the sockets to bind to. Thanks for the hint! uq> > > uq> > > I think this just hides the problem. If gshapiro@'s explanation is uq> > > correct, no :::0.0.0.0/96 address should be returned if the name uq> > > resolution works fine... uq> > > uq> > > -- Hiroki uq> > > uq> > uq> > getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- uq> > uq> > If a host has both IPv6 and IPv4 addresses, both are returned. uq> > The IPv4 address is presented as a mapped address. uq> > The order in which the addresses are returns depends on the uq> > address selection policy (_hpreorder in lib/libc/net/name6.c) uq> uq> Is this also supposed to work for selecting the source IP address for uq> outgoing packets/sockets? And should it work for ping6? Yes. uq> Using a tunnel for IPv6, I have this transfer net configured on my uq> router, but for ACL purposes I would like to have all connections come uq> from my real prefix, not the transfer net. So I wrote my own policy, yet uq> ping6 seems to ignore it. uq> As you can see, source prefix stays 2a02:2528:ff00, though I'd like it uq> to be 2a02:2528:ff0d. This is because the prefix on the interface has the first priority. Why don't you use an fe80::/10 address to route packets to the other endpoint of tun0? -- Hiroki pgpFTwL8cirug.pgp Description: PGP signature
Re: sendmail vs ipv6 broken after upgrade to 9.1
On Wed, 2013-01-09 at 14:14:18 +0100, Michiel Boland wrote: > On 01/08/2013 23:33, Hiroki Sato wrote: > > Ulrich Spörlein wrote > >in <20130108184051.gi35...@acme.spoerlein.net>: > > > > uq> After setting this, it now looks like this: > > uq> root@acme: ~# ip6addrctl > > uq> Prefix Prec Label Use > > uq> ::1/128 50 00 > > uq> ::/0 40 10 > > uq> 2002::/16 30 20 > > uq> ::/96 20 30 > > uq> :::0.0.0.0/96 10 40 > > uq> > > uq> And even sendmail is happily finding the sockets to bind to. Thanks for > > the hint! > > > > I think this just hides the problem. If gshapiro@'s explanation is > > correct, no :::0.0.0.0/96 address should be returned if the name > > resolution works fine... > > > > -- Hiroki > > > > getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- > > If a host has both IPv6 and IPv4 addresses, both are returned. > The IPv4 address is presented as a mapped address. > The order in which the addresses are returns depends on the > address selection policy (_hpreorder in lib/libc/net/name6.c) Is this also supposed to work for selecting the source IP address for outgoing packets/sockets? And should it work for ping6? Using a tunnel for IPv6, I have this transfer net configured on my router, but for ACL purposes I would like to have all connections come from my real prefix, not the transfer net. So I wrote my own policy, yet ping6 seems to ignore it. The tunnel: tun0: flags=8051 metric 0 mtu 1280 options=8 inet6 fe80::230:5ff:fe77:e7a0%tun0 prefixlen 64 scopeid 0xd inet6 fe80::2428:ff00:1b:2%tun0 prefixlen 64 scopeid 0xd inet6 2a02:2528:ff00:1b::2 --> 2a02:2528:ff00:1b::1 prefixlen 128 nd6 options=21 The policy: root@coyote:~# ip6addrctl Prefix Prec Label Use ::1/128 50 00 ::/0 40 1 107 2002::/16 30 20 ::/96 20 30 :::0.0.0.0/96 10 40 2a02:2528:ff0d::/64 60 5 85 The ping: root@coyote:~# ping6 acme PING6(56=40+8+8 bytes) 2a02:2528:ff00:1b::2 --> 2a01:4f8:131:23c2::1 16 bytes from 2a01:4f8:131:23c2::1, icmp_seq=0 hlim=54 time=43.606 ms 16 bytes from 2a01:4f8:131:23c2::1, icmp_seq=1 hlim=54 time=42.871 ms As you can see, source prefix stays 2a02:2528:ff00, though I'd like it to be 2a02:2528:ff0d. Cheers, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sendmail vs ipv6 broken after upgrade to 9.1
Hi, > On Wed, 09 Jan 2013 07:33:54 +0900 (JST) > Hiroki Sato said: hrs> I think this just hides the problem. If gshapiro@'s explanation is hrs> correct, no :::0.0.0.0/96 address should be returned if the name hrs> resolution works fine... I changed getipnodebyname to obey ip6addrctl in years past. I read RFC 2553 again, and realize that it mentions IPv6 addresses are returned 1st. So, my past change might be bad thing. X-( However, I'm still curious about use of AI_ALL in sendmail. As far as I read the source of sendmail briefly, it seems the usage doesn't depend on AI_ALL. Sincerely, -- Hajimu UMEMOTO u...@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sendmail vs ipv6 broken after upgrade to 9.1
On 01/08/2013 23:33, Hiroki Sato wrote: Ulrich Spörlein wrote in <20130108184051.gi35...@acme.spoerlein.net>: uq> After setting this, it now looks like this: uq> root@acme: ~# ip6addrctl uq> Prefix Prec Label Use uq> ::1/128 50 00 uq> ::/0 40 10 uq> 2002::/16 30 20 uq> ::/96 20 30 uq> :::0.0.0.0/96 10 40 uq> uq> And even sendmail is happily finding the sockets to bind to. Thanks for the hint! I think this just hides the problem. If gshapiro@'s explanation is correct, no :::0.0.0.0/96 address should be returned if the name resolution works fine... -- Hiroki getipnodebyname(xx, AF_INET6, AI_DEFAULT|AI_ALL) does this:- If a host has both IPv6 and IPv4 addresses, both are returned. The IPv4 address is presented as a mapped address. The order in which the addresses are returns depends on the address selection policy (_hpreorder in lib/libc/net/name6.c) #include #include #include #include static void resolve(const char *); int main(int argc, char *argv[]) { int i; for (i = 1; i < argc; i++) { resolve(argv[i]); } return 0; } static void resolve(const char *hostname) { struct hostent *h; char **a; int i; int e = 0; h = getipnodebyname(hostname, AF_INET6, AI_DEFAULT|AI_ALL, &e); if (!h) { return; } printf("h_name: %s\n", h->h_name); for (a = h->h_aliases; *a; a++) { printf(" alias: %s\n", *a); } printf("h_addrtype: %d\n", h->h_addrtype); printf("h_length: %d\n", h->h_length); for (a = h->h_addr_list; *a; a++) { printf("h_length: %d\n", h->h_length); printf(" address: 0x"); for (i = 0; i < h->h_length; i++) { printf("%02x", (unsigned char)(*a)[i]); } printf("\n"); } } prefer_ipv4: $ ./a.out youtube.com h_name: youtube.com h_addrtype: 28 h_length: 16 h_length: 16 address: 0xadc241be h_length: 16 address: 0xadc2415b h_length: 16 address: 0xadc2415d h_length: 16 address: 0xadc24188 h_length: 16 address: 0x2a00145040130c5b prefer_ipv6: $ ./a.out youtube.com h_name: youtube.com h_addrtype: 28 h_length: 16 h_length: 16 address: 0x2a00145040130c5b h_length: 16 address: 0xadc2415b h_length: 16 address: 0xadc2415d h_length: 16 address: 0xadc24188 h_length: 16 address: 0xadc241be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"