Re: DNS control port additions to /etc/services
Le 2014-07-15 09:51, Antoine Jacoutot a écrit : +unbound-cntl 8953/tcp# Unbound validating, recursive, and caching DNS server control The IANA name for this port is ub-dns-control. http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8953 Does that matter at all? Simon
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 04:13, Jérémie Courrèges-Anglas a écrit : I don't like AI_ADDRCONFIG. It's useless as specified, and making it useful requires interpretations and deviations. Can you justify this? Sounds to me like a blanket statement as it is. My understanding is that its goal is to solve a real world problem, as in avoiding useless and potentially harmful DNS requests. So why not make it do that, and just that? Because I don't think the end goal is preventing IPv6 link-local communication, or communication with ::1 or localhost, etc. I don't understand the above paragraph at all. Facts only please, and no hyperbole. What's the problem exactly? -bit is set, IPv4 addresses will be returned only if an IPv4 address is -configured on an interface, and IPv6 addresses will be returned only if an IPv6 -address is configured on an interface. +bit is set, DNS requests for IPv4 addresses will be performed only if an +IPv4 address is configured on an interface, and DNS requetsts for IPv6 +addresses will be performed only if an IPv6 address is configured on an +interface. Targeting only DNS is wrong. That's not at all what AI_ADDRCONFIG does. It is of no use to return an IPv6 address that you found in a non-DNS database if the host has no IPv6 address configured on its interfaces. But take the above with a grain of salt because I absolutely don't understand the problem you're trying to fix. Simon
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit : Let's say you have a machine with no IPv6 address configured (or rather, only link-local addresses configured and ::1 on lo0). With the AI_ADDRCONFIG flag (either set explicitely or assumed if the caller passes no hints structure): - getaddrinfo(fe80::...%em0) fails with no address associated with name - getaddrinfo(::1) fails similarly - more generally, getaddrinfo(numeric IPv6 address) fails with no address associated with that name - getaddrinfo(localhost) now requires IPv4/v6 connectivity on non-lo interfaces. oops. All those are IMHO poor behavior (lies), especially since getaddrinfo is supposed to handle pretty much anything you're throwing at it. I think you need to change your expectations. If you're running on a host without IPv6, why would you want getaddrinfo() to return any IPv6 results? What good would it do to you? AI_ADDRCONFIG is all about what it *returns*. The fact that it allows skipping DNS requests is a nice side-effect. If your program needs to resolve addresses for the sake of resolving addresses, and you want accuracy, you need to explicitly unset AI_ADDRCONFIG. You're writing something special. In the general case, where you will just connect() or bind() on the returned addresses, AI_ADDRCONFIG makes sense as is. Has this caused any real-world problems? Simon
Re: [RFC] AI_ADDRCONFIG tweaks?
I think I have already addressed all your points below, no need to rehash endlessly. I'll let others chime in. I'm still very interested in any real-world problems this might have caused. Simon Le 2014-05-02 11:35, Jérémie Courrèges-Anglas a écrit : Simon Perreault si...@per.reau.lt writes: Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit : Let's say you have a machine with no IPv6 address configured (or rather, only link-local addresses configured and ::1 on lo0). With the AI_ADDRCONFIG flag (either set explicitely or assumed if the caller passes no hints structure): - getaddrinfo(fe80::...%em0) fails with no address associated with name - getaddrinfo(::1) fails similarly - more generally, getaddrinfo(numeric IPv6 address) fails with no address associated with that name - getaddrinfo(localhost) now requires IPv4/v6 connectivity on non-lo interfaces. oops. All those are IMHO poor behavior (lies), especially since getaddrinfo is supposed to handle pretty much anything you're throwing at it. I think you need to change your expectations. I don't think that any of the failing examples given above can qualify as reasonable expectation. If you're running on a host without IPv6, why would you want getaddrinfo() to return any IPv6 results? What good would it do to you? What's a regular OpenBSD host with no IPv6? I'd assume that it is a host that can perform IPv6 connections to ::1 / localhost and reach its neighbors through link-local addresses. It is certainly not a host that has been butchered by removing option INET6 or removing all automatically configured IPv6 address (link-local / lo0). If you pass a raw IPv6 address to getaddrinfo, is no address associated with name a reasonable result? AI_ADDRCONFIG is all about what it *returns*. The fact that it allows skipping DNS requests is a nice side-effect. Yet people use it for this side-effect, else why would you propose to make the base programs use it (explicitely) as a way to mitigate the impact of switching to family inet6 inet4 by default? If your program needs to resolve addresses for the sake of resolving addresses, and you want accuracy, I think that I've clearly explained that it is more than mere accuracy. you need to explicitly unset AI_ADDRCONFIG. You're writing something special. In the general case, where you will just connect() or bind() on the returned addresses, AI_ADDRCONFIG makes sense as is. Has this caused any real-world problems? All the examples I've listed above are cases where programs that used no hints will now fail. I think they're valid, real-world cases.
Re: [RFC] AI_ADDRCONFIG tweaks?
Le 2014-05-02 13:19, Jérémie Courrèges-Anglas a écrit : Some bugs: - https://sourceware.org/bugzilla/show_bug.cgi?id=12398 - http://article.gmane.org/gmane.comp.freedesktop.xcb/6973 - https://svn.boost.org/trac/boost/ticket/8503 Links with more information: - http://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG - https://fedoraproject.org/wiki/Features/FixNetworkNameResolution - http://tools.ietf.org/html/rfc2553 obsolete and also informational, specified AI_ADDRCONFIG for DNS () purposes only (dunno why this has been changed) Thanks! I'll look at these in detail and get back to you. Simon
Re: IPv6 by default
Le 2014-04-29 22:04, Theo de Raadt a écrit : measurements all over the world show that IPv4 is better in every respect. Not disagreeing, but I would like to have access to more data backing this up. I'm not satisfied with what I found (see other post). Change that, then we can talk. Working on it. ;) http://tools.ietf.org/html/rfc6888 Simon
Re: IPv6 by default
Le 2014-04-28 18:53, Chris Cappuccio a écrit : Why is the burden on everyone to provide 'valid' objections? Should not the burden be on you to at least hint at a point to this change? Given the miniscule IPv6 usage out there, why should IPv6 come first? I like how IPv6 support turns primary and secondary DNS caches from a redundancy feature for clients to dual points of failure (for some resolver implementations.) No response from either server for the first AF you try? Just wait for a full time out before you try the second AF! This is a valid point IMHO. Wouldn't it be better if libasr would run A and requests in parallel? Whichever response arrives first wins. Simon
Re: IPv6 by default
Le 2014-04-28 18:43, Kenneth Westerback a écrit : Why is the burden on everyone to provide 'valid' objections? I know that what I proposed cannot go in at the moment. It's my end goal. Now what I want is to have a clear picture of what the issues are, and whether there's anything I can do to help fix them. I'm not putting the burden on anyone except myself. Given the miniscule IPv6 usage out there, why should IPv6 come first? I don't see how usage is relevant. If IPv6 provided 1000% performance improvement with no downsides, we would want to use it even if global usage was low. Thanks, Simon
Re: IPv6 by default
Le 2014-04-28 18:54, Todd T. Fries a écrit : IPv6 is a 2nd class netizen in terms of reliability and user experience. Here's the relevant data I know of: Google's data [1] shows a few third-world countries where what you say is true, plus Japan because of a single particularly broken ISP [2]. RIPE Labs published numbers in 2012 showing a slight performance advantage for IPv4 [3]. I *think* I saw a more recent study showing a similarly slight advantage for IPv6, but I can't find it anymore, so it might be a brain fart. Is there anything else? Simon [1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption [2] http://www.jp.ipv6forum.com/201301/timetable/program/IPv6Summit2013-5_Lorenzo.pdf [3] https://labs.ripe.net/Members/emileaben/measuring-world-ipv6-launch-comparing-ipv4-and-ipv6-performance
Re: IPv6 by default
Le 2014-04-29 09:44, Kenneth Westerback a écrit : Why would having the IPv6 addresses come first in the returned list be required to 'use' them? Please explain. Well I thought this would be obvious, but applications using getaddrinfo() typically try connecting to each of the addresses returned in sequence and stop as soon as connect() returns 0. So you end up using whichever address was returned first 9 time out of 10. I'll reply to your other questions, and other similar ones from other folks, as soon as I have a good answer. Simon
Re: IPv6 by default
Le 2014-04-29 09:55, Henning Brauer a écrit : Wouldn't it be better if libasr would run A and requests in parallel? Whichever response arrives first wins. no, since that gives extremely unpredictable results. How about this then: - Run both requests in parallel. - When one response is received, start a short timer (e.g. 200ms or so). - If the second response is received before the timer expires, sort and return the results as usual. - Otherwise, kill the second request and return what you have. Simon
Re: IPv6 by default
Le 2014-04-29 09:52, Giancarlo Razzolini a écrit : I disable ipv6 across all my linux desktops installations because some daemons aren't smart enough to not try it first. Postfix is one that comes from the top of my mind. That's why we needed AI_ADDRCONFIG. The point is that getaddrinfo() shouldn't be doing IPvX lookups if you don't have at least one IPvX address configured on an interface. Also, I believe firefox will default to ipv6 then ipv4 if you have it enabled. It attempts both in parallel. Google for network.http.fast-fallback-to-IPv4. Simon
Re: IPv6 by default
Le 2014-04-29 10:12, Ted Unangst a écrit : - Run both requests in parallel. - When one response is received, start a short timer (e.g. 200ms or so). - If the second response is received before the timer expires, sort and return the results as usual. - Otherwise, kill the second request and return what you have. Yuck. You just added 200ms latency to every connection. If I'm reading the code correctly, this saves time on average even if we keep IPv4 as default, and is never worse than the current situation. getaddrinfo() queries both families in sequence. So you have to wait for the request even if the A request finishes quickly. Doesn't matter which one is first, you have to to wait for both. It makes sense to me to cap that waiting when the first request yielded results, no matter which family is the default. Please let me know if my understanding is wrong. Thanks, Simon
IPv6 by default
Tech, Now that my AI_ADDRCONFIG diff is in, it's time to reveal my evil master plan: make getaddrinfo() return IPv6 results first by default. The diff below would be the end goal. I guess people will have valid objections to it. I'd like to know what they are. Would it be necessary/desirable to check all calls to getaddrinfo() in base and add AI_ADDRCONFIG to hints.ai_flags where needed? (i.e. pretty much everywhere except special cases which right now I can't think of any) Thanks, Simon Index: lib/libc/asr/asr.c === RCS file: /cvs/src/lib/libc/asr/asr.c,v retrieving revision 1.33 diff -u -p -r1.33 asr.c --- lib/libc/asr/asr.c 26 Mar 2014 18:13:15 - 1.33 +++ lib/libc/asr/asr.c 28 Apr 2014 21:43:52 - @@ -518,8 +518,8 @@ asr_ctx_create(void) ac-ac_options = RES_RECURSE | RES_DEFNAMES | RES_DNSRCH; ac-ac_refcount = 1; ac-ac_ndots = 1; - ac-ac_family[0] = AF_INET; - ac-ac_family[1] = AF_INET6; + ac-ac_family[0] = AF_INET6; + ac-ac_family[1] = AF_INET; ac-ac_family[2] = -1; ac-ac_hostfile = DEFAULT_HOSTFILE; Index: share/man/man5/resolv.conf.5 === RCS file: /cvs/src/share/man/man5/resolv.conf.5,v retrieving revision 1.44 diff -u -p -r1.44 resolv.conf.5 --- share/man/man5/resolv.conf.514 Jul 2013 19:44:39 - 1.44 +++ share/man/man5/resolv.conf.528 Apr 2014 21:43:52 - @@ -217,8 +217,8 @@ For example: .It Cm family Specify which type of Internet protocol family to prefer, if a host is reachable using different address families. -By default IPv4 addresses are queried first, -and then IPv6 addresses. +By default IPv6 addresses are queried first, +and then IPv4 addresses. The syntax is: .Bd -ragged -offset indent .Cm family Ar family Op Ar family
Re: AI_ADDRCONFIG
On Wed, Apr 23, 2014 at 12:02:44PM -0400, Simon Perreault wrote:
Will send an updated diff later today.
It is now later today (ha!) and here's the promised updated diff.
Changes:
- Simplified and embettered address filtering based on Stuart Henderson's
comments.
- Fixed manpage formatting.
ok?
Simon
Index: include/netdb.h
===
RCS file: /cvs/src/include/netdb.h,v
retrieving revision 1.31
diff -u -p -r1.31 netdb.h
--- include/netdb.h 15 Sep 2012 00:47:08 - 1.31
+++ include/netdb.h 27 Apr 2014 17:36:39 -
@@ -167,9 +167,11 @@ extern int h_errno;
#define AI_EXT 8 /* enable non-portable extensions */
#define AI_NUMERICSERV 16 /* don't ever try servname lookup */
#define AI_FQDN32 /* return the FQDN that was resolved */
+#define AI_ADDRCONFIG 64 /* return configured address families only */
/* valid flags for addrinfo */
#define AI_MASK \
-(AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV | AI_FQDN)
+(AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV | AI_FQDN | \
+ AI_ADDRCONFIG)
#define NI_NUMERICHOST 1 /* return the host address, not the name */
#define NI_NUMERICSERV 2 /* return the service address, not the name */
Index: lib/libc/asr/getaddrinfo_async.c
===
RCS file: /cvs/src/lib/libc/asr/getaddrinfo_async.c,v
retrieving revision 1.26
diff -u -p -r1.26 getaddrinfo_async.c
--- lib/libc/asr/getaddrinfo_async.c26 Mar 2014 18:13:15 - 1.26
+++ lib/libc/asr/getaddrinfo_async.c27 Apr 2014 17:36:39 -
@@ -21,6 +21,7 @@
#include sys/socket.h
#include netinet/in.h
#include arpa/nameser.h
+#include net/if.h
#ifdef YP
#include rpc/rpc.h
#include rpcsvc/yp.h
@@ -32,6 +33,7 @@
#include asr.h
#include err.h
#include errno.h
+#include ifaddrs.h
#include resolv.h /* for res_hnok */
#include stdlib.h
#include string.h
@@ -104,6 +106,7 @@ getaddrinfo_async(const char *hostname,
else {
memset(as-as.ai.hints, 0, sizeof as-as.ai.hints);
as-as.ai.hints.ai_family = PF_UNSPEC;
+ as-as.ai.hints.ai_flags = AI_ADDRCONFIG;
}
asr_ctx_unref(ac);
@@ -127,8 +130,9 @@ getaddrinfo_async_run(struct asr_query *
char fqdn[MAXDNAME];
const char *str;
struct addrinfo *ai;
- int i, family, r;
+ int i, family, r, v4, v6;
FILE*f;
+ struct ifaddrs *ifa, *ifa0;
union {
struct sockaddr sa;
struct sockaddr_in sain;
@@ -193,6 +197,39 @@ getaddrinfo_async_run(struct asr_query *
ar-ar_gai_errno = EAI_SERVICE;
async_set_state(as, ASR_STATE_HALT);
break;
+ }
+
+ /* Restrict result set to configured address families */
+ if (ai-ai_flags AI_ADDRCONFIG) {
+ if (getifaddrs(ifa0) != 0) {
+ ar-ar_gai_errno = EAI_FAIL;
+ async_set_state(as, ASR_STATE_HALT);
+ break;
+ }
+ v4 = 0;
+ v6 = 0;
+ for (ifa = ifa0; ifa != NULL; ifa = ifa-ifa_next) {
+ if (ifa-ifa_flags IFF_LOOPBACK)
+ continue;
+ if (ifa-ifa_addr-sa_family == PF_INET)
+ v4 = 1;
+ else if (ifa-ifa_addr-sa_family == PF_INET6
+ !IN6_IS_ADDR_LINKLOCAL(((struct
+ sockaddr_in6 *)ifa-ifa_addr)-sin6_addr))
+ v6 = 1;
+ }
+ freeifaddrs(ifa0);
+ if (ai-ai_family == PF_UNSPEC !v4 !v6 ||
+ ai-ai_family == PF_INET !v4 ||
+ ai-ai_family == PF_INET6 !v6) {
+ ar-ar_gai_errno = EAI_NONAME;
+ async_set_state(as, ASR_STATE_HALT);
+ break;
+ }
+ if (ai-ai_family == PF_UNSPEC v4 !v6)
+ ai-ai_family = PF_INET;
+ if (ai-ai_family == PF_UNSPEC !v4 v6)
+ ai-ai_family = PF_INET6;
}
/* Make sure there is at least a valid combination */
Index: lib/libc/net/getaddrinfo.3
===
RCS file: /cvs/src/lib/libc/net/getaddrinfo.3,v
retrieving revision 1.54
diff -u -p -r1.54 getaddrinfo.3
--- lib/libc/net/getaddrinfo.3 21
AI_ADDRCONFIG
(I sent this diff to Éric Faurot on the 12th, but received no reply.)
Tech,
While everyone's having fun removing code from OpenSSL, I decided to add
some to libasr. I implemented AI_ADDRCONFIG, a getaddrinfo() flag
defined in RFC 2553/3493. Basically, it tells getaddrinfo() to skip IPvX
lookups when there are no IPvX addresses configured on any interface. It
is present on most other OSes. Tons of software out there have to play
Autoconf games to cope with its absence (which, on OpenBSD, predates
libasr if I'm not mistaken).
Noteworthy:
- I call getifaddrs() from getaddrinfo_run_async(). This should not
block, so no need to change the state machine.
- I added AI_ADDRCONFIG to the default hints, like glibc does, and as
was specified in RFC 2553. (RFC 3493 says nothing about default flags.)
ok? comments?
Simon
Index: include/netdb.h
===
RCS file: /cvs/src/include/netdb.h,v
retrieving revision 1.31
diff -u -p -r1.31 netdb.h
--- include/netdb.h 15 Sep 2012 00:47:08 - 1.31
+++ include/netdb.h 12 Apr 2014 17:40:38 -
@@ -167,9 +167,11 @@ extern int h_errno;
#define AI_EXT 8 /* enable non-portable extensions */
#define AI_NUMERICSERV 16 /* don't ever try servname lookup */
#define AI_FQDN32 /* return the FQDN that was resolved */
+#define AI_ADDRCONFIG 64 /* return configured address families only */
/* valid flags for addrinfo */
#define AI_MASK \
-(AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV |
AI_FQDN)
+(AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV |
AI_FQDN | \
+ AI_ADDRCONFIG)
#define NI_NUMERICHOST 1 /* return the host address, not the name */
#define NI_NUMERICSERV 2 /* return the service address, not the name */
Index: lib/libc/asr/getaddrinfo_async.c
===
RCS file: /cvs/src/lib/libc/asr/getaddrinfo_async.c,v
retrieving revision 1.26
diff -u -p -r1.26 getaddrinfo_async.c
--- lib/libc/asr/getaddrinfo_async.c26 Mar 2014 18:13:15 - 1.26
+++ lib/libc/asr/getaddrinfo_async.c12 Apr 2014 17:40:39 -
@@ -21,6 +21,7 @@
#include sys/socket.h
#include netinet/in.h
#include arpa/nameser.h
+#include net/if.h
#ifdef YP
#include rpc/rpc.h
#include rpcsvc/yp.h
@@ -32,6 +33,7 @@
#include asr.h
#include err.h
#include errno.h
+#include ifaddrs.h
#include resolv.h /* for res_hnok */
#include stdlib.h
#include string.h
@@ -104,6 +106,7 @@ getaddrinfo_async(const char *hostname,
else {
memset(as-as.ai.hints, 0, sizeof as-as.ai.hints);
as-as.ai.hints.ai_family = PF_UNSPEC;
+ as-as.ai.hints.ai_flags = AI_ADDRCONFIG;
}
asr_ctx_unref(ac);
@@ -127,8 +130,9 @@ getaddrinfo_async_run(struct asr_query *
char fqdn[MAXDNAME];
const char *str;
struct addrinfo *ai;
- int i, family, r;
+ int i, family, r, v4, v6;
FILE*f;
+ struct ifaddrs *ifa, *ifa0;
union {
struct sockaddr sa;
struct sockaddr_in sain;
@@ -193,6 +197,44 @@ getaddrinfo_async_run(struct asr_query *
ar-ar_gai_errno = EAI_SERVICE;
async_set_state(as, ASR_STATE_HALT);
break;
+ }
+
+ /* Restrict result set to configured address families */
+ if (ai-ai_flags AI_ADDRCONFIG) {
+ if (getifaddrs(ifa0) != 0) {
+ ar-ar_gai_errno = EAI_FAIL;
+ async_set_state(as, ASR_STATE_HALT);
+ break;
+ }
+ v4 = 0;
+ v6 = 0;
+ for (ifa = ifa0; ifa != NULL; ifa = ifa-ifa_next) {
+ if (ifa-ifa_addr-sa_family == PF_INET
+ ((struct sockaddr_in *)ifa-ifa_addr)
+ -sin_addr.s_addr != INADDR_LOOPBACK)
+ v4 = 1;
+ else if (ifa-ifa_addr-sa_family == PF_INET6
+ !IN6_IS_ADDR_LOOPBACK(
+ ((struct sockaddr_in6 *)ifa-ifa_addr)
+ -sin6_addr)
+ !((ifa-ifa_flags IFF_LOOPBACK)
+ IN6_IS_ADDR_LINKLOCAL(
+ ((struct sockaddr_in6 *)ifa-ifa_addr)
+ -sin6_addr)))
+ v6 = 1;
+ }
+ freeifaddrs(ifa0);
+ if (ai-ai_family == PF_UNSPEC !v4 !v6 ||
+ ai-ai_family
Re: AI_ADDRCONFIG
Le 2014-04-23 11:43, Stuart Henderson a écrit : On 2014/04/23 08:09, Simon Perreault wrote: +else if (ifa-ifa_addr-sa_family == PF_INET6 so... family is ipv6 +!IN6_IS_ADDR_LOOPBACK( +((struct sockaddr_in6 *)ifa-ifa_addr) +-sin6_addr) AND it's not a loopback address +!((ifa-ifa_flags IFF_LOOPBACK) +IN6_IS_ADDR_LINKLOCAL( +((struct sockaddr_in6 *)ifa-ifa_addr) +-sin6_addr))) AND NOT (loopback interface AND link-local address) But the intention seems to be if you have a usable v6 address that stands a chance of being routable - so shouldn't this last bit be AND NOT loopback interface AND NOT link-local address? !(ifa-ifa_flags IFF_LOOPBACK) !(IN6_IS_ADDR_LINKLOCAL( ((struct sockaddr_in6 *)ifa-ifa_addr))) Otherwise AI_ADDRCONFIG will still allow v6 addresses if you have a default OpenBSD configuration i.e. the automatically configured link-local address on an ethernet interface even if you've done nothing to try and make them work. I suspect it may not be quite RFC compliant, but I think actual usability trumps RFC compliance here. Yes, you're right, I over-thought things here. Will send an updated diff later today. Thanks a lot for your thorough review! Simon
Re: allow v6 privacy and static addresses to co-exist again
Le 2012-09-02 08:05, Stefan Sperling a écrit :
Simon's recent commit to prevent SLAAC address formation when
a static address is already configured has a side-effect for
autoconfprivacy users.
With the following in /etc/hostname.if:
dhcp
rtsol
inet6 some-address 64
the netstart script will run rtsol after assigning the static address,
hence preventing privacy addresses from being formed. The only effect
of 'rtsol' in this case is an auto-configured default route.
If a privacy address is manually configured first and a static address
second, the interface initially has both. But the static address prevents
creation of new addresses during RA reception. When the privacy address
becomes deprecated a fresh address is not added, breaking autoconfprivacy.
So using privacy addresses for outgoing connections and static addresses
for incoming connections is no longer possible. Do we want to support
this use case? It used to work ever since privacy addresses were introduced.
The diff below makes static addresses prevent SLAAC addresses in the
no-privacy case but allows static and privacy addresses to co-exist.
Because we create SLAAC addresses alongside privacy addresses, this
effectively reverts the default behaviour to what it was before
Simon's change. With the hostname.if snippet above we get:
- auto-configured default route
- SLAAC address
- privacy addresses (rotating over time)
- a static address
Those who prefer traditional inet6 behaviour can use:
dhcp
-autoconfprivacy
rtsol
This results in:
- auto-configured default route
- SLAAC address
Or:
dhcp
-autoconfprivacy
rtsol
inet6 some-address 64
This results in:
- auto-configured default route
- a static address
ok?
This makes sense, ok.
Please note the last comment in the comment at the top that says:
/*
* 5.5.3 (d). If the prefix advertised does not match the prefix of an
* address already in the list, and the Valid Lifetime is not 0,
* form an address. Note that even a manually configured address
* should reject autoconfiguration of a new address.
*/
This is no longer true. This comment is an excerpt from RFC 2462 which
was obsoleted by RFC 4862. The text was modified to say:
d) If the prefix advertised is not equal to the prefix of an
address configured by stateless autoconfiguration already in the
list of addresses [...]
So this change is not only good, it fits with the intent of the new RFC.
You might want to tweak the comments to reflect that.
Simon
Index: nd6_rtr.c
===
RCS file: /cvs/src/sys/netinet6/nd6_rtr.c,v
retrieving revision 1.62
diff -u -p -r1.62 nd6_rtr.c
--- nd6_rtr.c 28 Aug 2012 20:32:02 - 1.62
+++ nd6_rtr.c 2 Sep 2012 11:33:44 -
@@ -1275,7 +1275,8 @@ prelist_update(struct nd_prefix *new, st
}
if ((!autoconf || ((ifp-if_xflags IFXF_INET6_NOPRIVACY) == 0
- !tempaddr_preferred)) new-ndpr_vltime != 0 !statique) {
+ !tempaddr_preferred)) new-ndpr_vltime != 0
+ !((ifp-if_xflags IFXF_INET6_NOPRIVACY) statique)) {
/*
* There is no SLAAC address and/or there is no preferred RFC
* 4941 temporary address. And the valid prefix lifetime is
Re: CoDel
Le 2012-08-14 20:29, David Gwynne a écrit : ill have to fix that. Oh, and I also realized that CBQ is even worse: it calls microuptime() on every enqueue *and* every dequeue! If it really was a bug, people would have noticed, no? Simon On 15/08/2012, at 3:31 AM, Simon Perreault sperrea...@openbsd.org wrote: Le 2012-08-14 12:12, Ted Unangst a écrit : Five years ago I removed a once per packet microuptime call which led to something like a 33% improvement in throughput. I don't want to have to do that again. :) Hey I just realized that hfsc calls microuptime() for every single packet at dequeue time. altq_hfsc_dequeue() -- read_machclk() -- microuptime() Looks like codel won't be slowing hfsc down at least. :) Simon
Re: CoDel
Le 2012-08-14 11:03, Ted Unangst a écrit : On Tue, Aug 14, 2012 at 09:42, Simon Perreault wrote: - CoDel needs to timestamp each packet when it gets queued. - I added a new member in struct pkthdr for this. Is this ok? - I end up calling microuptime() for each packet. Is this ok? You want to use getmicrouptime, it's faster. See the man page. Will it have good enough precision? I need to check if packets have been in the queue for less than 5ms. The man page talks about a precision of 10ms, which would not be good enough I'm afraid. Thanks, Simon
Re: CoDel
Le 2012-08-14 12:12, Ted Unangst a écrit : Five years ago I removed a once per packet microuptime call which led to something like a 33% improvement in throughput. I don't want to have to do that again. :) Hey I just realized that hfsc calls microuptime() for every single packet at dequeue time. altq_hfsc_dequeue() -- read_machclk() -- microuptime() Looks like codel won't be slowing hfsc down at least. :) Simon
Re: ip6(4) manpage update
On 2012-06-11 15:31, Peter J. Philipp wrote: I just got through a thread in misc@, http://marc.info/?l=openbsd-miscm=133934252713974w=2 and it seems like the sample code in ip6(4) is wrong. I've made adjustments but it doesn't look as nice anymore, perhaps someone can look over it? These changes will really help someone first time trying the sample code, I think. Credit should be given to Simon Perreault, I just did what he suggested. You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS, IPV6_DSTOPTS, and IPV6_RTHDR. The RECV part was added to them in RFC3542. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: overlapping IPv6 fragments in pf
On 2012-01-13 12:13, Fernando Gont wrote: If you do not keep state, then. 1) If you don't get any further fragments, you saved memory and other resources, or, 2) If you do get other fragments, they'll be queued, and since other fragments were dropped, there won't be any reassembled datagram, and after a reassembly timeout the fragments will get dropped anyway. I disagree with your proposal. The amount of memory saved in case 1) is insignificant. It's a few bytes. The fragments themselves are not kept in memory. And there are no other resources. In case 2) you end up having to keep fragments in memory. This is bad. Also, there would be no guarantee in case 2) that reassembly does not happen because of possible packet duplication. Simon
Re: handle overlapping IPv6 fragments
On 01/12/2012 03:39 AM, Fernando Gont wrote: Do we want this in our stack although it is not an RFC yet? Or perhaps only in pf for extra security? I should note that an RFC can take at least a year to publish (if ever). We should not wait for an RFC. We should wait for a consensus to emerge. This can be quick, and I think we're almost there. So I think this patch can safely be committed now. Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Please test: TCP MSS vs PMTUD
PMTUD can only lower TCP MSS (either the default one or the one advertised by the peer), not raise it. This is how it was originally but it regressed at some point. The comments still mention the correct behaviour, but the code doesn't do what the comments say. This diff fixes that. Please test especially if you have unusual MTU, PMTUD, or MSS settings. Index: tcp_input.c === RCS file: /cvs/src/sys/netinet/tcp_input.c,v retrieving revision 1.232 diff -u -r1.232 tcp_input.c --- tcp_input.c 11 Mar 2010 00:24:58 - 1.232 +++ tcp_input.c 15 Apr 2010 20:22:49 - @@ -3092,7 +3092,7 @@ * from maxseg, because now every segment carries options * and thus we normally have somewhat less data in segments. */ - tp-t_maxopd = mss; + tp-t_maxopd = offer == -1 ? min(mss, tp-t_maxopd) : mss; if ((tp-t_flags (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP (tp-t_flags TF_RCVD_TSTMP) == TF_RCVD_TSTMP) @@ -3122,7 +3122,7 @@ } else tp-snd_cwnd = mss; - tp-t_maxseg = mss; + tp-t_maxseg = offer == -1 ? min(mss, tp-t_maxseg) : mss; return (offer != -1 ? mssopt : mss); } -- NAT64/DNS64 open-source -- http://ecdysis.viagenie.ca STUN/TURN server-- http://numb.viagenie.ca vCard 4.0 -- http://www.vcarddav.org
Make remote debugging with KGDB possible
Hello,
This patch makes remote debugging with KGDB possible. It fixes a known bug, see
e.g. http://kerneltrap.org/mailarchive/openbsd-misc/2008/10/7/3537224.
Simon
P.S. This is my first contribution, please tell me if I did anything wrong.
Index: sys/dev/isa/com_isa.c
===
RCS file: /cvs/src/sys/dev/isa/com_isa.c,v
retrieving revision 1.4
diff -N -u sys/dev/isa/com_isa.c
--- sys/dev/isa/com_isa.c 24 Oct 2005 14:22:34 - 1.4
+++ sys/dev/isa/com_isa.c 15 Dec 2009 17:54:34 -
@@ -129,7 +129,7 @@
iobase = ia-ia_iobase;
iot = ia-ia_iot;
-#ifdef KGBD
+#ifdef KGDB
if ((iobase != comconsaddr)
(iobase != com_kgdb_addr)) {
#else
--
DNS64 open-source -- http://ecdysis.viagenie.ca
STUN/TURN server-- http://numb.viagenie.ca
vCard 4.0 -- http://www.vcarddav.org
