Re: ksh "clear-screen" editing command

2019-04-02 Thread Sebastian Benoit
Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2019.04.02 10:52:34 +0200:
> On Mon, Apr 01 2019, Jeremie Courreges-Anglas  wrote:
> > On Mon, Jun 18 2018, "Todd C. Miller"  wrote:
> >> On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
> >>
> >>> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
> >>>
> >>> > If folks indeed think that this is a must-have feature, this is
> >>> > certainly a better approach.  I wonder though if the setupterm() call
> >>> > should happen earlier when interactive mode is initialized?
> >>>
> >>> This turns out to be simpler than expected.  Now whenever TERM is
> >>> set (including at startup) it will call setupterm().
> >>
> >> Hopefully final diff that better handles unknown term types.  Now
> >> if you set TERM=gobbledegook the old cur_term will be invalidated
> >> and clear-screen will not try to the escape sequence for the old
> >> terminal.
> >>
> >> I think this is good enough to commit.
> >
> > Since this went in, I'm using it on my machines instead of a bind -m hack.
> >
> > Can't we make ^L=clear-screen the default behavior?  I don't see
> > discussions about that.
> 
> So here's a diff.  oks/nays?

ok benno@

> 
> 
> NB: regress needs to be handled, as mentioned by Anton.  For now I think
> I'll comment out the ^L test, not sure how to amend it.
> 
> Index: emacs.c
> ===
> RCS file: /cvs/src/bin/ksh/emacs.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 emacs.c
> --- emacs.c   18 Jun 2018 17:03:58 -  1.85
> +++ emacs.c   2 Apr 2019 08:43:28 -
> @@ -1529,7 +1529,7 @@ x_init_emacs(void)
>   kb_add(x_prev_histword, CTRL('['), '_', 0);
>   /* how to handle: quote: ^^ */
>   kb_add(x_literal,   CTRL('^'), 0);
> - kb_add(x_draw_line, CTRL('L'), 0);
> + kb_add(x_clear_screen,  CTRL('L'), 0);
>   kb_add(x_search_char_back,  CTRL('['), CTRL(']'), 0);
>   kb_add(x_search_char_forw,  CTRL(']'), 0);
>   kb_add(x_search_hist,   CTRL('R'), 0);
> Index: ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.202
> diff -u -p -r1.202 ksh.1
> --- ksh.1 16 Dec 2018 13:08:35 -  1.202
> +++ ksh.1 2 Apr 2019 08:43:28 -
> @@ -4694,7 +4694,7 @@ Moves the cursor to the beginning of the
>  Uppercase the first character in the next
>  .Ar n
>  words, leaving the cursor past the end of the last word.
> -.It clear-screen:
> +.It clear-screen: ^L
>  Clears the screen if the
>  .Ev TERM
>  parameter is set and the terminal supports clearing the screen, then
> @@ -4891,7 +4891,7 @@ The last
>  word of the previous command is inserted at the cursor.
>  .It quote: ^^
>  The following character is taken literally rather than as an editing command.
> -.It redraw: ^L
> +.It redraw:
>  Reprints the prompt string and the current input line.
>  .It Xo search-character-backward:
>  .Op Ar n
> 
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 



Re: ksh "clear-screen" editing command

