+ return sysctl_int(oldp, oldlenp, newp, newlen, &dnsjacking);
+int dnsjacking = 0;
+ sin.sin_port = htons(dnsjacking);
How about using u_int16_t or in_port_t; and maybe error out if high
bits are set rather than ignoring them but still displaying them.
Ted Unangst wrote:
> Ted Unangst wrote:
> > So the plan is for rebound to be the 'system' resolver, with libc talking to
> > rbeound and rebound talking to the cloud. The main wrinkle is how does
> > rebound
> > find the cloud? rebound.conf, but dhclient doesn't know anything about
> > rebound.con
"Dmitrij D. Czarkoff" wrote:
>"Dmitrij D. Czarkoff" wrote:
>
>>"Dmitrij D. Czarkoff" wrote:
>>
>>>Claus Assmann wrote:
>>>
AFAICT the "percentage of disk" is optional
>>>
>>>disklabel(8) says:
>>>
>>>| A template for the automatic allocation can be passed \
>>>| to disklabel using
>>>| the
"Dmitrij D. Czarkoff" wrote:
>"Dmitrij D. Czarkoff" wrote:
>
>>Claus Assmann wrote:
>>
>>>AFAICT the "percentage of disk" is optional
>>
>>disklabel(8) says:
>>
>>| A template for the automatic allocation can be passed \
>>| to disklabel using
>>| the -T option. The template consists of one li
"Dmitrij D. Czarkoff" wrote:
>Claus Assmann wrote:
>
>>AFAICT the "percentage of disk" is optional
>
>disklabel(8) says:
>
>| A template for the automatic allocation can be passed \
>| to disklabel using
>| the -T option. The template consists of one line per partition, with
>| each line giving
Claus Assmann wrote:
>AFAICT the "percentage of disk" is optional
disklabel(8) says:
| A template for the automatic allocation can be passed to disklabel using
| the -T option. The template consists of one line per partition, with
| each line giving mountpoint, min-max size range, and percenta
I could have an answer that this compilation error was a bug of compiler,
and that bug will be tracked.
https://software.intel.com/en-us/forums/intel-c-compiler/topic/698109
I saw the type of buf was changed in cvs,
then I can avoid this compilation problem.
Thanks.
Kinichiro
While playing around with the autoinstaller and autodisklayout I
ran into several problems, some of which I worked around and for
one I created a possible patch, but I'm not sure if that's the right
thing to do.
I have a disklayout template like this:
/ 500M
swap1G
/tmp1G-2G
/var
On Sat, 24 Sep 2016 10:58:10 +0200
Vincent Gross wrote:
> Hi,
>
[snip]
>
> Aside from the mbuf issue, is this Ok ?
I will go back on the mbuff stuff later.
Diff rebased, ok anyone ?
Index: net/if_vxlan.c
===
RCS file: /cvs/src/s
On Sun, Oct 2, 2016 at 1:55 AM, David Gwynne wrote:
> i think the change to move tcp timers to timeouts got this bit wrong.
>
> we do want to print the timer if it is pending, it doesnt make sense
> otherwise.
...
> --- trpt.c 27 Aug 2016 01:50:07 - 1.33
> +++ trpt.c 2 Oct 2016
> > I stumbled upon unexpected behavior on OpenBSD 6.0 (all patches)
> > which seems to allow running commands as the original user when
> > using su and doas interactively because the controlling terminal
> > is the same.
>
> > Is this behavior expected and if so, how do I run commands from
> > r
Simon Ruderich wrote:
> Hello,
>
> I stumbled upon unexpected behavior on OpenBSD 6.0 (all patches)
> which seems to allow running commands as the original user when
> using su and doas interactively because the controlling terminal
> is the same.
> Is this behavior expected and if so, how do I r
On Mon, Oct 03, 2016 at 02:57:34PM +0200, Martin Pieuchot wrote:
> Here are some timeouts that require a process context in order to call
> ip_output().
>
> The reason is that rtalloc(9) might end up inserting a RTF_CLONING route
> and that requires holding a write lock. This isn't going to chang
Diff below introduces a single write lock that will be used to serialize
access to ip_output().
This lock will be then split in multiple readers and writers to allow
multiple forwarding paths to run in parallel of each others but still
serialized with the socket layer.
I'm currently looking for p
> Date: Mon, 3 Oct 2016 14:57:34 +0200
> From: Martin Pieuchot
>
> Here are some timeouts that require a process context in order to call
> ip_output().
>
> The reason is that rtalloc(9) might end up inserting a RTF_CLONING route
> and that requires holding a write lock. This isn't going to cha
On 03/10/16(Mon) 15:07, Rafael Zalamena wrote:
> While doing the "notify bridge of interface removal with hook" I noticed
> that the span ports suffer from not having something to remove them. To
> reproduce this problem, do the following steps:
>
> # ifconfig vether0 up
> # ifconfig bridge0 up
>
While doing the "notify bridge of interface removal with hook" I noticed
that the span ports suffer from not having something to remove them. To
reproduce this problem, do the following steps:
# ifconfig vether0 up
# ifconfig bridge0 up
# ifconfig bridge0 addspan vether0
# ifconfig vether0 destroy
Here are some timeouts that require a process context in order to call
ip_output().
The reason is that rtalloc(9) might end up inserting a RTF_CLONING route
and that requires holding a write lock. This isn't going to change
because we're also going to use write locks to protect pf(4) internals.
On Mon, Oct 03, 2016 at 12:16:49PM +0200, Martin Natano wrote:
> > /*
> > * Flags set by internal operations.
> > */
> > #define MNT_LOCAL 0x1000 /* filesystem is stored locally */
> > #define MNT_QUOTA 0x2000 /* quotas are enabled on filesystem
> > */
> > #define M
On Sat, Oct 01, 2016 at 03:54:40PM -0600, Theo de Raadt wrote:
> De-escalation using these "sudo" or "doas" like tools on a tty is
> somewhat unsafe - it has always been unsafe - because tty's have
> capabilities.
Until looking into this issue I was totally unaware of the
possible implications (ev
On 2016/10/02 19:37, Martin Pieuchot wrote:
> I'm trying to figure out where the regression in IPv6/NDP is and here's
> what I found so far.
>
> When the route expiration time got converted from time_second to
> time_uptime we forgot to do the same for values inside RAs. I'm not
> sure what's the
> > And I want this check also for sys_unmount().
> >
>
> Good idea, sys_mount() is easy, because the only flag allowed there is
> MNT_FORCE.
s/sys_mount/sys_unmount/
Thank you for the feedback.
On Sun, Oct 02, 2016 at 07:53:04PM +0200, Alexander Bluhm wrote:
>
> I think we once had a simmilar problem, when someone tried to unmount
> with MNT_DOOMED. So I like to check all flags at the beginning of
> the system call.
>
> But I think you should remove these f
23 matches
Mail list logo
