Re: allow 240/4 in various network daemons
Martin Schröder wrote: > Am Sa., 28. Mai 2022 um 22:46 Uhr schrieb Seth David Schoen > : > > We're also interested in talking about whether there's an appropriate > > path for supporting non-broadcast use of addresses within 127/8, our > > most controversial change. In Linux and FreeBSD, we're experimenting > > IPv6 is now older than IPv4 was when v6 was introduced. > You are beating a very dead horse. Martin, that comment is unhelpful.
Re: allow 240/4 in various network daemons
On 5/28/22 5:22 PM, Crystal Kolipe wrote: There certainly are people using this behaviour of the loopback address(es) in creative ways on non-OpenBSD systems: https://timkay.com/solo/ Changing it on those systems will likely break various users' scripts in unexpected ways. The script linked above doesn't work in it's original form on OpenBSD precisely because of the different behaviour of the 127/8 subnet. Not that I really care, because a solution to the _real_ problem already exists. It's called IPv6. True. But I would have to buy access to a VPN because my service provider hasn't extended IPv6 service to my location. Hurricane Electric isn't useful because some sites care about geography and they can't determine where a HE user is located.
Re: allow 240/4 in various network daemons
Am Sa., 28. Mai 2022 um 22:46 Uhr schrieb Seth David Schoen : > We're also interested in talking about whether there's an appropriate > path for supporting non-broadcast use of addresses within 127/8, our > most controversial change. In Linux and FreeBSD, we're experimenting IPv6 is now older than IPv4 was when v6 was introduced. You are beating a very dead horse. Best Martin
Re: allow 240/4 in various network daemons
On Sat, May 28, 2022 at 01:46:18PM -0700, Seth David Schoen wrote: > We're also interested in talking about whether there's an appropriate > path for supporting non-broadcast use of addresses within 127/8, our > most controversial change. In Linux and FreeBSD, we're experimenting > with the ideas of having a sysctl that defines the prefix length for > loopback on the 127 network (with the default value being 8), or making > the loopback interface honor netmasks in exactly the same way as other > network interfaces do (so if you set 255.0.0.0 as the mask on lo, then > it will believe 127.2.3.4 is reachable via loopback, while if you set > 255.255.255.255 as the mask, it will only believe 127.0.0.1 is > reachable). We think other systems will be willing to let people opt > into this change, but will likely not want to make it the default due to > concerns about possible existing uses for loopback addresses other than > 127.0.0.1. There certainly are people using this behaviour of the loopback address(es) in creative ways on non-OpenBSD systems: https://timkay.com/solo/ Changing it on those systems will likely break various users' scripts in unexpected ways. The script linked above doesn't work in it's original form on OpenBSD precisely because of the different behaviour of the 127/8 subnet. Not that I really care, because a solution to the _real_ problem already exists. It's called IPv6.
Re: allow 240/4 in various network daemons
Theo de Raadt writes: > This discussion relates to only one step of a number of potential increments. > > I believe it is a bad idea to conflate all of these potential address > space recovery changes as the same singular discussion. Not all the > decisions being made on intranets are sane. Not all of these proposals > make sense. Not all of these proposals make sense right away. > > Instead, they should be done piecemeal, and each one should be discussed > seperately, or we will lose the way. Thank you for merging the patches that improve OpenBSD's support for 0/8 and 240/4, and thank you again for making the lowest address broadcast change years ago. We'd be happy to hear more of your ideas about the best way to promote and discuss these changes. As you may be aware, software support for them is pretty good (and getting better all the time), while the IETF community has not been very enthusiastic about our drafts so far. We're also interested in talking about whether there's an appropriate path for supporting non-broadcast use of addresses within 127/8, our most controversial change. In Linux and FreeBSD, we're experimenting with the ideas of having a sysctl that defines the prefix length for loopback on the 127 network (with the default value being 8), or making the loopback interface honor netmasks in exactly the same way as other network interfaces do (so if you set 255.0.0.0 as the mask on lo, then it will believe 127.2.3.4 is reachable via loopback, while if you set 255.255.255.255 as the mask, it will only believe 127.0.0.1 is reachable). We think other systems will be willing to let people opt into this change, but will likely not want to make it the default due to concerns about possible existing uses for loopback addresses other than 127.0.0.1. (There was also a CVE affecting some software under Linux due to a kernel option where one could opt in to giving 127/8 both loopback and non-loopback semantics at the same time, which turns out to be a bad idea because then hosts on a LAN can address sockets that think they're bound only to loopback addresses! This is definitely not a good idea.) There also seems to be a strange ambiguity about whether OSes currently treat all of 127/8 as usable loopback or only treat 127.0.0.1 as reachable but effectively reserve all of the rest for future use. My impression is that either behavior is somewhat defensible under current standards, but I might have missed some language in an RFC that officially rules out one or the other.
Re: apmd(8): reconnecting AC, not battery
Hi Jason,
Jason McIntyre wrote on Sat, May 28, 2022 at 05:10:08PM +0100:
> On Sat, May 28, 2022 at 10:34:35AM +0100, Stuart Henderson wrote:
>> On 2022/05/28 06:52, Jason McIntyre wrote:
>>> On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote:
apmd says:
When the power status changes (battery is connected or disconnected),
apmd fetches the current status and reports it via syslog(3)
with logging facility LOG_DAEMON.
Is "battery" really meant here? Should that be the AC power?
Batteries are typically not being reconnected while running ...
>> They certainly can be, either while on external power, or in the case of
>> machines with multiple batteries (several generations of X series ThinkPads
>> have both internal and external batteries, so you can swap without powering
>> down even while on battery power). But yes the common case would be
>> external power.
(The manpage calls it "external power", "line current"
and "AC" interchangably.)
>>> i think you're right that the text is off. the author possibly meant to
>>> say battery was charging or discharging.
>>>
>>> anyway, if i don;t hear any reason not to soon, i'll commit your
>>> suggested diff (which i think is simpler and makes sense).
>> Why be inaccurate when we don't need to be - it's very uncommon to have
>> a machine with a battery with an AC input. "External power" would make
>> more sense.
> i have to say, i don;t understand the distinction. i thought a
> laptop was "a machine with a battery with an AC input" (or, at
> least, *and* an AC input). however i committed a diff with your
> text ("external power") knowing that you are undoubtedly correct ;)
I guess an example for what sthen@ wanted to say is that most laptops
have an external power adapter - for example, the one of the machine
i'm currently typing on has
INPUT: 100-240V~ 1.3A 50-60Hz
OUTPUT: 20V= 2.25A
printed on it (transforming AC to DC), so the machine itself
does *not* have an AC input. Instead, the "external power" the
machine receives is already DC.
Yours,
Ingo
Re: apmd(8): reconnecting AC, not battery
On Sat, May 28, 2022 at 10:34:35AM +0100, Stuart Henderson wrote:
> On 2022/05/28 06:52, Jason McIntyre wrote:
> > On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote:
> > > apmd says:
> > >
> > > When the power status changes (battery is connected or disconnected),
> > > apmd fetches the current status and reports it via syslog(3)
> > > with logging facility LOG_DAEMON.
> > >
> > > Is "battery" really meant here? Should that be the AC power?
> > > Batteries are typically not being reconnected while running ...
>
> They certainly can be, either while on external power, or in the case of
> machines with multiple batteries (several generations of X series ThinkPads
> have both internal and external batteries, so you can swap without powering
> down even while on battery power). But yes the common case would be
> external power.
>
> > > (The manpage calls it "external power", "line current"
> > > and "AC" interchangably.)
> > >
> > > Jan
> > >
> >
> > hi.
> >
> > i think you're right that the text is off. the author possibly meant to
> > say battery was charging or discharging.
> >
> > anyway, if i don;t hear any reason not to soon, i'll commit your
> > suggested diff (which i think is simpler and makes sense).
>
> Why be inaccurate when we don't need to be - it's very uncommon to have
> a machine with a battery with an AC input. "External power" would make
> more sense.
i have to say, i don;t understand the distinction. i thought a
laptop was "a machine with a battery with an AC input" (or, at
least, *and* an AC input). however i committed a diff with your
text ("external power") knowing that you are undoubtedly correct ;)
jmc
Re: apmd(8): reconnecting AC, not battery
On May 28 10:34:35, s...@spacehopper.org wrote: > On 2022/05/28 06:52, Jason McIntyre wrote: > > On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote: > > > apmd says: > > > > > > When the power status changes (battery is connected or disconnected), > > > apmd fetches the current status and reports it via syslog(3) > > > with logging facility LOG_DAEMON. > > > > > > Is "battery" really meant here? Should that be the AC power? > > > Batteries are typically not being reconnected while running ... > > They certainly can be, either while on external power, or in the case of > machines with multiple batteries (several generations of X series ThinkPads > have both internal and external batteries, so you can swap without powering > down even while on battery power). But yes the common case would be > external power. > > > > (The manpage calls it "external power", "line current" > > > and "AC" interchangably.) > > > > > > Jan > > > > > > > hi. > > > > i think you're right that the text is off. the author possibly meant to > > say battery was charging or discharging. > > > > anyway, if i don;t hear any reason not to soon, i'll commit your > > suggested diff (which i think is simpler and makes sense). > > Why be inaccurate when we don't need to be - it's very uncommon to have > a machine with a battery with an AC input. "External power" would make > more sense. I never liked the AC nomenclature either; it's battery vs wall socket, not AC vs DC. Feel free to change the wording of course. Jan
Re: Possible segfault in iked
On Sat, May 28, 2022 at 03:17:07PM +0200, Gerhard Roth wrote:
> Hi,
>
> since there's a 'sa_free(sa)' followed by a 'continue' a few lines down
> from the RB_FOREACH(), we must use RB_FOREACH_SAFE() instead.
>
> Gerhard
ok tobhe@
>
>
> Index: sbin/iked/ikev2.c
> ===
> RCS file: /cvs/src/sbin/iked/ikev2.c,v
> retrieving revision 1.346
> diff -u -p -C6 -u -p -r1.346 ikev2.c
> --- sbin/iked/ikev2.c 14 Mar 2022 12:58:55 - 1.346
> +++ sbin/iked/ikev2.c 28 May 2022 13:08:29 -
> @@ -223,13 +223,13 @@ ikev2_shutdown(struct privsep_proc *p)
> }
>
> int
> ikev2_dispatch_parent(int fd, struct privsep_proc *p, struct imsg *imsg)
> {
> struct iked *env = p->p_env;
> - struct iked_sa *sa;
> + struct iked_sa *sa, *satmp;
> struct iked_policy *pol, *old;
>
> switch (imsg->hdr.type) {
> case IMSG_CTL_RESET:
> return (config_getreset(env, imsg));
> case IMSG_CTL_COUPLE:
> @@ -242,13 +242,13 @@ ikev2_dispatch_parent(int fd, struct pri
> timer_del(env, >sc_inittmr);
> TAILQ_FOREACH(pol, >sc_policies, pol_entry) {
> if (policy_generate_ts(pol) == -1)
> fatalx("%s: too many traffic selectors",
> __func__);
> }
> /* Find new policies for dangling SAs */
> - RB_FOREACH(sa, iked_sas, >sc_sas) {
> + RB_FOREACH_SAFE(sa, iked_sas, >sc_sas, satmp) {
> if (sa->sa_state != IKEV2_STATE_ESTABLISHED) {
> sa_state(env, sa, IKEV2_STATE_CLOSING);
> ikev2_ike_sa_setreason(sa, "reload");
> sa_free(env, sa);
> continue;
> }
>
Possible segfault in iked
Hi,
since there's a 'sa_free(sa)' followed by a 'continue' a few lines down
from the RB_FOREACH(), we must use RB_FOREACH_SAFE() instead.
Gerhard
Index: sbin/iked/ikev2.c
===
RCS file: /cvs/src/sbin/iked/ikev2.c,v
retrieving revision 1.346
diff -u -p -C6 -u -p -r1.346 ikev2.c
--- sbin/iked/ikev2.c 14 Mar 2022 12:58:55 - 1.346
+++ sbin/iked/ikev2.c 28 May 2022 13:08:29 -
@@ -223,13 +223,13 @@ ikev2_shutdown(struct privsep_proc *p)
}
int
ikev2_dispatch_parent(int fd, struct privsep_proc *p, struct imsg *imsg)
{
struct iked *env = p->p_env;
- struct iked_sa *sa;
+ struct iked_sa *sa, *satmp;
struct iked_policy *pol, *old;
switch (imsg->hdr.type) {
case IMSG_CTL_RESET:
return (config_getreset(env, imsg));
case IMSG_CTL_COUPLE:
@@ -242,13 +242,13 @@ ikev2_dispatch_parent(int fd, struct pri
timer_del(env, >sc_inittmr);
TAILQ_FOREACH(pol, >sc_policies, pol_entry) {
if (policy_generate_ts(pol) == -1)
fatalx("%s: too many traffic selectors",
__func__);
}
/* Find new policies for dangling SAs */
- RB_FOREACH(sa, iked_sas, >sc_sas) {
+ RB_FOREACH_SAFE(sa, iked_sas, >sc_sas, satmp) {
if (sa->sa_state != IKEV2_STATE_ESTABLISHED) {
sa_state(env, sa, IKEV2_STATE_CLOSING);
ikev2_ike_sa_setreason(sa, "reload");
sa_free(env, sa);
continue;
}
smime.p7s
Description: S/MIME cryptographic signature
Re: apmd(8): reconnecting AC, not battery
On 2022/05/28 06:52, Jason McIntyre wrote: > On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote: > > apmd says: > > > > When the power status changes (battery is connected or disconnected), > > apmd fetches the current status and reports it via syslog(3) > > with logging facility LOG_DAEMON. > > > > Is "battery" really meant here? Should that be the AC power? > > Batteries are typically not being reconnected while running ... They certainly can be, either while on external power, or in the case of machines with multiple batteries (several generations of X series ThinkPads have both internal and external batteries, so you can swap without powering down even while on battery power). But yes the common case would be external power. > > (The manpage calls it "external power", "line current" > > and "AC" interchangably.) > > > > Jan > > > > hi. > > i think you're right that the text is off. the author possibly meant to > say battery was charging or discharging. > > anyway, if i don;t hear any reason not to soon, i'll commit your > suggested diff (which i think is simpler and makes sense). Why be inaccurate when we don't need to be - it's very uncommon to have a machine with a battery with an AC input. "External power" would make more sense.
env -S
I would like to see the non standard -S option added to env. Over the years I have come across the situation where multiple arguments are needed in the shebang line. I end up having to write a one line script that wraps the required arguments and then call that wrapper in the shebang. I'm ready to move forward. Both FreeBSD and GNU env have -S and I would like to see OpenBSD join the party. Is there any reason env shouldn't get -S? How can I go about getting -S added? Are there limitations on using the source from FreeBSD? Is anyone willing to help me code this? -alfred
