Re: feed l4 information into trunk(4) hash
Stuart Henderson(st...@openbsd.org) on 2014.12.11 23:52:44 +:
I'm wondering what reception this will get. It feeds TCP/UDP port
numbers into the hash for trunk(4) load balancing, so connections
between a single pair of hosts will get distributed across NICs.
Taken from FreeBSD r232629, they also added SIOC[CS]LAGGHASH ioctls
so that the hash type can be configured in ifconfig (l2/l3/l4),
I haven't done that but could if there's no general objection to
this.
i like this, and i think it might be good to have it optional in case it
causes problems with other equipment.
Benno
This method is used on some switches too (e.g. trunk-load-balance
L4-based on HP 2530 and 5400zl).
Index: if_trunk.c
===
RCS file: /cvs/src/sys/net/if_trunk.c,v
retrieving revision 1.93
diff -u -p -r1.93 if_trunk.c
--- if_trunk.c4 Dec 2014 00:01:53 - 1.93
+++ if_trunk.c11 Dec 2014 23:45:20 -
@@ -978,12 +978,23 @@ trunk_hashmbuf(struct mbuf *m, SIPHASH_K
int off;
struct ether_header *eh;
#ifdef INET
- struct ip *ip, ipbuf;
+ struct ip *ip;
+ u_int32_t *ports;
+ int iphlen;
#endif
#ifdef INET6
u_int32_t flow;
struct ip6_hdr *ip6, ip6buf;
#endif
+ union {
+#ifdef INET
+ struct ip ip;
+#endif
+#ifdef INET6
+ struct ip6_hdr ip6;
+#endif
+ uint32_t port;
+} buf;
SIPHASH_CTX ctx;
SipHash24_Init(ctx, key);
@@ -1013,10 +1024,25 @@ trunk_hashmbuf(struct mbuf *m, SIPHASH_K
#ifdef INET
case ETHERTYPE_IP:
if ((ip = (struct ip *)
- trunk_gethdr(m, off, sizeof(*ip), ipbuf)) == NULL)
+ trunk_gethdr(m, off, sizeof(*ip), buf)) == NULL)
return (p);
SipHash24_Update(ctx, ip-ip_src, sizeof(struct in_addr));
SipHash24_Update(ctx, ip-ip_dst, sizeof(struct in_addr));
+
+ /* l4 hash */
+ switch (ip-ip_p) {
+ case IPPROTO_TCP:
+ case IPPROTO_UDP:
+ iphlen = ip-ip_hl 2;
+ if (iphlen sizeof(*ip))
+ break;
+ off += iphlen;
+ ports = (u_int32_t *) trunk_gethdr(m, off,
sizeof(*ports), buf);
+ if (ports == NULL)
+ break;
+ SipHash24_Update(ctx, ports, sizeof(*ports));
+ break;
+ }
break;
#endif
#ifdef INET6
--
Re: random and time
On Thu, 11 Dec 2014 19:49:35 -0700 Theo de Raadt dera...@cvs.openbsd.org wrote: From the code I've been reading, I am certain some folk have looked into it. I'd even go as far as saying that there should be some folk around owning 0-days building on top of that. It's easy to synchronize with a web-server's time, even when it is not NTP-synchronized. The HTTP-Header is very helpful there. I am glad to know OpenBSD takes crypto seriously. Cheers FRIGN -- FRIGN d...@frign.de
pcap(3) manpage fixes
Function arguments in synopsis for pcap_inject and pcap_sendpacket are a bit messed up by comma. Types updated from actual code. And some .An and .In macro fixes while there. Index: pcap.3 === RCS file: /cvs/src/lib/libpcap/pcap.3,v retrieving revision 1.35 diff -u -p -r1.35 pcap.3 --- pcap.3 25 Jun 2013 16:49:39 - 1.35 +++ pcap.3 11 Dec 2014 23:13:38 - @@ -26,7 +26,7 @@ .Nm pcap .Nd Packet Capture library .Sh SYNOPSIS -.Fd #include pcap.h +.In pcap.h .Ft pcap_t * .Fn pcap_open_live char *device int snaplen int promisc int to_ms char *errbuf .Ft pcap_t * @@ -46,9 +46,9 @@ .Ft void .Fn pcap_dump u_char *user struct pcap_pkthdr *h u_char *sp .Ft int -.Fn pcap_inject pcap_t *p void *, size_t +.Fn pcap_inject pcap_t *p const void *buf size_t len .Ft int -.Fn pcap_sendpacket pcap_t *p void *, int +.Fn pcap_sendpacket pcap_t *p const u_char *buf int size .Ft int .Fn pcap_compile pcap_t *p struct bpf_program *fp char *str int optimize bpf_u_int32 netmask .Ft int @@ -562,7 +562,10 @@ routine to an error string. .Xr tcpdump 8 .\ , tcpslice(1) .Sh AUTHORS -Van Jacobson, -Craig Leres and -Steven McCanne, all of the +.An -nosplit +.An Van Jacobson , +.An Craig Leres +and +.An Steven McCanne , +all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
swapctl(2) manpage cleanup
The last sentence in HISTORY perhaps made sense before forking from Nx, but imho it's not relevant afterwards, especially since it mentions a header file which didn't come to Ox. .In and .An macro fixes, while there. Index: swapctl.2 === RCS file: /cvs/src/lib/libc/sys/swapctl.2,v retrieving revision 1.19 diff -u -p -r1.19 swapctl.2 --- swapctl.2 30 Sep 2013 12:02:36 - 1.19 +++ swapctl.2 12 Dec 2014 13:53:29 - @@ -36,9 +36,9 @@ .Nm swapctl .Nd modify swap configuration .Sh SYNOPSIS -.Fd #include sys/param.h -.Fd #include sys/swap.h -.Fd #include unistd.h +.In sys/param.h +.In sys/swap.h +.In unistd.h .Ft int .Fn swapctl int cmd const void *arg int misc .Sh DESCRIPTION @@ -218,15 +218,8 @@ The .Fn swapctl function call appeared in .Nx 1.3 . -The -.Fa se_path -member was added to -.Li struct swapent -in -.Nx 1.4 , -when the header file was also moved from -.Aq Pa vm/vm_swap.h . .Sh AUTHORS +.An -nosplit The current swap system was designed and implemented by .An Matthew Green Aq Mt m...@eterna.com.au , with help from
Re: Reduce OPENSSL_VERSION_TEXT to LibreSSL
On Thu, Dec 11, 2014 at 04:57:21PM +0100, Mark Kettenis wrote:
From: Bob Beck b...@openbsd.org
Date: Thu, 11 Dec 2014 08:39:15 -0700
i.e. if we want the openssl command to report someting specific we
put it in there, not a globally visible string that will be used for
the wrong things.
I think you guys are trying to hard to prevent people to shoot
themselves in the foot. As long as OpenSSL includes a version number
there, people will try this anyway. Shrug.
You're probably right Mark. Ports can and do patch opensslv.h anyway.
The more important thing is that the runtime query for version matches
the release, be it via openssl(1) or language bindings.
This should satisfy that requirement, prevent external code from baking
in an outdated string, and make it easy for -portable to keep its
runtime version number up-to-date as well.
ok?
Index: libcrypto/crypto/Makefile
===
RCS file: /cvs/src/lib/libcrypto/crypto/Makefile,v
retrieving revision 1.51
diff -u -p -u -p -r1.51 Makefile
--- libcrypto/crypto/Makefile 3 Dec 2014 22:14:38 - 1.51
+++ libcrypto/crypto/Makefile 12 Dec 2014 14:07:58 -
@@ -7,6 +7,8 @@ LCRYPTO_SRC=${SSL_SRC}/crypto
CFLAGS+= -Wall -Werror
+CFLAGS+= -DLIBRESSL_VERSION=\2.1\
+
.include bsd.own.mk # for 'NOPIC' definition
.if !defined(NOPIC)
CFLAGS+= -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_FUNOPEN
Index: libssl/src/crypto/cversion.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/cversion.c,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 cversion.c
--- libssl/src/crypto/cversion.c11 Jul 2014 11:42:28 - 1.15
+++ libssl/src/crypto/cversion.c12 Dec 2014 14:07:59 -
@@ -66,7 +66,7 @@ SSLeay_version(int t)
{
switch (t) {
case SSLEAY_VERSION:
- return OPENSSL_VERSION_TEXT;
+ return OPENSSL_VERSION_TEXT LIBRESSL_VERSION;
case SSLEAY_BUILT_ON:
return(built on: date not available);
case SSLEAY_CFLAGS:
Index: libssl/src/crypto/opensslv.h
===
RCS file: /cvs/src/lib/libssl/src/crypto/opensslv.h,v
retrieving revision 1.28
diff -u -p -u -p -r1.28 opensslv.h
--- libssl/src/crypto/opensslv.h14 Oct 2014 13:12:35 - 1.28
+++ libssl/src/crypto/opensslv.h12 Dec 2014 14:07:59 -
@@ -4,7 +4,7 @@
#define LIBRESSL_VERSION_NUMBER0x2000L
#define OPENSSL_VERSION_NUMBER 0x2000L
-#define OPENSSL_VERSION_TEXT LibreSSL 2.1
+#define OPENSSL_VERSION_TEXT LibreSSL
#define OPENSSL_VERSION_PTEXT part of OPENSSL_VERSION_TEXT
#define SHLIB_VERSION_HISTORY
Re: pcap(3) manpage fixes
Hi Kaspars, Kaspars Bankovskis wrote on Fri, Dec 12, 2014 at 03:22:16PM +0200: Function arguments in synopsis for pcap_inject and pcap_sendpacket are a bit messed up by comma. Types updated from actual code. And some .An and .In macro fixes while there. Committed, thanks. Some more argument names are missing, and i wouldn't be surprised if more argument types were wrong. If someone knowledgeable in this area could clean it up, that might be welcome. It's one of these pages that are kind of a mess in the first place, somewhat like rpc(3), excessively huge and suspiciously terse at the same time, quite possibly lacking relevant details in spite of all that bulk... :-( Yours, Ingo Index: pcap.3 === RCS file: /cvs/src/lib/libpcap/pcap.3,v retrieving revision 1.35 diff -u -p -r1.35 pcap.3 --- pcap.325 Jun 2013 16:49:39 - 1.35 +++ pcap.311 Dec 2014 23:13:38 - @@ -26,7 +26,7 @@ .Nm pcap .Nd Packet Capture library .Sh SYNOPSIS -.Fd #include pcap.h +.In pcap.h .Ft pcap_t * .Fn pcap_open_live char *device int snaplen int promisc int to_ms char *errbuf .Ft pcap_t * @@ -46,9 +46,9 @@ .Ft void .Fn pcap_dump u_char *user struct pcap_pkthdr *h u_char *sp .Ft int -.Fn pcap_inject pcap_t *p void *, size_t +.Fn pcap_inject pcap_t *p const void *buf size_t len .Ft int -.Fn pcap_sendpacket pcap_t *p void *, int +.Fn pcap_sendpacket pcap_t *p const u_char *buf int size .Ft int .Fn pcap_compile pcap_t *p struct bpf_program *fp char *str int optimize bpf_u_int32 netmask .Ft int @@ -562,7 +562,10 @@ routine to an error string. .Xr tcpdump 8 .\ , tcpslice(1) .Sh AUTHORS -Van Jacobson, -Craig Leres and -Steven McCanne, all of the +.An -nosplit +.An Van Jacobson , +.An Craig Leres +and +.An Steven McCanne , +all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.
chmod: range checks
Hi,
chmod doesn't check if the program name is at least 3 characters long
before checking its index 2.
Also, there is a compiler warning about signed vs unsigned when val
is used. In one instance, it's used with strtoul, in another with strtol,
checking its ranges. It's okay due to automatic casting but definitely
no clean code.
Tobias
Index: chmod.c
===
RCS file: /cvs/src/bin/chmod/chmod.c,v
retrieving revision 1.31
diff -u -p -u -p -r1.31 chmod.c
--- chmod.c 6 Oct 2014 17:37:34 - 1.31
+++ chmod.c 12 Dec 2014 17:10:29 -
@@ -58,7 +58,7 @@ main(int argc, char *argv[])
FTS *ftsp;
FTSENT *p;
void *set;
- long val;
+ unsigned long val;
int oct;
mode_t omode;
int Hflag, Lflag, Rflag, ch, fflag, fts_options, hflag, rval;
@@ -69,10 +69,12 @@ main(int argc, char *argv[])
setlocale(LC_ALL, );
- ischown = __progname[2] == 'o';
- ischgrp = __progname[2] == 'g';
- ischmod = __progname[2] == 'm';
- ischflags = __progname[2] == 'f';
+ if (strlen(__progname) 2) {
+ ischown = __progname[2] == 'o';
+ ischgrp = __progname[2] == 'g';
+ ischmod = __progname[2] == 'm';
+ ischflags = __progname[2] == 'f';
+ }
uid = (uid_t)-1;
gid = (gid_t)-1;
@@ -171,8 +173,8 @@ done:
mode = *argv;
if (*mode = '0' *mode = '7') {
errno = 0;
- val = strtol(mode, ep, 8);
- if (val INT_MAX || val 0)
+ val = strtoul(mode, ep, 8);
+ if (val INT_MAX)
errno = ERANGE;
if (errno)
err(1, invalid file mode: %s, mode);
panic: ehci_device_clear_toggle: queue active
I think this problem is particular to these machine because I cannot reproduce in my other openbsd machines when using same kernel and usb dongle... serial transcript - dmesg + ddb - attached - cannot paste well because of gmail. transcript Description: Binary data
Re: chmod: range checks
On Fri, 12 Dec 2014 18:16:35 +0100, Tobias Stoeckmann wrote: chmod doesn't check if the program name is at least 3 characters long before checking its index 2. OK. Also, there is a compiler warning about signed vs unsigned when val is used. In one instance, it's used with strtoul, in another with strtol, checking its ranges. It's okay due to automatic casting but definitely no clean code. OK. This is still a comparision between signed and unsigned but since INT_MAX is a constant the compiler can tell that it is safe. - todd
Re: panic: ehci_device_clear_toggle: queue active
On Fri, Dec 12, 2014, Abel Abraham Camarillo Ojeda wrote: I think this problem is particular to these machine because I cannot reproduce in my other openbsd Something similar happens on a Dell 6150 laptop (see below). The same (ANT+) USB stick does not trigger a panic on a Dell D830 (running some older OpenBSD version). The panic is triggered when GoldenCheetah tries to access the ANT+ stick. It seems something like this has been reported before; I found a few hits yesterday when I encountered the problem, but didn't see a solution in those mails. panic: ehci_device_clear_toggle: queue active ... Debugger() at Debugger+0x9 ehci_device_clear_toggle() at ehci_device_clear_toggle+0x2b usbd_clear_endpoint_stall() at usbd_clear_endpoint_stall+0x24 ugen_do_read() at ugen_do_read+0x4bc ugenread() at ugenread+0x48 spec_read() at spec_read_0x2c3 VOP_READ() at VOP_READ+0x3f vn_read() at vn_read+0xa1 dofilereadv() at dofilereadv+0x1c4 sys_read() at sys_read+0xaa syscall() at syscall+0x297 --- syscall (number 3) --- end of kernel end trace frame: 0x81, count: -12 0x11fd0fdbef8a: PID PPID PGRP UID S FLAGS WAIT COMMAND 7815 13631 13631 1037 3 0x83 thrsleep GoldenCheetah 1997 13631 13631 1037 3 0x483 select GoldenCheetah 30002 13631 13631 1037 3 0x483 thrsleep GoldenCheetah 24210 13631 13631 1037 3 0x483 poll GoldenCheetah *19973 13631 13631 1037 7 0x483 GoldenCheetah 13631 30656 13631 1037 3 0x8b pausesh ... xterms ... 17380 0 00 3 0x14200 usbtsk usbtask 1821 0 00 3 0x14200 usbatsk usbatask OpenBSD 5.6 (GENERIC.MP) #333: Fri Aug 8 00:20:21 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 30config_unit,memory_size real mem = 8495951872 (8102MB) avail mem = 8261009408 (7878MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xf2440 (67 entries) bios0: vendor Dell Inc. version A12 date 05/09/2012 bios0: Dell Inc. Latitude E6510 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC TCPA MCFG HPET BOOT SLIC SSDT acpi0: wakeup devices AGP_(S4) P0P1(S4) UAR1(S3) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2449.14 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2314.35 MHz 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 2, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2345.20 MHz cpu2: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz, 2344.81 MHz cpu3: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 2, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (AGP_) acpiprt2 at acpi0: bus 10 (P0P1) acpiprt3 at acpi0: bus 1 (RP01) acpiprt4 at acpi0: bus -1 (RP02) acpiprt5 at acpi0: bus 2 (RP03) acpiprt6 at acpi0: bus 4 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG3) acpiprt11 at acpi0: bus -1 (PEG5) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpibtn0 at acpi0: LID_
Re: relayd: convert to siphash
On Wed, Dec 10, 2014 at 21:51, Max Fillinger wrote:
Here's a version without malloc'ing the key.
Looks like it still does?
+ if (sip_key == NULL) {
+ sip_key = malloc(SIPHASH_KEY_LENGTH);
+ arc4random_buf(sip_key,
SIPHASH_KEY_LENGTH);
@@ -515,8 +516,8 @@ struct rsession {
struct ctl_relay_event se_in;
struct ctl_relay_event se_out;
void *se_priv;
- u_int32_tse_hashkey;
- int se_hashkeyset;
+ SIPHASH_CTX se_hashctx;
+ int se_hashctxset;
This isn't really how the hash ctx is supposed to be used. relayd is
doing something a little different here. I'll look at it eventually,
but this isn't as straightforward as a mechanical conversion.
Re: Make dhclient not use lease files
Why aren't you just deleting the lease file on shutdown?
On Dec 8, 2014 10:04 AM, Jurjen Oskam jur...@osk.am wrote:
Hi,
My (residential) ISP assigns me an IP address using DHCP. The lease time
is 7
days or so. I just put dhcp in hostname.re1 and everything works, except
for
a minor annoyance.
When re1 goes down (e.g. because of a reboot) the ISP *requires* a
successful
DHCP exchange to occur before it enables the link on a layer 3 level. It
does
not matter whether there still is a valid lease or not: after re1 goes
down,
there *has* to be a DHCP exchange otherwise the link won't work.
What makes this worse is that the DHCP server does not always immediately
respond after re1 comes back up. It regularly happens that dhclient
concludes
that the DHCP server is unreachable, finds that it still has a valid lease
in the lease file, and it'll use that. The problem with this is that
dhclient
doesn't seem to try to contact the server anymore. With long lease times,
it
could take days for dhclient to try to renew the lease.
I've tried using timeout 0 in dhclient.conf, but that only causes
dhclient
to immediately using the lease from the lease file (after trying to
reacquire
its previous address for ten seconds). Using an arbitrarily high timeout
value doesn't seem right.
The retry setting doesn't seem to help in this case: by default it's set to
5 minutes, but in my testing I noticed that once dhclient is bound to a
lease
from the lease file, this setting doesn't seem to be used anymore.
Perhaps I've missed something, but I concluded that in my scenario lease
files are never useful. I modified dhclient to accept a new option called
no-lease-file in dhclient.conf. A diff against -current is below. I've
tested it lightly on a laptop, and it seems to work OK. I've been using
roughly the same diff against -stable for a day or two.
Index: sbin/dhclient/clparse.c
===
RCS file: /cvs/src/sbin/dhclient/clparse.c,v
retrieving revision 1.90
diff -u -p -r1.90 clparse.c
--- sbin/dhclient/clparse.c 3 Nov 2014 22:06:39 - 1.90
+++ sbin/dhclient/clparse.c 8 Dec 2014 10:07:39 -
@@ -67,6 +67,7 @@ read_client_conf(void)
new_parse(path_dhclient_conf);
/* Set some defaults. */
+ config-use_lease_file = 1;
config-link_timeout = 10;
config-timeout = 60;
config-select_interval = 0;
@@ -153,6 +154,7 @@ read_client_leases(void)
* TOK_BACKOFF_CUTOFF number |
* TOK_INITIAL_INTERVAL number |
* interface-declaration |
+ * TOK_NO_LEASE_FILE |
* TOK_LEASE client-lease-statement |
* TOK_ALIAS client-lease-statement |
* TOK_REJECT reject-statement
@@ -240,6 +242,10 @@ parse_client_statement(FILE *cfile)
break;
case TOK_INTERFACE:
parse_interface_declaration(cfile);
+ break;
+ case TOK_NO_LEASE_FILE:
+ config-use_lease_file = 0;
+ parse_semi(cfile);
break;
case TOK_LEASE:
parse_client_lease_statement(cfile, 1);
Index: sbin/dhclient/conflex.c
===
RCS file: /cvs/src/sbin/dhclient/conflex.c,v
retrieving revision 1.29
diff -u -p -r1.29 conflex.c
--- sbin/dhclient/conflex.c 5 May 2014 18:02:49 - 1.29
+++ sbin/dhclient/conflex.c 8 Dec 2014 10:07:39 -
@@ -352,6 +352,7 @@ static const struct keywords {
{ media, TOK_MEDIA },
{ medium, TOK_MEDIUM },
{ next-server,TOK_NEXT_SERVER },
+ { no-lease-file, TOK_NO_LEASE_FILE },
{ option, TOK_OPTION },
{ prepend,TOK_PREPEND },
{ rebind, TOK_REBIND },
Index: sbin/dhclient/dhclient.c
===
RCS file: /cvs/src/sbin/dhclient/dhclient.c,v
retrieving revision 1.343
diff -u -p -r1.343 dhclient.c
--- sbin/dhclient/dhclient.c8 Dec 2014 02:04:58 - 1.343
+++ sbin/dhclient/dhclient.c8 Dec 2014 10:07:39 -
@@ -549,15 +549,17 @@ main(int argc, char *argv[])
close(tailfd);
}
- if ((fd = open(path_dhclient_db,
- O_RDONLY|O_EXLOCK|O_CREAT|O_NOFOLLOW, 0640)) == -1)
- error(can't open and lock %s: %s, path_dhclient_db,
- strerror(errno));
- read_client_leases();
- if ((leaseFile = fopen(path_dhclient_db, w)) == NULL)
- error(can't open %s: %s, path_dhclient_db,
strerror(errno));
- rewrite_client_leases();
- close(fd);
+ if (config-use_lease_file) {
+ if ((fd = open(path_dhclient_db,
+
Re: chmod: range checks
On Fri, Dec 12, 2014 at 10:45:04AM -0700, Todd C. Miller wrote:
On Fri, 12 Dec 2014 18:16:35 +0100, Tobias Stoeckmann wrote:
chmod doesn't check if the program name is at least 3 characters long
before checking its index 2.
OK.
Just throwing this out there: will this program ever get
installed with filename shorter than ch{grp,mod,own,flags}?
--patrick
Also, there is a compiler warning about signed vs unsigned when val
is used. In one instance, it's used with strtoul, in another with strtol,
checking its ranges. It's okay due to automatic casting but definitely
no clean code.
OK. This is still a comparision between signed and unsigned but
since INT_MAX is a constant the compiler can tell that it is safe.
- todd
ospfd siphash
This is pretty easy.
Index: lsupdate.c
===
RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
retrieving revision 1.41
diff -u -p -r1.41 lsupdate.c
--- lsupdate.c 17 Jan 2013 09:06:35 - 1.41
+++ lsupdate.c 12 Dec 2014 18:53:50 -
@@ -18,13 +18,13 @@
*/
#include sys/types.h
-#include sys/hash.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include stdlib.h
#include string.h
+#include siphash.h
#include ospf.h
#include ospfd.h
@@ -528,6 +528,8 @@ struct lsa_cache {
u_int32_thashmask;
} lsacache;
+SIPHASH_KEY lsacachekey;
+
struct lsa_ref *lsa_cache_look(struct lsa_hdr *);
void
@@ -543,10 +545,17 @@ lsa_cache_init(u_int32_t hashsize)
for (i = 0; i hs; i++)
LIST_INIT(lsacache.hashtbl[i]);
+ arc4random_buf(lsacachekey, sizeof(lsacachekey));
lsacache.hashmask = hs - 1;
}
+uint32_t
+lsa_hash_hdr(const struct lsa_hdr *hdr)
+{
+ return SipHash24(lsacachekey, hdr, sizeof(*hdr));
+}
+
struct lsa_ref *
lsa_cache_add(void *data, u_int16_t len)
{
@@ -573,8 +582,7 @@ lsa_cache_add(void *data, u_int16_t len)
ref-len = len;
ref-refcnt = 1;
- head = lsacache.hashtbl[hash32_buf(ref-hdr, sizeof(ref-hdr),
- HASHINIT) lsacache.hashmask];
+ head = lsacache.hashtbl[lsa_hash_hdr(ref-hdr) lsacache.hashmask];
LIST_INSERT_HEAD(head, ref, entry);
return (ref);
}
@@ -612,8 +620,7 @@ lsa_cache_look(struct lsa_hdr *lsa_hdr)
struct lsa_cache_head *head;
struct lsa_ref *ref;
- head = lsacache.hashtbl[hash32_buf(lsa_hdr, sizeof(*lsa_hdr),
- HASHINIT) lsacache.hashmask];
+ head = lsacache.hashtbl[lsa_hash_hdr(lsa_hdr) lsacache.hashmask];
LIST_FOREACH(ref, head, entry) {
if (memcmp(ref-hdr, lsa_hdr, sizeof(*lsa_hdr)) == 0)
Re: chmod: range checks
On Fri, Dec 12, 2014 at 10:42:21AM -0800, patrick keshishian wrote:
Just throwing this out there: will this program ever get
installed with filename shorter than ch{grp,mod,own,flags}?
No.
It's still a form of input validation. Therefore, it should be done.
And a user can create such a link (even though behavior is pretty
obfuscated then).
$ cd ~/bin
$ which x
which: x: Command not found.
$ ln -s /bin/chmod x
$ x
usage: x [-h] [-R [-H | -L | -P]] group file ...
$ _
Tobias
Re: relayd: convert to siphash
On Fri, Dec 12, 2014 at 12:57:08PM -0500, Ted Unangst wrote:
On Wed, Dec 10, 2014 at 21:51, Max Fillinger wrote:
Here's a version without malloc'ing the key.
Looks like it still does?
+ if (sip_key == NULL) {
+ sip_key = malloc(SIPHASH_KEY_LENGTH);
+ arc4random_buf(sip_key,
SIPHASH_KEY_LENGTH);
@@ -515,8 +516,8 @@ struct rsession {
struct ctl_relay_event se_in;
struct ctl_relay_event se_out;
void*se_priv;
- u_int32_tse_hashkey;
- int se_hashkeyset;
+ SIPHASH_CTX se_hashctx;
+ int se_hashctxset;
This isn't really how the hash ctx is supposed to be used. relayd is
doing something a little different here. I'll look at it eventually,
but this isn't as straightforward as a mechanical conversion.
I saw the diff and I will take care of it. It needs some work but
that comes along with other changes that I'm doing in the hash code as
well.
Reyk
Re: siphash in bgpd
On Mon, Dec 08, 2014 at 18:58, Ted Unangst wrote:
bgpd seemed like a good place to try out the new siphash functions.
Three hash tables are pretty straight forward conversions. Diff below.
Done.
rde_rib.c nexthop_hash uses hash32 for ipv6, and a simple xor hash for
ipv4. I left that alone as the diff would be more than mechanical.
red_update.c up_generate also uses hash32 to generate a hint for the
RB tree. I left that alone as well.
Now for these two. Convert nexthop_hash to actually hash the ip4
address. Probably an improvement. Am I missing a reason why this would
need to be deterministic?
The rb tree hint probably doesn't matter as much, but for the sake of
consistency, I think it's best.
Index: rde_rib.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_rib.c,v
retrieving revision 1.140
diff -u -p -r1.140 rde_rib.c
--- rde_rib.c 12 Dec 2014 18:15:51 - 1.140
+++ rde_rib.c 12 Dec 2014 20:12:01 -
@@ -18,7 +18,6 @@
#include sys/types.h
#include sys/queue.h
-#include sys/hash.h
#include stdlib.h
#include string.h
@@ -1065,6 +1064,8 @@ struct nexthop_table {
u_int32_tnexthop_hashmask;
} nexthoptable;
+SIPHASH_KEY nexthoptablekey;
+
void
nexthop_init(u_int32_t hashsize)
{
@@ -1078,6 +1079,7 @@ nexthop_init(u_int32_t hashsize)
for (i = 0; i hs; i++)
LIST_INIT(nexthoptable.nexthop_hashtbl[i]);
+ arc4random_buf(nexthoptablekey, sizeof(nexthoptablekey));
nexthoptable.nexthop_hashmask = hs - 1;
}
@@ -1308,17 +1310,16 @@ nexthop_hash(struct bgpd_addr *nexthop)
switch (nexthop-aid) {
case AID_INET:
- h = (AF_INET ^ ntohl(nexthop-v4.s_addr) ^
- ntohl(nexthop-v4.s_addr) 13)
- nexthoptable.nexthop_hashmask;
+ h = SipHash24(nexthoptablekey, nexthop-v4.s_addr,
+ sizeof(nexthop-v4.s_addr));
break;
case AID_INET6:
- h = hash32_buf(nexthop-v6, sizeof(struct in6_addr),
- HASHINIT) nexthoptable.nexthop_hashmask;
+ h = SipHash24(nexthoptablekey, nexthop-v6,
+ sizeof(struct in6_addr));
break;
default:
fatalx(nexthop_hash: unsupported AF);
}
- return (nexthoptable.nexthop_hashtbl[h]);
+ return (nexthoptable.nexthop_hashtbl[h
nexthoptable.nexthop_hashmask]);
}
Index: rde_update.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_update.c,v
retrieving revision 1.81
diff -u -p -r1.81 rde_update.c
--- rde_update.c14 Aug 2013 20:34:27 - 1.81
+++ rde_update.c12 Dec 2014 20:17:19 -
@@ -17,11 +17,11 @@
*/
#include sys/types.h
#include sys/queue.h
-#include sys/hash.h
#include limits.h
#include stdlib.h
#include string.h
+#include siphash.h
#include bgpd.h
#include rde.h
@@ -63,6 +63,8 @@ RB_GENERATE(uptree_prefix, update_prefix
RB_PROTOTYPE(uptree_attr, update_attr, entry, up_attr_cmp)
RB_GENERATE(uptree_attr, update_attr, entry, up_attr_cmp)
+SIPHASH_KEY uptree_key;
+
void
up_init(struct rde_peer *peer)
{
@@ -78,6 +80,7 @@ up_init(struct rde_peer *peer)
peer-up_acnt = 0;
peer-up_nlricnt = 0;
peer-up_wcnt = 0;
+ arc4random_buf(uptree_key, sizeof(uptree_key));
}
void
@@ -363,6 +366,7 @@ up_generate(struct rde_peer *peer, struc
{
struct update_attr *ua = NULL;
struct update_prefix*up;
+ SIPHASH_CTX ctx;
if (asp) {
ua = calloc(1, sizeof(struct update_attr));
@@ -378,10 +382,11 @@ up_generate(struct rde_peer *peer, struc
* use aspath_hash as attr_hash, this may be unoptimal
* but currently I don't care.
*/
- ua-attr_hash = hash32_buf(ua-attr, ua-attr_len, HASHINIT);
+ SipHash24_Init(ctx, uptree_key);
+ SipHash24_Update(ctx, ua-attr, ua-attr_len);
if (ua-mpattr)
- ua-attr_hash = hash32_buf(ua-mpattr, ua-mpattr_len,
- ua-attr_hash);
+ SipHash24_Update(ctx, ua-mpattr, ua-mpattr_len);
+ ua-attr_hash = SipHash24_End(ctx);
}
up = calloc(1, sizeof(struct update_prefix));
acpithinkpad handle event 0x6060
Hi! My ThinkPad Edge E130 (see dmesg below) generates this message, if the Fn-key is pressed for a few seconds: acpithinkpad0: unknown event 0x6060 I am not quite sure what the event is for, so the event name in the diff below might be misleadig, but I found some hints that the windows drivers would allow to toggle between legacy mode (F1-F12 for normal F1-F12 keys; Fn+F1-F12 for media keys) and default mode (F1-F12 for media keys; Fn+F1-F12 for normal F1-F12 keys). The diff just ignores the event... Index: acpithinkpad.c === RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v retrieving revision 1.41 diff -u -p -r1.41 acpithinkpad.c --- acpithinkpad.c 8 Oct 2014 14:30:32 - 1.41 +++ acpithinkpad.c 12 Dec 2014 19:31:23 - @@ -93,6 +93,7 @@ #defineTHINKPAD_THERMAL_TABLE_CHANGED 0x6030 #defineTHINKPAD_POWER_CHANGED 0x6040 #defineTHINKPAD_BACKLIGHT_CHANGED 0x6050 +#defineTHINKPAD_BUTTON_FN_TOGGLE 0x6060 #defineTHINKPAD_TABLET_SCREEN_CHANGED 0x60c0 #defineTHINKPAD_SWITCH_WIRELESS0x7000 @@ -373,6 +374,7 @@ thinkpad_hotkey(struct aml_node *node, i case THINKPAD_BUTTON_FN_F1: case THINKPAD_BUTTON_FN_F6: case THINKPAD_BUTTON_FN_SPACE: + case THINKPAD_BUTTON_FN_TOGGLE: case THINKPAD_BUTTON_LOCK_SCREEN: case THINKPAD_BUTTON_POINTER_SWITCH: case THINKPAD_BUTTON_THINKLIGHT: OpenBSD 5.6-current (GENERIC) #1: Fri Dec 12 20:04:07 CET 2014 root@boreas:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 3965214720 (3781MB) avail mem = 3855839232 (3677MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae3a000 (49 entries) bios0: vendor LENOVO version H4ET67WW (2.06 ) date 10/18/2012 bios0: LENOVO 335889G acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI UEFI MSDM UEFI DBG2 acpi0: wakeup devices P0P1(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) BLAN(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEG2(S4) PEG3(S4) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz, 1696.41 MHz 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,AVX,F16C,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 2 (RP01) acpiprt3 at acpi0: bus 3 (RP02) acpiprt4 at acpi0: bus 4 (RP03) acpiprt5 at acpi0: bus -1 (RP04) acpiprt6 at acpi0: bus -1 (RP05) acpiprt7 at acpi0: bus 9 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C2, C1, PSS acpitz0 at acpi0: critical temperature is 99 degC acpithinkpad0 at acpi0 acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model 45N1059 serial 21883 type LION oem LGC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: PWRB cpu0: Enhanced SpeedStep 1696 MHz: speeds: 1801, 1800, 1700, 1600, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800, 774 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 3G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 4000 rev 0x09 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M inteldrm0: 1366x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) xhci0 at pci0 dev 20 function 0 Intel 7 Series xHCI rev 0x04: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 Intel xHCI root hub rev 3.00/1.00 addr 1 Intel 7 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 Intel 7 Series USB rev 0x04: apic 2 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 7 Series HD Audio rev 0x04: msi azalia0: codecs: Realtek ALC269, Intel/0x2806, using Realtek ALC269 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 7 Series PCIE rev 0xc4: msi pci1 at
ldapd: server response code should be long long
The function send_ldap_extended_response() takes as its second-to-last
argument a long long result_code, but the infrastructure for handling
LDAP extended operations in ldap_extended() restricts them to an int.
I don't think there's any risk or bug here, this is just type
correctness.
Index: ldape.c
===
RCS file: /cvs/src/usr.sbin/ldapd/ldape.c,v
retrieving revision 1.18
diff -u -r1.18 ldape.c
--- ldape.c 2 Nov 2013 13:31:51 - 1.18
+++ ldape.c 12 Dec 2014 22:27:49 -
@@ -39,7 +39,7 @@
struct imsg *imsg);
static void ldape_needfd(struct imsgev *iev);
-int ldap_starttls(struct request *req);
+long long ldap_starttls(struct request *req);
voidsend_ldap_extended_response(struct conn *conn,
int msgid, unsigned long type,
long long result_code,
@@ -279,7 +279,7 @@
return ldap_respond(req, LDAP_COMPARE_FALSE);
}
-int
+long long
ldap_starttls(struct request *req)
{
if ((req-conn-listener-flags F_STARTTLS) == 0) {
@@ -294,12 +294,13 @@
int
ldap_extended(struct request *req)
{
- int i, rc = LDAP_PROTOCOL_ERROR;
+ int i;
+ long longrc = LDAP_PROTOCOL_ERROR;
char*oid = NULL;
struct ber_element *ext_val = NULL;
struct {
const char *oid;
- int (*fn)(struct request *);
+ long long (*fn)(struct request *);
} extended_ops[] = {
{ 1.3.6.1.4.1.1466.20037, ldap_starttls },
{ NULL }
Re: LibreSSL 2.1.2 released
With libressl 2.1.2, I observe: ldd -r /usr/lib64/libtls.so.1 linux-vdso.so.1 (0x7ffe5462e000) libc.so.6 = /lib64/libc.so.6 (0x7ffe5405f000) /lib64/ld-linux-x86-64.so.2 (0x7ffe5463) undefined symbol: GENERAL_NAME_free (/usr/lib64/libtls.so.1) undefined symbol: X509_NAME_get_text_by_NID (/usr/lib64/libtls.so.1) undefined symbol: ASN1_STRING_length(/usr/lib64/libtls.so.1) undefined symbol: SSL_get_error (/usr/lib64/libtls.so.1) undefined symbol: OBJ_txt2nid (/usr/lib64/libtls.so.1) undefined symbol: sk_pop_free (/usr/lib64/libtls.so.1) undefined symbol: SSL_write (/usr/lib64/libtls.so.1) undefined symbol: SSLv23_client_method (/usr/lib64/libtls.so.1) undefined symbol: sk_value (/usr/lib64/libtls.so.1) [...] Is this intentional, or would you concur that libressl-2.1.2/tls/Makefile.am should get a libtls_la_LIBADD = ../ssl/libssl.la line? In addition, when building for mingw, there is a warning. libtool: link: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries To solve that, simply add libcrypto_la_LDFLAGS = -no-undefined [same for libssl,libtls] Without this, the DLLs won't be produced.
Re: LibreSSL 2.1.2 released
On Dec 12, 2014, at 5:04 PM, Jan Engelhardt jeng...@inai.de wrote: With libressl 2.1.2, I observe: ldd -r /usr/lib64/libtls.so.1 linux-vdso.so.1 (0x7ffe5462e000) libc.so.6 = /lib64/libc.so.6 (0x7ffe5405f000) /lib64/ld-linux-x86-64.so.2 (0x7ffe5463) undefined symbol: GENERAL_NAME_free (/usr/lib64/libtls.so.1) undefined symbol: X509_NAME_get_text_by_NID (/usr/lib64/libtls.so.1) undefined symbol: ASN1_STRING_length(/usr/lib64/libtls.so.1) undefined symbol: SSL_get_error (/usr/lib64/libtls.so.1) undefined symbol: OBJ_txt2nid (/usr/lib64/libtls.so.1) undefined symbol: sk_pop_free (/usr/lib64/libtls.so.1) undefined symbol: SSL_write (/usr/lib64/libtls.so.1) undefined symbol: SSLv23_client_method (/usr/lib64/libtls.so.1) undefined symbol: sk_value (/usr/lib64/libtls.so.1) [...] Is this intentional, or would you concur that libressl-2.1.2/tls/Makefile.am should get a libtls_la_LIBADD = ../ssl/libssl.la line? That sounds right. In addition, when building for mingw, there is a warning. libtool: link: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries To solve that, simply add libcrypto_la_LDFLAGS = -no-undefined [same for libssl,libtls] Without this, the DLLs won't be produced. Thanks for the hint, will do! - Brent
ukbd.c update for older macbook airs
Hey,
On some macbook airs, the function keys have different functionality when the
Fn key is pressed. I've added an additional munge function to handle these
particular cases.
Thanks,
William Orr
Index: sys/dev/usb/ukbd.c
===
RCS file: /cvs/src/sys/dev/usb/ukbd.c,v
retrieving revision 1.69
diff -u -b -w -p -r1.69 ukbd.c
--- sys/dev/usb/ukbd.c 11 Dec 2014 18:39:27 - 1.69
+++ sys/dev/usb/ukbd.c 13 Dec 2014 04:18:55 -
@@ -180,6 +180,7 @@ struct ukbd_translation {
void ukbd_gdium_munge(void *, uint8_t *, u_int);
#endif
void ukbd_apple_munge(void *, uint8_t *, u_int);
+void ukbd_apple_mba_munge(void *, uint8_t *, u_int);
void ukbd_apple_iso_munge(void *, uint8_t *, u_int);
uint8_tukbd_translate(const struct ukbd_translation *, size_t,
uint8_t);
@@ -244,13 +245,29 @@ ukbd_attach(struct device *parent, struc
if (hid_locate(desc, dlen, HID_USAGE2(HUP_APPLE, HUG_FN_KEY),
uha-reportid, hid_input, sc-sc_apple_fn, qflags)) {
if (qflags HIO_VARIABLE) {
+ /* Older Macbook Air's have different fn key
layouts */
if (iso)
sc-sc_munge = ukbd_apple_iso_munge;
- else
+ else {
+ switch (uha-uaa-product) {
+ case
USB_PRODUCT_APPLE_WELLSPRING4A_ANSI:
+ case
USB_PRODUCT_APPLE_WELLSPRING4A_ISO:
+ case
USB_PRODUCT_APPLE_WELLSPRING4A_JIS:
+ case
USB_PRODUCT_APPLE_WELLSPRING4_ANSI:
+ case
USB_PRODUCT_APPLE_WELLSPRING4_ISO:
+ case
USB_PRODUCT_APPLE_WELLSPRING4_JIS:
+ case
USB_PRODUCT_APPLE_WELLSPRING_ANSI:
+ case
USB_PRODUCT_APPLE_WELLSPRING_ISO:
+ case
USB_PRODUCT_APPLE_WELLSPRING_JIS:
+ sc-sc_munge =
ukbd_apple_mba_munge;
+ break;
+ default:
sc-sc_munge = ukbd_apple_munge;
}
}
}
+ }
+ }
if (uha-uaa-vendor == USB_VENDOR_TOPRE
uha-uaa-product == USB_PRODUCT_TOPRE_HHKB) {
@@ -478,6 +495,52 @@ ukbd_apple_munge(void *vsc, uint8_t *ibu
{ 67, 127 },/* F10 - audio mute */
{ 68, 129 },/* F11 - audio lower */
{ 69, 128 },/* F12 - audio raise */
+#endif
+ { 79, 77 }, /* right - end */
+ { 80, 74 }, /* left - home */
+ { 81, 78 }, /* down - page down */
+ { 82, 75 } /* up - page up */
+ };
+
+ if (!hid_get_data(ibuf, ilen, sc-sc_apple_fn))
+ return;
+
+ spos = ibuf + kbd-sc_keycodeloc.pos / 8;
+ epos = spos + kbd-sc_nkeycode;
+
+ for (pos = spos; pos != epos; pos++) {
+ xlat = ukbd_translate(apple_fn_trans,
+ nitems(apple_fn_trans), *pos);
+ if (xlat != 0)
+ *pos = xlat;
+ }
+}
+
+void
+ukbd_apple_mba_munge(void *vsc, uint8_t *ibuf, u_int ilen)
+{
+ struct ukbd_softc *sc = vsc;
+ struct hidkbd *kbd = sc-sc_kbd;
+ uint8_t *pos, *spos, *epos, xlat;
+
+ static const struct ukbd_translation apple_fn_trans[] = {
+ { 40, 73 }, /* return - insert */
+ { 42, 76 }, /* backspace - delete */
+#ifdef notyet
+ { 58, 0 }, /* F1 - screen brightness down */
+ { 59, 0 }, /* F2 - screen brightness up */
+ { 60, 0 }, /* F3 */
+ { 61, 0 }, /* F4 */
+ { 62, 0 }, /* F5 */
+ { 63, 0 }, /* F6 - audio back */
+ { 64, 0 }, /* F7 - audio pause/play */
+ { 65, 0 }, /* F8 - audio next */
+#endif
+ { 66, 127 },/* F9 - audio mute */
+ { 67, 129 },/* F10 - audio lower */
+ { 68, 128 },/* F11 - audio raise */
+#ifdef notyet
+ { 69, 0 }, /* F12 - eject */
#endif
{ 79, 77 }, /* right - end */
{ 80, 74 }, /* left - home */
