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
trac
> 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.
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 determin
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 mak
> 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.
> > 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 po
> 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
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.
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 a
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
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
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 mo
> 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.kb
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
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 vol
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
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
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
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 wo
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
t
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
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 canno
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 be
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 a
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 I
> 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 count
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? Whiche
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
==
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
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
>
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
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 au
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 -00
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 reque
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() t
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 secon
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
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.
>
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()
sh
* 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:
>
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 p
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
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 wh
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
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].
* 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 c
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
* 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
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
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 hel
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 p
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
=
> 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
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 revisio
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 Henders
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 lik
* 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 defau
57 matches
Mail list logo
