Le 2014-07-15 09:51, Antoine Jacoutot a écrit :
+unbound-cntl 8953/tcp# Unbound validating,
recursive, and caching DNS server control
The IANA name for this port is "ub-dns-control".
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-number
Le 2014-05-02 13:19, Jérémie Courrèges-Anglas a écrit :
> Some bugs:
> - https://sourceware.org/bugzilla/show_bug.cgi?id=12398
> - http://article.gmane.org/gmane.comp.freedesktop.xcb/6973
> - https://svn.boost.org/trac/boost/ticket/8503
>
> Links with more information:
> - http://fedoraproject.org
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 writes:
>
Le 2014-05-02 10:48, Jérémie Courrèges-Anglas a écrit :
> Let's say you have a machine with no IPv6 address configured (or rather,
> only link-local addresses configured and ::1 on lo0). With the
> AI_ADDRCONFIG flag (either set explicitely or assumed if the caller
> passes no hints structure):
>
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-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.
Workin
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
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
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
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].
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
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 manpa
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
>
>> +
(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
looku
Le 2014-01-26 11:27, Christian Weisgerber a écrit :
Over IPv6, UDP packets must have a non-zero checksum (RFC2460,
section 8.1).
That is no longer true.
http://tools.ietf.org/html/rfc6935#section-5
VXLAN and friends use zero UDP checksums over IPv6.
Simon
Le 2012-09-17 12:57, csszep a écrit :
Do you have any plans for similar changes in the OpenBSD IPv6 stack?
http://svn.freebsd.org/changeset/base/204798
I have no such plans, but the changes do make sense IMHO.
Simon
Le 2012-09-02 08:05, Stefan Sperling a écrit :
Simon's recent commit to prevent SLAAC address formation when
a static address is already configured has a side-effect for
autoconfprivacy users.
With the following in /etc/hostname.if:
dhcp
rtsol
inet6 some-address 64
the netstart script
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 wrote
Le 2012-08-14 12:12, Ted Unangst a écrit :
Five years ago I removed a once per packet microuptime call which led
to something like a 33% improvement in throughput. I don't want to
have to do that again. :)
Hey I just realized that hfsc calls microuptime() for every single
packet at dequeue ti
Le 2012-08-14 11:03, Ted Unangst a écrit :
On Tue, Aug 14, 2012 at 09:42, Simon Perreault wrote:
- CoDel needs to timestamp each packet when it gets queued.
- I added a new member in struct pkthdr for this. Is this ok?
- I end up calling microuptime() for each packet. Is this ok?
You want to
Hi tech@,
I started implementing CoDel[1] in altq, as an alternative to RED. It's based on
the Linux implementation, which is dual-licensed GPL/BSD. I'm looking for early
feedback (design, big issues, etc.). Work-in-progress diff is below.
The big issues I see are:
- CoDel needs to timestamp eac
ok over it? These
changes will really help someone first time trying the sample code, I think.
Credit should be given to Simon Perreault, I just did what he suggested.
You can expect the same issue with IPV6_PKTINFO, IPV6_HOPOPTS,
IPV6_DSTOPTS, and IPV6_RTHDR. The "RECV" part was added
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.
On 2010-04-19 08:31, Gregory Edigarov wrote:
sometimes it is better and necessary to have interfaces named under one
standartized name like fether0... fetherN for example
Why? And how can groups not accomplish that?
Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN serv
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 te
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
==
30 matches
Mail list logo