2019-04-02 Thread Klemens Nanni
On Tue, Apr 02, 2019 at 11:39:05AM -0400, Andras Farkas wrote:
> $ set -o vi
> $ true^[^L #redraws the line
> $ true
> 
> vi uses the escape or ^[ character to go into command mode from insert mode
Ooooh... I blatantly tried ^L without ESC in vi mode, of course that
won't work.

Yup, sorry for the noise.

OK kn (again)



Re: ksh "clear-screen" editing command

2019-04-02 Thread Theo Buehler
On Tue, Apr 02, 2019 at 05:31:22PM +0200, Klemens Nanni wrote:
> On Tue, Apr 02, 2019 at 05:20:19PM +0200, Theo Buehler wrote:
> > Yes, ^L is printed in vi insert mode. The text you quoted is about vi
> > command mode which does indeed redraw the current line on ^L. I agree
> > with jca, no need for a change there.
> I'm confused.  Without jca's diff, I did the following:
> 
>   xterm -e /bin/sh
>   $ set -o vi
>   $ ^L^L  # literal escape, nothing happens

You're staying in insert mode. As I said, paragraph is about command
(normal) mode:
The ⟨ESC⟩ key is used to enter command
 mode, where commands similar to those used by vi(1) are available.  A
 Ctrl-L sequence (^L) can be used in this mode to redraw the current
 command line.

$ set -o vi

enter hello^L^L and get the following output:

$ hello
$ hello
$ hello

With each ^L you will get another line containing "$ hello".



Re: ksh "clear-screen" editing command

2019-04-02 Thread Andras Farkas
On Tue, Apr 2, 2019 at 11:32 AM Klemens Nanni  wrote:
> On Tue, Apr 02, 2019 at 05:20:19PM +0200, Theo Buehler wrote:
> > Yes, ^L is printed in vi insert mode. The text you quoted is about vi
> > command mode which does indeed redraw the current line on ^L. I agree
> > with jca, no need for a change there.
> I'm confused.  Without jca's diff, I did the following:
>
> xterm -e /bin/sh
> $ set -o vi
> $ ^L^L  # literal escape, nothing happens
>
> $ set -o emacs
> $ true^L# redraws the line
> $ true
>
> So where does ^L redraw the current line on ^L for you?

$ set -o vi
$ true^[^L #redraws the line
$ true

vi uses the escape or ^[ character to go into command mode from insert mode



Re: ksh "clear-screen" editing command

2019-04-02 Thread Klemens Nanni
On Tue, Apr 02, 2019 at 05:20:19PM +0200, Theo Buehler wrote:
> Yes, ^L is printed in vi insert mode. The text you quoted is about vi
> command mode which does indeed redraw the current line on ^L. I agree
> with jca, no need for a change there.
I'm confused.  Without jca's diff, I did the following:

xterm -e /bin/sh
$ set -o vi
$ ^L^L  # literal escape, nothing happens

$ set -o emacs
$ true^L# redraws the line
$ true

So where does ^L redraw the current line on ^L for you?



Re: ksh "clear-screen" editing command

2019-04-02 Thread Theo Buehler
On Tue, Apr 02, 2019 at 05:04:42PM +0200, Klemens Nanni wrote:
> On Tue, Apr 02, 2019 at 04:56:58PM +0200, Jeremie Courreges-Anglas wrote:
> > The diff changes only the emacs mode.  I don't think sh.1 needs to be
> > adjusted given that the paragraph you quote is about vi mode.
> Sure it's just emacs mode.  But for sh(1), ^L does print a literal "^L"
> in vi mode; in emacs mode, it currently refreshes the line as this
> paragraph states.

Yes, ^L is printed in vi insert mode. The text you quoted is about vi
command mode which does indeed redraw the current line on ^L. I agree
with jca, no need for a change there.



Re: ksh "clear-screen" editing command

2019-04-02 Thread Theo Buehler
On Tue, Apr 02, 2019 at 10:52:34AM +0200, Jeremie Courreges-Anglas wrote:
> On Mon, Apr 01 2019, Jeremie Courreges-Anglas  wrote:
> > On Mon, Jun 18 2018, "Todd C. Miller"  wrote:
> >> On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
> >>
> >>> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
> >>>
> >>> > If folks indeed think that this is a must-have feature, this is
> >>> > certainly a better approach.  I wonder though if the setupterm() call
> >>> > should happen earlier when interactive mode is initialized?
> >>>
> >>> This turns out to be simpler than expected.  Now whenever TERM is
> >>> set (including at startup) it will call setupterm().
> >>
> >> Hopefully final diff that better handles unknown term types.  Now
> >> if you set TERM=gobbledegook the old cur_term will be invalidated
> >> and clear-screen will not try to the escape sequence for the old
> >> terminal.
> >>
> >> I think this is good enough to commit.
> >
> > Since this went in, I'm using it on my machines instead of a bind -m hack.
> >
> > Can't we make ^L=clear-screen the default behavior?  I don't see
> > discussions about that.
> 
> So here's a diff.  oks/nays?
> 

ok

> 
> NB: regress needs to be handled, as mentioned by Anton.  For now I think
> I'll comment out the ^L test, not sure how to amend it.
> 
> Index: emacs.c
> ===
> RCS file: /cvs/src/bin/ksh/emacs.c,v
> retrieving revision 1.85
> diff -u -p -r1.85 emacs.c
> --- emacs.c   18 Jun 2018 17:03:58 -  1.85
> +++ emacs.c   2 Apr 2019 08:43:28 -
> @@ -1529,7 +1529,7 @@ x_init_emacs(void)
>   kb_add(x_prev_histword, CTRL('['), '_', 0);
>   /* how to handle: quote: ^^ */
>   kb_add(x_literal,   CTRL('^'), 0);
> - kb_add(x_draw_line, CTRL('L'), 0);
> + kb_add(x_clear_screen,  CTRL('L'), 0);
>   kb_add(x_search_char_back,  CTRL('['), CTRL(']'), 0);
>   kb_add(x_search_char_forw,  CTRL(']'), 0);
>   kb_add(x_search_hist,   CTRL('R'), 0);
> Index: ksh.1
> ===
> RCS file: /cvs/src/bin/ksh/ksh.1,v
> retrieving revision 1.202
> diff -u -p -r1.202 ksh.1
> --- ksh.1 16 Dec 2018 13:08:35 -  1.202
> +++ ksh.1 2 Apr 2019 08:43:28 -
> @@ -4694,7 +4694,7 @@ Moves the cursor to the beginning of the
>  Uppercase the first character in the next
>  .Ar n
>  words, leaving the cursor past the end of the last word.
> -.It clear-screen:
> +.It clear-screen: ^L
>  Clears the screen if the
>  .Ev TERM
>  parameter is set and the terminal supports clearing the screen, then
> @@ -4891,7 +4891,7 @@ The last
>  word of the previous command is inserted at the cursor.
>  .It quote: ^^
>  The following character is taken literally rather than as an editing command.
> -.It redraw: ^L
> +.It redraw:
>  Reprints the prompt string and the current input line.
>  .It Xo search-character-backward:
>  .Op Ar n
> 
> 
> -- 
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> 



Re: ksh "clear-screen" editing command

2019-04-02 Thread Klemens Nanni
On Tue, Apr 02, 2019 at 04:56:58PM +0200, Jeremie Courreges-Anglas wrote:
> The diff changes only the emacs mode.  I don't think sh.1 needs to be
> adjusted given that the paragraph you quote is about vi mode.
Sure it's just emacs mode.  But for sh(1), ^L does print a literal "^L"
in vi mode; in emacs mode, it currently refreshes the line as this
paragraph states.



Re: ksh "clear-screen" editing command

2019-04-02 Thread Jeremie Courreges-Anglas
On Tue, Apr 02 2019, Klemens Nanni  wrote:
> On Tue, Apr 02, 2019 at 10:52:34AM +0200, Jeremie Courreges-Anglas wrote:
>> So here's a diff.  oks/nays?
> OK with the one mention in sh(1) adjusted as well:
>
>  There are two modes, interactive and command.  The shell starts in
>  interactive mode.  In this mode text is entered normally.  A ⟨newline⟩
>  executes the current command line.  The command line, unless empty, is
>  entered into command history.  The ⟨ESC⟩ key is used to enter command
>  mode, where commands similar to those used by vi(1) are available.  A
>  Ctrl-L sequence (^L) can be used in this mode to redraw the current
>  command line.

The diff changes only the emacs mode.  I don't think sh.1 needs to be
adjusted given that the paragraph you quote is about vi mode.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



[PATCH] [src] sbin/unwind/unwind.conf.5 - DoT capitalisation

2019-04-02 Thread Raf Czlonka
Hi all,

Consistently capitalise 'DoT'.

Regards,

Raf

Index: unwind.conf.5
===
RCS file: /cvs/src/sbin/unwind/unwind.conf.5,v
retrieving revision 1.11
diff -u -p -r1.11 unwind.conf.5
--- unwind.conf.5   2 Apr 2019 09:20:52 -   1.11
+++ unwind.conf.5   2 Apr 2019 14:45:00 -
@@ -52,7 +52,7 @@ Macro names may not be reserved words (f
 .Ic forwarder ,
 .Ic port ,
 or
-.Ic Dot ) .
+.Ic DoT ) .
 Macros are not expanded inside quotes.
 .Pp
 For example:



Re: ksh: quote empties

2019-04-02 Thread Klemens Nanni
On Sun, Dec 30, 2018 at 02:43:37PM -0800, Philip Guenther wrote:
> This thread was never resolved/committed.  Looking again at the diffs, I 
> still think I prefer that we _not_ touch print_value_quoted(), as the 
> other callers all use the 'key=value' format and don't need special 
> handling of empty values, leaving a diff like the one below.
I think this is a sensible approach.

OK kn



Re: ksh "clear-screen" editing command

2019-04-02 Thread Klemens Nanni
On Tue, Apr 02, 2019 at 10:52:34AM +0200, Jeremie Courreges-Anglas wrote:
> So here's a diff.  oks/nays?
OK with the one mention in sh(1) adjusted as well:

 There are two modes, interactive and command.  The shell starts in
 interactive mode.  In this mode text is entered normally.  A ⟨newline⟩
 executes the current command line.  The command line, unless empty, is
 entered into command history.  The ⟨ESC⟩ key is used to enter command
 mode, where commands similar to those used by vi(1) are available.  A
 Ctrl-L sequence (^L) can be used in this mode to redraw the current
 command line.



Re: introduce 'pfctl -FR' to reset settings to defaults

2019-04-02 Thread Klemens Nanni
On Tue, Apr 02, 2019 at 02:01:05PM +0200, Alexandr Nedvedicky wrote:
> I think Petr is right here. my patch requires yet another finishing touch:
Fair enough, but it should be noted that this somewhat changes behaviour
of the existing interface:

> 8<---8<---8<--8<
> diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c
> index 40929d90530..032fdd08b57 100644
> --- a/sbin/pfctl/pfctl.c
> +++ b/sbin/pfctl/pfctl.c
> @@ -2267,6 +2267,8 @@ pfctl_reset(int dev, int opts)
>  
> if (pfctl_trans(dev, , DIOCXCOMMIT, 0))
> warn("%s, DIOCXCOMMIT", __func__);
> +
> +   pfctl_clear_interface_flags(dev, opts);
Now this is done with `-F reset' and therefore `-F all'...

>  }
>  
>  int
> @@ -2594,7 +2596,6 @@ main(int argc, char *argv[])
> pfctl_clear_src_nodes(dev, opts);
> pfctl_clear_stats(dev, ifaceopt, opts);
> pfctl_clear_fingerprints(dev, opts);
> -   pfctl_clear_interface_flags(dev, opts);
Where previously, without being documented, only `-F all' would do so.

> pfctl_reset(dev, opts);
> }

I think that is fine in this particular case, but clearing things in
specific flush commands that were previously only touched by the `all'
hammer can be dangerous.



Re: introduce 'pfctl -FR' to reset settings to defaults

2019-04-02 Thread Alexandr Nedvedicky
Hello,


On Tue, Apr 02, 2019 at 12:59:33PM +0200, Petr Hoffmann wrote:
> On 02.04.2019 12:06, Klemens Nanni wrote:
> >On Tue, Apr 02, 2019 at 11:28:43AM +0200, Petr Hoffmann wrote:
> >>would make me believe everything mentioned as OPTIONS in pf.conf(5) is about
> >>to be reset. I see e.g. the debug level is reset, but what about the other
> >>stuff like fingerprints, 'skip on' and other options set via the 'set'
> >>command? Maybe the manpage should be more precise here?
> >Seems fine to me, given that a) some options are not persisted in the
> >driver but only effective during ruleset parsing and b) stuff like
> >fingerprints is already flushed separately, see pfctl(8) `-F osfp'.
> For me, forcing the user to think what is meant by 'options' is not
> very friendly, though I understand the idea behind *some* options
> being used only while parsing. Let's assume I'm the smart user who
> is able to distinguish them. But then, 'set skip on' is the
> persistent one, right, but still not reset, I guess.
> 

I think Petr is right here. my patch requires yet another finishing touch:

8<---8<---8<--8<
diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c
index 40929d90530..032fdd08b57 100644
--- a/sbin/pfctl/pfctl.c
+++ b/sbin/pfctl/pfctl.c
@@ -2267,6 +2267,8 @@ pfctl_reset(int dev, int opts)
 
if (pfctl_trans(dev, , DIOCXCOMMIT, 0))
warn("%s, DIOCXCOMMIT", __func__);
+
+   pfctl_clear_interface_flags(dev, opts);
 }
 
 int
@@ -2594,7 +2596,6 @@ main(int argc, char *argv[])
pfctl_clear_src_nodes(dev, opts);
pfctl_clear_stats(dev, ifaceopt, opts);
pfctl_clear_fingerprints(dev, opts);
-   pfctl_clear_interface_flags(dev, opts);
pfctl_reset(dev, opts);
}
break;
8<---8<---8<--8<

I'll walk through my change one more time to check if there are similar
oversights.

thanks and
regards
sasha



Re: Removing PF

2019-04-02 Thread R0me0 ***
For God sake, OpenBSD still there

Be Puffy!

Em ter, 2 de abr de 2019 às 03:51, Constantine A. Murenin 
escreveu:

> On 2019-W14-1 19:12 -0700, Jordan Geoghegan wrote:
> > Realistically, we need to move to the one true firewall-- iptables!
> > Ideally,  OpenBSD needs a firewall thats 'web scale' that can be
> > administered from a PHP web based frontend that uses JSON message
> > passing for clustering and failover.
>
> Don't forget about sharding -- we should probably use MongoDB for a
> pfsync(4) replacement.
>
> C.
>
>


Re: introduce 'pfctl -FR' to reset settings to defaults

2019-04-02 Thread Petr Hoffmann

On 02.04.2019 12:06, Klemens Nanni wrote:

On Tue, Apr 02, 2019 at 11:28:43AM +0200, Petr Hoffmann wrote:

would make me believe everything mentioned as OPTIONS in pf.conf(5) is about
to be reset. I see e.g. the debug level is reset, but what about the other
stuff like fingerprints, 'skip on' and other options set via the 'set'
command? Maybe the manpage should be more precise here?

Seems fine to me, given that a) some options are not persisted in the
driver but only effective during ruleset parsing and b) stuff like
fingerprints is already flushed separately, see pfctl(8) `-F osfp'.
For me, forcing the user to think what is meant by 'options' is not very 
friendly, though I understand the idea behind *some* options being used 
only while parsing. Let's assume I'm the smart user who is able to 
distinguish them. But then, 'set skip on' is the persistent one, right, 
but still not reset, I guess.


