Le 2014-07-15 09:51, Antoine Jacoutot a écrit :
+unbound-cntl 8953/tcp# Unbound validating,
recursive, and caching DNS server control
The IANA name for this port is ub-dns-control.
Le 2014-05-02 04:13, Jérémie Courrèges-Anglas a écrit :
I don't like AI_ADDRCONFIG. It's useless as specified, and making it
useful requires interpretations and deviations.
Can you justify this? Sounds to me like a blanket statement as it is.
My understanding is that its goal is to solve a
Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit :
Let's say you have a machine with no IPv6 address configured (or rather,
only link-local addresses configured and ::1 on lo0). With the
AI_ADDRCONFIG flag (either set explicitely or assumed if the caller
passes no hints structure):
-
I think I have already addressed all your points below, no need to
rehash endlessly. I'll let others chime in.
I'm still very interested in any real-world problems this might have caused.
Simon
Le 2014-05-02 11:35, Jérémie Courrèges-Anglas a écrit :
Simon Perreault si...@per.reau.lt writes
Le 2014-05-02 13:19, Jérémie Courrèges-Anglas a écrit :
Some bugs:
- https://sourceware.org/bugzilla/show_bug.cgi?id=12398
- http://article.gmane.org/gmane.comp.freedesktop.xcb/6973
- https://svn.boost.org/trac/boost/ticket/8503
Links with more information:
-
Le 2014-04-29 22:04, Theo de Raadt a écrit :
measurements all over the world show that IPv4 is better
in every respect.
Not disagreeing, but I would like to have access to more data backing
this up. I'm not satisfied with what I found (see other post).
Change that, then we can talk.
Working
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
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
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].
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-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
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()
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
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
On Wed, Apr 23, 2014 at 12:02:44PM -0400, Simon Perreault wrote:
Will send an updated diff later today.
It is now later today (ha!) and here's the promised updated diff.
Changes:
- Simplified and embettered address filtering based on Stuart Henderson's
comments.
- Fixed manpage formatting
(I sent this diff to Éric Faurot on the 12th, but received no reply.)
Tech,
While everyone's having fun removing code from OpenSSL, I decided to add
some to libasr. I implemented AI_ADDRCONFIG, a getaddrinfo() flag
defined in RFC 2553/3493. Basically, it tells getaddrinfo() to skip IPvX
Le 2014-04-23 11:43, Stuart Henderson a écrit :
On 2014/04/23 08:09, Simon Perreault wrote:
+else if (ifa-ifa_addr-sa_family == PF_INET6
so... family is ipv6
+!IN6_IS_ADDR_LOOPBACK(
+((struct
Le 2012-09-02 08:05, Stefan Sperling a écrit :
Simon's recent commit to prevent SLAAC address formation when
a static address is already configured has a side-effect for
autoconfprivacy users.
With the following in /etc/hostname.if:
dhcp
rtsol
inet6 some-address 64
the netstart
Le 2012-08-14 20:29, David Gwynne a écrit :
ill have to fix that.
Oh, and I also realized that CBQ is even worse: it calls microuptime()
on every enqueue *and* every dequeue!
If it really was a bug, people would have noticed, no?
Simon
On 15/08/2012, at 3:31 AM, Simon Perreault sperrea
Le 2012-08-14 11:03, Ted Unangst a écrit :
On Tue, Aug 14, 2012 at 09:42, Simon Perreault wrote:
- CoDel needs to timestamp each packet when it gets queued.
- I added a new member in struct pkthdr for this. Is this ok?
- I end up calling microuptime() for each packet. Is this ok?
You want
Le 2012-08-14 12:12, Ted Unangst a écrit :
Five years ago I removed a once per packet microuptime call which led
to something like a 33% improvement in throughput. I don't want to
have to do that again. :)
Hey I just realized that hfsc calls microuptime() for every single
packet at dequeue
it? These
changes will really help someone first time trying the sample code, I think.
Credit should be given to Simon Perreault, I just did what he suggested.
You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS,
IPV6_DSTOPTS, and IPV6_RTHDR. The RECV part was added to them in RFC3542.
Simon
On 2012-01-13 12:13, Fernando Gont wrote:
If you do not keep state, then.
1) If you don't get any further fragments, you saved memory and other
resources, or,
2) If you do get other fragments, they'll be queued, and since other
fragments were dropped, there won't be any reassembled datagram, and
On 01/12/2012 03:39 AM, Fernando Gont wrote:
Do we want this in our stack although it is not an RFC yet?
Or perhaps only in pf for extra security?
I should note that an RFC can take at least a year to publish (if ever).
We should not wait for an RFC. We should wait for a consensus to emerge.
PMTUD can only lower TCP MSS (either the default one or the one
advertised by the peer), not raise it. This is how it was originally but
it regressed at some point. The comments still mention the correct
behaviour, but the code doesn't do what the comments say. This diff
fixes that.
Please
Hello,
This patch makes remote debugging with KGDB possible. It fixes a known bug, see
e.g. http://kerneltrap.org/mailarchive/openbsd-misc/2008/10/7/3537224.
Simon
P.S. This is my first contribution, please tell me if I did anything wrong.
Index: sys/dev/isa/com_isa.c
26 matches
Mail list logo
