Re: [patch] faq pf/carp
I think this just means that the 5.7 manpages need to be extracted on the www
server..
On 15 June 2015 13:50:54 BST, Julien Dhaille wrote:
>Hi tech,
>few links on the bottom of http://www.openbsd.org/faq/pf/carp.html
>looks
>broken ("Bad request, You specified an invalid manpath").
>
>cheers
>
>Index: www/faq/pf/carp.html
>===
>RCS file: /cvs/www/faq/pf/carp.html,v
>retrieving revision 1.41
>diff -u -p -u -r1.41 carp.html
>--- www/faq/pf/carp.html11 May 2015 11:18:30 - 1.41
>+++ www/faq/pf/carp.html15 Jun 2015 12:43:14 -
>@@ -690,10 +690,10 @@ Please see these other sources for more
>
>
>
>-http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4&manpath=OpenBSD+5.7
>"
>+href="http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4";
> >carp(4)
>
>-http://www.openbsd.org/cgi-bin/man.cgi?query=pfsync&sektion=4&manpath=OpenBSD+5.7
>"
>+href="http://www.openbsd.org/cgi-bin/man.cgi?query=pfsync&sektion=4";
> >pfsync(4)
>
> http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&sektion=8";
>@@ -702,7 +702,7 @@ Please see these other sources for more
> http://www.openbsd.org/cgi-bin/man.cgi?query=hostname.if&sektion=5";
> >hostname.if(5)
>
>-http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5&manpath=OpenBSD+5.7
>"
>+href="http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5
>"
> >pf.conf(5)
>
> http://www.openbsd.org/cgi-bin/man.cgi?query=ifstated&sektion=8";
--
Sent from a phone, please excuse the formatting.
[patch] cleaner checksum modification for pf
Hi,
These patches against HEAD re-instate the pf algorithm of OpenBSD 5.4
for preserving payload checksums end-to-end but rewritten without the
ugly and error-prone (but speedy!) nested pf_cksum_fixup calls.
I have been running this code on a small Alix (i386) IPv4 gateway for a
month with no obvious issues. To test as many of the affected features
as possible, its pf.conf included:
match scrub (random-id)
match on egress scrub (max-mss 1440, reassemble tcp)
match out on egress from !egress:network nat-to egress:0
pass out on egress inet proto tcp modulate state
pass in inet proto tcp from any to egress port ... rdr-to ...
I've tried to avoid significant performance impact on modern hardware,
and don't expect any, but have not tested this. I've aimed for
simplicity in the first instance and there is scope for optimisation if
necessary.
I've attached my test notes below, covering every change. Note:
- I was unable to test af-to, which does a lot of packet fiddling.
I've never used it before and was unable to get it working on a
generic kernel. I figure I'm just missing something. I used the line
pass out on vr0 inet af-to inet6 from fec0:0:0:2::1 to fec0:0:0:2::2
but although inet4 tcp connection attempts were translated
to fec0:0:0:2::2, its SYN replies received RST from the
router, fec0:0:02:::1.
- My inet6 testing was limited to two nodes connected via the alix
router.
- I've assumed that "rdr-to" is good if "nat-to" tests ok as the code
paths look virtually identical.
- I haven't tested modification of unaligned TCP options,
for SACK and timestamp, but have tested the unaligned paths of the
change primitives.
- the patch includes a small fix for pf_pdesc_setup to setup the
pdesc protocol checksum for ICMPv6
The patch is in three commits to ease review, to be applied in order:
0. rename pf_change_a -> pf_change_32_unaligned to better reflect its
use
1. reinstate pf_cksum_fixup sans nesting
2. avoid unnecessary calls to pf_change_32_unaligned
...but if another format is easier, let me know.
This patch should be examined closely --- it's been a while since I've
worked at this level and I've never worked on OpenBSD code.
I'm keen to hear comments, questions or criticisms.
best,
Richard.
- [G] means that errors here are expected
to have been exposed in the course of running on the gateway.
- [O] means these changes involve primitives tested elsewhere.
pf_tcp_track_full, pf_create_state [G]
- modulate sequence number ("modulate state")
"pf_change_a", old unaligned copy -> pf_change_32
new pf_change_a
pf_translate
- translate address and port, if any
AF_INET [G]
AF_INET6 [TESTED between two addresses UDP, TCP, ICMP6]
- translate ICMP icmp_id for ICMP_ECHO [TESTED]
pf_change_16
- translate ICMP6 icmp6_id for ICMP6_ECHO [TESTED]
pf_change_16
- translate address for non TCP,UDP,ICMP,ICMP6 protocol [TESTED]
"pf_change_a", old unaligned copy -> pf_change_32
new pf_change_a
pf_modulate_sack
- modulate SACK sequence numbers [G]
pf_change_32_unaligned [need to test unaligned options]
minor refactoring to support fixup
pf_test_state_icmp
- translate ICMP unrelated to another connection, e.g ECHO [TESTED]
- translate icmp_id
- translate address
new pf_change_a
- ICMP error related to another connection, e.g dest unreachable
- translate address, quoted address, port ("nat", "rdr-to")
via pf_change_icmp, see this
- translate quoted address family ("af-to") [*]
via pf_change_icmp_af
pf_change_ap
TCP
- demodulate quoted TCP sequence number [TESTED]
"pf_change_a", old unaligned -> pf_change_32
UDP [TESTED]
- zero quoted UDP checksum
pf_change_16
pf_change_icmp [O]
- change quoted protocol port and address, if any
- change outer ip address
pf_cksum_fixup_a
pf_cksum_fixup
pf_change_a
pf_change_icmp_af
- replace quoted IPv4 / IPv6 headers with converse AF.
pf_cksum_cover / uncover
pf_translate_icmp_af [O]
- to AF_INET
- sets icmp type, code
nextmtu for ICMP6_PACKET_TOO_BIG
pptr for ICMP_PARAMPROB
- to AF_INET6
- sets icmp type, code
nextmtu for ICMP_UNREACH_NEEDFRAG
ptr for ICMP_PARAMPROB
pf_change_8 [TESTED when testing alt
Re: Waiting for 'high priority' events with kqueue
On 15 June 2015 at 22:40, Mark Kettenis wrote:
>> I'm using this inside an event handling library/framework.
>> It uses a kqueue rather than poll() or select() under the hood.
>> The users of our API expect that they'd get the same behaviour as if
>> they used poll directly themselves.
>
> Most users don't actually expect OOB data. It's generally a bad idea
> to use it, since there are subtle difference between OSes, it is
> probably unwise for people to use this feature.
Sometimes you need it; invariably, if the OS offers it, someone will
come to need it.
e.g. this was recently fast tracked, as someone needed to poll the
sysfs on linux (which requires POLLPRI)
However (as a good cross platform library should), we're trying to add
baseline support for POLLPRI across all our targets.
>> The issue is one of feature parity. On posix-y systems, there are
>> multiple ways to wait for an event on a file descriptor.
>>
>> - select(), which takes a 'readable' set (equivalent to POLLIN), a
>> 'writable' set (equivalent to POLLOUT), and a 'error' set (POLLPRI +
>> some others depending on OS)
>> - poll(), which takes POLL{IN,RDNORM, RDBAND, PRI, OUT, WRNORM, WRBAND}
>> - Linux only: epoll(), which takes the same flags as poll()
>> - Solaris only: port with PORT_SOURCE_FD, which takes the same flags as
>> poll()
>> - BSDs: kqueue: which has EVFILT_READ (with default flags is
>> equivalent to POLLIN) and EVFILT_WRITE (equivalent to POLLOUT)
>>
>> Any given single threaded program generally has to pick one of the
>> above, and use it throughout.
>> The platform specific options (epoll, ports, kqueue) are generally
>> more performant.
>>
>> The issue I'm trying to solve is: if a program needs to poll for
>> priority events (i.e. POLLPRI) on OpenBSD, they have to use select()
>> or poll(); it takes the kqueue option off the table.
>> I'd like to fix this.
>>
>>
>> My suggested fix was to add the same API as OSX; i.e. EV_OOBAND flag,
>> which causes kqueue's EVFILT_READ to act like it was given POLLPRI
>> instead of just POLLIN.
>> But anything else that adds the ability would be fine too :)
>
> Well, given
>
> https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html
>
> I'd say, no. In fact, that article suggests this interface is no
> longer supported in OS X either.
I do recall that bug, I'm not sure what the fix the distributed ended up being.
> The article indicates that DagonFlyBSD has EVFILT_EXCEPT to signal OOB
> data. That would probably be a better choice. But as I said, the OOB
> data mechanism is an obscure feature and I'm not convinced that this
> is worth spending time on.
Ah ha! EVFILT_EXCEPT seems a much nicer solution to the problem.
Would OpenBSD consider adding support for it?
(as I mentioned above, I don't care *how* it's done, just that the
general facility is available via kqueue)
Daurn.
uslcom(4): add ID for Netgear M7100
This particular 10Gb switch from Netgear has both a standard DB9
serial port for its console, and a mini-USB port, selectable via
switch. The mini-USB is apparently connected to an internal CP2102
serial/USB adapter (0846:1100).
Comes with Windows drivers on CD; worked out-of-the-box (with 'cp210x'
module) on a random Linux box. On OpenBSD it gets bound to ugen, but
after adding the device ID to the uslcom(4) driver, console access
works perfectly via cuaU0.
Before:
ugen0 at uhub3 port 1 "Silicon Labs CP2102 USB to UART Bridge
Controller" rev 1.10/1.00 addr 3
After:
uslcom0 at uhub3 port 1 "Silicon Labs CP2102 USB to UART Bridge
Controller" rev 1.10/1.00 addr 2
ucom0 at uslcom0 portno 0
usbdevs -dv:
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x8086), rev 1.00
uhub3
port 1 addr 2: full speed, power 100 mA, config 1, CP2102 USB to UART
Bridge Controller(0x1100), Silicon Labs(0x0846), rev 1.00,
iSerialNumber 3713515PF00DF
uslcom0
port 2 addr 3: low speed, power 100 mA, config 1, APC AP5631(0x0706),
Avocent(0x0624), rev 1.00
uhidev0
uhidev1
Diff:
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.645
diff -u -p -r1.645 usbdevs
--- sys/dev/usb/usbdevs 16 Feb 2015 14:51:44 - 1.645
+++ sys/dev/usb/usbdevs 15 Jun 2015 18:24:38 -
@@ -3081,6 +3081,7 @@ product NETGEAR EA101 0x1001 Ethernet
product NETGEAR EA101X 0x1002 Ethernet
product NETGEAR FA101 0x1020 10/100 Ethernet
product NETGEAR FA120 0x1040 USB 2.0 Fast Ethernet
+product NETGEAR M7100 0x1100 M7100 switch console
product NETGEAR MA111NA 0x4110 802.11b
product NETGEAR MA111V2 0x4230 802.11b V2
product NETGEAR WG111V2_2 0x4240 PrismGT USB 2.0 WLAN
Index: sys/dev/usb/uslcom.c
===
RCS file: /cvs/src/sys/dev/usb/uslcom.c,v
retrieving revision 1.33
diff -u -p -r1.33 uslcom.c
--- sys/dev/usb/uslcom.c 23 Nov 2014 21:18:46 - 1.33
+++ sys/dev/usb/uslcom.c 15 Jun 2015 18:24:39 -
@@ -142,6 +142,7 @@ static const struct usb_devno uslcom_dev
{ USB_VENDOR_LINKINSTRUMENTS, USB_PRODUCT_LINKINSTRUMENTS_MSO28_2 },
{ USB_VENDOR_MEI, USB_PRODUCT_MEI_CASHFLOW_SC },
{ USB_VENDOR_MEI, USB_PRODUCT_MEI_S2000 },
+ { USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_M7100 },
{ USB_VENDOR_OWEN, USB_PRODUCT_OWEN_AC4 },
{ USB_VENDOR_PHILIPS, USB_PRODUCT_PHILIPS_ACE1001 },
{ USB_VENDOR_RENESAS, USB_PRODUCT_RENESAS_RX610 },
(I also attached the diff, because gmail appears to be munging tabs
when I paste it inline. Sorry about that; at least it's only two
lines.)
-Andrew
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.645
diff -u -p -r1.645 usbdevs
--- sys/dev/usb/usbdevs 16 Feb 2015 14:51:44 - 1.645
+++ sys/dev/usb/usbdevs 15 Jun 2015 18:24:38 -
@@ -3081,6 +3081,7 @@ product NETGEAR EA101 0x1001 Ethernet
product NETGEAR EA101X 0x1002 Ethernet
product NETGEAR FA101 0x1020 10/100 Ethernet
product NETGEAR FA120 0x1040 USB 2.0 Fast Ethernet
+product NETGEAR M7100 0x1100 M7100 switch console
product NETGEAR MA111NA0x4110 802.11b
product NETGEAR MA111V20x4230 802.11b V2
productNETGEAR WG111V2_2 0x4240 PrismGT USB 2.0 WLAN
Index: sys/dev/usb/uslcom.c
===
RCS file: /cvs/src/sys/dev/usb/uslcom.c,v
retrieving revision 1.33
diff -u -p -r1.33 uslcom.c
--- sys/dev/usb/uslcom.c23 Nov 2014 21:18:46 - 1.33
+++ sys/dev/usb/uslcom.c15 Jun 2015 18:24:39 -
@@ -142,6 +142,7 @@ static const struct usb_devno uslcom_dev
{ USB_VENDOR_LINKINSTRUMENTS, USB_PRODUCT_LINKINSTRUMENTS_MSO28_2 },
{ USB_VENDOR_MEI, USB_PRODUCT_MEI_CASHFLOW_SC },
{ USB_VENDOR_MEI, USB_PRODUCT_MEI_S2000 },
+ { USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_M7100 },
{ USB_VENDOR_OWEN, USB_PRODUCT_OWEN_AC4 },
{ USB_VENDOR_PHILIPS, USB_PRODUCT_PHILIPS_ACE1001 },
{ USB_VENDOR_RENESAS, USB_PRODUCT_RENESAS_RX610 },
patch: dump(8)'s Default Volume Behavior
On Sun, Jun 14, 2015 at 06:14:09PM -0600, Theo de Raadt wrote:
> > If so, let me know and I can write a patch.
>
> Please do, then it is easier for archaic people to play with it.
This is my first patch, so I may have made some mistakes.
I tried to correct and expand the man page while leaving its existing
format. It's a little redundant, but it seems like this caveat is
important enough to describe more than once.
Of course, this breaks existing scripts that used the -a option -
they'll just get the usage prompt. It will fail more dangerously
(silently) with scripts intended for old-style tapes, so (if I
understand correctly) it should probably go in "Following -current" and
the release notes.
Index: sbin/dump/dump.8
===
RCS file: /cvs/src/sbin/dump/dump.8,v
retrieving revision 1.49
diff -u -p -r1.49 dump.8
--- sbin/dump/dump.83 May 2015 01:44:34 - 1.49
+++ sbin/dump/dump.815 Jun 2015 23:16:10 -
@@ -40,7 +40,7 @@
.Sh SYNOPSIS
.Nm dump
.Bk -words
-.Op Fl 0123456789acnSuWw
+.Op Fl 0123456789AcnSuWw
.Op Fl B Ar records
.Op Fl b Ar blocksize
.Op Fl d Ar density
@@ -62,8 +62,8 @@ A dump that is larger than the output me
multiple volumes.
On most media the size is determined by writing until an
end-of-media indication is returned.
-This can be enforced by using the
-.Fl a
+This is the default behavior and can be overridden with the
+.Fl A
option.
.Pp
.Nm
@@ -98,7 +98,10 @@ On media that cannot reliably return an
each volume is of a fixed size;
the actual size is determined by the tape size, density and/or
block count options below.
-By default, the same output file name is used for each volume
+The
+.Fl A
+option should be used with such media.
+The same output file name is used for each volume
after prompting the operator to change media.
.Pp
Rewinding or ejecting tape features after a close operation on
@@ -126,15 +129,24 @@ to
copy all files new or modified since the
last dump of a lower level.
The default level is 0.
-.It Fl a
-.Dq auto-size .
-Bypass all tape length considerations, and enforce writing until
-an end-of-media indication is returned.
-This option is recommended for most modern tape drives.
-Use of this option is particularly
-recommended when appending to an existing tape, or using a tape
-drive with hardware compression (where you can never be sure about
-the compression ratio).
+.It Fl A
+.Dq fixed-size .
+Assume that the media cannot reliably return
+an end-of-media indication, and therefore use fixed
+volume sizes.
+.Nm
+will prompt the operator
+for the readiness of each
+volume before it is written to.
+.Pp
+This was once the default behavior of
+.Nm dump Ns ,
+while the
+.Fl a
+option enforced auto-sizing. The default was reversed
+because backup volumes
+without end-of-media indication are becoming
+increasingly rare.
.It Fl B Ar records
The number of kilobytes per volume, rounded
down to a multiple of the blocksize.
@@ -451,6 +463,13 @@ The
.Bx 4.3
option syntax is implemented for backward compatibility but
is not documented here.
+.Pp
+The
+.Fl A
+option first appeared and the
+.Fl a
+option was removed in
+.Ox 5.8 .
.Sh BUGS
Fewer than 32 read errors on the filesystem are ignored.
.Pp
Index: sbin/dump/dump.h
===
RCS file: /cvs/src/sbin/dump/dump.h,v
retrieving revision 1.24
diff -u -p -r1.24 dump.h
--- sbin/dump/dump.h23 May 2015 05:17:20 - 1.24
+++ sbin/dump/dump.h15 Jun 2015 23:16:10 -
@@ -68,7 +68,7 @@ int newtape;/* new tape flag */
intdensity;/* density in 0.1" units */
int64_ttapesize; /* estimated tape size, blocks */
int64_ttsize; /* tape size in 0.1" units */
-intunlimited; /* if set, write to end of medium */
+intfixed; /* if set, use fixed volume size */
int64_tasize; /* number of 0.1" units written on current tape
*/
intetapes; /* estimated number of tapes */
intnonodump; /* if set, do not honor UF_NODUMP user flags */
Index: sbin/dump/main.c
===
RCS file: /cvs/src/sbin/dump/main.c,v
retrieving revision 1.56
diff -u -p -r1.56 main.c
--- sbin/dump/main.c23 May 2015 05:17:20 - 1.56
+++ sbin/dump/main.c15 Jun 2015 23:16:10 -
@@ -115,7 +115,7 @@ main(int argc, char *argv[])
usage();
obsolete(&argc, &argv);
- while ((ch = getopt(argc, argv, "0123456789aB:b:cd:f:h:ns:ST:uWw")) !=
-1)
+ while ((ch = getopt(argc, argv, "0123456789AB:b:cd:f:h:ns:ST:uWw")) !=
-1)
switch (ch) {
/* dump level */
case '0': case '1': case '2': case '3': case '4':
@@ -193,8 +193,8 @@ main(int argc, char *argv[])
exit(X_FINOK); /* do nothing else */
break;
-
Re: fix stuck iwm(4) task thread
On Mon, Jun 15, 2015 at 05:04:38PM +0200, Stefan Sperling wrote:
> After suspend/resume I've found an iwm task sleeping forever. ps showed:
>
> 0 7029 0 0 -22 0 0 0 iwmau2 DK??0:00.00 (iwmns)
>
> In this state, the driver awaits a notification from the firmware
> which it won't ever get after the system has resumed from sleep.
> The task running the state change to 'auth' state should abort itself.
>
> The diff below should fix this particular (hard to reproduce) problem.
> I don't particularly enjoy adding more hacks like this but this is at
> least consistent with how this driver currently operates.
PLease disregard for now. This is not a very good fix.
I'd like to attempt a broader approach.
>
> Index: if_iwm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
> retrieving revision 1.45
> diff -u -p -r1.45 if_iwm.c
> --- if_iwm.c 15 Jun 2015 08:06:11 - 1.45
> +++ if_iwm.c 15 Jun 2015 11:59:54 -
> @@ -4984,7 +4984,7 @@ iwm_auth(struct iwm_softc *sc)
> struct iwm_node *in = (void *)ic->ic_bss;
> uint32_t duration;
> uint32_t min_duration;
> - int error;
> + int error, generation;
>
> in->in_assoc = 0;
>
> @@ -5025,6 +5025,7 @@ iwm_auth(struct iwm_softc *sc)
> 100 + in->in_ni.ni_intval);
> iwm_mvm_protect_session(sc, in, duration, min_duration, 500);
>
> + generation = sc->sc_generation;
> while (sc->sc_auth_prot != 2) {
> /*
>* well, meh, but if the kernel is sleeping for half a
> @@ -5038,7 +5039,9 @@ iwm_auth(struct iwm_softc *sc)
> sc->sc_auth_prot = 0;
> return EAUTH;
> }
> - tsleep(&sc->sc_auth_prot, 0, "iwmau2", 0);
> + tsleep(&sc->sc_auth_prot, 0, "iwmau2", hz);
> + if (generation != sc->sc_generation)
> + return (ENXIO);
> }
>
> return 0;
[patch]rcs: mark unlink as (void)
Hi tech@, mark this unlink(2) call as *(void)*, as there is no need to check the return value. This makes it more consistent to all other unlink(2) calls, since they are marked as *(void)* as well. Regards, --F. Index: co.c === RCS file: /cvs/src/usr.bin/rcs/co.c,v retrieving revision 1.121 diff -u -p -r1.121 co.c --- co.c13 Jun 2015 20:15:21 - 1.121 +++ co.c15 Jun 2015 19:50:12 - @@ -553,7 +553,7 @@ checkout_file_has_diffs(RCSFILE *rfp, RC ret = diffreg(dst, tempfile, bp, D_FORCEASCII); buf_free(bp); - unlink(tempfile); + (void)unlink(tempfile); free(tempfile); return (ret);
FAQ 15.2, invalid manpath
In FAQ 15.2, clicking on any of the pkg_add, pkg_delete, pkg_info or pkg_create links results in a Bad Request from man.cgi. None of the other manpage links raise the error. E.g., http://www.openbsd.org/cgi-bin/man.cgi?query=pkg_add&sektion=1&manpath=OpenBSD+5.7 …from… http://www.openbsd.org/faq/faq15.html#PkgMgmt Once I removed “manpath=OpenBSD+5.7” from the URL, I was taken to the right manpage.
fix stuck iwm(4) task thread
After suspend/resume I've found an iwm task sleeping forever. ps showed:
0 7029 0 0 -22 0 0 0 iwmau2 DK??0:00.00 (iwmns)
In this state, the driver awaits a notification from the firmware
which it won't ever get after the system has resumed from sleep.
The task running the state change to 'auth' state should abort itself.
The diff below should fix this particular (hard to reproduce) problem.
I don't particularly enjoy adding more hacks like this but this is at
least consistent with how this driver currently operates.
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_iwm.c
--- if_iwm.c15 Jun 2015 08:06:11 - 1.45
+++ if_iwm.c15 Jun 2015 11:59:54 -
@@ -4984,7 +4984,7 @@ iwm_auth(struct iwm_softc *sc)
struct iwm_node *in = (void *)ic->ic_bss;
uint32_t duration;
uint32_t min_duration;
- int error;
+ int error, generation;
in->in_assoc = 0;
@@ -5025,6 +5025,7 @@ iwm_auth(struct iwm_softc *sc)
100 + in->in_ni.ni_intval);
iwm_mvm_protect_session(sc, in, duration, min_duration, 500);
+ generation = sc->sc_generation;
while (sc->sc_auth_prot != 2) {
/*
* well, meh, but if the kernel is sleeping for half a
@@ -5038,7 +5039,9 @@ iwm_auth(struct iwm_softc *sc)
sc->sc_auth_prot = 0;
return EAUTH;
}
- tsleep(&sc->sc_auth_prot, 0, "iwmau2", 0);
+ tsleep(&sc->sc_auth_prot, 0, "iwmau2", hz);
+ if (generation != sc->sc_generation)
+ return (ENXIO);
}
return 0;
[patch] faq pf/carp
Hi tech,
few links on the bottom of http://www.openbsd.org/faq/pf/carp.html looks
broken ("Bad request, You specified an invalid manpath").
cheers
Index: www/faq/pf/carp.html
===
RCS file: /cvs/www/faq/pf/carp.html,v
retrieving revision 1.41
diff -u -p -u -r1.41 carp.html
--- www/faq/pf/carp.html11 May 2015 11:18:30 - 1.41
+++ www/faq/pf/carp.html15 Jun 2015 12:43:14 -
@@ -690,10 +690,10 @@ Please see these other sources for more
-http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4&manpath=OpenBSD+5.7
"
+http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4";
>carp(4)
-http://www.openbsd.org/cgi-bin/man.cgi?query=pfsync&sektion=4&manpath=OpenBSD+5.7
"
+http://www.openbsd.org/cgi-bin/man.cgi?query=pfsync&sektion=4";
>pfsync(4)
http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&sektion=8";
@@ -702,7 +702,7 @@ Please see these other sources for more
http://www.openbsd.org/cgi-bin/man.cgi?query=hostname.if&sektion=5";
>hostname.if(5)
-http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5&manpath=OpenBSD+5.7
"
+http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&sektion=5
"
>pf.conf(5)
http://www.openbsd.org/cgi-bin/man.cgi?query=ifstated&sektion=8";
--
Julien Dhaille
Re: Waiting for 'high priority' events with kqueue
> Date: Mon, 15 Jun 2015 12:59:50 +1000
> From: Daurnimator
>
> On 14 June 2015 at 14:51, Philip Guenther wrote:
> > On Wed, Jun 10, 2015 at 10:21 PM, Daurnimator wrote:
> >> I'm working on adding support for "high priority" events to a user space
> >> event library.
> >> Conceptually, I need the equivalent of poll() with POLLPRI, but via kqueue.
> >
> > POLLPRI only works for STREAMS. What sort of fd are you using this
> > on? What does it *mean*?
On OpenBSD POLLPRI and POLLRDBAND effectively are the same thing.
Pretty much means that there is OOB data to be read from a socket.
Other than hat, only some obscure pty code will generate them.
> Whatever it would mean to use POLLPRI with poll().
> Or a slightly looser criteria: whatever the equivalent to the 3rd set
> to select() means.
> ==> On OpenBSD, this is equivalent to POLLPRI:
> http://fxr.watson.org/fxr/source/kern/sys_generic.c?v=OPENBSD#L744
>
> >> FreeBSD and Apple OSX provide this via the 'EV_OOBAND' flag to EV_SET.
> >
> > Uh, I just checked against FreeBSD subversion I don't see an EV_OOBAND
> > in their kqueue(2) manpage or . What version did you see
> > this in?
>
> Sorry, I was confused on this point; I actually only saw it in the OSX
> sources:
> On OSX, poll() with POLLPRI is actually implemented **using** kqueue
> with EV_OOBAND.
> See:
> http://fxr.watson.org/fxr/source/bsd/kern/sys_generic.c?v=xnu-1699.24.8#L149
>
> >> Is there a way to wait for "high priority" events with kqueue on OpenBSD?
> >
> > Lacking a definition for "high priority", no.
> >
> >
> >> I had a read through various kernel sources, but didn't manage to find
> >> anything.
> >> Could OpenBSD add support for the EV_OOBAND flag?
> >
> > What Problem Are You Trying To Solve?
>
> I'm using this inside an event handling library/framework.
> It uses a kqueue rather than poll() or select() under the hood.
> The users of our API expect that they'd get the same behaviour as if
> they used poll directly themselves.
Most users don't actually expect OOB data. It's generally a bad idea
to use it, since there are subtle difference between OSes, it is
probably unwise for people to use this feature.
> >> Who is responsible for these sorts of things?
> >
> > Whomever is convinced it's worthwhile. Lacking a definition, it
> > certainly can't be.
> >
> >
> > Philip Guenther
>
> The issue is one of feature parity. On posix-y systems, there are
> multiple ways to wait for an event on a file descriptor.
>
> - select(), which takes a 'readable' set (equivalent to POLLIN), a
> 'writable' set (equivalent to POLLOUT), and a 'error' set (POLLPRI +
> some others depending on OS)
> - poll(), which takes POLL{IN,RDNORM, RDBAND, PRI, OUT, WRNORM, WRBAND}
> - Linux only: epoll(), which takes the same flags as poll()
> - Solaris only: port with PORT_SOURCE_FD, which takes the same flags as
> poll()
> - BSDs: kqueue: which has EVFILT_READ (with default flags is
> equivalent to POLLIN) and EVFILT_WRITE (equivalent to POLLOUT)
>
> Any given single threaded program generally has to pick one of the
> above, and use it throughout.
> The platform specific options (epoll, ports, kqueue) are generally
> more performant.
>
> The issue I'm trying to solve is: if a program needs to poll for
> priority events (i.e. POLLPRI) on OpenBSD, they have to use select()
> or poll(); it takes the kqueue option off the table.
> I'd like to fix this.
>
>
> My suggested fix was to add the same API as OSX; i.e. EV_OOBAND flag,
> which causes kqueue's EVFILT_READ to act like it was given POLLPRI
> instead of just POLLIN.
> But anything else that adds the ability would be fine too :)
Well, given
https://blog.sandstorm.io/news/2015-04-08-osx-security-bug.html
I'd say, no. In fact, that article suggests this interface is no
longer supported in OS X either.
The article indicates that DagonFlyBSD has EVFILT_EXCEPT to signal OOB
data. That would probably be a better choice. But as I said, the OOB
data mechanism is an obscure feature and I'm not convinced that this
is worth spending time on.
Re: [patch]rcs: usage functions above the main ones
this seems fine to me
On Sun, Jun 14, 2015 at 10:38:40PM +0200, Fritjof Bornebusch wrote:
> Hi tech@,
>
> most of the tools implements the *usage* function above the *main* function.
> This patch makes it more consistent to these tools and where the different
> *usage*
> functions are implemented in rcs in general.
>
> Any comments?
>
> Regards,
> --F.
>
>
> Index: co.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/co.c,v
> retrieving revision 1.121
> diff -u -p -r1.121 co.c
> --- co.c 13 Jun 2015 20:15:21 - 1.121
> +++ co.c 14 Jun 2015 20:21:41 -
> @@ -43,6 +43,17 @@ static voidcheckout_err_nobranch(RCSFIL
> const char *, int);
> static int checkout_file_has_diffs(RCSFILE *, RCSNUM *, const char *);
>
> +__dead void
> +checkout_usage(void)
> +{
> + fprintf(stderr,
> + "usage: co [-TV] [-ddate] [-f[rev]] [-I[rev]] [-kmode] [-l[rev]]\n"
> + " [-M[rev]] [-p[rev]] [-q[rev]] [-r[rev]] [-sstate]\n"
> + " [-u[rev]] [-w[user]] [-xsuffixes] [-ztz] file ...\n");
> +
> + exit(1);
> +}
> +
> int
> checkout_main(int argc, char **argv)
> {
> @@ -216,17 +227,6 @@ checkout_main(int argc, char **argv)
> }
>
> return (ret);
> -}
> -
> -__dead void
> -checkout_usage(void)
> -{
> - fprintf(stderr,
> - "usage: co [-TV] [-ddate] [-f[rev]] [-I[rev]] [-kmode] [-l[rev]]\n"
> - " [-M[rev]] [-p[rev]] [-q[rev]] [-r[rev]] [-sstate]\n"
> - " [-u[rev]] [-w[user]] [-xsuffixes] [-ztz] file ...\n");
> -
> - exit(1);
> }
>
> /*
> Index: ident.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/ident.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 ident.c
> --- ident.c 2 Oct 2014 06:23:15 - 1.30
> +++ ident.c 14 Jun 2015 20:21:41 -
> @@ -41,6 +41,14 @@ static int flags = 0;
> static void ident_file(const char *, FILE *);
> static void ident_line(FILE *);
>
> +__dead void
> +ident_usage(void)
> +{
> + fprintf(stderr, "usage: ident [-qV] [file ...]\n");
> +
> + exit(1);
> +}
> +
> int
> ident_main(int argc, char **argv)
> {
> @@ -158,12 +166,4 @@ ident_line(FILE *fp)
> out:
> if (bp != NULL)
> buf_free(bp);
> -}
> -
> -__dead void
> -ident_usage(void)
> -{
> - fprintf(stderr, "usage: ident [-qV] [file ...]\n");
> -
> - exit(1);
> }
> Index: merge.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/merge.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 merge.c
> --- merge.c 10 Oct 2014 08:15:25 - 1.9
> +++ merge.c 14 Jun 2015 20:21:41 -
> @@ -32,6 +32,15 @@
> #include "rcsprog.h"
> #include "diff.h"
>
> +__dead void
> +merge_usage(void)
> +{
> + fprintf(stderr,
> + "usage: merge [-EepqV] [-L label] file1 file2 file3\n");
> +
> + exit(D_ERROR);
> +}
> +
> int
> merge_main(int argc, char **argv)
> {
> @@ -108,13 +117,4 @@ merge_main(int argc, char **argv)
> buf_free(bp);
>
> return (status);
> -}
> -
> -__dead void
> -merge_usage(void)
> -{
> - (void)fprintf(stderr,
> - "usage: merge [-EepqV] [-L label] file1 file2 file3\n");
> -
> - exit(D_ERROR);
> }
> Index: rcsclean.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/rcsclean.c,v
> retrieving revision 1.54
> diff -u -p -r1.54 rcsclean.c
> --- rcsclean.c16 Jan 2015 06:40:11 - 1.54
> +++ rcsclean.c14 Jun 2015 20:21:41 -
> @@ -43,6 +43,16 @@ static int uflag = 0;
> static int flags = 0;
> static char *locker = NULL;
>
> +__dead void
> +rcsclean_usage(void)
> +{
> + fprintf(stderr,
> + "usage: rcsclean [-TV] [-kmode] [-n[rev]] [-q[rev]] [-r[rev]]\n"
> + "[-u[rev]] [-xsuffixes] [-ztz] [file ...]\n");
> +
> + exit(1);
> +}
> +
> int
> rcsclean_main(int argc, char **argv)
> {
> @@ -116,16 +126,6 @@ rcsclean_main(int argc, char **argv)
> rcsclean_file(argv[i], rev_str);
>
> return (0);
> -}
> -
> -__dead void
> -rcsclean_usage(void)
> -{
> - fprintf(stderr,
> - "usage: rcsclean [-TV] [-kmode] [-n[rev]] [-q[rev]] [-r[rev]]\n"
> - "[-u[rev]] [-xsuffixes] [-ztz] [file ...]\n");
> -
> - exit(1);
> }
>
> static void
> Index: rcsdiff.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/rcsdiff.c,v
> retrieving revision 1.83
> diff -u -p -r1.83 rcsdiff.c
> --- rcsdiff.c 13 Jun 2015 20:15:21 - 1.83
> +++ rcsdiff.c 14 Jun 2015 20:21:41 -
> @@ -45,6 +45,16 @@ static int quiet;
> static int kflag = RCS_KWEXP_ERR;
> static char *diff_ignore_pats;
>
> +__dead void
> +rcsdiff_usage(void)
> +{
> + fprintf(stderr,
> + "usage: rcsdiff [-cnquV] [-kmode] [
Re: pf: increment rule counters after successful state insertion
On Tue, Jun 09, 2015 at 18:11 +0200, Mike Belopuhov wrote:
> Hi,
>
> I was surprised to see 'State Creations' rule counter go up when
> no real state creation happens. This is because we increment all
> counters too early, but then don't decrement 'states_tot' which
> is a total number of states created by the rule. Not entirely
> sure why was it done but I see no reason for it to stay this way.
>
> IMO total has to increase only when we succeed inserting the state
> into the table.
>
> This has an additional benefit of making error handling simpler:
> we don't need to unroll our counter increments if we do them right
> after pf_state_insert.
>
> OK?
>
I'm still looking for OKs on this one.
> diff --git sys/net/pf.c sys/net/pf.c
> index 4192f14..efa1388 100644
> --- sys/net/pf.c
> +++ sys/net/pf.c
> @@ -273,20 +273,10 @@ struct pf_pool_limit pf_pool_limits[PF_LIMIT_MAX] = {
> } \
> SLIST_FOREACH(mrm, &s->match_rules, entry) \
> mrm->r->states_cur++; \
> } while (0)
>
> -#define STATE_DEC_COUNTERS(s)\
> - do {\
> - struct pf_rule_item *mrm; \
> - if (s->anchor.ptr != NULL) \
> - s->anchor.ptr->states_cur--;\
> - s->rule.ptr->states_cur--; \
> - SLIST_FOREACH(mrm, &s->match_rules, entry) \
> - mrm->r->states_cur--; \
> - } while (0)
> -
> static __inline int pf_src_compare(struct pf_src_node *, struct pf_src_node
> *);
> static __inline int pf_state_compare_key(struct pf_state_key *,
> struct pf_state_key *);
> static __inline int pf_state_compare_id(struct pf_state *,
> struct pf_state *);
> @@ -3464,11 +3454,10 @@ pf_create_state(struct pf_pdesc *pd, struct pf_rule
> *r, struct pf_rule *a,
> }
> s->rule.ptr = r;
> s->anchor.ptr = a;
> s->natrule.ptr = nr;
> memcpy(&s->match_rules, rules, sizeof(s->match_rules));
> - STATE_INC_COUNTERS(s);
> if (r->allow_opts)
> s->state_flags |= PFSTATE_ALLOWOPTS;
> if (r->rule_flag & PFRULE_STATESLOPPY)
> s->state_flags |= PFSTATE_SLOPPY;
> if (r->rule_flag & PFRULE_PFLOW)
> @@ -3591,10 +3580,12 @@ pf_create_state(struct pf_pdesc *pd, struct pf_rule
> *r, struct pf_rule *a,
> REASON_SET(&reason, PFRES_STATEINS);
> goto csfailed;
> } else
> *sm = s;
>
> + STATE_INC_COUNTERS(s);
> +
> if (tag > 0) {
> pf_tag_ref(tag);
> s->tag = tag;
> }
> if (pd->proto == IPPROTO_TCP && (th->th_flags & (TH_SYN|TH_ACK)) ==
> @@ -3621,21 +3612,17 @@ pf_create_state(struct pf_pdesc *pd, struct pf_rule
> *r, struct pf_rule *a,
>
> csfailed:
> if (s) {
> pf_normalize_tcp_cleanup(s);/* safe even w/o init */
> pf_src_tree_remove_state(s);
> + pool_put(&pf_state_pl, s);
> }
>
> for (i = 0; i < PF_SN_MAX; i++)
> if (sns[i] != NULL)
> pf_remove_src_node(sns[i]);
>
> - if (s) {
> - STATE_DEC_COUNTERS(s);
> - pool_put(&pf_state_pl, s);
> - }
> -
> return (PF_DROP);
> }
>
> int
> pf_translate(struct pf_pdesc *pd, struct pf_addr *saddr, u_int16_t sport,
Re: [patch]rcs: xstrdup just wrappes strdup
On Mon, Jun 15, 2015 at 10:09:39AM +0200, Fritjof Bornebusch wrote: > On Sun, Jun 14, 2015 at 05:02:05PM -0600, Theo de Raadt wrote: > > > But I am not sure about this change. xmalloc.c came from ssh (and is > > > also used by file and diff). Would it be better to keep it in sync? How > > > portable is strdup? > > > > strdup is extremely portable. > > > > The last mainstream operating system which lacked it was Ultrix. > > So you could call it 100.00% portable. > > > > Since there is no portable version of openRCS is it that necessary > to focus on portability? Functions like explicit_bzero(3) are not > portable either, but used widely. No but there is a portable version of ssh and it uses the same xmalloc.c > > Or is it more to find a balance between the usage of internal function, > but make the tool not that hard to port to other systems? > > Regards, > --F.
Re: [patch]rcs: xstrdup just wrappes strdup
What about diff and ssh and file? They all use the a copy of the same
xmalloc.c.
On Mon, Jun 15, 2015 at 10:00:01AM +0200, Fritjof Bornebusch wrote:
> Hi,
>
> thanks for the hint.
> This one should do the trick.
>
>
>
>
> Index: xmalloc.c
> ===
> RCS file: /cvs/src/usr.bin/rcs/xmalloc.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 xmalloc.c
> --- xmalloc.c 13 Jun 2015 20:15:21 - 1.9
> +++ xmalloc.c 15 Jun 2015 07:52:15 -
> @@ -68,13 +68,10 @@ xreallocarray(void *ptr, size_t nmemb, s
> char *
> xstrdup(const char *str)
> {
> - size_t len;
> char *cp;
> -
> - len = strlen(str) + 1;
> - cp = xmalloc(len);
> - if (strlcpy(cp, str, len) >= len)
> - errx(1, "xstrdup: string truncated");
> +
> + if ((cp = strdup(str)) == NULL)
> + err(1, "xstrdup");
> return cp;
> }
>
Re: [patch]rcs: xstrdup just wrappes strdup
On Sun, Jun 14, 2015 at 05:02:05PM -0600, Theo de Raadt wrote: > > But I am not sure about this change. xmalloc.c came from ssh (and is > > also used by file and diff). Would it be better to keep it in sync? How > > portable is strdup? > > strdup is extremely portable. > > The last mainstream operating system which lacked it was Ultrix. > So you could call it 100.00% portable. > Since there is no portable version of openRCS is it that necessary to focus on portability? Functions like explicit_bzero(3) are not portable either, but used widely. Or is it more to find a balance between the usage of internal function, but make the tool not that hard to port to other systems? Regards, --F.
Re: [patch]rcs: xstrdup just wrappes strdup
Hi,
thanks for the hint.
This one should do the trick.
Index: xmalloc.c
===
RCS file: /cvs/src/usr.bin/rcs/xmalloc.c,v
retrieving revision 1.9
diff -u -p -r1.9 xmalloc.c
--- xmalloc.c 13 Jun 2015 20:15:21 - 1.9
+++ xmalloc.c 15 Jun 2015 07:52:15 -
@@ -68,13 +68,10 @@ xreallocarray(void *ptr, size_t nmemb, s
char *
xstrdup(const char *str)
{
- size_t len;
char *cp;
-
- len = strlen(str) + 1;
- cp = xmalloc(len);
- if (strlcpy(cp, str, len) >= len)
- errx(1, "xstrdup: string truncated");
+
+ if ((cp = strdup(str)) == NULL)
+ err(1, "xstrdup");
return cp;
}