Petr


On 02.04.2019 12:06, Klemens Nanni wrote:

On Tue, Apr 02, 2019 at 11:28:43AM +0200, Petr Hoffmann wrote:

would make me believe everything mentioned as OPTIONS in pf.conf(5) is about
to be reset. I see e.g. the debug level is reset, but what about the other
stuff like fingerprints, 'skip on' and other options set via the 'set'
command? Maybe the manpage should be more precise here?

Seems fine to me, given that a) some options are not persisted in the
driver but only effective during ruleset parsing and b) stuff like
fingerprints is already flushed separately, see pfctl(8) `-F osfp'.





Re: Removing PF

2019-04-02 Thread obsd

Op 2-4-2019 om 04:12 schreef Jordan Geoghegan:


On 4/1/19 9:03 AM, Kevin Chadwick wrote:

On 4/1/19 3:18 PM, Mateusz Guzik wrote:

While I support pf removal, I don't think bpf is the way to go.

FreeBSD just removed their pf [1] so the code is up for grabs and you
can import it with one weird trick.

[1] 
https://lists.freebsd.org/pipermail/svn-src-projects/2019-April/013336.html

lol, did you read the link that you posted

"pf in FreeBSD lags years behind OpenBSD's pf. Remove it. Users are 
advised to

migrate to ipf."

Why would they replace new pf with old or are you trying to suggest 
ipf instead

of bpf?



Realistically, we need to move to the one true firewall-- iptables! 
Ideally,  OpenBSD needs a firewall thats 'web scale' that can be 
administered from a PHP web based frontend that uses JSON message 
passing for clustering and failover.




Realistically, what was wrong with ipchains? I would prefer that!



bgpd fix SE spinning on startup

2019-04-02 Thread Claudio Jeker
I noticed that when starting my test bgpd multihop sessions that the
session engine is busy spinning until the tables are loaded. Now since the
network is rather slow this does not make sense and indicates that the
poll timeout is wrongly set to 0 almost all the time until the session
finished the initial load.

Looking at this I realized that the current indication that there is still
work pending for a peer is wrong. Just checking if there is data in the
read buffer is wrong since in my case this most probably because of a
short read and so no immediate work needs to happen. This diff changes
the check and replaces it with a flag that is only set in the case we
stopped parsing because of hitting the MSG_PROCESS_LIMIT.

With this my session engine no longer busy loops at start which saves a
lot of CPU :)
-- 
:wq Claudio


Index: session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.377
diff -u -p -r1.377 session.c
--- session.c   31 Mar 2019 16:57:38 -  1.377
+++ session.c   2 Apr 2019 10:23:09 -
@@ -81,7 +81,7 @@ void  session_rrefresh(struct peer *, u_i
 intsession_graceful_restart(struct peer *);
 intsession_graceful_stop(struct peer *);
 intsession_dispatch_msg(struct pollfd *, struct peer *);
-intsession_process_msg(struct peer *);
+void   session_process_msg(struct peer *);
 intparse_header(struct peer *, u_char *, u_int16_t *, u_int8_t *);
 intparse_open(struct peer *);
 intparse_update(struct peer *);
@@ -426,7 +426,7 @@ session_main(int debug, int verbose)
if (p->wbuf.queued > 0 || p->state == STATE_CONNECT)
events |= POLLOUT;
/* is there still work to do? */
-   if (p->rbuf && p->rbuf->wpos)
+   if (p->rpending)
timeout = 0;
 
/* poll events */
@@ -1779,7 +1779,7 @@ session_dispatch_msg(struct pollfd *pfd,
return (0);
 }
 
-int
+void
 session_process_msg(struct peer *p)
 {
struct mrt  *mrt;
@@ -1790,19 +1790,20 @@ session_process_msg(struct peer *p)
 
rpos = 0;
av = p->rbuf->wpos;
+   p->rpending = 0;
 
/*
 * session might drop to IDLE -> buffers deallocated
 * we MUST check rbuf != NULL before use
 */
for (;;) {
-   if (rpos + MSGSIZE_HEADER > av)
-   break;
if (p->rbuf == NULL)
+   return;
+   if (rpos + MSGSIZE_HEADER > av)
break;
if (parse_header(p, p->rbuf->buf + rpos, ,
) == -1)
-   return (0);
+   return;
if (rpos + msglen > av)
break;
p->rbuf->rptr = p->rbuf->buf + rpos;
@@ -1847,11 +1848,11 @@ session_process_msg(struct peer *p)
bgp_fsm(p, EVNT_CON_FATAL);
}
rpos += msglen;
-   if (++processed > MSG_PROCESS_LIMIT)
+   if (++processed > MSG_PROCESS_LIMIT) {
+   p->rpending = 1;
break;
+   }
}
-   if (p->rbuf == NULL)
-   return (1);
 
if (rpos < av) {
left = av - rpos;
@@ -1859,8 +1860,6 @@ session_process_msg(struct peer *p)
p->rbuf->wpos = left;
} else
p->rbuf->wpos = 0;
-
-   return (1);
 }
 
 int
Index: session.h
===
RCS file: /cvs/src/usr.sbin/bgpd/session.h,v
retrieving revision 1.135
diff -u -p -r1.135 session.h
--- session.h   31 Mar 2019 16:57:38 -  1.135
+++ session.h   2 Apr 2019 10:13:28 -
@@ -231,6 +231,7 @@ struct peer {
u_int8_t demoted;
u_int8_t passive;
u_int8_t throttled;
+   u_int8_t rpending;
 };
 
 extern time_t   pauseaccept;



Re: introduce 'pfctl -FR' to reset settings to defaults

2019-04-02 Thread Klemens Nanni
On Tue, Apr 02, 2019 at 11:28:43AM +0200, Petr Hoffmann wrote:
> would make me believe everything mentioned as OPTIONS in pf.conf(5) is about
> to be reset. I see e.g. the debug level is reset, but what about the other
> stuff like fingerprints, 'skip on' and other options set via the 'set'
> command? Maybe the manpage should be more precise here?
Seems fine to me, given that a) some options are not persisted in the
driver but only effective during ruleset parsing and b) stuff like
fingerprints is already flushed separately, see pfctl(8) `-F osfp'.



