Re: Fix wxabort refs in mmap and mprotect man pages
On Fri, Mar 10, 2017 at 08:00:44PM -0500, Michael Reed wrote: > The sysctl(3) man page does not seem to contain anything about kern.exabort. > While here, also use proper .Xr markup. > the markup fix is correct, but...sysctl(3) does document kern.wxabort (KERN_WXABORT). jmc > > Index: mmap.2 > === > RCS file: /cvs/src/lib/libc/sys/mmap.2,v > retrieving revision 1.52 > diff -u -p -r1.52 mmap.2 > --- mmap.2 27 May 2016 19:45:04 - 1.52 > +++ mmap.2 11 Mar 2017 00:58:46 - > @@ -281,7 +281,8 @@ In particular, > .Dv PROT_WRITE | PROT_EXEC > mappings are not permitted in most binaries (see > .Dv kern.wxabort > -in sysctl 3 > +in > +.Xr sysctl 8 > for more information). > .El > .Sh SEE ALSO > Index: mprotect.2 > === > RCS file: /cvs/src/lib/libc/sys/mprotect.2,v > retrieving revision 1.20 > diff -u -p -r1.20 mprotect.2 > --- mprotect.2 27 May 2016 19:45:04 - 1.20 > +++ mprotect.2 11 Mar 2017 00:58:46 - > @@ -104,7 +104,8 @@ In particular, > .Dv PROT_WRITE | PROT_EXEC > mappings are not permitted in most binaries (see > .Dv kern.wxabort > -in sysctl 3 > +in > +.Xr sysctl 8 > for more information). > .It Bq Er EINVAL > The >
Re: sha2(3): five != four
On Fri, Mar 10, 2017 at 07:27:57PM -0800, Philip Guenther wrote: > > With the addition of the SHA512_256 family, there are five families, not > four. > > ok? > i'm ok with this, but it's one of those situations where us correctly documenting the number of things in existence doesn;t gain us anything (it doesn't help the reader) but we put ourselves at risk of being caught out when the number changes. i'd say, remove the sentence! see inline for another thought: > Index: /usr/src/lib/libc/hash/sha2.3 > === > RCS file: /data/src/openbsd/src/lib/libc/hash/sha2.3,v > retrieving revision 1.26 > diff -u -p -r1.26 sha2.3 > --- /usr/src/lib/libc/hash/sha2.3 4 Sep 2016 09:28:12 - 1.26 > +++ /usr/src/lib/libc/hash/sha2.3 11 Mar 2017 03:23:05 - > @@ -168,11 +168,12 @@ The SHA2 functions implement the NIST Se > FIPS PUB 180-2. > The SHA2 functions are used to generate a condensed representation of a > message called a message digest, suitable for use as a digital signature. > -There are four families of functions, with names corresponding to > +There are five families of functions, with names corresponding to > the number of bits in the resulting message digest. > The SHA-224 and SHA-256 functions are limited to processing a message of less > than 2^64 bits as input. > -The SHA-384 and SHA-512 functions can process a message of at most 2^128 - 1 > +The SHA-384, SHA-512, and SHA-512/256 functions can process a message > +of at most 2^128 - 1 you could just say "The others can process" to avoid getting caught out again. jmc > bits as input. > .Pp > The SHA2 functions are considered to be more secure than the >
videomode/edid.c: conditionally print mode details
Only print details about parsed EDID blocks if -DDIAGNOSTIC, consistent with the surrounding printf()'s. Ian Index: edid.c === RCS file: /cvs/src/sys/dev/videomode/edid.c,v retrieving revision 1.3 diff -u -p -r1.3 edid.c --- edid.c 5 Dec 2012 23:20:22 - 1.3 +++ edid.c 11 Mar 2017 06:03:25 - @@ -594,8 +594,10 @@ edid_parse(uint8_t *data, struct edid_in if (edid->edid_modes[i].dot_clock > max_dotclock) max_dotclock = edid->edid_modes[i].dot_clock; +#ifdef DIAGNOSTIC printf("max_dotclock according to supported modes: %d\n", max_dotclock); +#endif mhz = (max_dotclock + 999) / 1000;
"user" chroot (patch)
In running risky non-root applications, it'd be great to chroot(2) without needing to be root. But the manpage says no. So I added a system call, uchroot(2), that does the following: (1) performs the change-root w/o checking for root (2) disables setuid (flag is inherited) The (2) plugs the hole wherein a non-root normal chroot could allow for privilege escalation by a cooked master.passwd and setuid. Enclosed is a patch. (Without the bits generated from make syscalls: I don't know whether that's preferred. Also doesn't include the libc parts.) It can't be this easy, can it? What did I miss? My initial motivation is CGI scripts, which can and do pledge, yes, but I'd like to limit *path-pledged processes to a directory so scripts can't read everything else in /var/www. For example, within /var/www, to (say) /vhosts/foo.com. Best, Kristaps Index: src/sys/kern/kern_prot.c === RCS file: /cvs/src/sys/kern/kern_prot.c,v retrieving revision 1.67 diff -u -p -u -r1.67 kern_prot.c --- src/sys/kern/kern_prot.c 7 Nov 2016 00:26:32 - 1.67 +++ src/sys/kern/kern_prot.c 11 Mar 2017 05:37:47 - @@ -1077,6 +1077,10 @@ proc_cansugid(struct proc *p) if ((p->p_p->ps_flags & PS_TRACED) != 0) return (0); + /* not if we've done a uchroot(2) */ + if (p->p_p->ps_uchroot) + return (0); + /* processes with shared filedescriptors shouldn't. */ if (p->p_fd->fd_refcnt > 1) return (0); Index: src/sys/kern/syscalls.master === RCS file: /cvs/src/sys/kern/syscalls.master,v retrieving revision 1.174 diff -u -p -u -r1.174 syscalls.master --- src/sys/kern/syscalls.master 4 Sep 2016 17:22:40 - 1.174 +++ src/sys/kern/syscalls.master 11 Mar 2017 05:37:47 - @@ -563,3 +563,4 @@ 328 OBSOL __tfork51 329 STD NOLOCK { void sys___set_tcb(void *tcb); } 330 STD NOLOCK { void *sys___get_tcb(void); } +331 STD { int sys_uchroot(const char *path); } Index: src/sys/kern/vfs_syscalls.c === RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.271 diff -u -p -u -r1.271 vfs_syscalls.c --- src/sys/kern/vfs_syscalls.c 15 Feb 2017 03:36:58 - 1.271 +++ src/sys/kern/vfs_syscalls.c 11 Mar 2017 05:37:47 - @@ -726,6 +726,41 @@ sys_chroot(struct proc *p, void *v, regi return (0); } +int +sys_uchroot(struct proc *p, void *v, register_t *retval) +{ + struct sys_chroot_args /* { + syscallarg(const char *) path; + } */ *uap = v; + struct filedesc *fdp = p->p_fd; + struct vnode *old_cdir, *old_rdir; + int error; + struct nameidata nd; + + NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE, + SCARG(uap, path), p); + if ((error = change_dir(&nd, p)) != 0) + return (error); + + p->p_p->ps_uchroot = 1; + + if (fdp->fd_rdir != NULL) { + /* + * A chroot() done inside a changed root environment does + * an automatic chdir to avoid the out-of-tree experience. + */ + vref(nd.ni_vp); + old_rdir = fdp->fd_rdir; + old_cdir = fdp->fd_cdir; + fdp->fd_rdir = fdp->fd_cdir = nd.ni_vp; + vrele(old_rdir); + vrele(old_cdir); + } else + fdp->fd_rdir = nd.ni_vp; + + return (0); +} + /* * Common routine for chroot and chdir. */ Index: src/sys/sys/proc.h === RCS file: /cvs/src/sys/sys/proc.h,v retrieving revision 1.236 diff -u -p -u -r1.236 proc.h --- src/sys/sys/proc.h 5 Mar 2017 06:40:18 - 1.236 +++ src/sys/sys/proc.h 11 Mar 2017 05:37:47 - @@ -223,6 +223,8 @@ struct process { uint64_t ps_pledge; struct whitepaths *ps_pledgepaths; + u_short ps_uchroot; /* Are we user-chrooted? */ + int64_t ps_kbind_cookie; u_long ps_kbind_addr;
sha2(3): five != four
With the addition of the SHA512_256 family, there are five families, not four. ok? Index: /usr/src/lib/libc/hash/sha2.3 === RCS file: /data/src/openbsd/src/lib/libc/hash/sha2.3,v retrieving revision 1.26 diff -u -p -r1.26 sha2.3 --- /usr/src/lib/libc/hash/sha2.3 4 Sep 2016 09:28:12 - 1.26 +++ /usr/src/lib/libc/hash/sha2.3 11 Mar 2017 03:23:05 - @@ -168,11 +168,12 @@ The SHA2 functions implement the NIST Se FIPS PUB 180-2. The SHA2 functions are used to generate a condensed representation of a message called a message digest, suitable for use as a digital signature. -There are four families of functions, with names corresponding to +There are five families of functions, with names corresponding to the number of bits in the resulting message digest. The SHA-224 and SHA-256 functions are limited to processing a message of less than 2^64 bits as input. -The SHA-384 and SHA-512 functions can process a message of at most 2^128 - 1 +The SHA-384, SHA-512, and SHA-512/256 functions can process a message +of at most 2^128 - 1 bits as input. .Pp The SHA2 functions are considered to be more secure than the
Re: Add RTL8153 support to ure(4)
On Fri, 10 Mar 2017 at 20:54:39 +0100, Mark Kettenis wrote: > Fairly straightforward port of the changes made to the FreeBSD driver. > Like re(4) this has a fairly incestious relationship with rgephy(4) as > it needs a similar hack to read the media status register. > > Tests, especially on RTL8152 hardware, and OKs are welcome. Works fine on my Anker USB 3 ethernet device, which previously attached via cdce: cdce0 at uhub0 port 13 configuration 2 interface 0 "Realtek USB 10/100/1000 LAN" rev 3.00/30.00 addr 7 cdce0: address 00:e0:1e:81:01:39 now: ure0 at uhub0 port 12 configuration 1 interface 0 "Realtek USB 10/100/1000 LAN" rev 3.00/30.00 addr 7 ure0: ver 5c10, address 00:e0:1e:81:01:39 rgephy0 at ure0 phy 0: RTL8251 PHY, rev. 0
kernel crash operating USB device programmer
I'm trying to operate an Atmel AVRISP mkII device programmer using the "avrdude" program. The kernel crashes identically running either 6.0 release or 6.1 snapshot. Is this a known problem? Here is the ddb output and the dmesg. I will try to produce any other useful data or to use ddb to examine the kernel. If a crash dump is useful I can put one on the web for download. I can try to trace the program execution prior to the crash. I don't think ktrace would help unless it does fsync after every entry... Thanks Geoff Steckel Mar 10 19:58:48 store /bsd: panic: ehci_device_clear_toggle: queue active Mar 10 19:58:48 store /bsd: Stopped at Debugger+0x9: leave Mar 10 19:58:48 store /bsd:TIDPIDUID PRFLAGS PFLAGS CPU COMMAND Mar 10 19:58:48 store /bsd: * 2171 2171 0 0x3 00 avrdude Mar 10 19:58:48 store /bsd: Debugger() at Debugger+0x9 Mar 10 19:58:48 store /bsd: panic() at panic+0xfe Mar 10 19:58:48 store /bsd: ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b Mar 10 19:58:48 store /bsd: usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24 Mar 10 19:58:48 store /bsd: ugen_do_read() at ugen_do_read+0x4e6 Mar 10 19:58:48 store /bsd: ugenread() at ugenread+0x48 Mar 10 19:58:48 store /bsd: spec_read() at spec_read+0x2c5 Mar 10 19:58:48 store /bsd: VOP_READ() at VOP_READ+0x3f Mar 10 19:58:48 store /bsd: vn_read() at vn_read+0xa1 Mar 10 19:58:48 store /bsd: dofilereadv() at dofilereadv+0x204 Mar 10 19:58:48 store /bsd: sys_read() at sys_read+0x89 Mar 10 19:58:48 store /bsd: syscall() at syscall+0x27b Mar 10 19:58:48 store /bsd: --- syscall (number 3) --- Mar 10 19:58:48 store /bsd: end trace frame: 0x0, count: 3 Mar 10 19:58:48 store /bsd: 0x108592d58a1a: Mar 10 20:26:39 store /bsd: OpenBSD 6.1-beta (GENERIC.MP) #224: Thu Mar 9 18:50:15 MST 2017 Mar 10 20:26:39 store /bsd: dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Mar 10 20:26:39 store /bsd: real mem = 8466022400 (8073MB) Mar 10 20:26:39 store /bsd: avail mem = 8204775424 (7824MB) Mar 10 20:26:39 store /bsd: mpath0 at root Mar 10 20:26:39 store /bsd: scsibus0 at mpath0: 256 targets Mar 10 20:26:39 store /bsd: mainbus0 at root Mar 10 20:26:39 store /bsd: bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb450 (20 entries) Mar 10 20:26:39 store /bsd: bios0: vendor American Megatrends Inc. version "4.6.5" date 06/05/2013 Mar 10 20:26:39 store /bsd: bios0: BIOSTAR Group NM70I-1037U Mar 10 20:26:39 store /bsd: acpi0 at bios0: rev 2 Mar 10 20:26:39 store /bsd: acpi0: sleep states S0 S1 S4 S5 Mar 10 20:26:39 store /bsd: acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT Mar 10 20:26:39 store /bsd: acpi0: wakeup devices PS2K(S4) UAR1(S4) P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) [...] Mar 10 20:26:39 store /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 bits Mar 10 20:26:39 store /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Mar 10 20:26:39 store /bsd: cpu0 at mainbus0: apid 0 (boot processor) Mar 10 20:26:39 store /bsd: cpu0: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz, 1796.21 MHz Mar 10 20:26:39 store /bsd: cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT Mar 10 20:26:39 store /bsd: cpu0: 256KB 64b/line 8-way L2 cache Mar 10 20:26:39 store /bsd: cpu0: TSC frequency 1796209080 Hz Mar 10 20:26:39 store /bsd: cpu0: smt 0, core 0, package 0 Mar 10 20:26:39 store /bsd: mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges Mar 10 20:26:39 store /bsd: cpu0: apic clock running at 99MHz Mar 10 20:26:39 store /bsd: cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE Mar 10 20:26:39 store /bsd: cpu1 at mainbus0: apid 2 (application processor) Mar 10 20:26:39 store /bsd: cpu1: Intel(R) Celeron(R) CPU 1037U @ 1.80GHz, 1795.92 MHz Mar 10 20:26:39 store /bsd: cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT Mar 10 20:26:39 store /bsd: cpu1: 256KB 64b/line 8-way L2 cache Mar 10 20:26:39 store /bsd: cpu1: smt 0, core 1, package 0 Mar 10 20:26:39 store /bsd: ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins Mar 10 20:26:39 store /bsd: acpimcfg0 at acpi0 addr 0xf800, bus 0-63 Mar 10 20:26:39 store /bsd: acpihpet0 at acpi0: 14318179 Hz Mar 10 20:26:39 store /bsd: acpiprt0 at acpi0: bus 0 (PCI0) Mar 10 20:26:39 store /bsd: acpiprt1 at acpi0: bus -1 (P0P1) Mar 10 20:26:39 store /bsd: acpiprt2 at acpi0: bus 2 (RP01) Mar 10 20:26:39 st
Fix wxabort refs in mmap and mprotect man pages
The sysctl(3) man page does not seem to contain anything about kern.exabort. While here, also use proper .Xr markup. Index: mmap.2 === RCS file: /cvs/src/lib/libc/sys/mmap.2,v retrieving revision 1.52 diff -u -p -r1.52 mmap.2 --- mmap.2 27 May 2016 19:45:04 - 1.52 +++ mmap.2 11 Mar 2017 00:58:46 - @@ -281,7 +281,8 @@ In particular, .Dv PROT_WRITE | PROT_EXEC mappings are not permitted in most binaries (see .Dv kern.wxabort -in sysctl 3 +in +.Xr sysctl 8 for more information). .El .Sh SEE ALSO Index: mprotect.2 === RCS file: /cvs/src/lib/libc/sys/mprotect.2,v retrieving revision 1.20 diff -u -p -r1.20 mprotect.2 --- mprotect.2 27 May 2016 19:45:04 - 1.20 +++ mprotect.2 11 Mar 2017 00:58:46 - @@ -104,7 +104,8 @@ In particular, .Dv PROT_WRITE | PROT_EXEC mappings are not permitted in most binaries (see .Dv kern.wxabort -in sysctl 3 +in +.Xr sysctl 8 for more information). .It Bq Er EINVAL The
fix ifconfig scan confusing WEP and WPA
While a wifi interface is configured to use WEP 'ifconfig scan' will mistakenly show all WPA APs as WEP ones. Fix below. This is a small ABI change in struct ieee80211_nodereq. Index: sys/net80211/ieee80211_ioctl.c === RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.c,v retrieving revision 1.48 diff -u -p -r1.48 ieee80211_ioctl.c --- sys/net80211/ieee80211_ioctl.c 19 Jan 2017 01:07:35 - 1.48 +++ sys/net80211/ieee80211_ioctl.c 11 Mar 2017 00:44:41 - @@ -107,6 +107,11 @@ ieee80211_node2req(struct ieee80211com * /* RSN */ nr->nr_rsnciphers = ni->ni_rsnciphers; nr->nr_rsnakms = 0; + nr->nr_rsnprotos = 0; + if (ni->ni_rsnprotos & IEEE80211_PROTO_WPA) + nr->nr_rsnprotos |= IEEE80211_WPA_PROTO_WPA1; + if (ni->ni_rsnprotos & IEEE80211_PROTO_RSN) + nr->nr_rsnprotos |= IEEE80211_WPA_PROTO_WPA2; if (ni->ni_rsnakms & IEEE80211_AKM_8021X) nr->nr_rsnakms |= IEEE80211_WPA_AKM_8021X; if (ni->ni_rsnakms & IEEE80211_AKM_PSK) Index: sys/net80211/ieee80211_ioctl.h === RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.h,v retrieving revision 1.27 diff -u -p -r1.27 ieee80211_ioctl.h --- sys/net80211/ieee80211_ioctl.h 15 Aug 2016 22:14:19 - 1.27 +++ sys/net80211/ieee80211_ioctl.h 11 Mar 2017 00:33:59 - @@ -328,6 +328,7 @@ struct ieee80211_nodereq { u_int16_t nr_state; /* node state in the cache */ /* RSN */ + u_int nr_rsnprotos; u_int nr_rsnciphers; u_int nr_rsnakms; Index: sbin/ifconfig/ifconfig.c === RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.337 diff -u -p -r1.337 ifconfig.c --- sbin/ifconfig/ifconfig.c21 Jan 2017 08:31:44 - 1.337 +++ sbin/ifconfig/ifconfig.c11 Mar 2017 00:45:24 - @@ -2375,9 +2375,9 @@ ieee80211_printnode(struct ieee80211_nod if (nr->nr_capinfo) { printb_status(nr->nr_capinfo, IEEE80211_CAPINFO_BITS); if (nr->nr_capinfo & IEEE80211_CAPINFO_PRIVACY) { - if (nr->nr_rsnciphers & IEEE80211_WPA_CIPHER_CCMP) + if (nr->nr_rsnprotos & IEEE80211_WPA_PROTO_WPA2) fputs(",wpa2", stdout); - else if (nr->nr_rsnciphers & IEEE80211_WPA_CIPHER_TKIP) + else if (nr->nr_rsnprotos & IEEE80211_WPA_PROTO_WPA1) fputs(",wpa1", stdout); else fputs(",wep", stdout);
Re: dynamic RTS threshold in 11n mode
On Sat, Mar 04, 2017 at 10:04:51PM +0100, Stefan Sperling wrote: > This diff makes the RTS threshold dynamic in 11n mode. > It flips the RTS threshold between DEFAULT (512 bytes) and MAX (the > maximum size of a non-aggregated 802.11 frame). Things have been working fine for me with this diff. Any concerns about putting it in? > The decision whether to use RTS is implemented as a heuristic described > in the MiRA paper. > > MiRa enables RTS if there are retries with almost no loss, indicating > competition with other APs and clients. It leaves RTS disabled if > there is a lot of loss, indicating we are too far away from the AP > or using a bad Tx rate which won't cover the distance. > > Because an athn(4) hostap needs a per-client threshold I am introducing > ni_rtsthreshold in struct ieee80211_node. This could completely replace > the ic_rtsthreshold in struct ieee80211com eventually. For now I am only > switching 11n capable drivers over to ni_rtsthreshold. > > I am interested in test reports. > When testing this please look for changes in both latency and throughput > and let me know if you think it behaves better or worse with this diff. > > Index: dev/ic/ar5008.c > === > RCS file: /cvs/src/sys/dev/ic/ar5008.c,v > retrieving revision 1.42 > diff -u -p -r1.42 ar5008.c > --- dev/ic/ar5008.c 1 Feb 2017 12:45:56 - 1.42 > +++ dev/ic/ar5008.c 4 Mar 2017 15:29:02 - > @@ -1513,7 +1513,7 @@ ar5008_tx(struct athn_softc *sc, struct > > htprot = (ic->ic_bss->ni_htop1 & IEEE80211_HTOP1_PROT_MASK); > /* NB: Group frames are sent using CCK in 802.11b/g. */ > - if (totlen > ic->ic_rtsthreshold) { > + if (totlen > ni->ni_rtsthreshold) { > ds->ds_ctl0 |= AR_TXC0_RTS_ENABLE; > } else if (((ic->ic_flags & IEEE80211_F_USEPROT) && > athn_rates[ridx[0]].phy == IEEE80211_T_OFDM) || > Index: dev/ic/ath.c > === > RCS file: /cvs/src/sys/dev/ic/ath.c,v > retrieving revision 1.112 > diff -u -p -r1.112 ath.c > --- dev/ic/ath.c 22 Jan 2017 10:17:37 - 1.112 > +++ dev/ic/ath.c 4 Mar 2017 15:29:23 - > @@ -2259,7 +2259,7 @@ ath_tx_start(struct ath_softc *sc, struc > if (IEEE80211_IS_MULTICAST(wh->i_addr1)) { > flags |= HAL_TXDESC_NOACK; /* no ack on broad/multicast */ > sc->sc_stats.ast_tx_noack++; > - } else if (pktlen > ic->ic_rtsthreshold) { > + } else if (pktlen > ni->ni_rtsthreshold) { > flags |= HAL_TXDESC_RTSENA; /* RTS based on frame length */ > sc->sc_stats.ast_tx_rts++; > } > Index: dev/pci/if_iwm.c > === > RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v > retrieving revision 1.165 > diff -u -p -r1.165 if_iwm.c > --- dev/pci/if_iwm.c 20 Feb 2017 15:38:04 - 1.165 > +++ dev/pci/if_iwm.c 4 Mar 2017 15:30:11 - > @@ -4038,7 +4038,7 @@ iwm_tx(struct iwm_softc *sc, struct mbuf > > if (type == IEEE80211_FC0_TYPE_DATA && > !IEEE80211_IS_MULTICAST(wh->i_addr1) && > - (totlen + IEEE80211_CRC_LEN > ic->ic_rtsthreshold || > + (totlen + IEEE80211_CRC_LEN > ni->ni_rtsthreshold || > (ic->ic_flags & IEEE80211_F_USEPROT))) > flags |= IWM_TX_CMD_FLG_PROT_REQUIRE; > > Index: dev/pci/if_iwn.c > === > RCS file: /cvs/src/sys/dev/pci/if_iwn.c,v > retrieving revision 1.184 > diff -u -p -r1.184 if_iwn.c > --- dev/pci/if_iwn.c 20 Feb 2017 15:38:04 - 1.184 > +++ dev/pci/if_iwn.c 4 Mar 2017 15:30:02 - > @@ -2992,7 +2992,7 @@ iwn_tx(struct iwn_softc *sc, struct mbuf > /* Check if frame must be protected using RTS/CTS or CTS-to-self. */ > if (!IEEE80211_IS_MULTICAST(wh->i_addr1)) { > /* NB: Group frames are sent using CCK in 802.11b/g/n (2GHz). */ > - if (totlen + IEEE80211_CRC_LEN > ic->ic_rtsthreshold) { > + if (totlen + IEEE80211_CRC_LEN > ni->ni_rtsthreshold) { > flags |= IWN_TX_NEED_RTS; > } else if ((ic->ic_flags & IEEE80211_F_USEPROT) && > ridx >= IWN_RIDX_OFDM6) { > Index: net80211/ieee80211_mira.c > === > RCS file: /cvs/src/sys/net80211/ieee80211_mira.c,v > retrieving revision 1.10 > diff -u -p -r1.10 ieee80211_mira.c > --- net80211/ieee80211_mira.c 28 Jan 2017 16:01:36 - 1.10 > +++ net80211/ieee80211_mira.c 4 Mar 2017 16:55:00 - > @@ -84,6 +84,9 @@ voidieee80211_mira_probe_next_rate(stru > uint32_t ieee80211_mira_valid_rates(struct ieee80211com *, > struct ieee80211_node *); > uint32_t ieee80211_mira_mcs_below(struct ieee80211_mira_node *, int); > +void ieee80211_mira
Re: pfsync if_get conversion
On Thu, Mar 09, 2017 at 12:42:43PM +0100, Martin Pieuchot wrote: > On 09/03/17(Thu) 08:48, Stefan Sperling wrote: > > This diff converts a struct ifnet pointer in pfsync's softc into an > > ifindex with corresponding if_get()/if_put() calls. > > This avoid the panic but obfuscate the problem. What you want is a > detachhook such that if the parent interface is destroyed you don't > leave a sale pointer. > > You can look at how vlan(4) or other pseudo drivers do it. Right. The diff below fixes the issue, too. vlan(4) uses both a detachhook and if_get/if_put. Fixing the crash is important so I would commit this fix separately first. I could later redo my if_get/if_put diff on top unless that is not wanted. Index: if_pfsync.c === RCS file: /cvs/src/sys/net/if_pfsync.c,v retrieving revision 1.245 diff -u -p -r1.245 if_pfsync.c --- if_pfsync.c 20 Feb 2017 06:30:39 - 1.245 +++ if_pfsync.c 10 Mar 2017 08:58:18 - @@ -234,6 +234,7 @@ struct pfsync_softc { TAILQ_HEAD(, tdb)sc_tdb_q; void*sc_lhcookie; + void*sc_dhcookie; struct timeout sc_tmo; }; @@ -252,6 +253,7 @@ int pfsyncoutput(struct ifnet *, struct intpfsyncioctl(struct ifnet *, u_long, caddr_t); void pfsyncstart(struct ifnet *); void pfsync_syncdev_state(void *); +void pfsync_ifdetach(void *); void pfsync_deferred(struct pf_state *, int); void pfsync_undefer(struct pfsync_deferral *, int); @@ -365,10 +367,13 @@ pfsync_clone_destroy(struct ifnet *ifp) if (sc->sc_link_demoted) carp_group_demote_adj(&sc->sc_if, -1, "pfsync destroy"); #endif - if (sc->sc_sync_if) + if (sc->sc_sync_if) { hook_disestablish( sc->sc_sync_if->if_linkstatehooks, sc->sc_lhcookie); + hook_disestablish(sc->sc_sync_if->if_detachhooks, + sc->sc_dhcookie);; + } if_detach(ifp); pfsync_drop(sc); @@ -427,6 +432,14 @@ pfsync_syncdev_state(void *arg) } } +void +pfsync_ifdetach(void *arg) +{ + struct pfsync_softc *sc = arg; + + sc->sc_sync_if = NULL; +} + int pfsync_alloc_scrub_memory(struct pfsync_state_peer *s, struct pf_state_peer *d) @@ -1313,10 +1326,14 @@ pfsyncioctl(struct ifnet *ifp, u_long cm sc->sc_defer = pfsyncr.pfsyncr_defer; if (pfsyncr.pfsyncr_syncdev[0] == 0) { - if (sc->sc_sync_if) + if (sc->sc_sync_if) { hook_disestablish( sc->sc_sync_if->if_linkstatehooks, sc->sc_lhcookie); + hook_disestablish( + sc->sc_sync_if->if_detachhooks, + sc->sc_dhcookie);; + } sc->sc_sync_if = NULL; if (imo->imo_num_memberships > 0) { in_delmulti(imo->imo_membership[ @@ -1338,10 +1355,14 @@ pfsyncioctl(struct ifnet *ifp, u_long cm sifp->if_mtu < MCLBYTES - sizeof(struct ip)) pfsync_sendout(); - if (sc->sc_sync_if) + if (sc->sc_sync_if) { hook_disestablish( sc->sc_sync_if->if_linkstatehooks, sc->sc_lhcookie); + hook_disestablish( + sc->sc_sync_if->if_detachhooks, + sc->sc_dhcookie);; + } sc->sc_sync_if = sifp; if (imo->imo_num_memberships > 0) { @@ -1388,6 +1409,8 @@ pfsyncioctl(struct ifnet *ifp, u_long cm sc->sc_lhcookie = hook_establish(sc->sc_sync_if->if_linkstatehooks, 1, pfsync_syncdev_state, sc); + sc->sc_dhcookie = hook_establish(sc->sc_sync_if->if_detachhooks, + 0, pfsync_ifdetach, sc); pfsync_request_full_update(sc); splx(s);
Re: Add RTL8153 support to ure(4)
> Date: Sat, 11 Mar 2017 07:23:47 +1000 > From: Jonathan Matthew > > On Fri, Mar 10, 2017 at 08:54:39PM +0100, Mark Kettenis wrote: > > Fairly straightforward port of the changes made to the FreeBSD driver. > > Like re(4) this has a fairly incestious relationship with rgephy(4) as > > it needs a similar hack to read the media status register. > > > > Tests, especially on RTL8152 hardware, and OKs are welcome. > > Works fine on the terrible machine I ported this driver on: > > ure0 at uhub0 port 3 configuration 1 interface 0 "Realtek USB 10/100 LAN" rev > 2.10/20.00 addr 3 > ure0: ver 4c10, address c4:4e:ac:80:69:f5 > rlphy0 at ure0 phy 0: RTL8201E 10/100 PHY, rev. 2 > > I had a look at doing this a while ago, but found that my RTL8153 worked > fine with cdce(4) so I kind of lost interest, but I don't see any reason > not to add 8153 support here. That's interesting. Because mine didn't work in cdce(4) mode. Sending packets worked, but I didn't receive any replies. Anyway, thanks, Mark
Re: Add RTL8153 support to ure(4)
On Fri, Mar 10, 2017 at 08:54:39PM +0100, Mark Kettenis wrote: > Fairly straightforward port of the changes made to the FreeBSD driver. > Like re(4) this has a fairly incestious relationship with rgephy(4) as > it needs a similar hack to read the media status register. > > Tests, especially on RTL8152 hardware, and OKs are welcome. Works fine on the terrible machine I ported this driver on: ure0 at uhub0 port 3 configuration 1 interface 0 "Realtek USB 10/100 LAN" rev 2.10/20.00 addr 3 ure0: ver 4c10, address c4:4e:ac:80:69:f5 rlphy0 at ure0 phy 0: RTL8201E 10/100 PHY, rev. 2 I had a look at doing this a while ago, but found that my RTL8153 worked fine with cdce(4) so I kind of lost interest, but I don't see any reason not to add 8153 support here. ok.
Add RTL8153 support to ure(4)
Fairly straightforward port of the changes made to the FreeBSD driver. Like re(4) this has a fairly incestious relationship with rgephy(4) as it needs a similar hack to read the media status register. Tests, especially on RTL8152 hardware, and OKs are welcome. Index: dev/usb/if_ure.c === RCS file: /cvs/src/sys/dev/usb/if_ure.c,v retrieving revision 1.3 diff -u -p -r1.3 if_ure.c --- dev/usb/if_ure.c22 Jan 2017 10:17:39 - 1.3 +++ dev/usb/if_ure.c10 Mar 2017 19:53:42 - @@ -1,6 +1,6 @@ /* $OpenBSD: if_ure.c,v 1.3 2017/01/22 10:17:39 dlg Exp $ */ /*- - * Copyright (c) 2015 Kevin Lo + * Copyright (c) 2015-2016 Kevin Lo * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -58,7 +58,8 @@ #include #include -#include "if_urereg.h" +#include +#include #ifdef URE_DEBUG #define DPRINTF(x) do { if (uredebug) printf x; } while (0) @@ -69,9 +70,9 @@ int uredebug = 0; #define DPRINTFN(n,x) #endif - const struct usb_devno ure_devs[] = { - { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8152 } + { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8152 }, + { USB_VENDOR_REALTEK, USB_PRODUCT_REALTEK_RTL8153 } }; inture_match(struct device *, void *, void *); @@ -126,6 +127,7 @@ int ure_ifmedia_upd(struct ifnet *); void ure_ifmedia_sts(struct ifnet *, struct ifmediareq *); inture_ioctl(struct ifnet *, u_long, caddr_t); void ure_rtl8152_init(struct ure_softc *); +void ure_rtl8153_init(struct ure_softc *); void ure_disable_teredo(struct ure_softc *); void ure_init_fifo(struct ure_softc *); @@ -302,6 +304,10 @@ ure_miibus_readreg(struct device *dev, i if (usbd_is_dying(sc->ure_udev)) return 0; + /* Let the rgephy driver read the URE_PLA_PHYSTATUS register. */ + if (reg == RL_GMEDIASTAT) + return ure_read_1(sc, URE_PLA_PHYSTATUS, URE_MCU_TYPE_PLA); + ure_lock_mii(sc); val = ure_ocp_reg_read(sc, URE_OCP_BASE_MII + reg * 2); ure_unlock_mii(sc); @@ -337,6 +343,11 @@ ure_miibus_statchg(struct device *dev) case IFM_100_TX: sc->ure_flags |= URE_FLAG_LINK; break; + case IFM_1000_T: + if ((sc->ure_flags & URE_FLAG_8152) != 0) + break; + sc->ure_flags |= URE_FLAG_LINK; + break; default: break; } @@ -389,7 +400,9 @@ ure_iff(struct ure_softc *sc) return; ifp->if_flags &= ~IFF_ALLMULTI; - rxmode = ure_read_4(sc, URE_PLA_RCR, URE_MCU_TYPE_PLA); + rxmode = URE_RCR_APM; + if (ifp->if_flags & IFF_BROADCAST) + rxmode |= URE_RCR_AB; if (ifp->if_flags & IFF_PROMISC || sc->ure_ac.ac_multirangecnt > 0) { ifp->if_flags |= IFF_ALLMULTI; if (ifp->if_flags & IFF_PROMISC) @@ -443,7 +456,6 @@ ure_init(void *xsc) struct ure_softc*sc = xsc; struct ure_chain*c; struct ifnet*ifp = &sc->ure_ac.ac_if; - uint32_trxmode; usbd_status err; int s, i; @@ -487,18 +499,6 @@ ure_init(void *xsc) ure_read_2(sc, URE_PLA_MISC_1, URE_MCU_TYPE_PLA) & ~URE_RXDY_GATED_EN); - /* Set Rx mode. */ - rxmode = URE_RCR_APM; - - /* If we want promiscuous mode, set the allframes bit. */ - if (ifp->if_flags & IFF_PROMISC) - rxmode |= URE_RCR_AAP; - - if (ifp->if_flags & IFF_BROADCAST) - rxmode |= URE_RCR_AB; - - ure_write_4(sc, URE_PLA_RCR, URE_MCU_TYPE_PLA, rxmode); - /* Load the multicast filter. */ ure_iff(sc); @@ -697,6 +697,156 @@ ure_rtl8152_init(struct ure_softc *sc) } void +ure_rtl8153_init(struct ure_softc *sc) +{ + uint16_t val; + uint8_t u1u2[8]; + int i; + + /* Disable ALDPS. */ + ure_ocp_reg_write(sc, URE_OCP_POWER_CFG, + ure_ocp_reg_read(sc, URE_OCP_POWER_CFG) & ~URE_EN_ALDPS); + usbd_delay_ms(sc->ure_udev, 20); + + memset(u1u2, 0x00, sizeof(u1u2)); + ure_write_mem(sc, URE_USB_TOLERANCE, + URE_MCU_TYPE_USB | URE_BYTE_EN_SIX_BYTES, u1u2, sizeof(u1u2)); + +for (i = 0; i < URE_TIMEOUT; i++) { + if (ure_read_2(sc, URE_PLA_BOOT_CTRL, URE_MCU_TYPE_PLA) & + URE_AUTOLOAD_DONE) + break; + usbd_delay_ms(sc->ure_udev, 10); + } + if (i == URE_TIMEOUT) + printf("%s: timeout waiting for chip autoload\n", + sc->ure_dev.dv_xname); + + for (i = 0; i < URE_TIMEOUT; i++) { + val = ure_ocp_reg_read(sc, URE_
Re: acme-client -t switch?
--On Thursday, March 09, 2017 06:13:38 PM +0100 Sebastian Benoit wrote: Stuart Henderson(s...@spacehopper.org) on 2017.03.07 21:56:56 +: Since this came up.. what does anyone think about adding the original version back to ports? (personally, I could do with moving things away from the python version, but I need dns-01..) I'm planing on re-introducing the [-t switch] functinality. What direction are you planning on going with that? Using the model that Kristaps is using in the git version where challenges are provided on stdout to another program? Or using something closer to the original implementation where acme-client executes an arbitrary program when it needs to do the challenge? I think the stdout mechanism would be cleaner as that way an extension only needs to integrate by calling acme-client, not integrating both caller and callee. It would also reduce the differences between the versions. Devin
Re: www/61.html reallocarray(1) typo
Hi Hiltjo, Hiltjo Posthuma wrote on Fri, Mar 10, 2017 at 04:26:24PM +0100: > I think a small typo slipped in the 6.1 notes. Patch below: Committed, thanks. Ingo (The patch is correct. This second link talks about reallocarray, not about recallocarray.) > diff --git a/61.html b/61.html > index 4b5dadbd4..18208b588 100644 > --- a/61.html > +++ b/61.html > @@ -244,7 +244,7 @@ to 6.1. > New function > http://man.openbsd.org/recallocarray.3";>recallocarray(3) > to reduce the risk of incorrect clearing of memory before and after > -http://man.openbsd.org/reallocarray.3";>recallocarray(3). > +http://man.openbsd.org/reallocarray.3";>reallocarray(3). > ... > >
Re: www/61.html reallocarray(1) typo
> On 10 Mar 2017, at 4:43 PM, Otto Moerbeek wrote: > > On Fri, Mar 10, 2017 at 04:26:24PM +0100, Hiltjo Posthuma wrote: > >> I think a small typo slipped in the 6.1 notes. Patch below: > > Nope, the actual new functions is called recallocarray... Yup, and still a typo in one way or another: >> -> href="http://man.openbsd.org/reallocarray.3";>recallocarray(3). realloc recalloc
Re: www/61.html reallocarray(1) typo
On Fri, Mar 10, 2017 at 04:26:24PM +0100, Hiltjo Posthuma wrote: > Hey, > > I think a small typo slipped in the 6.1 notes. Patch below: Nope, the actual new functions is called recallocarray... -Otto > > diff --git a/61.html b/61.html > index 4b5dadbd4..18208b588 100644 > --- a/61.html > +++ b/61.html > @@ -244,7 +244,7 @@ to 6.1. > New function > http://man.openbsd.org/recallocarray.3";>recallocarray(3) > to reduce the risk of incorrect clearing of memory before and after > -http://man.openbsd.org/reallocarray.3";>recallocarray(3). > +http://man.openbsd.org/reallocarray.3";>reallocarray(3). > ... > > > > -- > Kind regards, > Hiltjo
www/61.html reallocarray(1) typo
Hey, I think a small typo slipped in the 6.1 notes. Patch below: diff --git a/61.html b/61.html index 4b5dadbd4..18208b588 100644 --- a/61.html +++ b/61.html @@ -244,7 +244,7 @@ to 6.1. New function http://man.openbsd.org/recallocarray.3";>recallocarray(3) to reduce the risk of incorrect clearing of memory before and after -http://man.openbsd.org/reallocarray.3";>recallocarray(3). +http://man.openbsd.org/reallocarray.3";>reallocarray(3). ... -- Kind regards, Hiltjo
Fix multiple USB use-after-free
In polling mode, finished transfers are processed by the waiting thread. This happens inside usbd_dopoll(). That means it's unsafe to dereference ``xfer'' after calling it: 352:usbd_dopoll(pipe->device); 353:if (xfer->done) 354:break; When interrupts are enabled and a transfer times out it is unsafe to dereference ``xfer'' after being awaken. That's because the aborting task calls wakeup(9) after executing the callback: 807:pipe->methods->done(xfer); 808:if (xfer->callback) 809:xfer->callback(xfer, xfer->priv, xfer->status); ... 821:if ((flags & USBD_SYNCHRONOUS) && !polling) 822: wakeup(xfer); These problems are inherent to the fact that the ``done'' flag is on the ``xfer'' descriptor. The diff below fixes the problem by using a unique ID to check if a submitted transfer is finished or not. Since we know that the ``pipe'' associated to a transfer wont disappear until it is closed, we can use it to store the current ID. When can also tsleep(9) on the address of the pipe instead of the address of the transfer. Note that with this change usbd_transfer() will no longer report all possible USB error messages. But I'd say it's an improvement since not a single driver can handle them. ok? Index: ehci.c === RCS file: /cvs/src/sys/dev/usb/ehci.c,v retrieving revision 1.197 diff -u -p -r1.197 ehci.c --- ehci.c 10 Mar 2017 11:18:48 - 1.197 +++ ehci.c 10 Mar 2017 12:00:57 - @@ -3348,7 +3348,6 @@ ehci_device_isoc_start(struct usbd_xfer TAILQ_INSERT_TAIL(&sc->sc_intrhead, ex, inext); xfer->status = USBD_IN_PROGRESS; - xfer->done = 0; splx(s); return (USBD_IN_PROGRESS); Index: usbdi.c === RCS file: /cvs/src/sys/dev/usb/usbdi.c,v retrieving revision 1.89 diff -u -p -r1.89 usbdi.c --- usbdi.c 10 Mar 2017 11:18:48 - 1.89 +++ usbdi.c 10 Mar 2017 12:00:58 - @@ -54,6 +54,8 @@ extern int usbdebug; #define DPRINTFN(n,x) #endif +uint64_t usbd_xfer_id; /* unique ID per xfer */ + void usbd_request_async_cb(struct usbd_xfer *, void *, usbd_status); void usbd_start_next(struct usbd_pipe *pipe); usbd_status usbd_open_pipe_ival(struct usbd_interface *, u_int8_t, u_int8_t, @@ -282,6 +284,8 @@ usbd_transfer(struct usbd_xfer *xfer) struct usbd_bus *bus = pipe->device->bus; int polling = bus->use_polling; usbd_status err; + uint32_t timeout; + uint64_t uxid; int flags, s; if (usbd_is_dying(pipe->device)) @@ -293,8 +297,6 @@ usbd_transfer(struct usbd_xfer *xfer) if (usbdebug > 5) usbd_dump_queue(pipe); #endif - xfer->done = 0; - if (pipe->aborting) return (USBD_CANCELLED); @@ -320,8 +322,12 @@ usbd_transfer(struct usbd_xfer *xfer) usb_syncmem(&xfer->dmabuf, 0, xfer->length, BUS_DMASYNC_PREREAD); - err = pipe->methods->transfer(xfer); + /* We cannot dereference ``xfer'' after giving it to the HC. */ + uxid = xfer->id; + flags = xfer->flags; + timeout = xfer->timeout; + err = pipe->methods->transfer(xfer); if (err != USBD_IN_PROGRESS && err != USBD_NORMAL_COMPLETION) { /* The transfer has not been queued, so free buffer. */ if (xfer->rqflags & URQ_AUTO_DMABUF) { @@ -330,50 +336,52 @@ usbd_transfer(struct usbd_xfer *xfer) } } - if (!(xfer->flags & USBD_SYNCHRONOUS)) + if (!(flags & USBD_SYNCHRONOUS) || (err != USBD_IN_PROGRESS)) return (err); /* Sync transfer, wait for completion. */ - if (err != USBD_IN_PROGRESS) - return (err); - s = splusb(); if (polling) { int timo; - for (timo = xfer->timeout; timo >= 0; timo--) { + for (timo = timeout; timo >= 0; timo--) { usb_delay_ms(bus, 1); if (bus->dying) { - xfer->status = USBD_IOERROR; - usb_transfer_complete(xfer); + err = USBD_IOERROR; break; } usbd_dopoll(pipe->device); - if (xfer->done) + if (pipe->uxid != uxid) { + err = USBD_NORMAL_COMPLETION; break; + } } - if (timo < 0) { - xfer->status = USBD_TIMEOUT; - usb_transfer_complete(xfer); - } + if (timo < 0) + err
[patch] snmpd hrStorageSize negative values
Hi. snmpd(8) uses unsigned ints internally to represent the size and used space of a file system. The HOST-RESOURCES-MIB defines the valid values for those OIDs as 0..2147483647. With sufficiently large file systems, this can cause negative numbers to be returned for the size and used space OIDs. .1.3.6.1.2.1.25.2.3.1.5.36=-1573167768 At sthen's suggestion, do what net-snmp does and fiddle with the values to prevent wrapping. Yes this mucks with the actual values of size, used space, and block size, but it allows snmpd to convey the proper size and used space of the file system which is what most everybody is really interested in. In case gmail hoses this diff, it's also here: https://www.packetmischief.ca/files/patches/snmpd.hrstorage2.diff Index: usr.sbin/snmpd/mib.c === RCS file: /data/cvs-mirror/OpenBSD/src/usr.sbin/snmpd/mib.c,v retrieving revision 1.80 diff -p -u -r1.80 mib.c --- usr.sbin/snmpd/mib.c 17 Nov 2015 12:30:23 - 1.80 +++ usr.sbin/snmpd/mib.c 19 Feb 2017 20:01:46 - @@ -643,6 +643,14 @@ mib_hrstorage(struct oid *oid, struct be units = mnt->f_bsize; size = mnt->f_blocks; used = mnt->f_blocks - mnt->f_bfree; + + /* for large filesystems, do not overflow hrStorageSize */ + while (size > INT32_MAX) { + size = size >> 1; + units = units << 1; + used = used >> 1; + } + sop = &so[3]; break; } .joel
Re: Improved support for Apple trackpads: tests needed
Hi Ulf, > This patch for ubcmtp makes it use the multitouch-input functions of > wsmouse. It's the first driver that would apply the "tracking" variant > (wsmouse_mtframe). > > No wonders will result from the change, but the two-finger gestures that > involve movement - scrolling and click-and-drag with two fingers on a > clickpad - should work without flaws. > > A quick way to check whether all touch positions are available and the > selection of the active touch works properly is two-finger-scrolling, > performed with only one finger moving, then switching to the other one. > > Please note that click-and-drag will still require that the "ClickPad" > attribute is set in the synaptics(4) configuration. > > The patch has been tested on a MacBookPro 8,2 (from 2011). It would be > nice to learn that it doesn't introduce regressions on older or newer > models. > > If you don't use a brand-new version of the synaptics driver, you may > encounter the following bug: If the X cursor is in a window with > scrollable content and you put two finger on the touchpad without moving > them, the window content may quickly scroll up and down by a small > distance. This bug is fixed in the latest version. i've been running a kernel with your patch in, works here, MacBookAir 6,1 notable improvement, gestures is more responsive, i've tested text selection and scrolling with two-fingers and also by putting one-finger and scroling with the second finger... works fine... thanks for the patch, it's just makes my life more confortable. // gsoares