Re: IPv6 by default
* Adam Thompson [2014-04-29 04:37]: > On April 28, 2014 5:43:34 PM CDT, Kenneth Westerback > wrote: > >On 28 April 2014 18:05, Simon Perreault wrote: > >> 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. no way. > >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? that is the right question, and there is no good answer... > Someone has to take the first/next step except that it is a step towards the drain. > Sent from my Android device with K-9 Mail. Please excuse my brevity. Sent from a computer using a keyboard and software. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: IPv6 by default
On 2014/04/28 18:05, Simon Perreault wrote: > 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 Too soon I think. Wait a little longer and more major ISPs will turn IPv4 into the second class citizen as they fumble with their cgnat deployments then this will make a lot more sense. Now that akamai have their /10 taking ARIN into the final /8 run-out position that RIPE and APNIC have been in for some time, this will accelerate.
Re: p2p interfaces and route to loopback
On 28/04/14(Mon) 22:57, Martin Pieuchot wrote:
> On 28/04/14(Mon) 21:51, Stuart Henderson wrote:
> > On 2014/04/28 19:09, Martin Pieuchot wrote:
> > > On 28/04/14(Mon) 17:53, Stuart Henderson wrote:
> > > > On 2014/04/28 18:39, Martin Pieuchot wrote:
> > > > > On 28/04/14(Mon) 17:32, Stuart Henderson wrote:
> > > > > > On 2014/04/28 17:15, Stuart Henderson wrote:
> > > > > > > This breaks my setup,
> > > > > > >
> > > > > > > # /sbin/route add -inet6 default -ifp pppoe1 fe80::
> > > > > > > route: writing to routing socket: Network is unreachable
> > > > > > > add net default: gateway fe80::: Network is unreachable
> > > > > > >
> > > > > >
> > > > > > hmmm... actually it seems something that was committed broke this;
> > > > > > any suggestions of likely candidates?
> > > > >
> > > > > Concerning routing & inet6 that might be the rt_ifa_add_loop()
> > > > > committed
> > > > > on the 3rd of April, but you tested and ok'd it or the rtinit() ->
> > > > > rt_ifa_add() conversion committed the 10th of April.
> > > >
> > > > Window narrowed to between these:
> > > >
> > > > OpenBSD 5.5-current (GENERIC.MP) #61: Tue Apr 8 17:28:01 MDT
> > > > 2014
> > > > OpenBSD 5.5-current (GENERIC.MP) #63: Thu Apr 10 20:45:05 MDT
> > > > 2014
> > > >
> > > > Could it be in6.c 1.135? (I need to stop breaking my net for a bit to
> > > > get some other things done..)
> > >
> > > I doubt it will be this one since it's just removing a wrapper, but I
> > > don't see anything else in this timeframe.
> > >
> >
> > This is the one that breaks it, I can't just pull this diff out
> > though, other things are stacked on top.
>
> Thanks for finding it, I'll cook a fix then.
Here's a diff that fixes it in a way that allows me to remove the lladdr
from the global lists.
So the story behind this crap is horrible. Basically when you do:
# route -ifp pppoe1
route(8) encodes the interface name into "sdl_data" using link_addr(3).
This function is used only once and takes a crazy string argument like:
em0:00.18.91.13.ed.30, really? But in your case, it only copy "pppoe1".
Then to really obfuscate the things, ifa_ifwithnet() was comparing this
name like if it was an address...
So makes thing obvious and call ifunit() directly if we didn't find an
ifp with sdl_index.
Ok?
Index: net/route.c
===
RCS file: /home/ncvs/src/sys/net/route.c,v
retrieving revision 1.164
diff -u -p -r1.164 route.c
--- net/route.c 25 Apr 2014 10:41:09 - 1.164
+++ net/route.c 29 Apr 2014 08:55:15 -
@@ -658,6 +658,8 @@ ifa_ifwithroute(int flags, struct sockad
struct sockaddr_dl *sdl = (struct sockaddr_dl *)gateway;
struct ifnet *ifp = if_get(sdl->sdl_index);
+ if (ifp == NULL)
+ ifp = ifunit(sdl->sdl_data);
if (ifp != NULL)
ifa = ifp->if_lladdr;
} else {
@@ -702,6 +704,8 @@ rt_getifa(struct rt_addrinfo *info, u_in
sdl = (struct sockaddr_dl *)info->rti_info[RTAX_IFP];
ifp = if_get(sdl->sdl_index);
+ if (ifp == NULL)
+ ifp = ifunit(sdl->sdl_data);
}
if (info->rti_ifa == NULL && info->rti_info[RTAX_IFA] != NULL)
Switch getopt example to getprogname()
Hi,
This patch for /usr/share/misc/getopt enforces the use of getprogname()
instead of __progname.
Is this desirable? If so I also have a patch for style(9).
Index: getopt
===
RCS file: /cvs/src/share/misc/getopt,v
retrieving revision 1.8
diff -u -p -r1.8 getopt
--- getopt 1 Feb 2006 09:27:28 - 1.8
+++ getopt 29 Apr 2014 09:29:27 -
@@ -40,8 +40,6 @@ main(int argc, char *argv[])
void
usage(void)
{
- extern char *__progname;
-
- (void)fprintf(stderr, "usage: %s [-b] [-f file]\n", __progname);
+ (void)fprintf(stderr, "usage: %s [-b] [-f file]\n", getprogname());
exit(1);
}
Re: Switch getopt example to getprogname()
> Date: Tue, 29 Apr 2014 11:31:48 +0200 > From: Tristan Le Guern > > Hi, > > This patch for /usr/share/misc/getopt enforces the use of getprogname() > instead of __progname. > > Is this desirable? If so I also have a patch for style(9). getprogname(3) isn't really more portable than __progname, and the latter is probably slightly more efficient (smaller code). So I don't really see the point.
crypto pqueue patches v2
Hi all,
This is a second post of my patches for pqueue. I've also fixed
a few things based on comments I received.
These patches have only been build tested so far. No functional
change is intended. It is a simplification of the existing code.
ok?
Index: pqueue.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/pqueue/pqueue.c,v
retrieving revision 1.4
diff -u -p -r1.4 pqueue.c
--- pqueue.c27 Apr 2014 20:20:59 - 1.4
+++ pqueue.c29 Apr 2014 09:54:20 -
@@ -69,8 +69,9 @@ typedef struct _pqueue {
pitem *
pitem_new(unsigned char *prio64be, void *data)
{
- pitem *item = (pitem *)malloc(sizeof(pitem));
+ pitem *item;
+ item = malloc(sizeof(pitem));
if (item == NULL)
return NULL;
@@ -85,30 +86,18 @@ pitem_new(unsigned char *prio64be, void
void
pitem_free(pitem *item)
{
- if (item == NULL)
- return;
-
free(item);
}
pqueue_s *
pqueue_new(void)
{
- pqueue_s *pq = (pqueue_s *)malloc(sizeof(pqueue_s));
-
- if (pq == NULL)
- return NULL;
-
- memset(pq, 0x00, sizeof(pqueue_s));
- return pq;
+ return calloc(1, sizeof(pqueue_s));
}
void
pqueue_free(pqueue_s *pq)
{
- if (pq == NULL)
- return;
-
free(pq);
}
Index: pqueue.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/pqueue/pqueue.c,v
retrieving revision 1.4
diff -u -p -r1.4 pqueue.c
--- pqueue.c27 Apr 2014 20:20:59 - 1.4
+++ pqueue.c29 Apr 2014 10:47:54 -
@@ -168,33 +168,12 @@ pitem *
pqueue_find(pqueue_s *pq, unsigned char *prio64be)
{
pitem *next;
- pitem *found = NULL;
- if (pq->items == NULL)
- return NULL;
+ for (next = pq->items; next != NULL; next = next->next)
+ if (memcmp(next->priority, prio64be, 8) == 0)
+ return next;
- for (next = pq->items; next->next != NULL; next = next->next) {
- if (memcmp(next->priority, prio64be, 8) == 0) {
- found = next;
- break;
- }
- }
-
- /* check the one last node */
- if (memcmp(next->priority, prio64be, 8) ==0)
- found = next;
-
- if (! found)
- return NULL;
-
-#if 0 /* find works in peek mode */
- if (prev == NULL)
- pq->items = next->next;
- else
- prev->next = next->next;
-#endif
-
- return found;
+ return NULL;
}
void
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
On 29 April 2014 08:57, Simon Perreault wrote: > 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. > I repeat the question - what is the point of your goal to return IPv6 addresses first? Why change? Even in a world where IPv6 was 99.99% of the traffic, what advantages would accrue to having IPv6 addresses returned first? I'm not hostile or opposed, I just think this appears to be a complete waste of your time. >> 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. > Why would having the IPv6 addresses come first in the returned list be required to 'use' them? Please explain. Ken > Thanks, > Simon
Re: IPv6 by default
* Simon Perreault [2014-04-29 14:58]: > 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. however, it provides far worse performance with shitloads of downsides... -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: IPv6 by default
Em 29-04-2014 04:51, Stuart Henderson escreveu: > Too soon I think. Wait a little longer and more major ISPs will turn > IPv4 into the second class citizen as they fumble with their cgnat > deployments then this will make a lot more sense. Now that akamai have > their /10 taking ARIN into the final /8 run-out position that RIPE and > APNIC have been in for some time, this will accelerate. 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. Also, I believe firefox will default to ipv6 then ipv4 if you have it enabled. Too soon I think. I'm hoping for ipv6 get more traction soon, so we could end using nat on our pf rules. -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: IPv6 by default
* Simon Perreault [2014-04-29 14:41]: > 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". no, since that gives extremely unpredictable results. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
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
On Tue, Apr 29, 2014 at 08:57, Simon Perreault wrote: > 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-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
On Tue, Apr 29, 2014 at 08:57:57AM -0400, Simon Perreault wrote: > 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. The problem is that IPv6 is tunnels all the way down (at least in many locations) and has more delay. At the moment it is not even equal to the IPv4 performance so why should we force it on everyone using OpenBSD on this planet? At the moment people that want to taste the new and improved taste of IPv6 should edit resolv.conf or resolv.conf.tail to change the order. -- :wq Claudio
Re: IPv6 by default
* Simon Perreault [2014-04-29 16:05]: > 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. that could work, of course. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
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
On Tue, Apr 29, 2014 at 10:04:35AM -0400, Simon Perreault wrote: > 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 I'm still not sure what problem you bare trying to solve. I only see added complexity here. -Otto
Re: IPv6 by default
On 2014/04/29 10:52, Giancarlo Razzolini wrote: > Em 29-04-2014 04:51, Stuart Henderson escreveu: > > Too soon I think. Wait a little longer and more major ISPs will turn > > IPv4 into the second class citizen as they fumble with their cgnat > > deployments then this will make a lot more sense. Now that akamai have > > their /10 taking ARIN into the final /8 run-out position that RIPE and > > APNIC have been in for some time, this will accelerate. > > 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. This is not something you should have to touch at desktops. Either you run router advs in which case you should have working v6, or you don't, in which case programs using AI_ADDRCONFIG should not automatically pick them. The two biggest problems: 1. networks which run router advs but the v6 connectivity is broken. 2. networks with a malicious user sending adv's. similar to rogue dhcp servers for v4, but less understood and fewer controls in switches to deal with it, >Also, I believe firefox will default to > ipv6 then ipv4 if you have it enabled. Too soon I think. I'm hoping for > ipv6 get more traction soon, so we could end using nat on our pf rules. Mainstream browsers have their own heuristics to use ipv6 where it works, but they way they do this only makes sense for a longer-running process. AI_ADDRCONFIG is meant to be the way to select use of v6 where it works. Problem 1 above could possibly be dealt with by caching the status as to whether v6 actually works or not somewhere and using that in the decision whether to return v4 or v6 addresses.. Problem 2, well, I think networks who sufficiently care about it can make things safer, and those that don't probably aren't blocking rogue DHCP either.
Re: IPv6 by default
On Tue, Apr 29, 2014 at 10:04, Simon Perreault wrote: > - 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.
Re: IPv6 by default
On 29 April 2014 09:59, Simon Perreault wrote: > 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. Not obvious at all. I only learned of the existance of getaddrinfo() last week in Marrakesh when I tried to work on some OpenSSL code. Don't make such assumptions! :-) This seems to boil down to "I want to trick programs into using IPv6 if both are available." Not a goal I agree with, but an understandable one if we were on the verge of widespread adoption of IPv6. A better one would be "IPv6 is coming. Let's try to shake out programs new enough to use getaddrinfo() but old enough to not bother handling IPv6 addresses." Especially if you made it an option to explicitly make the kernel a more hostile environment. I'd still think this is premature, but probably worth discussion. It would seem a more laudible immediate goal would be to spread getaddrinfo() more consistantly into the daemons to prepare for our new IPv6 overlords. Ken > > 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 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
tedu .klogin
Is it ok to zap .klogin?
cheers
David
Index: distrib/sets/lists/etc/mi
===
RCS file: /cvs/src/distrib/sets/lists/etc/mi,v
retrieving revision 1.162
diff -u -p -u -p -r1.162 mi
--- distrib/sets/lists/etc/mi 24 Apr 2014 21:07:37 - 1.162
+++ distrib/sets/lists/etc/mi 29 Apr 2014 14:13:14 -
@@ -205,7 +205,6 @@
./root/.Xdefaults
./root/.cshrc
./root/.cvsrc
-./root/.klogin
./root/.login
./root/.profile
./var/crash/minfree
Index: etc/Makefile
===
RCS file: /cvs/src/etc/Makefile,v
retrieving revision 1.356
diff -u -p -u -p -r1.356 Makefile
--- etc/Makefile24 Apr 2014 15:05:10 - 1.356
+++ etc/Makefile29 Apr 2014 14:13:14 -
@@ -131,8 +131,6 @@ distribution-etc-root-var: distrib-dirs
cd root; \
${INSTALL} -c -o root -g wheel -m 644 dot.cshrc \
${DESTDIR}/root/.cshrc; \
- ${INSTALL} -c -o root -g wheel -m 600 dot.klogin \
- ${DESTDIR}/root/.klogin; \
${INSTALL} -c -o root -g wheel -m 644 dot.login \
${DESTDIR}/root/.login; \
${INSTALL} -c -o root -g wheel -m 644 dot.profile \
Index: etc/changelist
===
RCS file: /cvs/src/etc/changelist,v
retrieving revision 1.86
diff -u -p -u -p -r1.86 changelist
--- etc/changelist 22 Apr 2014 10:24:29 - 1.86
+++ etc/changelist 29 Apr 2014 14:13:14 -
@@ -153,7 +153,6 @@
/etc/ypldap.conf
/root/.Xdefaults
/root/.cshrc
-/root/.klogin
/root/.login
/root/.profile
/root/.rhosts
Index: etc/mtree/special
===
RCS file: /cvs/src/etc/mtree/special,v
retrieving revision 1.103
diff -u -p -u -p -r1.103 special
--- etc/mtree/special 22 Apr 2014 10:48:36 - 1.103
+++ etc/mtree/special 29 Apr 2014 14:13:17 -
@@ -118,7 +118,6 @@ uucptype=dir mode=0755 uname=root gnam
root type=dir mode=0700 uname=root gname=wheel
.cshrc type=file mode=0644 uname=root gname=wheel
-.klogintype=file mode=0600 uname=root gname=wheel optional
.login type=file mode=0644 uname=root gname=wheel
.profile type=file mode=0644 uname=root gname=wheel
.rhoststype=file mode=0600 uname=root gname=wheel optional
Index: etc/root/dot.klogin
===
RCS file: etc/root/dot.klogin
diff -N etc/root/dot.klogin
--- etc/root/dot.klogin 9 Jun 2002 06:15:15 - 1.4
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,4 +0,0 @@
-# $OpenBSD: dot.klogin,v 1.4 2002/06/09 06:15:15 todd Exp $
-
-#user1.root@your.realm.wherever
-#user2.root@your.realm.wherever
Index: libexec/security/security
===
RCS file: /cvs/src/libexec/security/security,v
retrieving revision 1.26
diff -u -p -u -p -r1.26 security
--- libexec/security/security 21 Apr 2014 15:46:03 - 1.26
+++ libexec/security/security 29 Apr 2014 14:14:00 -
@@ -103,7 +103,7 @@ sub check_passwd {
"\t by root; cannot check for existence " .
"of alternate access files."
or check_access_file "$home/.$_", $name
- foreach qw(ssh rhosts shosts klogin);
+ foreach qw(ssh rhosts shosts);
}
nag $uid == 0 && $name ne 'root',
"Login $name has a user ID of 0.";
@@ -407,7 +407,7 @@ sub check_dot_writeable {
return if $name =~ /^[+-]/; # skip YP lines
foreach my $f (qw(
.bashrc .bash_profile .bash_login .bash_logout .cshrc
- .emacs .exrc .forward .fvwmrc .inputrc .klogin .kshrc .login
+ .emacs .exrc .forward .fvwmrc .inputrc .kshrc .login
.logout .nexrc .profile .screenrc .ssh .ssh/config
.ssh/authorized_keys .ssh/authorized_keys2 .ssh/environment
.ssh/known_hosts .ssh/rc .tcshrc .twmrc .xsession .xinitrc
Do not abuse nd6_rtrequest() for p2p interfaces
So, I'm resending this diff since the previous bug has been fixed,
still looking for oks.
On 09/04/14(Wed) 11:22, Martin Pieuchot wrote:
> When an IPv6 address is configured on a point-to-point interface, it
> is associated to nd6_rtrequest(). This is because nd6_request()
> contains a hack to automatically create a route to loopback for p2p
> interfaces.
>
> The resulting route looks like this:
>
> fe80::300:245f:fedc:22f8%pppoe0link#12HL
> 00 - 4 lo0
>
>
> I'd like to stop abusing nd6_rtrequest() for point-to-point interfaces
> because I want to introduce a similar behavior for IPv4. So the diff
> below adds a sppp_rtrequest() function that works for both IPv4 and
> IPv6 and creates a local route if the loopback interface has an address
> of the same family. This diff introduce a difference in the routing
> table, see below, but it shouldn't matter. The RTF_LLINFO flags is
> necessary for ND6 or ARP, not for p2p interfaces.
>
>
> -fe80::300:245f:fedc:22f8%pppoe0link#12HL
> 00 - 4 lo0
> -2011:4b10:1003:ff::1 link#12HL
> 00 - 4 lo0
> +fe80::300:245f:fedc:22f8%pppoe0::1H
> 00 - 4 lo0
> +2011:4b10:1003:ff::1 ::1H
> 00 - 4 lo0
Here's an updated diff that addresses some points raised by claudio@:
- Support all the p2p interfaces but mpe(4) (should I include it?)
- Add comment about lo0 vs rdomain in {p2p,arp,nd6}_rtrequest().
Index: net/if.c
===
RCS file: /home/ncvs/src/sys/net/if.c,v
retrieving revision 1.286
diff -u -p -r1.286 if.c
--- net/if.c22 Apr 2014 12:35:00 - 1.286
+++ net/if.c29 Apr 2014 14:22:28 -
@@ -990,6 +990,71 @@ link_rtrequest(int cmd, struct rtentry *
}
/*
+ * Default action when installing a local route on a point-to-point
+ * interface.
+ */
+void
+p2p_rtrequest(int req, struct rtentry *rt)
+{
+ struct ifnet *ifp = rt->rt_ifp;
+ struct ifaddr *ifa, *lo0ifa;
+
+ switch (req) {
+ case RTM_ADD:
+ /*
+* XXX Here we abuse RTF_LLINFO to add a route to
+* loopback. We do that to always have a route
+* pointing to our address.
+*/
+ if ((rt->rt_flags & RTF_LLINFO) == 0)
+ break;
+
+ TAILQ_FOREACH(ifa, &ifp->if_addrlist, ifa_list) {
+ if (memcmp(rt_key(rt), ifa->ifa_addr,
+ rt_key(rt)->sa_len) == 0)
+ break;
+ }
+
+ if (ifa == NULL)
+ break;
+
+ /*
+* XXX Since lo0 is in the default rdomain we should not
+* (ab)use it for any route related to an interface of a
+* different rdomain.
+*/
+ TAILQ_FOREACH(lo0ifa, &lo0ifp->if_addrlist, ifa_list)
+ if (lo0ifa->ifa_addr->sa_family ==
+ ifa->ifa_addr->sa_family)
+ break;
+
+ if (lo0ifa == NULL)
+ break;
+
+ rt_setgate(rt, rt_key(rt), lo0ifa->ifa_addr, ifp->if_rdomain);
+ rt->rt_ifp = lo0ifp;
+ rt->rt_flags &= ~RTF_LLINFO;
+
+ /*
+* make sure to set rt->rt_ifa to the interface
+* address we are using, otherwise we will have trouble
+* with source address selection.
+*/
+ if (ifa != rt->rt_ifa) {
+ ifafree(rt->rt_ifa);
+ ifa->ifa_refcnt++;
+ rt->rt_ifa = ifa;
+ }
+ break;
+ case RTM_DELETE:
+ case RTM_RESOLVE:
+ default:
+ break;
+ }
+}
+
+
+/*
* Bring down all interfaces
*/
void
Index: net/if_gif.c
===
RCS file: /home/ncvs/src/sys/net/if_gif.c,v
retrieving revision 1.66
diff -u -p -r1.66 if_gif.c
--- net/if_gif.c21 Apr 2014 12:22:25 - 1.66
+++ net/if_gif.c29 Apr 2014 14:22:28 -
@@ -354,7 +354,8 @@ int
gif_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data)
{
struct gif_softc *sc = (struct gif_softc*)ifp;
- struct ifreq *ifr = (struct ifreq*)data;
+ struct ifreq *ifr = (struct ifreq *)data;
+ struct ifaddr*ifa = (struct ifaddr *)data;
int error = 0, size;
struct sockaddr *dst, *src;
struct sockaddr *sa;
@@ -363,6 +364,7 @@ gif_ioctl(struct ifnet *ifp, u_long cmd,
switch (cmd) {
case SIOCSIFADDR:
+ ifa->ifa_rtrequest = p2p_rtreq
patch: use a lookup table in BIO_get_port()
Not sure this is sensible as it encourages people to simply
update the table.
I was inclined to remove the code entirely but I am not sure
what broken systems might rely on this.
Only build tested.
Thoughts?
Index: b_sock.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/bio/b_sock.c,v
retrieving revision 1.33
diff -u -p -r1.33 b_sock.c
--- b_sock.c26 Apr 2014 18:56:37 - 1.33
+++ b_sock.c29 Apr 2014 13:55:39 -
@@ -140,6 +140,19 @@ BIO_get_port(const char *str, unsigned s
{
int i;
struct servent *s;
+ size_t len;
+ struct {
+ const char *name;
+ int port;
+ } servmap[] = {
+ { "http", 80 },
+ { "telnet", 23 },
+ { "socks", 1080 },
+ { "https", 443 },
+ { "ssl",443 },
+ { "ftp",21 },
+ { "gopher", 70 }
+ };
if (str == NULL) {
BIOerr(BIO_F_BIO_GET_PORT, BIO_R_NO_PORT_DEFINED);
@@ -155,21 +168,14 @@ BIO_get_port(const char *str, unsigned s
*port_ptr = ntohs((unsigned short)s->s_port);
CRYPTO_w_unlock(CRYPTO_LOCK_GETSERVBYNAME);
if (s == NULL) {
- if (strcmp(str, "http") == 0)
- *port_ptr = 80;
- else if (strcmp(str, "telnet") == 0)
- *port_ptr = 23;
- else if (strcmp(str, "socks") == 0)
- *port_ptr = 1080;
- else if (strcmp(str, "https") == 0)
- *port_ptr = 443;
- else if (strcmp(str, "ssl") == 0)
- *port_ptr = 443;
- else if (strcmp(str, "ftp") == 0)
- *port_ptr = 21;
- else if (strcmp(str, "gopher") == 0)
- *port_ptr = 70;
- else {
+ len = sizeof(servmap) / sizeof(servmap[0]);
+ for (i = 0; i < len; i++) {
+ if (strcmp(str, servmap[i].name) == 0) {
+ *port_ptr = servmap[i].port;
+ break;
+ }
+ }
+ if (i == len) {
SYSerr(SYS_F_GETSERVBYNAME, errno);
ERR_asprintf_error_data("service='%s'", str);
return (0);
Re: patch: use a lookup table in BIO_get_port()
On 29 April 2014 10:42, Dimitris Papastamos wrote:
> Not sure this is sensible as it encourages people to simply
> update the table.
>
> I was inclined to remove the code entirely but I am not sure
> what broken systems might rely on this.
>
> Only build tested.
>
> Thoughts?
>
> Index: b_sock.c
> ===
> RCS file: /cvs/src/lib/libssl/src/crypto/bio/b_sock.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 b_sock.c
> --- b_sock.c26 Apr 2014 18:56:37 - 1.33
> +++ b_sock.c29 Apr 2014 13:55:39 -
> @@ -140,6 +140,19 @@ BIO_get_port(const char *str, unsigned s
> {
> int i;
> struct servent *s;
> + size_t len;
> + struct {
> + const char *name;
> + int port;
> + } servmap[] = {
> + { "http", 80 },
> + { "telnet", 23 },
> + { "socks", 1080 },
> + { "https", 443 },
> + { "ssl",443 },
> + { "ftp",21 },
> + { "gopher", 70 }
> + };
>
> if (str == NULL) {
> BIOerr(BIO_F_BIO_GET_PORT, BIO_R_NO_PORT_DEFINED);
> @@ -155,21 +168,14 @@ BIO_get_port(const char *str, unsigned s
> *port_ptr = ntohs((unsigned short)s->s_port);
> CRYPTO_w_unlock(CRYPTO_LOCK_GETSERVBYNAME);
> if (s == NULL) {
> - if (strcmp(str, "http") == 0)
> - *port_ptr = 80;
> - else if (strcmp(str, "telnet") == 0)
> - *port_ptr = 23;
> - else if (strcmp(str, "socks") == 0)
> - *port_ptr = 1080;
> - else if (strcmp(str, "https") == 0)
> - *port_ptr = 443;
> - else if (strcmp(str, "ssl") == 0)
> - *port_ptr = 443;
> - else if (strcmp(str, "ftp") == 0)
> - *port_ptr = 21;
> - else if (strcmp(str, "gopher") == 0)
> - *port_ptr = 70;
> - else {
> + len = sizeof(servmap) / sizeof(servmap[0]);
> + for (i = 0; i < len; i++) {
> + if (strcmp(str, servmap[i].name) == 0) {
> + *port_ptr = servmap[i].port;
> + break;
> + }
> + }
> + if (i == len) {
> SYSerr(SYS_F_GETSERVBYNAME, errno);
> ERR_asprintf_error_data("service='%s'", str);
> return (0);
>
In my b_sock.c rewrite I just nuked all the manual comparisons, other
than the weird 'ssl' == 'https' which I thought might break some
program/environment, and relied on the service name lookup which
includes all the specified ones.
Ken
Re: IPv6 by default
Penned by Kenneth Westerback on 20140429 8:44.16, we have: | On 29 April 2014 08:57, Simon Perreault wrote: | > 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. | > | | I repeat the question - what is the point of your goal to return IPv6 | addresses first? Why change? Even in a world where IPv6 was 99.99% of | the traffic, what advantages would accrue to having IPv6 addresses | returned first? I'm not hostile or opposed, I just think this appears | to be a complete waste of your time. | | >> 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. | > | | Why would having the IPv6 addresses come first in the returned list be | required to 'use' them? Please explain. Many commonly used applications that have the ability to connect to both IPv4 and IPv6 will connect to the first address. This is a mere convenience. Everybody knows I use IPv6 a lot and I am fine with the resolv.conf 'family inet4 inet6' remaining as it is until a future time if/when it makes sense to change it. Doing so prematurely does not help. Thanks, -- Todd T. Fries . http://todd.fries.net/pgp.txt . @unix2mars . github:toddfries
growfs fix
This seems to fix growfs on 4k-sector drives by doing the test write
to the last sector rather than the last 512-byte block, which can't be
accessed directly on 4k-sector drives.
Any other growfs users out there want to test on 'normal' drives?
Ken
Index: growfs.c
===
RCS file: /cvs/src/sbin/growfs/growfs.c,v
retrieving revision 1.33
diff -u -p -r1.33 growfs.c
--- growfs.c10 Nov 2013 00:48:04 - 1.33
+++ growfs.c29 Apr 2014 15:42:56 -
@@ -1899,7 +1899,7 @@ int
main(int argc, char **argv)
{
DBG_FUNC("main")
- char*device;
+ char*device, *lastsector;
int ch;
long long size = 0;
unsigned intNflag = 0;
@@ -2072,12 +2072,16 @@ main(int argc, char **argv)
(intmax_t)sblock.fs_size);
/*
-* Try to access our new last block in the filesystem. Even if we
-* later on realize we have to abort our operation, on that block
+* Try to access our new last sector in the filesystem. Even if we
+* later on realize we have to abort our operation, on that sector
* there should be no data, so we can't destroy something yet.
*/
- wtfs(DL_SECTOBLK(lp, DL_GETPSIZE(pp)) - 1, (size_t)DEV_BSIZE,
- (void *)&sblock, fso, Nflag);
+ lastsector = calloc(1, lp->d_secsize);
+ if (!lastsector)
+ err(1, "No memory for last sector test write");
+ wtfs(DL_SECTOBLK(lp, DL_GETPSIZE(pp) - 1), lp->d_secsize,
+ lastsector, fso, Nflag);
+ free(lastsector);
/*
* Now calculate new superblock values and check for reasonable
Re: IPv6 by default
Penned by Otto Moerbeek on 20140429 9:07.54, we have: | On Tue, Apr 29, 2014 at 10:04:35AM -0400, Simon Perreault wrote: | | > 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 | | I'm still not sure what problem you bare trying to solve. I only see | added complexity here. | | -Otto Some broken routers that dish out dhcp leases and set themselves as the recursive resolver have been reported to not respond when someone queries . There may be some benifit, but for what percent of users? Added complexity seems not the direction we want to go in, indeed. Thanks, -- Todd T. Fries . http://todd.fries.net/pgp.txt . @unix2mars . github:toddfries
Re: IPv6 by default
> Date: Tue, 29 Apr 2014 09:55:58 -0400 > From: Simon Perreault > > 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]. Isn't there a correlation between those countries and actual IPv6 usage? > Is there anything else? IPv6 is at least an order of magnitude more complex than IPv4. Less IPv6 results in better security.
Re: IPv6 by default
On 2014-04-29, Mark Kettenis wrote: >> 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]. > > Isn't there a correlation between those countries and actual IPv6 usage? According to "Akamai's State of the Internet" Q4 2013 report (figure 16, PDF page 15): Country/Region Q4'13 IPv6QoQ Traffic %Change 1 Switzerland 9.3%33% 2 Romania 7.9% 7.8% 3 Luxembourg 6.7%35% 4 Germany 5.8%43% 5 Peru5.5%41% 6 United States 5.2%25% 7 Belgium 4.7%23% 8 France 4.5% -11% 9 Ireland 4.3%14% 10 Japan 2.2%11% http://www.akamai.com/stateoftheinternet/ -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: IPv6 by default
On 29 April 2014 12:57, Christian Weisgerber wrote: > On 2014-04-29, Mark Kettenis wrote: > >>> 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]. >> >> Isn't there a correlation between those countries and actual IPv6 usage? > > According to "Akamai's State of the Internet" Q4 2013 report > (figure 16, PDF page 15): > >Country/Region Q4'13 IPv6QoQ > Traffic %Change > 1 Switzerland 9.3%33% > 2 Romania 7.9% 7.8% > 3 Luxembourg 6.7%35% > 4 Germany 5.8%43% > 5 Peru5.5%41% > 6 United States 5.2%25% > 7 Belgium 4.7%23% > 8 France 4.5% -11% > 9 Ireland 4.3%14% > 10 Japan 2.2%11% > > http://www.akamai.com/stateoftheinternet/ > > -- > Christian "naddy" Weisgerber na...@mips.inka.de > Switzerland needs to be broken out to exclude Claudio and Peter Hessler. :-) Ken
Re: IPv6 by default
On Tue, Apr 29, 2014 at 04:57:28PM +, Christian Weisgerber wrote: > On 2014-04-29, Mark Kettenis wrote: > > >> 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]. > > > > Isn't there a correlation between those countries and actual IPv6 usage? > > According to "Akamai's State of the Internet" Q4 2013 report > (figure 16, PDF page 15): > >Country/Region Q4'13 IPv6QoQ > Traffic %Change > 1 Switzerland 9.3%33% > 2 Romania 7.9% 7.8% > 3 Luxembourg 6.7%35% > 4 Germany 5.8%43% > 5 Peru5.5%41% > 6 United States 5.2%25% > 7 Belgium 4.7%23% > 8 France 4.5% -11% > 9 Ireland 4.3%14% > 10 Japan 2.2%11% > > http://www.akamai.com/stateoftheinternet/ > > -- > Christian "naddy" Weisgerber na...@mips.inka.de If you look at the stats of ams-ix, you'll see IPv6 traffic growing, but at about the same rate as IPv6. It has been hovering at about 0.5% for quite a while, and only the last 2 month it is growing a bit (to 0.6%). https://ams-ix.net/technical/statistics/sflow-stats/ether-type -Otto
nibbles to bytes in malloc
This changes getrnibble in malloc to getrbyte() for more potential
randomness.
The delayed chunk array can (should) be larger, but requires more than
a nibble of random to span it. Not changed yet, but with this diff it
can grow (or even shrink) in the future.
The bit offset in malloc_bytes cannot be spanned by a single nibble
either. Instead of adding two nibbles together, just use a whole byte.
Everything is simpler now.
Index: stdlib/malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.158
diff -u -p -r1.158 malloc.c
--- stdlib/malloc.c 23 Apr 2014 15:07:27 - 1.158
+++ stdlib/malloc.c 29 Apr 2014 19:33:12 -
@@ -61,7 +61,7 @@
#define MALLOC_MAXCHUNK(1 << MALLOC_MAXSHIFT)
#define MALLOC_MAXCACHE256
-#define MALLOC_DELAYED_CHUNKS 15 /* max of getrnibble() */
+#define MALLOC_DELAYED_CHUNK_MASK 15
#define MALLOC_INITIAL_REGIONS 512
#define MALLOC_DEFAULT_CACHE 64
@@ -115,7 +115,7 @@ struct dir_info {
/* free pages cache */
struct region_info free_regions[MALLOC_MAXCACHE];
/* delayed free chunk slots */
- void *delayed_chunks[MALLOC_DELAYED_CHUNKS + 1];
+ void *delayed_chunks[MALLOC_DELAYED_CHUNK_MASK + 1];
u_short chunk_start;
#ifdef MALLOC_STATS
size_t inserts;
@@ -191,9 +191,9 @@ static int malloc_active; /* status of
static size_t malloc_guarded; /* bytes used for guards */
static size_t malloc_used;/* bytes allocated */
-static size_t rnibblesused;/* random nibbles used */
+static size_t rbytesused; /* random bytes used */
static u_char rbytes[512]; /* random bytes */
-static u_char getrnibble(void);
+static u_char getrbyte(void);
extern char*__progname;
@@ -273,18 +273,18 @@ static void
rbytes_init(void)
{
arc4random_buf(rbytes, sizeof(rbytes));
- rnibblesused = 0;
+ rbytesused = 0;
}
static inline u_char
-getrnibble(void)
+getrbyte(void)
{
u_char x;
- if (rnibblesused >= 2 * sizeof(rbytes))
+ if (rbytesused >= sizeof(rbytes))
rbytes_init();
- x = rbytes[rnibblesused++ / 2];
- return (rnibblesused & 1 ? x & 0xf : x >> 4);
+ x = rbytes[rbytesused++];
+ return x;
}
/*
@@ -317,7 +317,7 @@ unmap(struct dir_info *d, void *p, size_
rsz = mopts.malloc_cache - d->free_regions_size;
if (psz > rsz)
tounmap = psz - rsz;
- offset = getrnibble() + (getrnibble() << 4);
+ offset = getrbyte();
for (i = 0; tounmap > 0 && i < mopts.malloc_cache; i++) {
r = &d->free_regions[(i + offset) & (mopts.malloc_cache - 1)];
if (r->p != NULL) {
@@ -398,7 +398,7 @@ map(struct dir_info *d, size_t sz, int z
/* zero fill not needed */
return p;
}
- offset = getrnibble() + (getrnibble() << 4);
+ offset = getrbyte();
for (i = 0; i < mopts.malloc_cache; i++) {
r = &d->free_regions[(i + offset) & (mopts.malloc_cache - 1)];
if (r->p != NULL) {
@@ -920,7 +920,7 @@ malloc_bytes(struct dir_info *d, size_t
i = d->chunk_start;
if (bp->free > 1)
- i += getrnibble();
+ i += getrbyte();
if (i >= bp->total)
i &= bp->total - 1;
for (;;) {
@@ -1200,7 +1200,7 @@ ofree(void *p)
if (mopts.malloc_junk && sz > 0)
memset(p, SOME_FREEJUNK, sz);
if (!mopts.malloc_freenow) {
- i = getrnibble();
+ i = getrbyte() & MALLOC_DELAYED_CHUNK_MASK;
tmp = p;
p = g_pool->delayed_chunks[i];
g_pool->delayed_chunks[i] = tmp;
Re: IPv6 by default
On Tue, Apr 29, 2014 at 10:52:06AM -0300, Giancarlo Razzolini wrote: | Em 29-04-2014 04:51, Stuart Henderson escreveu: | > Too soon I think. Wait a little longer and more major ISPs will turn | > IPv4 into the second class citizen as they fumble with their cgnat | > deployments then this will make a lot more sense. Now that akamai have | > their /10 taking ARIN into the final /8 run-out position that RIPE and | > APNIC have been in for some time, this will accelerate. | | 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. Also, I believe firefox will default to | ipv6 then ipv4 if you have it enabled. Too soon I think. I'm hoping for | ipv6 get more traction soon, so we could end using nat on our pf rules. Disabling IPv6 should not be necessary: it shouldn't be enabled by default, even link-local addresses. Why oh why can I bring up an interface and have attackers probe me over IPv6 on a default OpenBSD install while they cannot do so over IPv4? Why is IPv6 more enabled than IPv4? IPv4 takes configuration before it will work, IPv6 works without it. I believe that's a problem that should be fixed before changing other defaults. If I want IPv6 (static / RS / DHCPv6 / whatever), I should configure my machine with it .. just like with IPv4 (static / DHCP / whatever). Fuck this bullshit. Please note that this is the protocol where many a developer will complain about how it's more complex than IPv4. Paul 'WEiRD' de Weerd PS: I tend to want IPv6 everywhere - I'm just opposing this STUPID default in OpenBSD. -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: IPv6 by default
Em 29-04-2014 17:25, Paul de Weerd escreveu: > Disabling IPv6 should not be necessary: it shouldn't be enabled by > default, even link-local addresses. Exactly my point. Even with only link local addresses, some daemons bind to tcp6 wildcard sockets and I can detect delays when using a linux with the dual stack. > > Why oh why can I bring up an interface and have attackers probe me > over IPv6 on a default OpenBSD install while they cannot do so over > IPv4? Why is IPv6 more enabled than IPv4? IPv4 takes configuration > before it will work, IPv6 works without it. I believe that's a > problem that should be fixed before changing other defaults. The ipv6 setup must be much simpler than ipv4. And it is. Using rtadvd on OpenBSD for example is simpler than setting up a dhcp server. > > If I want IPv6 (static / RS / DHCPv6 / whatever), I should configure > my machine with it .. just like with IPv4 (static / DHCP / whatever). > Fuck this bullshit. Please note that this is the protocol where many > a developer will complain about how it's more complex than IPv4. > > Paul 'WEiRD' de Weerd > > PS: I tend to want IPv6 everywhere - I'm just opposing this STUPID > default in OpenBSD. > IPv6 will make our life as sysadmins much easier. IPv6 will happen. The sooner the better. But this default on OpenBSD is not the way to make it happen faster. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: IPv6 by default
On Tue, Apr 29, 2014 at 2:25 PM, Paul de Weerd wrote: > > > Why oh why can I bring up an interface and have attackers probe me > over IPv6 on a default OpenBSD install while they cannot do so over > IPv4? Why is IPv6 more enabled than IPv4? IPv4 takes configuration > before it will work, IPv6 works without it. I believe that's a > problem that should be fixed before changing other defaults. > > Talk from defcon last year on abusing IPV6: https://www.defcon.org/images/defcon-21/dc-21-presentations/Alonso/DEFCON-21-Alonso-Fear-the-Evil-FOCA-Updated.pdf Video is up too - Alonso is pretty funny: https://media.defcon.org/DEF%20CON%2021/DEF%20CON%2021%20video%20and%20slides/DEF%20CON%2021%20Hacking%20Conference%20Presentation%20By%20Chema%20Alonso%20-%20Fear%20the%20Evil%20FOCA%20IPv6%20attacks%20-%20Video%20and%20Slides.m4v I agree default should be IPV6 off... On Tue, Apr 29, 2014 at 2:25 PM, Paul de Weerd wrote: > On Tue, Apr 29, 2014 at 10:52:06AM -0300, Giancarlo Razzolini wrote: > | Em 29-04-2014 04:51, Stuart Henderson escreveu: > | > Too soon I think. Wait a little longer and more major ISPs will turn > | > IPv4 into the second class citizen as they fumble with their cgnat > | > deployments then this will make a lot more sense. Now that akamai have > | > their /10 taking ARIN into the final /8 run-out position that RIPE and > | > APNIC have been in for some time, this will accelerate. > | > | 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. Also, I believe firefox will default to > | ipv6 then ipv4 if you have it enabled. Too soon I think. I'm hoping for > | ipv6 get more traction soon, so we could end using nat on our pf rules. > > Disabling IPv6 should not be necessary: it shouldn't be enabled by > default, even link-local addresses. > > Why oh why can I bring up an interface and have attackers probe me > over IPv6 on a default OpenBSD install while they cannot do so over > IPv4? Why is IPv6 more enabled than IPv4? IPv4 takes configuration > before it will work, IPv6 works without it. I believe that's a > problem that should be fixed before changing other defaults. > > If I want IPv6 (static / RS / DHCPv6 / whatever), I should configure > my machine with it .. just like with IPv4 (static / DHCP / whatever). > Fuck this bullshit. Please note that this is the protocol where many > a developer will complain about how it's more complex than IPv4. > > Paul 'WEiRD' de Weerd > > PS: I tend to want IPv6 everywhere - I'm just opposing this STUPID > default in OpenBSD. > > -- > >[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/ > >
Re: polling SSL kerberos and srp support
Am Montag, 28. April 2014, 21:40:30 schrieb Ted Unangst: > Also note that I'm not really interested in rumors or whispers. You > don't need to tell me that it's possible somebody else uses > Kerberos. I know it's possible, that's why I'm asking. I'd like to > know who. One data point: Apache HTTPD 2.4 supports SRP.
Re: IPv6 by default
On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote: > 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. Good point. I think I was tricked by your proposal into thinking the current code did something else. Even so, I have a new objection. :) This will introduce a lot of strange effects based on whether the second response arrives in time or not. I would not want to debug this.
Re: IPv6 by default
On 2014/04/29 22:25, Paul de Weerd wrote: > Disabling IPv6 should not be necessary: it shouldn't be enabled by > default, even link-local addresses. If doing this, then we need a way to enable link-local, like the opposite of "ifconfig $if -inet6". Current process to re-enable just the link-local is to configure some other v6 address and delete it again, which is acceptable when the option to remove the link-local is just used by people who explicitly don't want v6 at all, but is a bit too ugly if it's something that people need to use just to enable v6. I also wonder about blocking all-nodes mcast in the sample pf.conf... (personally there are places I find them very useful but I think this is a saner default - it's always fun doing a node-name query on conference wifi/etc). Index: pf.conf === RCS file: /cvs/src/etc/pf.conf,v retrieving revision 1.53 diff -u -p -r1.53 pf.conf --- pf.conf 25 Jan 2014 10:28:36 - 1.53 +++ pf.conf 29 Apr 2014 21:35:03 - @@ -19,6 +19,8 @@ set skip on lo block return # block stateless traffic pass # establish keep-state +block in inet6 proto icmp6 to ff02::1 # block all-nodes multicast queries + # rules for spamd(8) #table persist #table persist file "/etc/mail/nospamd" > Why oh why can I bring up an interface and have attackers probe me > over IPv6 on a default OpenBSD install while they cannot do so over > IPv4? Why is IPv6 more enabled than IPv4? IPv4 takes configuration > before it will work, IPv6 works without it. I believe that's a > problem that should be fixed before changing other defaults. > > If I want IPv6 (static / RS / DHCPv6 / whatever), I should configure > my machine with it .. just like with IPv4 (static / DHCP / whatever). > Fuck this bullshit. Please note that this is the protocol where many > a developer will complain about how it's more complex than IPv4. > > Paul 'WEiRD' de Weerd > > PS: I tend to want IPv6 everywhere - I'm just opposing this STUPID > default in OpenBSD. My thinking is that *if* someone has taken steps to enable v6, then programs should try to use it for comms where possible. "family inet6 inet4" is too blunt and affects people who don't want to touch v6. But if we can be smarter about only using v6 where people have made that decision (i.e. AI_ADDRCONFIG), preferring it is a good way to get the code better exercised and bugs found.
pckbd volume keys (part 1), diff to test
This diff attempts to "unify" volume keys; it makes pckbd and ukbd
volume keys behave like all other volume keys (acpithinkpad,
acpiasus, macppc/abtn and similar drivers): simply adjust the
hardware volume without passing keystroke events to upper layers
(i.e. "consume" the keystroke).
If your volume keys tend to mess the volume while in X (example
mplayer), try this diff and see if it makes things better (or
worse).
--- sys/dev/pckbc/pckbd.c.orig Tue Apr 29 19:29:09 2014
+++ sys/dev/pckbc/pckbd.c Tue Apr 29 22:46:30 2014
@@ -177,7 +177,7 @@ int pckbd_init(struct pckbd_internal *, pckbc_tag_t, p
void pckbd_input(void *, int);
static int pckbd_decode(struct pckbd_internal *, int,
- u_int *, int *);
+ u_int *, int *, int);
static int pckbd_led_encode(int);
struct pckbd_internal pckbd_consdata;
@@ -788,7 +788,8 @@ pckbd_scancode_translate(struct pckbd_internal *id, in
}
static int
-pckbd_decode(struct pckbd_internal *id, int datain, u_int *type, int *dataout)
+pckbd_decode(struct pckbd_internal *id, int datain, u_int *type,
+int *dataout, int raw)
{
int key;
int releasing;
@@ -832,8 +833,8 @@ pckbd_decode(struct pckbd_internal *id, int datain, u_
id->t_lastchar = 0;
*type = WSCONS_EVENT_KEY_UP;
} else {
- /* Always ignore typematic keys */
- if (key == id->t_lastchar)
+ /* Always ignore typematic keys, except in raw-mode */
+ if (key == id->t_lastchar && !raw)
return 0;
id->t_lastchar = key;
*type = WSCONS_EVENT_KEY_DOWN;
@@ -894,16 +895,25 @@ void
pckbd_input(void *vsc, int data)
{
struct pckbd_softc *sc = vsc;
- int rc, type, key;
+ int rc, type, key, consumed;
data = pckbd_scancode_translate(sc->id, data);
if (data == 0)
return;
- rc = pckbd_decode(sc->id, data, &type, &key);
+#ifdef WSDISPLAY_COMPAT_RAWKBD
+ rc = pckbd_decode(sc->id, data, &type, &key, sc->rawkbd);
+#else
+ rc = pckbd_decode(sc-id, data, &type, &key, 0);
+#endif
+ consumed = (rc != 0) ? wskbd_volkey(sc->sc_wskbddev, type, key) : 0;
#ifdef WSDISPLAY_COMPAT_RAWKBD
if (sc->rawkbd) {
+ if (consumed) {
+ sc->sc_rawcnt = 0;
+ return;
+ }
sc->sc_rawbuf[sc->sc_rawcnt++] = (char)data;
if (rc != 0 || sc->sc_rawcnt == sizeof(sc->sc_rawbuf)) {
@@ -911,15 +921,10 @@ pckbd_input(void *vsc, int data)
sc->sc_rawcnt);
sc->sc_rawcnt = 0;
}
-
- /*
-* Pass audio keys to wskbd_input anyway.
-*/
- if (rc == 0 || (key != 160 && key != 174 && key != 176))
- return;
+ return;
}
#endif
- if (rc != 0)
+ if (rc != 0 && !consumed)
wskbd_input(sc->sc_wskbddev, type, key);
}
@@ -1024,7 +1029,7 @@ pckbd_cngetc(void *v, u_int *type, int *data)
if (val == 0)
continue;
- if (pckbd_decode(t, val, type, data))
+ if (pckbd_decode(t, val, type, data, 0))
return;
}
}
--- sys/dev/usb/hidkbd.c.orig Tue Apr 29 19:29:09 2014
+++ sys/dev/usb/hidkbd.cTue Apr 29 19:29:24 2014
@@ -411,6 +411,9 @@ hidkbd_decode(struct hidkbd *kbd, struct hidkbd_data *
for (i = j = 0; i < nkeys; i++) {
key = ibuf[i];
c = hidkbd_trtab[key & CODEMASK];
+ if (wskbd_volkey(kbd->sc_wskbddev, (key & RELEASE) ?
+ WSCONS_EVENT_KEY_UP : WSCONS_EVENT_KEY_DOWN, c))
+ continue;
if (c == NN)
continue;
if (c & 0x80)
@@ -425,24 +428,7 @@ hidkbd_decode(struct hidkbd *kbd, struct hidkbd_data *
}
s = spltty();
wskbd_rawinput(kbd->sc_wskbddev, cbuf, j);
-
- /*
-* Pass audio keys to wskbd_input anyway.
-*/
- for (i = 0; i < nkeys; i++) {
- key = ibuf[i];
- switch (key & CODEMASK) {
- case 127:
- case 128:
- case 129:
- wskbd_input(kbd->sc_wskbddev,
- key & RELEASE ? WSCONS_EVENT_KEY_UP :
- WSCONS_EVENT_KEY_DOWN, key & CODEMASK);
- break;
- }
- }
splx(s);
-
return;
}
#endif
@@ -450,6 +436,10 @@ hidkbd_decode(struct h
pckbd volume keys (part 2): knob to pass keystrokes
this diff applies on top of the previous one; it adds the
hw.kbdvolume sysctl(1) entry to select how pckbd & ukbd volume keys
are handled:
hw.kbdvolume=0
pass keystrokes to upper layer as we do for regular keys,
thus usable by X apps as hot-keys or whatever.
hw.kbdvolume=1
change the ouputs.master control of the first audio device,
keystrokes are consumed by the kernel and not visible by
userland. This is the default, as this is the behavior of
all other (acpi, macppc, ... ) volume keys.
I'm not 100% convinced this knob is is needed; some of us think
it's useful, so i thow it here for completeness. Let me know if you
think this is needed.
To test it, rebuild your kernel, do a "make includes" in usr/src,
rebuild then re-install the sysctl utility. Then:
sysctl hw.kbdvolume=0
to force the pckbd and ukbd drivers to pass volume keys as regular
keystrokes. And:
sysctl hw.kbdvolume=1
to revert to the default behavior (ie adjust the volume).
-- Alexandre
--- sys/dev/wscons/wskbd.c.orig Tue Apr 29 22:54:12 2014
+++ sys/dev/wscons/wskbd.c Tue Apr 29 22:54:26 2014
@@ -299,6 +299,7 @@ voidwskbd_update_layout(struct wskbd_internal *,
kbd_
#if NAUDIO > 0
extern int wskbd_set_mixervolume(long, long);
#endif
+extern int kbdvolume; /* see sys/kern/kern_sysctl.c */
void
wskbd_update_layout(struct wskbd_internal *id, kbd_t enc)
@@ -706,6 +707,8 @@ wskbd_input(struct device *dev, u_int type, int value)
int
wskbd_volkey(struct device *dev, u_int type, int key)
{
+ if (!kbdvolume)
+ return 0;
switch (key) {
case 160:
#if NAUDIO > 0
--- sys/sys/sysctl.h.orig Tue Apr 29 22:54:12 2014
+++ sys/sys/sysctl.hTue Apr 29 22:54:26 2014
@@ -798,7 +798,8 @@ struct kinfo_file {
#defineHW_USERMEM6420 /* quad: non-kernel memory */
#defineHW_NCPUFOUND21 /* int: number of cpus found*/
#defineHW_ALLOWPOWERDOWN 22 /* allow power button shutdown
*/
-#defineHW_MAXID23 /* number of valid hw ids */
+#defineHW_KBDVOLUME23 /* volume keys adjust volume */
+#defineHW_MAXID24 /* number of valid hw ids */
#defineCTL_HW_NAMES { \
{ 0, 0 }, \
@@ -824,6 +825,7 @@ struct kinfo_file {
{ "usermem", CTLTYPE_QUAD }, \
{ "ncpufound", CTLTYPE_INT }, \
{ "allowpowerdown", CTLTYPE_INT }, \
+ { "kbdvolume", CTLTYPE_INT }, \
}
/*
--- sys/kern/kern_sysctl.c.orig Tue Apr 29 22:54:12 2014
+++ sys/kern/kern_sysctl.c Tue Apr 29 22:54:26 2014
@@ -612,6 +612,7 @@ kern_sysctl(int *name, u_int namelen, void *oldp, size
*/
char *hw_vendor, *hw_prod, *hw_uuid, *hw_serial, *hw_ver;
int allowpowerdown = 1;
+int kbdvolume = 1;
int
hw_sysctl(int *name, u_int namelen, void *oldp, size_t *oldlenp, void *newp,
@@ -723,6 +724,11 @@ hw_sysctl(int *name, u_int namelen, void *oldp, size_t
allowpowerdown));
return (sysctl_int(oldp, oldlenp, newp, newlen,
&allowpowerdown));
+#ifndefSMALL_KERNEL
+ case HW_KBDVOLUME:
+ return (sysctl_int(oldp, oldlenp, newp, newlen,
+ &kbdvolume));
+#endif
default:
return (EOPNOTSUPP);
}
Re: pckbd volume keys (part 2): knob to pass keystrokes
> this diff applies on top of the previous one; it adds the > hw.kbdvolume sysctl(1) entry to select how pckbd & ukbd volume keys > are handled: > > hw.kbdvolume=0 > > pass keystrokes to upper layer as we do for regular keys, > thus usable by X apps as hot-keys or whatever. > > hw.kbdvolume=1 > > change the ouputs.master control of the first audio device, > keystrokes are consumed by the kernel and not visible by > userland. This is the default, as this is the behavior of > all other (acpi, macppc, ... ) volume keys. This approach is simplestic and wrong.
Re: Question and regression test for strftime adn wcsftime
On Tue, Apr 22, 2014 at 11:43:21PM +0200, Stefan Sperling wrote:
I think a better step forward for LC_TIME support would be to focus on
nl_langinfo() first and make it return locale-specific data for LC_TIME.
The functions you're looking at are icing on the cake. We should be
looking at adding more LC_TIME foundations first.
nl_langinfo, strftime and wcsftime are ready to use any LC_TIME in
their current shape.
However they use different structures (_TimeLocale in the case
of nl_langinfo, lc_time_T using char in the case of strftime and
lc_time_T but using wchar_t in the case of wcsftime).
The attached patch unifies the structure that these 3 functions
use. The unified one will be the structure _TimeLocale declared in
sys/sys/localedef.h but reordering it and adding the field date_fmt
to match lc_time_T (in this it will be easier to read locales
I have prepared and will send later).
The function to read the locales will be based on the function _loc
currently defined in strftime.c but since it is generic for the moment
I'm removing from strftime.c and in another patch I will reintroduce it.
How and where do you intend to store locale-specific LC_TIME data?
Do you intend to copy FreeBSD's format?
An alternative (but more work) would be to implement a localedef
utility and switch locale definition data to the format specified
by POSIX. I'm not sure how widespread the localedef format really is.
But having a data format that follows the same spec as the functions
using the data might be easier to maintain in the long term.
Your regression test has at least one bug ('bad' is never initialised).
> diff -ruN src56-orig/regress/lib/libc/time/Makefile
src/regress/lib/libc/time/Makefile
> --- src56-orig/regress/lib/libc/time/Makefile Tue Jan 20 11:47:55 2004
> +++ src/regress/lib/libc/time/Makefile Thu Apr 17 08:37:20 2014
> @@ -1,5 +1,5 @@
> # $OpenBSD: Makefile,v 1.1 2004/01/20 16:47:55 millert Exp $
>
> -SUBDIR+=strptime
> +SUBDIR+=ftime strptime
>
> .include
> diff -ruN src56-orig/regress/lib/libc/time/ftime/Makefile
src/regress/lib/libc/time/ftime/Makefile
> --- src56-orig/regress/lib/libc/time/ftime/MakefileWed Dec 31
19:00:00 1969
> +++ src/regress/lib/libc/time/ftime/Makefile Thu Apr 17 08:37:05 2014
> @@ -0,0 +1,11 @@
> +
> +NOMAN=
> +PROG=check_ftime
> +
> +CFLAGS=-g
> +
> +
> +run-regress-check_ftime: ${PROG}
> + ./${PROG} >/dev/null
> +
> +.include
> diff -ruN src56-orig/regress/lib/libc/time/ftime/check_ftime.c
src/regress/lib/libc/time/ftime/check_ftime.c
> --- src56-orig/regress/lib/libc/time/ftime/check_ftime.c Wed Dec 31
19:00:00 1969
> +++ src/regress/lib/libc/time/ftime/check_ftime.c Thu Apr 17 11:46:19 2014
> @@ -0,0 +1,268 @@
> +/**
> + * Public domain according to Colombian Legislation.
> + * http://www.pasosdejesus.org/dominio_publico_colombia.html
> + * 2014. vtam...@pasosdejesus.org
> + *
> + * $OpenBSD$
> + */
> +
> +#include
> +#include
> +#include
> +
> +int bad;
> +
> +#define p(t) printf("%s:\t ",#t); \
> + if (t) { \
> + printf("\x1b[38;5;2mOK\x1b[0m\n"); \
> + } else { \
> + bad++; \
> + printf("\x1b[38;5;1mERROR\x1b[0m\n"); \
> + }
> +
> +
> +void test_ftime_posix()
> +{
> + char nom[256];
> + char col[512];
> + wchar_t wcol[512];
> + char *nl;
> + char *enc[]= { "ISO8859-1", "ISO8859-15", "UTF-8" };
> + struct lconv *p;
> + struct tm tl;
> + int i;
> + time_t ti;
> + long ts;
> + for(i = 0; i < sizeof(enc) / sizeof(char *) ; i++) {
> + snprintf(nom, sizeof(nom), "POSIX.%s", enc[i]);
> + printf("nom=%s\n", nom);
> + nl = setlocale(LC_ALL, nom);
> + printf("locale %s\n", nl);
> + p = localeconv();
> + ti = (time_t)139695; //Tue Apr 8 09:40:00 2014
> + gmtime_r(&ti, &tl) ;
> + /*p = strptime("", "", &tm); */
> + strftime(col, sizeof(col), "%A", &tl);
> + p(strcmp(col, "Tuesday") == 0);
> + wcsftime(wcol, sizeof(wcol), L"%A", &tl);
> + p(wcscmp(wcol, L"Tuesday") == 0);
> +
> + strftime(col, sizeof(col), "%a", &tl);
> + p(strcmp(col, "Tue") == 0);
> + wcsftime(wcol, sizeof(wcol), L"%a", &tl);
> + p(wcscmp(wcol, L"Tue") == 0);
> +
> + strftime(col, sizeof(col), "%B", &tl);
> + p(strcmp(col, "April") == 0);
> + wcsftime(wcol, sizeof(wcol), L"%B", &tl);
> + p(wcscmp(wcol, L"April") == 0);
> +
> + strftime(col, sizeof(col), "%b", &tl);
> + p(strcmp(col, "Apr") == 0);
> + wcsftime(wcol, sizeof(wcol), L"%b", &tl);
> + p(wcscmp(wcol, L"Apr") == 0);
> +
> + strftime(col, sizeof(col), "%C", &tl);
> + p(strcmp(col, "20") == 0);
> + wcsftime(wcol, sizeof(wcol), L"%C", &tl);
> + p(wcscmp(wcol, L"20") == 0);
> +
> + strftime(col, sizeof(col), "%c", &tl);
> + printf("%s\n", col);
> + p(strcmp(col, "Tue Apr 8 09:40:00
Re: IPv6 by default
previously on this list Stuart Henderson contributed: > My thinking is that *if* someone has taken steps to enable v6, > then programs should try to use it for comms where possible. > "family inet6 inet4" is too blunt and affects people who don't want > to touch v6. I'm used to seeing NOINET6 in ifconfig and just realised it isn't set on this machine :-( still it's blocked by PF :-) If a user says none to ipv6 address in the installer why not set things appropriately. It occured to me that /etc/rc has PF settings that a default ipv6 block may prevent initial machine accessibility? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___
Re: IPv6 by default
On 04/30/14 00:12, Ted Unangst wrote: On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote: 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. Good point. I think I was tricked by your proposal into thinking the current code did something else. Even so, I have a new objection. :) This will introduce a lot of strange effects based on whether the second response arrives in time or not. I would not want to debug this. However, doing the requests in parallel, each geting the same treatment as if done in sequence (timing out if need be, etc), and then sort them by the family directive as per resolv.conf could in theory cut the lookup time in half... And of course, here's a diff for that: Oh, crap. The cat ate it. Sorry. /Alexander
Re: IPv6 by default
On 04/30/14 01:45, Alexander Hall wrote: However, doing the requests in parallel, each geting the same treatment as if done in sequence (timing out if need be, etc), and then sort them by the family directive as per resolv.conf could in theory cut the lookup time in half... Not that this has anything to do with the original subject.
Re: patch: use a lookup table in BIO_get_port()
Don't bother with diffs to b_sock.c. Instead, if you have code
which uses it, talk to krw.
There is a monster diff coming which rewrites it all.
And by the way, all that code disapears and is replaced by 2 lines.
> Not sure this is sensible as it encourages people to simply
> update the table.
>
> I was inclined to remove the code entirely but I am not sure
> what broken systems might rely on this.
>
> Only build tested.
>
> Thoughts?
>
> Index: b_sock.c
> ===
> RCS file: /cvs/src/lib/libssl/src/crypto/bio/b_sock.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 b_sock.c
> --- b_sock.c 26 Apr 2014 18:56:37 - 1.33
> +++ b_sock.c 29 Apr 2014 13:55:39 -
> @@ -140,6 +140,19 @@ BIO_get_port(const char *str, unsigned s
> {
> int i;
> struct servent *s;
> + size_t len;
> + struct {
> + const char *name;
> + int port;
> + } servmap[] = {
> + { "http", 80 },
> + { "telnet", 23 },
> + { "socks", 1080 },
> + { "https", 443 },
> + { "ssl",443 },
> + { "ftp",21 },
> + { "gopher", 70 }
> + };
>
> if (str == NULL) {
> BIOerr(BIO_F_BIO_GET_PORT, BIO_R_NO_PORT_DEFINED);
> @@ -155,21 +168,14 @@ BIO_get_port(const char *str, unsigned s
> *port_ptr = ntohs((unsigned short)s->s_port);
> CRYPTO_w_unlock(CRYPTO_LOCK_GETSERVBYNAME);
> if (s == NULL) {
> - if (strcmp(str, "http") == 0)
> - *port_ptr = 80;
> - else if (strcmp(str, "telnet") == 0)
> - *port_ptr = 23;
> - else if (strcmp(str, "socks") == 0)
> - *port_ptr = 1080;
> - else if (strcmp(str, "https") == 0)
> - *port_ptr = 443;
> - else if (strcmp(str, "ssl") == 0)
> - *port_ptr = 443;
> - else if (strcmp(str, "ftp") == 0)
> - *port_ptr = 21;
> - else if (strcmp(str, "gopher") == 0)
> - *port_ptr = 70;
> - else {
> + len = sizeof(servmap) / sizeof(servmap[0]);
> + for (i = 0; i < len; i++) {
> + if (strcmp(str, servmap[i].name) == 0) {
> + *port_ptr = servmap[i].port;
> + break;
> + }
> + }
> + if (i == len) {
> SYSerr(SYS_F_GETSERVBYNAME, errno);
> ERR_asprintf_error_data("service='%s'", str);
> return (0);
>
Re: IPv6 by default
> I know that what I proposed cannot go in at the moment. It's my end > goal. The goal is ridiculous. If anything, it should be sorted by the "best addresses first". Today the best addresses are IPv4. There is no dynamic method to determine "best", but measurements all over the world show that IPv4 is better in every respect. Change that, then we can talk.
Re: Switch getopt example to getprogname()
> > Date: Tue, 29 Apr 2014 11:31:48 +0200 > > From: Tristan Le Guern > > > > Hi, > > > > This patch for /usr/share/misc/getopt enforces the use of getprogname() > > instead of __progname. > > > > Is this desirable? If so I also have a patch for style(9). > > getprogname(3) isn't really more portable than __progname, and the > latter is probably slightly more efficient (smaller code). So I don't > really see the point. getprogname(3) has the potential to be more portable, so I think the suggestion is valid.
Re: IPv6 by default
> Someone has to take the first/next step, and that's a very > traditional role for OpenBSD. Apply these kinds of changes to your entire production network, and report back in 6 months if you are still running them.
vfs references to strncpy and MFSNAMELEN
The constant MFSNAMELEN as defined in: lib/libc/sys/getfsstat.2:#define MFSNAMELEN 16 lib/libc/sys/statfs.2:#define MFSNAMELEN 16 sys/sys/mount.h: #define MFSNAMELEN 16 defines the fs type name and, according to comments, it includes nul terminating character. The following code makes uses of strncpy and involves MFSNAMELEN ./sys/kern/vfs_subr.c:225: strncpy(mp->mnt_stat.f_fstypename, vfsp->vfc_name, MFSNAMELEN); ./sys/kern/vfs_subr.c:2272: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/kern/vfs_syscalls.c:243: strncpy(mp->mnt_stat.f_fstypename, vfsp->vfc_name, MFSNAMELEN); ./sys/miscfs/procfs/procfs_vfsops.c:190:strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/msdosfs/msdosfs_vfsops.c:669: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/nfs/nfs_vfsops.c:646: strncpy(&mp->mnt_stat.f_fstypename[0], mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/ntfs/ntfs_vfsops.c:628: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/ufs/ext2fs/ext2fs_vfsops.c:704: strncpy(sbp->f_fstypename, mp->mnt_vfc->vfc_name, MFSNAMELEN); ./sys/ufs/mfs/mfs_vfsops.c:222: strncpy(&sbp->f_fstypename[0], mp->mnt_vfc->vfc_name, MFSNAMELEN); Can be those replace safely by strlcpy without any modification to MFSNAMELEN constant?
Re: IPv6 by default
On Tue 29 Apr 2014 09:04:36 PM CDT, Theo de Raadt wrote: I know that what I proposed cannot go in at the moment. It's my end goal. The goal is ridiculous. If anything, it should be sorted by the "best addresses first". Today the best addresses are IPv4. There is no dynamic method to determine "best", but measurements all over the world show that IPv4 is better in every respect. Change that, then we can talk. ... Apply these kinds of changes to your entire production network, and report back in 6 months if you are still running them. You're right for almost all residential customers today and most business customers of incumbent providers. However, based on available evidence, IPv4 is not better than IPv6 in every respect for everyone. My IPv6 transit is free, and runs at 1Gbit/sec. (Thank you, Hurricane Electric. Yes, I know this will change someday.) My IPv4 transit is definitely not free, and runs at 100Mbit/sec. I have a /48 of IPv6 addresses, whereas I have only a /24 of IPv4 addresses. Both address blocks cost the same amount; the $/IP ratio is clear. IPv6 is clearly better for me, because I've taken steps to obtain native IPv6 transport. That fact skews my results. My own measurements show that for many services, Amazon's cloud being a notable example, native IPv6 provides noticeably lower latency than IPv4 - even when taking the same AS path. IPv4 routes tend to have higher hop-counts than the corresponding IPv6 routes. Using cpercival's tarsnap service as a test endpoint: from my workstation, the IPv4 route is 15 hops long and exhibits RTT in the 54msec range, whereas the IPv6 route is 9 hops long and 33msec. Google's public DNS servers are 13 [v4] vs. 11 [v6] hops and identical latency (32msec). Akamai is 8 [v4] vs. 6 [v6] hops, and nearly-identical latency, once I get past the local cache. My data (not just these two examples) shows native IPv6 having a noticeable performance advantage over IPv4. (It's not because of the 1Gb/100Mb links, either; my workstation is at the far end of a 20Mbit radio link from my routers.) In every case I can find, IPv6 is now at least as good as IPv4, and is often "better in every respect". That conclusion does still flip 180 degrees around, for obvious reasons, when the only IPv6 connectivity is through a tunnel. I've been fully[*] dual-stacked for almost a year, and well over a year since I started preferring my IPv6 tunnel wherever possible. The redundant OpenBSD-based BGP routers were installed October 26th 2013 and were routing IPv6 shortly thereafter. The topology has changed several times over that period of time, and the addition of IPv6 has not created problems for me any more significant than IPv4 has. (Renumbering is exactly as much a PITA in v6 as v4, despite what some optimists still claim.) Yes, I have had to choose software that supports IPv6, but that's not difficult nowadays... the lack of DHCPv6 in base OpenBSD is the only major gap that I've had trouble filling. Overall, OpenBSD supports IPv6 extremely well, more than well enough to run my network, which is why I don't understand the determination to passive-agressively not endorse it. I don't know anyone who seriously believes, by this point, that IPv6 is not going to take over eventually. Yes, the entire industry is doomed to repeat its mistakes, that's blazingly obvious. Yes, IPv6 has some serious flaws, and as a protocol suite, it sucks rocks in many ways. Does that mean you have to actively resist fostering IPv6 adoption? OpenBSD is already the only free OS that handles IPv6 fragmentation "correctly"... and it certainly wouldn't be the first OS to prefer IPv6. (That would actually be Windows Vista, I believe. OK, that's not a glowing endorsement...) [*] except for one software management console that doesn't support IPv6 at all. My printers, my WiFi APs, even my CEPH cluster are all IPv6-native. The worst network-stack stupidity I've seen so far was on the WiFi AP, and it only affected IPv4. -- -Adam Thompson athom...@athompso.net
Re: IPv6 by default
> However, based on available evidence, IPv4 is not better than IPv6 in > every respect for everyone. You've written a long mail and completely missed the point. This is not a conversation about your IPv6 connection. It is about what the sensible default should be for everyone.
iked dynamic address configuration
This is a new and improved patch to add dynamic address allocation support
to iked. Includes an update to the man page, and a simpler implementation
then my previous work.
- An address pool is globally defined as "pool ", and
referenced from a policy with "pool ". (If this patch finally gets
traction, I'd like to make setting up a typical roadwarrior vpn is even
simpler by adding a feature that creates a pool mirroring the policy's
first flow's "to" range.)
- A request for a specific address that is available in the pool will be
honoured (ie Win7 static IP)
- There is a hard limit of 65536 addresses (8kb) per pool, which should be
plenty, and makes the code simpler.
- Configuration changes to live address pools work. Allocated addresses
stay allocated so long as they fall inside the updated range, but not if
they become in range of some other pool.
- "ikectl reset all" will drop all pools. If there is a usecase for it, I
can add a "reset pool" to just drop all pools.
Testing has thus far been limited to Windows 7.
--Ryan Slack
Index: config.c
===
RCS file: /cvs/src/sbin/iked/config.c,v
retrieving revision 1.22
diff -u -p -r1.22 config.c
--- config.c 28 Nov 2013 20:28:34 - 1.22
+++ config.c 30 Apr 2014 02:57:33 -
@@ -22,6 +22,8 @@
#include
#include
+#include
+
#include
#include
#include
@@ -89,6 +91,10 @@ config_free_sa(struct iked *env, struct
if (sa->sa_policy) {
(void)RB_REMOVE(iked_sapeers, &sa->sa_policy->pol_sapeers, sa);
policy_unref(env, sa->sa_policy);
+
+ if(sa->sa_policy->pol_addr_pool[0] != '\0')
+ addr_pool_release(env,sa->sa_policy->pol_addr_pool,
+ &sa->sa_cfg_peer.cfg.address.addr);
}
ikev2_msg_flushqueue(env, &sa->sa_requests);
@@ -376,6 +382,87 @@ config_new_user(struct iked *env, struct
return (usr);
}
+struct iked_addr_pool*
+config_new_addr_pool(struct iked *env, struct iked_addr_pool *new)
+{
+ struct iked_addr_pool *pool,*old;
+ struct iked_sa *sa;
+ int i;
+ struct sockaddr_storage *ss_addr;
+ struct in_addr *a4;
+ struct in6_addr *a6;
+
+ if (!(new->pool_size && new->pool_size < IKED_ADDR_POOL_SIZE_MAX
+ && new->pool_name[0] && new->pool_af)) {
+ log_warnx("%s: required values missing", __func__);
+ return (NULL);
+ }
+
+ if ((pool = calloc(1, sizeof(*pool))) == NULL)
+ return (NULL);
+
+ memcpy(pool, new, sizeof(*pool));
+
+ if ((pool->pool_used = bit_alloc(pool->pool_size)) == NULL)
+ goto fail;
+ bit_set(pool->pool_used, 0);
+
+ if ((old = RB_INSERT(iked_addr_pools, &env->sc_pools, pool)) != NULL) {
+ log_debug("%s: updating address pool '%s'", __func__,
+ pool->pool_name);
+
+ if(old->pool_size) free(old->pool_used);
+ free(old);
+
+ } else {
+ log_debug("%s: inserting new address pool '%s'", __func__,
+ pool->pool_name);
+ }
+
+ RB_FOREACH(sa, iked_sas, &env->sc_sas) {
+ ss_addr = &sa->sa_cfg_peer.cfg.address.addr;
+ if (ss_addr->ss_family != pool->pool_af ||
+ sa->sa_cfg_peer.cfg_action != IKEV2_CP_REPLY ||
+ strcmp(sa->sa_policy->pol_addr_pool, pool->pool_name))
+ continue;
+
+ switch (pool->pool_af) {
+ case AF_INET:
+ a4 = &((struct sockaddr_in *)ss_addr)->sin_addr;
+ i = betoh32(a4->s_addr) - betoh32(pool->pool_start[3]);
+ break;
+ case AF_INET6:
+ a6 = &((struct sockaddr_in6*)ss_addr)->sin6_addr;
+ if(memcmp(a6->s6_addr, pool->pool_start, 12)) i = -1;
+ else i = betoh32(a6->s6_addr[3]) -
+ betoh32(pool->pool_start[3]);
+ break;
+ default:
+ log_warnx("%s: invalid address family", __func__);
+ goto fail;
+ }
+
+ if (0 <= i && (uint32_t)i < pool->pool_size) {
+ bit_set(pool->pool_used, i);
+ }
+ }
+
+ return pool;
+ fail:
+ if(pool->pool_size) free(pool->pool_used);
+ free(pool);
+ return (NULL);
+}
+
+int
+config_free_addr_pool(struct iked *env, struct iked_addr_pool* pool)
+{
+ RB_REMOVE(iked_addr_pools, &env->sc_pools, pool);
+ if(pool->pool_size) free(pool->pool_used);
+ free(pool);
+ return (0);
+}
+
/*
* Inter-process communication of configuration items.
*/
@@ -442,6 +529,7 @@ config_getreset(struct iked *env, struct
struct iked_policy *pol, *nextpol;
struct iked_sa *sa, *nextsa;
struct iked_user *usr, *nextusr;
+ struct iked_addr_pool *pool, *nextpool;
u_int mode;
IMSG_SIZE_CHECK(imsg, &mode);
@@ -475,6 +563,16 @@ config_getreset(struct iked *env, struct
}
}
+ if (mode == RESET_ALL || mode == RESET_ADDR_POOL) {
+ log_debug("%s: flushing address pools", __func__);
+ for (pool = RB_MIN(iked_addr_pools, &env->sc_pools);
+ pool != NULL; pool = nextpool) {
+ nextpool = RB_NEXT(iked_addr_pools, &env->sc_pools,
+ pool);
+ config_free_addr_pool(env, pool);
+ }
+ }
+
return (0);
}
@@ -577,6 +675,35 @@ config_getuser(struct iked *env, struct
return (-1);
print_user(&usr);
+
+ return (0);
+}
+
+int
+config_setaddrpool(struct iked *env, struct iked_addr_pool *pool,
+enum privsep_procid id)
+{
+ if (env->sc_opts & IKED_OPT_N