Re: introduce 'pfctl -FR' to reset settings to defaults

2019-04-02 Thread Petr Hoffmann

Hi,

seeing this in the manpage
--8<--
+.It Fl F Cm Reset
+Reset limits, timeouts and options back to default settings.
-->8--
would make me believe everything mentioned as OPTIONS in pf.conf(5) is 
about to be reset. I see e.g. the debug level is reset, but what about 
the other stuff like fingerprints, 'skip on' and other options set via 
the 'set' command? Maybe the manpage should be more precise here?


PH

On 02.04.2019 9:40, Alexandr Nedvedicky wrote:

Hello,

below is diff I plan to commit. I did add a comment to pfctl_reset()
and wording in manpage.

thanks and
regards
sashan

8<---8<---8<---8<---
diff --git a/sbin/pfctl/pfctl.8 b/sbin/pfctl/pfctl.8
index 48b2893cfcd..00bd27c200a 100644
--- a/sbin/pfctl/pfctl.8
+++ b/sbin/pfctl/pfctl.8
@@ -197,6 +197,8 @@ Flush the filter information (statistics that are not bound 
to rules).
  Flush the tables.
  .It Fl F Cm osfp
  Flush the passive operating system fingerprints.
+.It Fl F Cm Reset
+Reset limits, timeouts and options back to default settings.
  .It Fl F Cm all
  Flush all of the above.
  .El
diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c
index 493ff47af2f..40929d90530 100644
--- a/sbin/pfctl/pfctl.c
+++ b/sbin/pfctl/pfctl.c
@@ -105,6 +105,7 @@ int  pfctl_load_rule(struct pfctl *, char *, struct pf_rule 
*, int);
  const char*pfctl_lookup_option(char *, const char **);
  void  pfctl_state_store(int, const char *);
  void  pfctl_state_load(int, const char *);
+void   pfctl_reset(int, int);
  
  const char	*clearopt;

  char  *rulesopt;
@@ -205,7 +206,8 @@ static const struct {
  };
  
  static const char *clearopt_list[] = {

-   "rules", "Sources", "states", "info", "Tables", "osfp", "all", NULL
+   "rules", "Sources", "states", "info", "Tables", "osfp", "Reset",
+   "all", NULL
  };
  
  static const char *showopt_list[] = {

@@ -2232,6 +2234,41 @@ pfctl_state_load(int dev, const char *file)
fclose(f);
  }
  
+void

+pfctl_reset(int dev, int opts)
+{
+   struct pfctlpf;
+   struct pfr_buffer t;
+   int i;
+
+   pf.dev = dev;
+   pfctl_init_options();
+
+   /* Force reset upon pfctl_load_options() */
+   pf.debug_set = 1;
+   pf.reass_set = 1;
+   pf.syncookieswat_set = 1;
+   pf.ifname = strdup("none");
+   pf.ifname_set = 1;
+
+   memset(, 0, sizeof(t));
+   t.pfrb_type = PFRB_TRANS;
+   if (pfctl_trans(dev, , DIOCXBEGIN, 0))
+   warn("%s, DIOCXBEGIN", __func__);
+
+
+   for (i = 0; pf_limits[i].name; i++)
+   pf.limit_set[pf_limits[i].index] = 1;
+
+   for (i = 0; pf_timeouts[i].name; i++)
+   pf.timeout_set[pf_timeouts[i].timeout] = 1;
+
+   pfctl_load_options();
+
+   if (pfctl_trans(dev, , DIOCXCOMMIT, 0))
+   warn("%s, DIOCXCOMMIT", __func__);
+}
+
  int
  main(int argc, char *argv[])
  {
@@ -2558,6 +2595,7 @@ main(int argc, char *argv[])
pfctl_clear_stats(dev, ifaceopt, opts);
pfctl_clear_fingerprints(dev, opts);
pfctl_clear_interface_flags(dev, opts);
+   pfctl_reset(dev, opts);
}
break;
case 'o':
@@ -2566,6 +2604,9 @@ main(int argc, char *argv[])
case 'T':
pfctl_clear_tables(anchorname, opts);
break;
+   case 'R':
+   pfctl_reset(dev, opts);
+   break;
}
}
if (state_killers) {





Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table

2019-04-02 Thread Mitchell Krome
On 2/04/2019 3:30 pm, Remi Locherer wrote:
> Hi Mitchell
> 
> On Sat, Mar 30, 2019 at 04:10:09PM +1000, Mitchell Krome wrote:
>> I kept finding I had a lingering /30 route when I turned off one of my
>> test boxes. I tracked it down to ospfd sending RTM_ADD for a stub
>> network with the non-masked prefix. The RTM_ADD path applies the mask
>> inside the kernel, so the route got added as expected, but the
>> RTM_DELETE enforces an exact match, so it could never remove the route.
>>
>> The advertised stub network was as follows:
>>
>> Link connected to: Stub Network
>>  Link ID (Network ID): 10.10.20.2
>> Link Data (Network Mask): 255.255.255.252
>>  Metric: 10
> 
> Please send the details of your setup so it is easy to reproduce the issue.
> - OpenBSD version
> - ospfd.conf
> - interface configs
> - routing table

I am running a kernel I compiled myself with source from ~2 weeks ago.
See the bottom for other info.

> 
>> ospfd sends the interface address rather than network address as the
>> link ID. The RFC says "set the Link ID of the Type 3 link to the
>> subnet's IP address" which to me means we probably should also apply the
>> mask before we add the stub to the LSA to avoid getting into this place
>> to start with? 
> 
> This only applies to Type 3 LSAs. Below table is from RFC 2328
> chapter 12.1.4:
> 
> LS Type   Link State ID
> ___
> 1 The originating router's Router ID.
> 2 The IP interface address of the
>   network's Designated Router.
> 3 The destination network's IP address.
> 4 The Router ID of the described AS
>   boundary router.
> 5 The destination network's IP address.
> 
>>
>> The patch below just masks the stub network before it gets added to the
>> route table, so that we can properly delete it. I can send a patch to
>> mask it before sending the LSA too if the consensus is that is how it
>> should be.
> 
> With your patch you change the case "LSA_TYPE_ROUTER" (LS Type 1) and not
> LS type 3.

Inside the LSA type 1 there is a type 3 link which is a "stub network".
That is what I was changing. Under 12.4.1.1 second dotpoint it says for
a point to point network add a type 3 link. Maybe I got the terminology
wrong, but this was definitely the thing I intended to change

   Link type   Description   Link ID
   __
   1   Point-to-pointNeighbor Router ID
   link
   2   Link to transit   Interface address of
   network   Designated Router
   3   Link to stub  IP network number
   network
   4   Virtual link  Neighbor Router ID


   Table 18: Link descriptions in the
  router-LSA.


> 
> Remi
> 

Box 1:

openbsd1# cat /etc/hostname.lo1
inet 10.0.0.1/32

openbsd1# cat /etc/hostname.gre0
up
mpls
tunnel 10.10.10.1 10.10.10.2
tunneldomain 10
inet 10.10.20.1/30
dest 10.10.20.2

openbsd1# cat /etc/ospfd.conf
area 0.0.0.0 {
interface lo1 {
passive
}
interface gre0
}

Box 2:

openbsd2# cat /etc/hostname.lo1
inet 10.0.0.2/32

openbsd2# cat /etc/hostname.gre0
up
mpls
tunnel 10.10.10.2 10.10.10.1
tunneldomain 10
inet 10.10.20.2/30
dest 10.10.20.1

openbsd2# cat /etc/hostname.gre1
up
mpls
tunnel 10.10.10.5 10.10.10.6
tunneldomain 10
inet 10.10.20.5/30
dest 10.10.20.6

openbsd2# cat /etc/ospfd.conf
area 0.0.0.0 {
interface lo1 {
passive
}
interface gre0
interface gre1
}

Box 3:

openbsd3# cat /etc/hostname.lo1
inet 10.0.0.3/32

openbsd3# cat /etc/hostname.gre0
up
mpls
tunnel 10.10.10.6 10.10.10.5
tunneldomain 10
inet 10.10.20.6/30
dest 10.10.20.5

openbsd3# cat /etc/ospfd.conf
area 0.0.0.0 {
interface lo1 {
passive
}
interface gre0
}


1: Box 1 has ospfd disabled. Route table on box 3:

openbsd3# route show
Routing tables

Internet:
DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
10.0.0.2/3210.10.20.5 UG 11 -32 gre0
10.0.0.3   10.0.0.3   UHl0  156 32768 1 lo1
10.10.20.0/30  10.10.20.5 UG 00 -32 gre0
10.10.20.5 10.10.20.6 UHh5  431 - 8 gre0
10.10.20.6 10.10.20.5 UHl0  143 - 1 gre0
10.10.20.6/32  10.10.20.5 UG 00 -32 gre0
localhost  localhost  UHl0   12 32768 1 lo0

2: Enable ospfd on box 1. Note the /30 is still in the routing table,
but also 

Re: ksh "clear-screen" editing command

2019-04-02 Thread Jeremie Courreges-Anglas
On Mon, Apr 01 2019, Jeremie Courreges-Anglas  wrote:
> On Mon, Jun 18 2018, "Todd C. Miller"  wrote:
>> On Sun, 17 Jun 2018 15:52:34 -0600, "Todd C. Miller" wrote:
>>
>>> On Sun, 17 Jun 2018 17:29:31 +0200, Mark Kettenis wrote:
>>>
>>> > If folks indeed think that this is a must-have feature, this is
>>> > certainly a better approach.  I wonder though if the setupterm() call
>>> > should happen earlier when interactive mode is initialized?
>>>
>>> This turns out to be simpler than expected.  Now whenever TERM is
>>> set (including at startup) it will call setupterm().
>>
>> Hopefully final diff that better handles unknown term types.  Now
>> if you set TERM=gobbledegook the old cur_term will be invalidated
>> and clear-screen will not try to the escape sequence for the old
>> terminal.
>>
>> I think this is good enough to commit.
>
> Since this went in, I'm using it on my machines instead of a bind -m hack.
>
> Can't we make ^L=clear-screen the default behavior?  I don't see
> discussions about that.

So here's a diff.  oks/nays?


NB: regress needs to be handled, as mentioned by Anton.  For now I think
I'll comment out the ^L test, not sure how to amend it.

Index: emacs.c
===
RCS file: /cvs/src/bin/ksh/emacs.c,v
retrieving revision 1.85
diff -u -p -r1.85 emacs.c
--- emacs.c 18 Jun 2018 17:03:58 -  1.85
+++ emacs.c 2 Apr 2019 08:43:28 -
@@ -1529,7 +1529,7 @@ x_init_emacs(void)
kb_add(x_prev_histword, CTRL('['), '_', 0);
/* how to handle: quote: ^^ */
kb_add(x_literal,   CTRL('^'), 0);
-   kb_add(x_draw_line, CTRL('L'), 0);
+   kb_add(x_clear_screen,  CTRL('L'), 0);
kb_add(x_search_char_back,  CTRL('['), CTRL(']'), 0);
kb_add(x_search_char_forw,  CTRL(']'), 0);
kb_add(x_search_hist,   CTRL('R'), 0);
Index: ksh.1
===
RCS file: /cvs/src/bin/ksh/ksh.1,v
retrieving revision 1.202
diff -u -p -r1.202 ksh.1
--- ksh.1   16 Dec 2018 13:08:35 -  1.202
+++ ksh.1   2 Apr 2019 08:43:28 -
@@ -4694,7 +4694,7 @@ Moves the cursor to the beginning of the
 Uppercase the first character in the next
 .Ar n
 words, leaving the cursor past the end of the last word.
-.It clear-screen:
+.It clear-screen: ^L
 Clears the screen if the
 .Ev TERM
 parameter is set and the terminal supports clearing the screen, then
@@ -4891,7 +4891,7 @@ The last
 word of the previous command is inserted at the cursor.
 .It quote: ^^
 The following character is taken literally rather than as an editing command.
-.It redraw: ^L
+.It redraw:
 Reprints the prompt string and the current input line.
 .It Xo search-character-backward:
 .Op Ar n


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE



Re: iked curve25519

2019-04-02 Thread Theo de Raadt
I think this is the right time to do this.

Stuart Henderson  wrote:

> On 2019/03/30 13:43, Theo de Raadt wrote:
> > I think we should switch, waiting doesn't help.
> > 
> > Reyk Floeter  wrote:
> > 
> > > I like the idea of switching it to the proper ID.
> > > 
> > > Reyk
> > > 
> > > > Am 30.03.2019 um 20:31 schrieb Stuart Henderson :
> > > > 
> > > > curve25519 had a proper ID (31) assigned in 2016 but we still have
> > > > the draft private-use ID in iked. Any thoughts on whether we can just
> > > > cut across to the proper ID, or whether that will be too painful?
> > > > Are many people using this already?
> > > > 
> > > 
> > 
> 
> Here's the cut-across diff. OK?
> 
> To transition, before updating, configure the responder to allow both
> curve25519 and another PFS group e.g.
> 
> ...
>   ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group curve25519 \
>   ikesa enc aes-256 prf hmac-sha2-256 auth hmac-sha2-256 group brainpool512 \
> ...
> 
> Then switch the initiators to the other group, then upgrade and switch
> back as wanted.
> 
> This doesn't affect the default iked configuration, and is unlikely to
> affect non-OpenBSD devices as curve25519 with the draft ID does not seem
> widely used elsewhere, so shouldn't trouble too many people.
> 
> Index: dh.c
> ===
> RCS file: /cvs/src/sbin/iked/dh.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 dh.c
> --- dh.c  27 Oct 2017 14:26:35 -  1.21
> +++ dh.c  1 Apr 2019 19:06:18 -
> @@ -244,9 +244,7 @@ const struct group_id ike_groups[] = {
>   { GROUP_ECP, 28, 256, NULL, NULL, NID_brainpoolP256r1 },
>   { GROUP_ECP, 29, 384, NULL, NULL, NID_brainpoolP384r1 },
>   { GROUP_ECP, 30, 512, NULL, NULL, NID_brainpoolP512r1 },
> -
> - /* "Private use" extensions */
> - { GROUP_CURVE25519, 1034, CURVE25519_SIZE * 8 }
> + { GROUP_CURVE25519, 31, CURVE25519_SIZE * 8 }
>  };
>  
>  void
> Index: iked.conf.5
> ===
> RCS file: /cvs/src/sbin/iked/iked.conf.5,v
> retrieving revision 1.53
> diff -u -p -r1.53 iked.conf.5
> --- iked.conf.5   31 Jan 2018 13:25:55 -  1.53
> +++ iked.conf.5   1 Apr 2019 19:06:18 -
> @@ -883,7 +883,7 @@ The currently supported group types are 
>  MODP (exponentiation groups modulo a prime),
>  EC2N (elliptic curve groups over GF[2^N]),
>  ECP (elliptic curve groups modulo a prime),
> -or the non-standard Curve25519.
> +or Curve25519.
>  Please note that the EC2N groups are considered as insecure and only
>  provided for backwards compatibility.
>  .Sh EXAMPLES
> Index: ikev2.h
> ===
> RCS file: /cvs/src/sbin/iked/ikev2.h,v
> retrieving revision 1.28
> diff -u -p -r1.28 ikev2.h
> --- ikev2.h   27 Feb 2019 06:33:57 -  1.28
> +++ ikev2.h   1 Apr 2019 19:06:18 -
> @@ -231,16 +231,16 @@ extern struct iked_constmap ikev2_xforma
>  #define IKEV2_XFORMDH_MODP_4096  16  /* DH Group 16 */
>  #define IKEV2_XFORMDH_MODP_6144  17  /* DH Group 17 */
>  #define IKEV2_XFORMDH_MODP_8192  18  /* DH Group 18 */
> -#define IKEV2_XFORMDH_ECP_25619  /* DH Group 19 */
> -#define IKEV2_XFORMDH_ECP_38420  /* DH Group 20 */
> -#define IKEV2_XFORMDH_ECP_52121  /* DH Group 21 */
> -#define IKEV2_XFORMDH_ECP_19225  /* DH Group 25 */
> -#define IKEV2_XFORMDH_ECP_22426  /* DH Group 26 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P224R1   27  /* DH Group 27 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P256R1   28  /* DH Group 28 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P384R1   29  /* DH Group 29 */
> -#define IKEV2_XFORMDH_BRAINPOOL_P512R1   30  /* DH Group 30 */
> -#define IKEV2_XFORMDH_X_CURVE25519   1034/* 
> draft-ietf-ipsecme-safecurves-00 */
> +#define IKEV2_XFORMDH_ECP_25619  /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_38420  /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_52121  /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_19225  /* RFC5114 */
> +#define IKEV2_XFORMDH_ECP_22426  /* RFC5114 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P224R1   27  /* RFC6954 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P256R1   28  /* RFC6954 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P384R1   29  /* RFC6954 */
> +#define IKEV2_XFORMDH_BRAINPOOL_P512R1   30  /* RFC6954 */
> +#define IKEV2_XFORMDH_CURVE25519 31  /* RFC8031 */
>  
>  extern struct iked_constmap ikev2_xformdh_map[];
>  
> Index: parse.y
> ===
> RCS file: /cvs/src/sbin/iked/parse.y,v
> retrieving revision 1.78
> diff -u -p -r1.78 parse.y
> --- parse.y   13 Feb 2019 22:57:07 -  1.78
> +++ parse.y   1 Apr 

Re: ksh "clear-screen" editing command

2019-04-02 Thread Peter Hessler
On 2019 Apr 01 (Mon) at 09:53:31 -0600 (-0600), Todd C. Miller wrote:
:On Mon, 01 Apr 2019 16:52:34 +0200, Jeremie Courreges-Anglas wrote:
:
:> Since this went in, I'm using it on my machines instead of a bind -m hack.
:>
:> Can't we make ^L=clear-screen the default behavior?  I don't see
:> discussions about that.
:
:AT ksh doesn't clear the screen by default on ^L.  Other shells
:like bash, zsh, and tcsh do.  I don't object to making it the default
:but as I'm not a ksh user I'll defer to those who are.
:
: - todd
:

I always wondered why bash felt broken, this is one of the reasons.

I hate it, but I guess I can add a line to my configs.

-- 
There is nothing wrong with Southern California that a rise in the
ocean level wouldn't cure.
-- Ross MacDonald



Re: introduce 'pfctl -FR' to reset settings to defaults

2019-04-02 Thread Alexandr Nedvedicky
Hello,

below is diff I plan to commit. I did add a comment to pfctl_reset()
and wording in manpage.

thanks and
regards
sashan

8<---8<---8<---8<---
diff --git a/sbin/pfctl/pfctl.8 b/sbin/pfctl/pfctl.8
index 48b2893cfcd..00bd27c200a 100644
--- a/sbin/pfctl/pfctl.8
+++ b/sbin/pfctl/pfctl.8
@@ -197,6 +197,8 @@ Flush the filter information (statistics that are not bound 
to rules).
 Flush the tables.
 .It Fl F Cm osfp
 Flush the passive operating system fingerprints.
+.It Fl F Cm Reset
+Reset limits, timeouts and options back to default settings.
 .It Fl F Cm all
 Flush all of the above.
 .El
diff --git a/sbin/pfctl/pfctl.c b/sbin/pfctl/pfctl.c
index 493ff47af2f..40929d90530 100644
--- a/sbin/pfctl/pfctl.c
+++ b/sbin/pfctl/pfctl.c
@@ -105,6 +105,7 @@ int  pfctl_load_rule(struct pfctl *, char *, struct pf_rule 
*, int);
 const char *pfctl_lookup_option(char *, const char **);
 void   pfctl_state_store(int, const char *);
 void   pfctl_state_load(int, const char *);
+void   pfctl_reset(int, int);
 
 const char *clearopt;
 char   *rulesopt;
@@ -205,7 +206,8 @@ static const struct {
 };
 
 static const char *clearopt_list[] = {
-   "rules", "Sources", "states", "info", "Tables", "osfp", "all", NULL
+   "rules", "Sources", "states", "info", "Tables", "osfp", "Reset",
+   "all", NULL
 };
 
 static const char *showopt_list[] = {
@@ -2232,6 +2234,41 @@ pfctl_state_load(int dev, const char *file)
fclose(f);
 }
 
+void
+pfctl_reset(int dev, int opts)
+{
+   struct pfctlpf;
+   struct pfr_buffer t;
+   int i;
+
+   pf.dev = dev;
+   pfctl_init_options();
+
+   /* Force reset upon pfctl_load_options() */
+   pf.debug_set = 1;
+   pf.reass_set = 1;
+   pf.syncookieswat_set = 1;
+   pf.ifname = strdup("none");
+   pf.ifname_set = 1;
+
+   memset(, 0, sizeof(t));
+   t.pfrb_type = PFRB_TRANS;
+   if (pfctl_trans(dev, , DIOCXBEGIN, 0))
+   warn("%s, DIOCXBEGIN", __func__);
+
+
+   for (i = 0; pf_limits[i].name; i++)
+   pf.limit_set[pf_limits[i].index] = 1;
+
+   for (i = 0; pf_timeouts[i].name; i++)
+   pf.timeout_set[pf_timeouts[i].timeout] = 1;
+
+   pfctl_load_options();
+
+   if (pfctl_trans(dev, , DIOCXCOMMIT, 0))
+   warn("%s, DIOCXCOMMIT", __func__);
+}
+
 int
 main(int argc, char *argv[])
 {
@@ -2558,6 +2595,7 @@ main(int argc, char *argv[])
pfctl_clear_stats(dev, ifaceopt, opts);
pfctl_clear_fingerprints(dev, opts);
pfctl_clear_interface_flags(dev, opts);
+   pfctl_reset(dev, opts);
}
break;
case 'o':
@@ -2566,6 +2604,9 @@ main(int argc, char *argv[])
case 'T':
pfctl_clear_tables(anchorname, opts);
break;
+   case 'R':
+   pfctl_reset(dev, opts);
+   break;
}
}
if (state_killers) {



Re: Removing PF

2019-04-02 Thread Constantine A. Murenin
On 2019-W14-1 19:12 -0700, Jordan Geoghegan wrote:
> Realistically, we need to move to the one true firewall-- iptables!
> Ideally,  OpenBSD needs a firewall thats 'web scale' that can be
> administered from a PHP web based frontend that uses JSON message
> passing for clustering and failover.

Don't forget about sharding -- we should probably use MongoDB for a pfsync(4) 
replacement.

C.



sdhc/sdmmc: don't detach non-removable devices

2019-04-02 Thread Stefan Sperling
This diff disables sdmmc device detach in the resume path if
APCI reports a non-removable device. This makes hibernate work
for me on a laptop with root disk on internal emmc storage.

With help from kettenis@

diff d7548b5925dd9032f6a15d6aebaed5bffcbcd366 /usr/src
blob - d6afef333a35d34751bc648701701d58dbd2034a
file + sys/dev/acpi/sdhc_acpi.c
--- sys/dev/acpi/sdhc_acpi.c
+++ sys/dev/acpi/sdhc_acpi.c
@@ -237,8 +237,13 @@ sdhc_acpi_do_explore(struct aml_node *node, void *arg)
/* Override card detect if we have non-removable devices. */
if (aml_evalinteger(sc->sc_acpi, node, "_RMV", 0, NULL, ))
rmv = 1;
-   if (rmv == 0 && sc->sc.sc_card_detect == NULL)
-   sc->sc.sc_card_detect = sdhc_acpi_card_detect_nonremovable;
+   if (rmv == 0) {
+   sc->sc.sc_flags |= SDHC_F_NONREMOVABLE;
+   if (sc->sc.sc_card_detect == NULL) {
+   sc->sc.sc_card_detect =
+   sdhc_acpi_card_detect_nonremovable;
+   }
+   }
 
sdhc_acpi_power_on(sc, node);
 
blob - 248878293e30407ccaf8b9c7ce4a901dbd9aca6c
file + sys/dev/sdmmc/sdhc.c
--- sys/dev/sdmmc/sdhc.c
+++ sys/dev/sdmmc/sdhc.c
@@ -335,6 +335,9 @@ sdhc_host_found(struct sdhc_softc *sc, bus_space_tag_t
if (ISSET(sc->sc_flags, SDHC_F_NODDR50))
saa.caps &= ~SMC_CAPS_MMC_DDR52;
 
+   if (ISSET(sc->sc_flags, SDHC_F_NONREMOVABLE))
+   saa.caps |= SMC_CAPS_NONREMOVABLE;
+
hp->sdmmc = config_found(>sc_dev, , NULL);
if (hp->sdmmc == NULL) {
error = 0;
blob - 7775015ac97e7f275f51306e5a0829cd9bd31d83
file + sys/dev/sdmmc/sdhcvar.h
--- sys/dev/sdmmc/sdhcvar.h
+++ sys/dev/sdmmc/sdhcvar.h
@@ -48,5 +48,6 @@ void  sdhc_needs_discover(struct sdhc_softc *);
 /* flag values */
 #define SDHC_F_NOPWR0  (1 << 0)
 #define SDHC_F_NODDR50 (1 << 1)
+#define SDHC_F_NONREMOVABLE(1 << 2)
 
 #endif
blob - 32285bce1cb57c6778a90551b69f62701dc1c59a
file + sys/dev/sdmmc/sdmmc.c
--- sys/dev/sdmmc/sdmmc.c
+++ sys/dev/sdmmc/sdmmc.c
@@ -181,7 +181,8 @@ sdmmc_activate(struct device *self, int act)
case DVACT_SUSPEND:
rv = config_activate_children(self, act);
/* If card in slot, cause a detach/re-attach */
-   if (ISSET(sc->sc_flags, SMF_CARD_PRESENT))
+   if (ISSET(sc->sc_flags, SMF_CARD_PRESENT) &&
+   !ISSET(sc->sc_caps, SMC_CAPS_NONREMOVABLE))
sc->sc_dying = -1;
break;
case DVACT_RESUME:
blob - 1cc635e3182fd8e532d4d534b8010cfa22002b51
file + sys/dev/sdmmc/sdmmcvar.h
--- sys/dev/sdmmc/sdmmcvar.h
+++ sys/dev/sdmmc/sdmmcvar.h
@@ -200,6 +200,7 @@ struct sdmmc_softc {
 #define SMC_CAPS_MMC_DDR52 0x2000  /* eMMC DDR52 timing */
 #define SMC_CAPS_MMC_HS200 0x4000  /* eMMC HS200 timing */
 #define SMC_CAPS_MMC_HS400 0x8000  /* eMMC HS400 timing */
+#define SMC_CAPS_NONREMOVABLE  0x1 /* non-removable devices */
 
int sc_function_count;  /* number of I/O functions (SDIO) */
struct sdmmc_function *sc_card; /* selected card */