The kernel rejects IPv6 destination addresses on point-to-point
interfaces if the prefixlen is not 128. Because ifconfig defaults
to prefixlen 64, configuring IPv6 on e.g. gif(4) requires an
explicit prefix length, for instance:
ifconfig gif0 inet6 ADDR1 ADDR2 prefixlen 128
Without prefixlen w
Jonathan Gray wrote:
> On Sat, Jun 24, 2017 at 11:20:00AM +1000, Jonathan Gray wrote:
> > On Sat, Jun 24, 2017 at 03:00:19AM +0200, Mark Kettenis wrote:
> > > The code doesn't fully initialize the structure, which was extended to
> > > include a flags member at some point. Since the pending inteld
On Fri, Jun 23, 2017 at 10:08:26PM +0800, Jia-Ju Bai wrote:
> Hi,
>
> I am a freshman in developing OpenBSD drivers, and I have a question in
> lock usage in OpenBSD kernel code.
>
> I only find two kinds of locks which are often used in OpenBSD drivers,
> namely "mutex lock" and "rw lock". I wan
On Sat, Jun 24, 2017 at 11:20:00AM +1000, Jonathan Gray wrote:
> On Sat, Jun 24, 2017 at 03:00:19AM +0200, Mark Kettenis wrote:
> > The code doesn't fully initialize the structure, which was extended to
> > include a flags member at some point. Since the pending inteldrm
> > update uses that flags
On Sat, Jun 24, 2017 at 03:00:19AM +0200, Mark Kettenis wrote:
> The code doesn't fully initialize the structure, which was extended to
> include a flags member at some point. Since the pending inteldrm
> update uses that flags member, the DRM_IOCTL_I915_GEM_MMAP ioctl
> starts randomly failing be
NIFS is checked inside start_cgiinfo() already, this nicely aligns with
the rest of the list in do_install().
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1015
diff -u -p -r1.1015 ins
Ingo Schwarze writes:
> Hi Jason,
>
> Jason McIntyre wrote on Thu, Jun 22, 2017 at 02:07:51PM +0100:
>
> > so do you want to remove the entry for 1003.1-2013 as well?
> > none of our man pages use it.
>
> The decisive point is that even current groff does not support it,
> so deleting it is unli
The code doesn't fully initialize the structure, which was extended to
include a flags member at some point. Since the pending inteldrm
update uses that flags member, the DRM_IOCTL_I915_GEM_MMAP ioctl
starts randomly failing because the flags member contains stack
garbage. The diff below fixes th
Hello,
I've got just one nit, which is probably overcautious, so I don't insist:
> @@ -231,8 +245,16 @@ void
> pf_free_fragment(struct pf_fragment *frag)
> {
> struct pf_frent *frent;
> + struct pf_frnode*frnode;
>
> - RB_REMOVE(pf_frag_tree, &pf_frag_tree, frag)
On Fri, Jun 23, 2017 at 07:33:40PM +0200, Ingo Schwarze wrote:
> Hi Jason,
>
> Jason McIntyre wrote on Fri, Jun 23, 2017 at 06:24:17PM +0100:
>
> > yes, i'm fine with removing it.
>
> Good, i'll commit it unless i hear objections.
>
> > i hate to say it, but i think it was you who added it!
>
Hi Jason,
Jason McIntyre wrote on Fri, Jun 23, 2017 at 06:24:17PM +0100:
> yes, i'm fine with removing it.
Good, i'll commit it unless i hear objections.
> i hate to say it, but i think it was you who added it!
RCS file: /cvs/src/usr.bin/mandoc/st.in,v
revision 1.17
date: 2013/12/30 09:47:43;
On Fri, Jun 23, 2017 at 07:05:34PM +0200, Ingo Schwarze wrote:
> Hi Jason,
>
> Jason McIntyre wrote on Thu, Jun 22, 2017 at 02:07:51PM +0100:
>
> > so do you want to remove the entry for 1003.1-2013 as well?
> > none of our man pages use it.
>
> The decisive point is that even current groff does
Hi Jason,
Jason McIntyre wrote on Thu, Jun 22, 2017 at 02:07:51PM +0100:
> so do you want to remove the entry for 1003.1-2013 as well?
> none of our man pages use it.
The decisive point is that even current groff does not support it,
so deleting it is unlikely to break other's pages.
OK?
Ingo
Hi,
I am a freshman in developing OpenBSD drivers, and I have a question in
lock usage in OpenBSD kernel code.
I only find two kinds of locks which are often used in OpenBSD drivers,
namely "mutex lock" and "rw lock". I want to know which lock can be held
when the current thread can sleep.
From
On 2017/06/23 16:19, Theo Buehler wrote:
> I understood 'manual upgrades' to be 'upgrading without the install
> kernel', as described in upgradeXX.html. The link kit is in baseXX.tgz
> and will be extracted with it. So you will end up runnig what you
> intended to run.
It can't work at the point.
> The "problem" with Theo (Buehler)'s approach is that that next boot
> will still not use a relinked kernel,
Any kernel you build is randomly linked. So yes, the next boot is
using a unique kernel. The distinction "relinked kernel" doesn't make
sense.
> so you need yet another reboot to relink
On Fri, Jun 23, 2017 at 07:53:35AM -0600, Theo de Raadt wrote:
> > Perhaps we'll come up with a simpler way down the road, but it isn't
> > *that* hard for manual upgrades. once you've installed the kernels, make
> > sure you've got the correct hash:
> >
> > sha256 -h /var/db/kernel.SHA256 /bs
On Fri, Jun 23, 2017 at 07:53:35AM -0600, Theo de Raadt wrote:
| > Perhaps we'll come up with a simpler way down the road, but it isn't
| > *that* hard for manual upgrades. once you've installed the kernels, make
| > sure you've got the correct hash:
| >
| > sha256 -h /var/db/kernel.SHA256 /bs
Dear team,
This patch adds support for the "graceful shutdown" well-known
community as described in draft-ietf-grow-bgp-gshut.
An example implementation would be to add the following to your
bgpd.conf:
match from any community GRACEFUL_SHUTDOWN set { localpref 0 }
Kind regards,
Job
---
e
Dear team,
This patch makes 'unknown' well-known communities more of a first-class
citizen.
A powerful property of well-known communities is that (often) operators
can implement the feature associated with a given well-known community
through their local routing policy, ahead of time before their
Dear team,
The lowest valid BGP LOCAL_PREF is 0, allowing bgpd to set 0 too will
accomodate interopability.
Kind regards,
Job
--- a/usr.sbin/bgpd/parse.y
+++ b/usr.sbin/bgpd/parse.y
@@ -1988,7 +1988,7 @@ filter_set_opt: LOCALPREF NUMBER {
}
> Perhaps we'll come up with a simpler way down the road, but it isn't
> *that* hard for manual upgrades. once you've installed the kernels, make
> sure you've got the correct hash:
>
> sha256 -h /var/db/kernel.SHA256 /bsd
>
> and the rc script will do the rest after the next reboot. I thin
Hi,
markus@ has seen problems with IPv4 fragments on high volume IPsec
tunnels. The fragment id gets reused to fast, this causes packet
loss and the situation does not recover. Details are in RFC 4963
"IPv4 Reassembly Errors at High Data Rates".
In ESP IPsec tunnels source/destination address a
On Fri, Jun 23, 2017 at 12:37:38PM +0200, Paul de Weerd wrote:
> On Fri, Jun 23, 2017 at 04:28:15AM -0600, Theo de Raadt wrote:
> | > /mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel
> | >
> | > ...
> | >
> | > + mail -Es "$(hostname) Kernel relink info" root >/dev
Hi,
Using relayd's redirect/forward on ipv6 addresses I discovered problems
relating to setting TTL.
There is no check for address family and setsockopt tries to apply IP_TTL
always.
Without ip ttl on ipv6 table, check_icmp gives
send_icmp: getsockopt: Invalid argument
With ip ttl on ipv6 tab
On Fri, Jun 23, 2017 at 04:28:15AM -0600, Theo de Raadt wrote:
| > /mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel
| >
| > ...
| >
| > + mail -Es "$(hostname) Kernel relink info" root >/dev/null
|
| No, that isn't cool.
|
| Yes, we are going to link in the insta
> /mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel
>
> ...
>
> + mail -Es "$(hostname) Kernel relink info" root >/dev/null
No, that isn't cool.
Yes, we are going to link in the install media. But not by reusing code
that way. Any chroot handling must be done mu
Hi tech@,
Remove unused confirm() and datime() functions.
Those functions are unused and have been compiled out since 1998,
it's time to let them go.
Comments? OK?
Index: games/adventure/io.c
===
RCS file: /cvs/src/games/adventure/
On Wed, Jun 21, 2017 at 01:13:31PM -0600, Theo de Raadt wrote:
| Future work should be to see if we can build a fresh kernel at
| install/upgrade time, for that "every computer is unique" feel.
How about we move the rc bits out from rc and into a small script
that we call from rc. Now we can also
On 23/06/17 04:43, David Gwynne wrote:
>
>> On 23 Jun 2017, at 01:15, Kapetanakis Giannis
>> wrote:
>>
>> Hi,
>>
>> Here is a patch for using alternative control socket for relayd and relayctl.
>> It's based on ospfd. I would like for this to get in order to be able to
>> control multiple relay
On Tue, Jun 06, 2017 at 09:51:53PM +1000, Jonathan Gray wrote:
> It turns out that despite RFC 6066 stating
> 'Literal IPv4 and IPv6 addresses are not permitted in "HostName".'
> for SNI the implementations of TLS in python and ruby do this.
>
> While chromium, firefox, lua(sec), java, go, ftp(1),
31 matches
Mail list logo
