Re: ldapd warning
On Sun, Nov 29, 2020 at 08:02:45AM +0100, Emil Engler wrote: > It can overflow! Please check for the positivity and width of size_t before! What can overflow? ret is guaranteed to be non-negative before the cast. As for the width (which would be about truncation, not overflow): while the standard allows for size_t to be an unsigned integer type as small as 16 bits, we generally assume that sizeof(size_t) >= sizeof(int). I don't think I've ever seen a width check ensuring this in our sources. > > Cheers, > Emil > > On 11/28/20 11:20 PM, Theo Buehler wrote: > > /usr/src/usr.sbin/ldapd/util.c:46:21: warning: comparison of integers of > > different signs: > >'int' and 'size_t' (aka 'unsigned long') [-Wsign-compare] > > if (ret < 0 || ret >= size) > > ~~~ ^ > > > > This has been around for a while. I forgot that I had this patch in my > > tree. > > > > Index: util.c > > === > > RCS file: /cvs/src/usr.sbin/ldapd/util.c,v > > retrieving revision 1.12 > > diff -u -p -r1.12 util.c > > --- util.c 24 Oct 2019 12:39:26 - 1.12 > > +++ util.c 4 Aug 2020 07:14:33 - > > @@ -43,7 +43,7 @@ bsnprintf(char *str, size_t size, const > > va_start(ap, format); > > ret = vsnprintf(str, size, format, ap); > > va_end(ap); > > - if (ret < 0 || ret >= size) > > + if (ret < 0 || (size_t)ret >= size) > > return 0; > > return 1; > > >
Re: ldapd warning
It can overflow! Please check for the positivity and width of size_t before! Cheers, Emil On 11/28/20 11:20 PM, Theo Buehler wrote: /usr/src/usr.sbin/ldapd/util.c:46:21: warning: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Wsign-compare] if (ret < 0 || ret >= size) ~~~ ^ This has been around for a while. I forgot that I had this patch in my tree. Index: util.c === RCS file: /cvs/src/usr.sbin/ldapd/util.c,v retrieving revision 1.12 diff -u -p -r1.12 util.c --- util.c 24 Oct 2019 12:39:26 - 1.12 +++ util.c 4 Aug 2020 07:14:33 - @@ -43,7 +43,7 @@ bsnprintf(char *str, size_t size, const va_start(ap, format); ret = vsnprintf(str, size, format, ap); va_end(ap); - if (ret < 0 || ret >= size) + if (ret < 0 || (size_t)ret >= size) return 0; return 1;
vmm(4): cpuid leaf 0x15 fixes clock speed problem in Linux guest [PATCH]
Hello!
On a host with Invariant TSC, vmm advertises to the guest support for
cpuid leaves up to 0x15 (in the response to leaf 0x00), but when the
guest asks for leaves higher than the host's cpuid level,
vmm_handle_cpuid serves the response for host's highest cpuid leaf
instead.
A Linux guest asks for cpuid leaf 0x15 in native_calibrate_tsc[1] and it
instead gets the answer say for 0x0B because that is the host's cpuid
level.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/kernel/tsc.c?h=52f6ded2a377#n628
The Linux guest then ends up using TSC as its clock source with a wild
conversion factor. Its clock runs say 6 times slower than real-time.
A 10-second sleep takes 60 seconds and the clock drifts faster than ntpd
can correct.
The patch below moves the logic that decides to emulate cpuid leaves up
in the code, so that the advertisement agrees with what will be actually
handled.
That fixes the clock speed problem in a Linux guest under vmm on my
laptop.
The host (laptop) is "Intel(R) Celeron(R) CPU N2940 @ 1.83GHz, 1833.34
MHz, 06-37-08" running OpenBSD/amd64 6.8-current. The CPU supports ITSC:
machdep.tscfreq=186925
machdep.invarianttsc=1
The host's cpuid_level is 11 (0x0B).
The guest is Linux 5.4.72 (from alpine-virt-3.12.1-x86_64.iso). Without
this patch in vmm.c, the guest's clock source selection goes like this:
$ grep -i tsc linux_dmesg_before.txt
[0.00] tsc: Fast TSC calibration failed
[0.02] tsc: Using PIT calibration value
[0.02] tsc: Detected 11004.239 MHz processor
[0.02] clocksource: tsc-early: mask: 0x max_cycles:
0x9e9ea4eaf13, max_idle_ns: 440795518199 ns
[3.552382] clocksource: Switched to clocksource tsc-early
[3.711267] clocksource: tsc: mask: 0x max_cycles:
0x9e9ea4eaf13, max_idle_ns: 440795518199 ns
[3.715133] clocksource: Switched to clocksource tsc
With the patch applied on the host, the Linux guest detects the correct CPU
speed and its clock runs at the correct speed:
$ grep -i tsc linux_dmesg_after.txt
[0.00] tsc: Fast TSC calibration failed
[0.00] tsc: Detected 1833.300 MHz processor
[0.642162] clocksource: tsc-early: mask: 0x max_cycles:
0x34da15b7553, max_idle_ns: 881590669491 ns
[1.404442] clocksource: Switched to clocksource tsc-early
[1.722187] clocksource: tsc: mask: 0x max_cycles:
0x34da15b7553, max_idle_ns: 881590669491 ns
[1.730739] clocksource: Switched to clocksource tsc
The patch is here inline. Full dmesgs are attached. Please let me know
what you think. Thank you!
Index: ./arch/amd64/amd64/vmm.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v
retrieving revision 1.274
diff -u -p -u -r1.274 vmm.c
--- ./arch/amd64/amd64/vmm.c10 Sep 2020 17:03:03 - 1.274
+++ ./arch/amd64/amd64/vmm.c28 Nov 2020 08:33:37 -
@@ -6592,6 +6592,7 @@ vmm_handle_cpuid(struct vcpu *vcpu)
struct vmcb *vmcb;
uint32_t eax, ebx, ecx, edx;
struct vmx_msr_store *msr_store;
+ int vmm_cpuid_level;
if (vmm_softc->mode == VMM_MODE_VMX ||
vmm_softc->mode == VMM_MODE_EPT) {
@@ -6625,6 +6626,17 @@ vmm_handle_cpuid(struct vcpu *vcpu)
vcpu->vc_gueststate.vg_rip += insn_length;
/*
+* If the host CPU does not implement the CPUID leaf 0x15
+* ("Time Stamp Counter and Nominal Core Crystal Clock Information")
+* and TSC is a reliable time source, then we will emulate the leaf
+* for the guest. This helps a Linux guest pick TSC as the clock
source.
+*/
+ if (cpuid_level < 0x15 && tsc_is_invariant)
+ vmm_cpuid_level = 0x15;
+ else
+ vmm_cpuid_level = cpuid_level;
+
+ /*
* "If a value entered for CPUID.EAX is higher than the maximum input
* value for basic or extended function for that processor then the
* data for the highest basic information leaf is returned."
@@ -6638,13 +6650,13 @@ vmm_handle_cpuid(struct vcpu *vcpu)
* going to reassign it a new value (based on the input parameter)
* later anyway.
*/
- if ((*rax > cpuid_level && *rax < 0x4000) ||
+ if ((*rax > vmm_cpuid_level && *rax < 0x4000) ||
(*rax > curcpu()->ci_pnfeatset)) {
DPRINTF("%s: invalid cpuid input leaf 0x%llx, guest rip="
"0x%llx - resetting to 0x%x\n", __func__, *rax,
vcpu->vc_gueststate.vg_rip - insn_length,
- cpuid_level);
- *rax = cpuid_level;
+ vmm_cpuid_level);
+ *rax = vmm_cpuid_level;
}
/*
@@ -6664,10 +6676,7 @@ vmm_handle_cpuid(struct vcpu *vcpu)
switch (*rax) {
case 0x00: /* Max level and vendor ID */
- if (cpuid_level < 0x15 && tsc_is_i
Re: kvm_getfiles and KERN_FILE_BYFILE
On Thu, Nov 26, 2020 at 1:08 PM Martijn van Duren < openbsd+t...@list.imperialat.at> wrote: > I'm currently playing around a bit with kvm_getfiles and found that I > couldn't use KERN_FILE_BYFILE with DTYPE_SOCKET. > According to kvm_getfiles(3): > For KERN_FILE_BYFILE the recognized file types are defined in > : > >DTYPE_VNODE files and devices >DTYPE_SOCKET sockets, regardless of domain >DTYPE_PIPEpipes and FIFOs >DTYPE_KQUEUE kqueues > > But these defines are under ifdef _KERNEL. > > So is the manpage lying here, or should the defines be hoisted out > of the ifdef? > Let's go ahead and hoist them: FreeBSD and NetBSD already have. If possible, the diff to do that should also simplify the #include bits in these files: usr.bin/netstat/inet.c usr.bin/fstat/fstat.c usr.bin/fstat/fuser.c usr.bin/systat/netstat.c Philip Guenther
ldapd warning
/usr/src/usr.sbin/ldapd/util.c:46:21: warning: comparison of integers of different signs: 'int' and 'size_t' (aka 'unsigned long') [-Wsign-compare] if (ret < 0 || ret >= size) ~~~ ^ This has been around for a while. I forgot that I had this patch in my tree. Index: util.c === RCS file: /cvs/src/usr.sbin/ldapd/util.c,v retrieving revision 1.12 diff -u -p -r1.12 util.c --- util.c 24 Oct 2019 12:39:26 - 1.12 +++ util.c 4 Aug 2020 07:14:33 - @@ -43,7 +43,7 @@ bsnprintf(char *str, size_t size, const va_start(ap, format); ret = vsnprintf(str, size, format, ap); va_end(ap); - if (ret < 0 || ret >= size) + if (ret < 0 || (size_t)ret >= size) return 0; return 1;
Re: stdio: fclose(3), fopen(3): intended locking hierarchy?
On Fri, Nov 27, 2020 at 10:35 PM Philip Guenther wrote:
...
> So yeah, maybe it does work to:
> 1) make __sfp() FLOCKFILE() the allocated FILE before unlocking sfp_mutex
> 2) update f{,d,mem,un}open() and open_*memstream() to match (1), unlocking
>in all paths when the FILE is safe to be accessed by _fwalk(), and
> locking
>sfp_mutex around the zeroing of _flags.
> 3) make fclose() and freopen() also lock sfp_mutex around the zeroing of
> _flags
>(should add an _frelease() to findfp.c that does this dance for (2) and
> (3))
> 4) make _fwalk() take sfp_mutex, and maybe also a FILE* so the setting of
>__SIGN can be done under the lock?
>
5) decide how/whether to handle adjust the FLOCKFILE placement in the
> _fwalk()
>tree: is the testing of the "is line-buffered" flag in lflush() safe
> without
>a lock? Mumble...
>
After thinking through states more, #4 isn't safe: _fwalk() can't take
sfp_mutex because it's called from __srefill() which has its FILE locked,
which would reverse the order: two concurrent calls to __srefill() from
line-buffered FILEs could have one in _fwalk() blocking on locking the
other, while the other blocks on the sfp_mutex for _fwalk().
Hmm, there's currently a loop between two __srefill() calls like that, as
there's nothing to force visibility of the __SIGN flag between CPUs so they
could try to lock each other. Grrr.
Time to check other BSDs and see if they have a good solution to this...
Philip
>
> Now, back to that first assumption: if you're not willing to assume
> it then the "is allocated" test needs to not use _flags but be some
> other state change which can be relied on to not have false-positives,
> but otherwise the other bits above still apply, I believe. Would
> be a major ABI change...and if we do that there's like 3 other
> things we should do at the same time (merge __sfileext into FILE,
> grow _file to an int, and maybe move the recursive mutex for
> f{,un}lockfile() into FILE?)
>
>
> Philip Guenther
>
>
Re: Fan Management Framework
Hello Constantine, Thanks for your feedback. And no, I wasn't aware about your previous patch set. Interesting background you have provided on that topic though. In the meantime I also received internal feedback from other developers, and as you already have mentioned it, there is no interest in adding fan control to base, mainly because of the obvious reasons that a) it adds too much complexity, and b) can lead to miss configurations which harm your hardware instead of protecting it. That's totally understandable and fine for me. I wasn't really aware that similar discussions already did take place in the past, otherwise I wouldn't have brought up the topic once again :-) Cheers, Marcus On Sat, 28 Nov 2020 12:45:20 -0800 "Constantine A. Murenin" wrote: > Hi Marcus, > > Sounds interesting! I don't know if you've seen it, but I did a > similar patchset back in the day, alas for the common PC desktops with > the lm(4) sensors; http://sensors.cnst.su/fanctl/ . However, there > hasn't been as much interest in fan control on OpenBSD as I had > initially expected when I got into the sensors in the mid-noughties; > and nowadays with cloud computing and cheap laptops, netbooks and > embedded ARM with automatic fan control and passive cooling, there are > easier options for Quiet Computing than using a desktop with an lm(4) > chip and active cooling. > > I also got the impression that fan control is incompatible with > OpenBSD philosophy where system stability and ease-of-use is preferred > to having lots of configuration options, especially those where you > can allegedly shoot yourself in the foot, so, per my understanding, > sadly, noone else was particularly interested in having a generic fan > control interface merged into the tree. > > On a more practical point, there's a variation between the different > devices on how to set fan control; for example, the asmc(4) patch you > have lets you set a min/max RPM, some wbsio(4)/lm(4) chips let you set > a target fan-speed and/or target temperature cruise (personally, I > think the target temperature cruise makes the most sense for fan > control), other lm(4) chips only let you set PWM duty cycle directly > (thus any form of cruise would then have to be implemented in > software, which would be less reliable and much more prone to > overheating should any of the software components crash), and ThinkPad > ACPI simply has levels between 0 and 7 or "8". > > I've implemented access to most of these hardware fan control features > of wbsio(4) / lm(4) in my patch just on top of the sensors framework > -- http://sensors.cnst.su/fanctl/ -- and I think it should be pretty > intuitive to use and understand if you do care about lm(4)-based fan > control. However, these variations in control options are probably > the reason why many third-party tools like SpeedFan on Windows have > only implemented the most basic PWM duty cycle support for each chip > on a hardware level, and instead rely on having the software perform > the monitoring/control loop for things like temperature cruise, even > where the underlying chips are capable of doing it themselves > autonomously (after first being programmed by the software), because > this way the user interface and experience is more clear and > consistent across the board (at the cost of reduced reliability if > SpeedFan app or Windows OS crash). > > I'd imagine these variations, together with fan control being deemed > optional by many developers, make it a somewhat hard sell for > integration in base, which is kind of sad, because all those > autonomous temperature cruise options in Winbond's lm(4) chips are > pretty neat, and something that I'd wish modern laptops would actually > offer in any way (as most of today's laptops -- including Apple > MacBook macOS ones -- are completely unusable on the lap due to the > terrible thermal profiles and a seeming lack of temperature-based > control options for their active cooling components). > > Cheers, > Constantine. > > On Fri, 27 Nov 2020 at 09:08, Marcus Glocker wrote: > > > > Hi, > > > > I recently decided to replace MacOSX on my iMac11,3 27" with > > OpenBSD. During the MacOSX times I had to replace the broken HDD > > with a new SSD. The new SSD didn't offer pins to attach the sensor > > cable back, which was previously attached to the HDD, so I left it > > loose. This caused the HDD fan to spin up to maximum over time. > > On MacOSX there are some fan control programs with which I could > > control the fan speed. I almost forgot about that "fix" over time, > > but installing OpenBSD on that machine remembered me of it - You > > can't overhear it :-) > > > > That made me play around with asmc(4), where I noticed you can not > > only read the fan properties, but also set them. I initially was > > thinking to make sysctl(8) able to set fan speeds, but what I could > > see is that the fan framework there seems to be designed to read > > only. Instead of poking aro
Re: Fwd: gre(4): mgre
On Sat, Nov 28, 2020 at 09:09:19PM +0100, Pierre Emeriaud wrote: > Le sam. 28 nov. 2020 ?? 17:54, Jason McIntyre a ??crit : > > an mgre example seems conspicuous by its absence, so i'd say adding one > > seems helpful. some comments inline: > > Thanks Jason for reviewing this patch. > > > > +.Pp > > > +In this example the host A has an outer IP of 198.51.100.12, host > > > +B has 203.0.113.27, and host C has 203.0.113.254. Adressing within > > > > new sentence, new line > > s/Adressing/Addressing/ > Done > > > > +the tunnel is done using 192.0.2.0/24. > > > > s/./:/ > Done > > > > +.Bd -literal > > add "-offset indent" to match the other examples > Done, although I copied this block from gre example, so there's > another occurrence here which I didn't touch. > yes, sorry, that's my mistake. i think the width of the gre example probably caused that. so i think you should keep your original text (i.e. no indent for the artwork; indent for commands). > > > +The same tunnel interface can be then used between host B and C by > > s/be then/then be/ > Done > > > finally: > > $ mandoc -Tlint gre.4 > > make sure the diff doesn;t add any issues! > four whitespaces removed. > grand. ok as far as i'm concerned. jmc > Index: share/man/man4/gre.4 > === > RCS file: /cvs/src/share/man/man4/gre.4,v > retrieving revision 1.79 > diff -u -p -u -r1.79 gre.4 > --- share/man/man4/gre.418 Nov 2020 16:19:54 - 1.79 > +++ share/man/man4/gre.428 Nov 2020 20:01:16 - > @@ -455,6 +455,67 @@ In most cases the following should work: > .Bd -literal -offset indent > pass quick on gre proto gre no state > .Ed > +.Ss Point-to-Multipoint Layer 3 GRE tunnel interfaces (mgre) example > +.Nm mgre > +can be used to build a point-to-multipoint tunnel network to several > +hosts using a single > +.Nm mgre > +interface. > +.Pp > +In this example the host A has an outer IP of 198.51.100.12, host > +B has 203.0.113.27, and host C has 203.0.113.254. > +.Pp > +Addressing within the tunnel is done using 192.0.2.0/24: > +.Bd -literal -offset indent > ++--- Host B > + / > + / > +Host A --- tunnel ---+ > + \e > + \e > ++--- Host C > +.Ed > +.Pp > +On Host A: > +.Bd -literal -offset indent > +# ifconfig mgreN create > +# ifconfig mgreN tunneladdr 198.51.100.12 > +# ifconfig mgreN inet 192.0.2.1 netmask 0xff00 up > +.Ed > +.Pp > +On Host B: > +.Bd -literal -offset indent > +# ifconfig mgreN create > +# ifconfig mgreN tunneladdr 203.0.113.27 > +# ifconfig mgreN inet 192.0.2.2 netmask 0xff00 up > +.Ed > +.Pp > +On Host C: > +.Bd -literal -offset indent > +# ifconfig mgreN create > +# ifconfig mgreN tunneladdr 203.0.113.254 > +# ifconfig mgreN inet 192.0.2.3 netmask 0xff00 up > +.Ed > +.Pp > +To reach Host B over the tunnel (from Host A), there has to be a > +route on Host A specifying the next-hop: > +.Pp > +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN > +.Pp > +Similarly, to reach Host A over the tunnel from Host B, a route must > +be present on B with A's outer IP as next-hop: > +.Pp > +.Dl # route add -host 192.0.2.1 198.51.100.12 -iface -ifp mgreN > +.Pp > +The same tunnel interface can then be used between host B and C by > +adding the appropriate routes, making the network any-to-any instead > +of hub-and-spoke: > +.Pp > +On Host B: > +.Dl # route add -host 192.0.2.3 203.0.113.254 -iface -ifp mgreN > +.Pp > +On Host C: > +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN > .Ss Point-to-Point Ethernet over GRE tunnel interfaces (egre) example > .Nm egre > can be used to carry Ethernet traffic between two endpoints over >
Re: Fan Management Framework
Hi Marcus, Sounds interesting! I don't know if you've seen it, but I did a similar patchset back in the day, alas for the common PC desktops with the lm(4) sensors; http://sensors.cnst.su/fanctl/ . However, there hasn't been as much interest in fan control on OpenBSD as I had initially expected when I got into the sensors in the mid-noughties; and nowadays with cloud computing and cheap laptops, netbooks and embedded ARM with automatic fan control and passive cooling, there are easier options for Quiet Computing than using a desktop with an lm(4) chip and active cooling. I also got the impression that fan control is incompatible with OpenBSD philosophy where system stability and ease-of-use is preferred to having lots of configuration options, especially those where you can allegedly shoot yourself in the foot, so, per my understanding, sadly, noone else was particularly interested in having a generic fan control interface merged into the tree. On a more practical point, there's a variation between the different devices on how to set fan control; for example, the asmc(4) patch you have lets you set a min/max RPM, some wbsio(4)/lm(4) chips let you set a target fan-speed and/or target temperature cruise (personally, I think the target temperature cruise makes the most sense for fan control), other lm(4) chips only let you set PWM duty cycle directly (thus any form of cruise would then have to be implemented in software, which would be less reliable and much more prone to overheating should any of the software components crash), and ThinkPad ACPI simply has levels between 0 and 7 or "8". I've implemented access to most of these hardware fan control features of wbsio(4) / lm(4) in my patch just on top of the sensors framework -- http://sensors.cnst.su/fanctl/ -- and I think it should be pretty intuitive to use and understand if you do care about lm(4)-based fan control. However, these variations in control options are probably the reason why many third-party tools like SpeedFan on Windows have only implemented the most basic PWM duty cycle support for each chip on a hardware level, and instead rely on having the software perform the monitoring/control loop for things like temperature cruise, even where the underlying chips are capable of doing it themselves autonomously (after first being programmed by the software), because this way the user interface and experience is more clear and consistent across the board (at the cost of reduced reliability if SpeedFan app or Windows OS crash). I'd imagine these variations, together with fan control being deemed optional by many developers, make it a somewhat hard sell for integration in base, which is kind of sad, because all those autonomous temperature cruise options in Winbond's lm(4) chips are pretty neat, and something that I'd wish modern laptops would actually offer in any way (as most of today's laptops -- including Apple MacBook macOS ones -- are completely unusable on the lap due to the terrible thermal profiles and a seeming lack of temperature-based control options for their active cooling components). Cheers, Constantine. On Fri, 27 Nov 2020 at 09:08, Marcus Glocker wrote: > > Hi, > > I recently decided to replace MacOSX on my iMac11,3 27" with OpenBSD. > During the MacOSX times I had to replace the broken HDD with a new SSD. > The new SSD didn't offer pins to attach the sensor cable back, which > was previously attached to the HDD, so I left it loose. This caused > the HDD fan to spin up to maximum over time. On MacOSX there are some > fan control programs with which I could control the fan speed. I > almost forgot about that "fix" over time, but installing OpenBSD on > that machine remembered me of it - You can't overhear it :-) > > That made me play around with asmc(4), where I noticed you can not > only read the fan properties, but also set them. I initially was > thinking to make sysctl(8) able to set fan speeds, but what I could > see is that the fan framework there seems to be designed to read > only. Instead of poking around further in sysctl(8), I had the idea > to create a small fan(4) framework layer, which can be controlled > through a device by using a fanctl(8) user-land program. > > I don't know if there are other fan sensor controllers which would > allow fan properties control. If yes, they potentially could attach > to the same fan framework. If not, the fan framework probably doesn't > make much sense only to be used by asmc(4). > > Some example: > > ... > asmc0 at acpi0: SMC_ (smc-piketon) addr 0x300/0x20: rev 1.59f559, 297 > keys > fan0 at asmc0 > ... > > bigmac# sysctl | grep fan > hw.sensors.asmc0.fan0=998 RPM (ODD, right mid rear) > hw.sensors.asmc0.fan1=3677 RPM (HDD, center mid rear) > hw.sensors.asmc0.fan2=939 RPM (CPU, left lower rear) > > bigmac# ./fanctl > driver=asmc0 > fan0.id=ODD, right mid rear > fan0.a
Re: Fwd: gre(4): mgre
Le sam. 28 nov. 2020 à 17:54, Jason McIntyre a écrit : > an mgre example seems conspicuous by its absence, so i'd say adding one > seems helpful. some comments inline: Thanks Jason for reviewing this patch. > > +.Pp > > +In this example the host A has an outer IP of 198.51.100.12, host > > +B has 203.0.113.27, and host C has 203.0.113.254. Adressing within > > new sentence, new line > s/Adressing/Addressing/ Done > > +the tunnel is done using 192.0.2.0/24. > > s/./:/ Done > > +.Bd -literal > add "-offset indent" to match the other examples Done, although I copied this block from gre example, so there's another occurrence here which I didn't touch. > > +The same tunnel interface can be then used between host B and C by > s/be then/then be/ Done > finally: > $ mandoc -Tlint gre.4 > make sure the diff doesn;t add any issues! four whitespaces removed. Index: share/man/man4/gre.4 === RCS file: /cvs/src/share/man/man4/gre.4,v retrieving revision 1.79 diff -u -p -u -r1.79 gre.4 --- share/man/man4/gre.418 Nov 2020 16:19:54 - 1.79 +++ share/man/man4/gre.428 Nov 2020 20:01:16 - @@ -455,6 +455,67 @@ In most cases the following should work: .Bd -literal -offset indent pass quick on gre proto gre no state .Ed +.Ss Point-to-Multipoint Layer 3 GRE tunnel interfaces (mgre) example +.Nm mgre +can be used to build a point-to-multipoint tunnel network to several +hosts using a single +.Nm mgre +interface. +.Pp +In this example the host A has an outer IP of 198.51.100.12, host +B has 203.0.113.27, and host C has 203.0.113.254. +.Pp +Addressing within the tunnel is done using 192.0.2.0/24: +.Bd -literal -offset indent ++--- Host B + / + / +Host A --- tunnel ---+ + \e + \e ++--- Host C +.Ed +.Pp +On Host A: +.Bd -literal -offset indent +# ifconfig mgreN create +# ifconfig mgreN tunneladdr 198.51.100.12 +# ifconfig mgreN inet 192.0.2.1 netmask 0xff00 up +.Ed +.Pp +On Host B: +.Bd -literal -offset indent +# ifconfig mgreN create +# ifconfig mgreN tunneladdr 203.0.113.27 +# ifconfig mgreN inet 192.0.2.2 netmask 0xff00 up +.Ed +.Pp +On Host C: +.Bd -literal -offset indent +# ifconfig mgreN create +# ifconfig mgreN tunneladdr 203.0.113.254 +# ifconfig mgreN inet 192.0.2.3 netmask 0xff00 up +.Ed +.Pp +To reach Host B over the tunnel (from Host A), there has to be a +route on Host A specifying the next-hop: +.Pp +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN +.Pp +Similarly, to reach Host A over the tunnel from Host B, a route must +be present on B with A's outer IP as next-hop: +.Pp +.Dl # route add -host 192.0.2.1 198.51.100.12 -iface -ifp mgreN +.Pp +The same tunnel interface can then be used between host B and C by +adding the appropriate routes, making the network any-to-any instead +of hub-and-spoke: +.Pp +On Host B: +.Dl # route add -host 192.0.2.3 203.0.113.254 -iface -ifp mgreN +.Pp +On Host C: +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN .Ss Point-to-Point Ethernet over GRE tunnel interfaces (egre) example .Nm egre can be used to carry Ethernet traffic between two endpoints over
Re: Fwd: gre(4): mgre
On Sat, Nov 28, 2020 at 12:18:26PM +0100, Pierre Emeriaud wrote: > Hi, > > mgre(4) does not appear to be documented well, I had to find David's > "mgre(4): point-to-multipoint gre tunnels" mail to understand how gre > endpoints are found. > > hi. an mgre example seems conspicuous by its absence, so i'd say adding one seems helpful. some comments inline: > > Index: share/man/man4/gre.4 > === > RCS file: /cvs/src/share/man/man4/gre.4,v > retrieving revision 1.79 > diff -u -p -u -r1.79 gre.4 > --- share/man/man4/gre.418 Nov 2020 16:19:54 - 1.79 > +++ share/man/man4/gre.427 Nov 2020 23:29:39 - > @@ -455,6 +455,66 @@ In most cases the following should work: > .Bd -literal -offset indent > pass quick on gre proto gre no state > .Ed > +.Ss Point-to-Multipoint Layer 3 GRE tunnel interfaces (mgre) example > +.Nm mgre > +can be used to build a point-to-multipoint tunnel network to several > +hosts using a single > +.Nm mgre > +interface. > +.Pp > +In this example the host A has an outer IP of 198.51.100.12, host > +B has 203.0.113.27, and host C has 203.0.113.254. Adressing within new sentence, new line s/Adressing/Addressing/ > +the tunnel is done using 192.0.2.0/24. s/./:/ > +.Bd -literal add "-offset indent" to match the other examples > ++--- Host B > + / > + / > +Host A --- tunnel ---+ > + \e > + \e > ++--- Host C > +.Ed > +.Pp > +On Host A: > +.Bd -literal -offset indent > +# ifconfig mgreN create > +# ifconfig mgreN tunneladdr 198.51.100.12 > +# ifconfig mgreN inet 192.0.2.1 netmask 0xff00 up > +.Ed > +.Pp > +On Host B: > +.Bd -literal -offset indent > +# ifconfig mgreN create > +# ifconfig mgreN tunneladdr 203.0.113.27 > +# ifconfig mgreN inet 192.0.2.2 netmask 0xff00 up > +.Ed > +.Pp > +On Host C: > +.Bd -literal -offset indent > +# ifconfig mgreN create > +# ifconfig mgreN tunneladdr 203.0.113.254 > +# ifconfig mgreN inet 192.0.2.3 netmask 0xff00 up > +.Ed > +.Pp > +To reach Host B over the tunnel (from Host A), there has to be a > +route on Host A specifying the next-hop: > +.Pp > +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN > +.Pp > +Similarly, to reach Host A over the tunnel from Host B, a route must > +be present on B with A's outer IP as next-hop: > +.Pp > +.Dl # route add -host 192.0.2.1 198.51.100.12 -iface -ifp mgreN > +.Pp > +The same tunnel interface can be then used between host B and C by s/be then/then be/ > +adding the appropriate routes, making the network any-to-any instead > +of hub-and-spoke: > +.Pp > +On Host B: > +.Dl # route add -host 192.0.2.3 203.0.113.254 -iface -ifp mgreN > +.Pp > +On Host C: > +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN > .Ss Point-to-Point Ethernet over GRE tunnel interfaces (egre) example > .Nm egre > can be used to carry Ethernet traffic between two endpoints over > finally: $ mandoc -Tlint gre.4 make sure the diff doesn;t add any issues! jmc
Re: sio_open.3: clarify what sio_start() does
Hi Alexandre, Alexandre Ratchov wrote on Fri, Nov 27, 2020 at 07:05:27PM +0100: > this wording is shorter and more precise and complete. This looks good mdoc(7)-wise, so go ahead, but please consider the two nits below when committing. Yours, Ingo > Index: sio_open.3 > === > RCS file: /cvs/src/lib/libsndio/sio_open.3,v > retrieving revision 1.51 > diff -u -p -r1.51 sio_open.3 > --- sio_open.320 Nov 2020 12:09:45 - 1.51 > +++ sio_open.327 Nov 2020 18:02:16 - > @@ -387,17 +387,17 @@ bitmasks should always be used. > .Ss Starting and stopping the device > The > .Fn sio_start > -function puts the device in a waiting state: > -the device will wait for playback data to be provided > -(using the > -.Fn sio_write > -function). > -Once enough data is queued to ensure that play buffers > -will not underrun, actual playback is started automatically. > -If record mode only is selected, then recording starts > -immediately. > +function prepares the devices to start. As Erico already noticed, i think you need to go back to the singular here, s/devices/device/. Otherwise, if changing to the plural is intentional, a clarification might make sense which other device(s) apart from .Fa hdl the text intends to talk about. > +Once the play buffer is full, i.e. This line should be: Once the play buffer is full, i.e.\& If a dot at the end of an input line is not a full stop, it needs escaping to prevent excessive horizontal spacing. > +.Fa sio_par.bufsz > +samples are queued with > +.Fn sio_write , > +playback starts automatically. > +If record mode only is selected, then > +.Fn sio_start > +starts recording immediately. > In full-duplex mode, playback and recording will start > -synchronously as soon as enough data to play is available. > +synchronously as soon as the play buffer is full. > .Pp > The > .Fn sio_stop
Fwd: gre(4): mgre
Hi, mgre(4) does not appear to be documented well, I had to find David's "mgre(4): point-to-multipoint gre tunnels" mail to understand how gre endpoints are found. Index: share/man/man4/gre.4 === RCS file: /cvs/src/share/man/man4/gre.4,v retrieving revision 1.79 diff -u -p -u -r1.79 gre.4 --- share/man/man4/gre.418 Nov 2020 16:19:54 - 1.79 +++ share/man/man4/gre.427 Nov 2020 23:29:39 - @@ -455,6 +455,66 @@ In most cases the following should work: .Bd -literal -offset indent pass quick on gre proto gre no state .Ed +.Ss Point-to-Multipoint Layer 3 GRE tunnel interfaces (mgre) example +.Nm mgre +can be used to build a point-to-multipoint tunnel network to several +hosts using a single +.Nm mgre +interface. +.Pp +In this example the host A has an outer IP of 198.51.100.12, host +B has 203.0.113.27, and host C has 203.0.113.254. Adressing within +the tunnel is done using 192.0.2.0/24. +.Bd -literal ++--- Host B + / + / +Host A --- tunnel ---+ + \e + \e ++--- Host C +.Ed +.Pp +On Host A: +.Bd -literal -offset indent +# ifconfig mgreN create +# ifconfig mgreN tunneladdr 198.51.100.12 +# ifconfig mgreN inet 192.0.2.1 netmask 0xff00 up +.Ed +.Pp +On Host B: +.Bd -literal -offset indent +# ifconfig mgreN create +# ifconfig mgreN tunneladdr 203.0.113.27 +# ifconfig mgreN inet 192.0.2.2 netmask 0xff00 up +.Ed +.Pp +On Host C: +.Bd -literal -offset indent +# ifconfig mgreN create +# ifconfig mgreN tunneladdr 203.0.113.254 +# ifconfig mgreN inet 192.0.2.3 netmask 0xff00 up +.Ed +.Pp +To reach Host B over the tunnel (from Host A), there has to be a +route on Host A specifying the next-hop: +.Pp +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN +.Pp +Similarly, to reach Host A over the tunnel from Host B, a route must +be present on B with A's outer IP as next-hop: +.Pp +.Dl # route add -host 192.0.2.1 198.51.100.12 -iface -ifp mgreN +.Pp +The same tunnel interface can be then used between host B and C by +adding the appropriate routes, making the network any-to-any instead +of hub-and-spoke: +.Pp +On Host B: +.Dl # route add -host 192.0.2.3 203.0.113.254 -iface -ifp mgreN +.Pp +On Host C: +.Dl # route add -host 192.0.2.2 203.0.113.27 -iface -ifp mgreN .Ss Point-to-Point Ethernet over GRE tunnel interfaces (egre) example .Nm egre can be used to carry Ethernet traffic between two endpoints over
