Re: Invalid structure spec for SIOCG80211ALLNODES
On Fri, Aug 15, 2014 at 09:35:03PM +0400, Vadim Zhukov wrote:
The SIOCG80211ALLNODES operate on struct ieee80211_nodereq_all, not
on struct ieee80211_nodereq, right? If I understand things correctly,
we were on a safe side because struct ieee80211_nodereq is larger
than struct ieee80211_nodereq_all. Should this follow some bump? OK?
OK, but remove the XXX comment ;)
--
WBR,
Vadim Zhukov
Index: ieee80211_ioctl.h
===
RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.h,v
retrieving revision 1.19
diff -u -p -r1.19 ieee80211_ioctl.h
--- ieee80211_ioctl.h 10 Jul 2014 14:32:28 - 1.19
+++ ieee80211_ioctl.h 15 Aug 2014 17:32:24 -
@@ -348,7 +348,8 @@ struct ieee80211_nodereq_all {
u_int8_tna_flags; /* IEEE80211_NODEREQ_*
*/
};
-#define SIOCG80211ALLNODES _IOWR('i', 214, struct ieee80211_nodereq)
+/* XXX typo, should be ieee80211_nodereq_all instead? */
+#define SIOCG80211ALLNODES _IOWR('i', 214, struct ieee80211_nodereq_all)
/* net80211 specific interface flags */
#define IEEE80211_F_HIDENWID 0x1000 /* CONF: hidden ssid mode */
--
Re: Invalid structure spec for SIOCG80211ALLNODES
2014-08-19 14:19 GMT+04:00 Reyk Floeter r...@openbsd.org:
On Fri, Aug 15, 2014 at 09:35:03PM +0400, Vadim Zhukov wrote:
The SIOCG80211ALLNODES operate on struct ieee80211_nodereq_all, not
on struct ieee80211_nodereq, right? If I understand things correctly,
we were on a safe side because struct ieee80211_nodereq is larger
than struct ieee80211_nodereq_all. Should this follow some bump? OK?
OK, but remove the XXX comment ;)
Thank you. It looks like we have more ioctl problems, though:
SIOCSPRISM2DEBUG=137, in /usr/src/sys/dev/ic/if_wi_ieee.h
same ID for SIOCGATHSTATS in /usr/src/sys/dev/ic/athvar.h
SIOCGSLSTATS=123, in /usr/src/sys/net/if_slvar.h
same ID for SIOCGPPPSTATS in /usr/src/sys/net/if_ppp.h
SIOCG80211ALLCHANS=215, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCHOSTAP_SFLAGS in /usr/src/sys/dev/ic/if_wi_hostap.h
SIOCS80211WMMPARMS=249, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCSWAVELAN in /usr/src/sys/dev/ic/if_wi_ieee.h
SIOCG80211WMMPARMS=250, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCGWAVELAN in /usr/src/sys/dev/ic/if_wi_ieee.h
SIOCS80211SCAN=210, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCHOSTAP_GET in /usr/src/sys/dev/ic/if_wi_hostap.h
SIOCG80211NODE=211, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCHOSTAP_ADD in /usr/src/sys/dev/ic/if_wi_hostap.h
SIOCS80211NODE=212, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCHOSTAP_DEL in /usr/src/sys/dev/ic/if_wi_hostap.h
SIOCS80211DELNODE=213, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCHOSTAP_GETALL in /usr/src/sys/dev/ic/if_wi_hostap.h
SIOCG80211ALLNODES=214, in /usr/src/sys/net80211/ieee80211_ioctl.h
same ID for SIOCHOSTAP_GFLAGS in /usr/src/sys/dev/ic/if_wi_hostap.h
First two conflicts look like harmless, bu I'm not sure how others are
supposed to work... I guess the wi(4) ones should be renamed? BTW,
kernel build breaks for me now if I don't tweak those IDs.
Index: ieee80211_ioctl.h
===
RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.h,v
retrieving revision 1.19
diff -u -p -r1.19 ieee80211_ioctl.h
--- ieee80211_ioctl.h 10 Jul 2014 14:32:28 - 1.19
+++ ieee80211_ioctl.h 15 Aug 2014 17:32:24 -
@@ -348,7 +348,8 @@ struct ieee80211_nodereq_all {
u_int8_tna_flags; /* IEEE80211_NODEREQ_*
*/
};
-#define SIOCG80211ALLNODES _IOWR('i', 214, struct ieee80211_nodereq)
+/* XXX typo, should be ieee80211_nodereq_all instead? */
+#define SIOCG80211ALLNODES _IOWR('i', 214, struct ieee80211_nodereq_all)
/* net80211 specific interface flags */
#define IEEE80211_F_HIDENWID 0x1000 /* CONF: hidden ssid mode */
--
WBR,
Vadim Zhukov
Fix skipping of process entries in procfs root listing
When the procfs root directory is listed using more than one getdents() call, the process iterator can mistakenly skip a few processes. The patch corrects this by making the index of the first process entry match with the static procfs entries. This prevents over-winding of the process list during subsequent getdents() calls. Index: sys/miscfs/procfs/procfs_vnops.c === RCS file: /cvs/src/sys/miscfs/procfs/procfs_vnops.c,v retrieving revision 1.60 diff -N -u -p sys/miscfs/procfs/procfs_vnops.c --- sys/miscfs/procfs/procfs_vnops.c8 Jul 2014 17:19:25 - 1.60 +++ sys/miscfs/procfs/procfs_vnops.c19 Aug 2014 13:54:11 - @@ -853,11 +853,15 @@ procfs_readdir(void *v) #ifdef PROCFS_ZOMBIE int doingzomb = 0; #endif + int firstproc; int pcnt = i; volatile struct process *pr = LIST_FIRST(allprocess); - if (pcnt 3) - pcnt = 3; + firstproc = 4; + if (VFSTOPROC(vp-v_mount)-pmnt_flags PROCFSMNT_LINUXCOMPAT) + firstproc += 2; + if (pcnt firstproc) + pcnt = firstproc; #ifdef PROCFS_ZOMBIE again: #endif
Make procfs root listing work again
Hello,
This patch corrects the process iterator in procfs_readdir(), allowing
procfs root listing to work again. The iterator was stuck to the first
instance of allprocess list because all the relevant LIST_NEXT()
statements were mistakenly removed in revision 1.58 of procfs_vnops.c.
Regards,
Visa Hankala
Index: sys/miscfs/procfs/procfs_vnops.c
===
RCS file: /cvs/src/sys/miscfs/procfs/procfs_vnops.c,v
retrieving revision 1.60
diff -N -u -p sys/miscfs/procfs/procfs_vnops.c
--- sys/miscfs/procfs/procfs_vnops.c8 Jul 2014 17:19:25 - 1.60
+++ sys/miscfs/procfs/procfs_vnops.c19 Aug 2014 13:54:11 -
@@ -909,18 +909,24 @@ procfs_readdir(void *v)
/* fall through */
default:
- while (pcnt i)
+ while (pcnt i) {
pcnt++;
+ pr = LIST_NEXT(pr, ps_list);
+ if (pr == NULL)
+ goto done;
+ }
d.d_fileno = PROCFS_FILENO(pr-ps_pid, Pproc);
d.d_namlen = snprintf(d.d_name,
sizeof(d.d_name),
%ld, (long)pr-ps_pid);
d.d_type = DT_REG;
+ pr = LIST_NEXT(pr, ps_list);
break;
}
if ((error = uiomove(d, UIO_MX, uio)) != 0)
break;
}
+ done:
#ifdef PROCFS_ZOMBIE
if (pr == NULL doingzomb == 0) {
doingzomb = 1;
Re: Add commitid support to loginfo in CVS
2014-08-18 9:23 GMT+04:00 Kent R. Spillner kspill...@acm.org:
Haven't tested, just eyeballing the diff; I have two questions inline
below.
1). Did you want to use proglen here?
Yep, good catch, thanks!
2). proglen is declared as an int; is there any danger malicious
values could cause an overflow, or are all of those values carefully
controlled?
Looking at the CVS code, it would blow up on overflowing int anyway,
so I don't care. Maybe I'm wrong...
Sending updated diff for archives; to be revisited when (if) more
complete commitid support will hit gnu/usr.bin/cvs itself.
--
WBR,
Vadim Zhukov
Index: src/logmsg.c
===
RCS file: /cvs/src/gnu/usr.bin/cvs/src/logmsg.c,v
retrieving revision 1.4
diff -u -p -r1.4 logmsg.c
--- src/logmsg.c4 Mar 2012 04:05:15 - 1.4
+++ src/logmsg.c19 Aug 2014 17:19:54 -
@@ -584,6 +584,9 @@ title_proc (p, closure)
{
switch (*c)
{
+ case 'i':
+ /* handled in caller */
+ continue;
case 's':
str_list =
xrealloc (str_list,
@@ -677,6 +680,7 @@ logfile_write (repository, filter, messa
or followed by a set of format characters surrounded by `{' and
`}' as separators. The format characters are:
+i = commit ID
s = file name
t = tag name
V = old version number (pre-checkin)
@@ -685,6 +689,7 @@ logfile_write (repository, filter, messa
For example, valid format strings are:
%{}
+%i
%s
%{s}
%{sVv}
@@ -709,10 +714,12 @@ logfile_write (repository, filter, messa
Why this duplicates the old behavior when the format string is
`%s' is left as an exercise for the reader. */
-fmt_percent = strchr (filter, '%');
+fmt_percent = filter;
+find_percent:
+fmt_percent = strchr (fmt_percent, '%');
if (fmt_percent)
{
- int len;
+ int len, proglen;
char *srepos;
char *fmt_begin, *fmt_end; /* beginning and end of the
format string specified in
@@ -737,6 +744,12 @@ logfile_write (repository, filter, messa
fmt_end = fmt_begin;
fmt_continue = fmt_begin;
}
+ else if (*(fmt_percent + 1) == '%')
+ {
+ memmove(fmt_percent, fmt_percent+1, strlen(fmt_percent));
+ fmt_percent++;
+ goto find_percent;
+ }
else if (*(fmt_percent + 1) == '{')
{
/* The percent has a set of characters following it. */
@@ -762,8 +775,7 @@ logfile_write (repository, filter, messa
}
else
{
- /* The percent has a single character following it. FIXME:
- %% should expand to a regular percent sign. */
+ /* The percent has a single character following it. */
fmt_begin = fmt_percent + 1;
fmt_end = fmt_begin + 1;
@@ -795,19 +807,26 @@ logfile_write (repository, filter, messa
type = T_REMOVED;
(void) walklist (changes, title_proc, NULL);
}
-
- free (str_list_format);
/* Construct the final string. */
srepos = Short_Repository (repository);
- prog = cp = xmalloc ((fmt_percent - filter) + 2 * strlen (srepos)
+ proglen = (fmt_percent - filter) + 2 * strlen (srepos)
+ 2 * strlen (str_list) + strlen (fmt_continue)
- + 10);
+ + 10;
+ if (strchr (str_list_format, 'i') != NULL)
+ /* assume no escaping needed */
+ proglen += strlen (global_session_id) * 2 + 1;
+
+ prog = cp = xmalloc (proglen);
(void) memcpy (cp, filter, fmt_percent - filter);
cp += fmt_percent - filter;
*cp++ = '';
+ if (strchr (str_list_format, 'i') != NULL) {
+ cp = shell_escape (cp, global_session_id);
+ *cp++ = ' ';
+ }
cp = shell_escape (cp, srepos);
cp = shell_escape (cp, str_list);
*cp++ = '';
@@ -815,6 +834,7 @@ logfile_write (repository, filter, messa
/* To be nice, free up some memory. */
+ free (str_list_format);
free (str_list);
str_list = (char *) NULL;
}
Index: src/mkmodules.c
===
RCS file: /cvs/src/gnu/usr.bin/cvs/src/mkmodules.c,v
retrieving revision 1.11
diff -u -p -r1.11 mkmodules.c
--- src/mkmodules.c 4 Mar 2012 04:05:15 - 1.11
+++ src/mkmodules.c 19 Aug 2014 17:19:54 -
@@ -65,6 +65,7 @@ static const char *const loginfo_content
# characters surrounded by `{' and `}' as separators. The format\n,
# characters are:\n,
#\n,
+# i = commit ID\n,
# s = file name\n,
# t = tag name\n,
# V
Re: sk(4): jumbo mbufs and rxring accounting
On 18/08/14 6:24 PM, David Gwynne wrote: On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote: i think i'll try to find the sk at work and wire it up. its just annoying cos im pretty sure its sr optics with sc connectors. thanks for testing. how's this one? Only running regular MTU traffic so far but the NIC at least works and beating on it I haven't seen any noticeable issues so far. I'll see if I can do some test with Jumbos a little later on today. sk0 902019 2 25619 sk0 1500 Link 00:00:5a:98:b9:c0 29810991 0 23786214 0 0 skc0 at pci0 dev 5 function 0 Schneider Koch SK-98xx rev 0x13, GEnesis (0x0): ivec 0x784 sk0 at skc0 port A: address 00:00:5a:98:b9:c0 brgphy0 at sk0 phy 1: BCM5400 1000baseT PHY, rev. 7 Some minor cosmetic issues I noticed while diff'ing the two revisions of the diff... m-m_len = m-m_pkthdr.len = SK_JLEN; has spaces instead of a tab and the whitespace after if_rxr_ioctl(). -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
From what I remember from last attempt to convert sk(4) to MCLGETI, there were problems which only showed up under load (possibly also involved NFS, I don't remember for sure) - I probably used netrate with something like netblast 11.22.33.44 12345 1 30 to generate a bunch of packets over it quickly, and tcpbench to generate high bandwidth use.
Re: sk(4): jumbo mbufs and rxring accounting
On 19/08/14 2:43 PM, Stuart Henderson wrote: From what I remember from last attempt to convert sk(4) to MCLGETI, there were problems which only showed up under load (possibly also involved NFS, I don't remember for sure) - I probably used netrate with something like netblast 11.22.33.44 12345 1 30 to generate a bunch of packets over it quickly, and tcpbench to generate high bandwidth use. The first diff he sent out didn't work at all. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
openospfd router-priority
All, I had implemented a network using openospf and initially left router-priorities off. Problem is I kept coming up FULL/OTHER and would not get routes. I changed the router priority values (not to match as when I matched got the same). I changed one side of a line to 10, while the other was 5. When I reloaded the side I changed, it stayed in FULL/OTHER state when it came up again. To get it to change to FULL/DR or FULL/BCKUP I needed to reload both systems ospfd daemons. Then it recalced fine. This leads me to believe that their isn't a full renegotiation if the other side is still running. That would be hard to do in an environment where you have to bring down the entire network to make a change. Is this a bug or was this the intended deployment. Also if priorities match, shouldn't they then move to see who has the highest RID to determine DR and Backup. Cause coming up as OTHER by default was a real pain. Thanks P.S. once all reloaded it works fine. Tim
L2VPN in OpenBSD
All, I noticed in a few write-ups by Claudio that PWE3 and VPLS were next on the roadmap. This seemed to be a few years ago. Any progress in that regard? Is their a page that tracks that status? Very interested, Thanks Tim
Re: L2VPN in OpenBSD
On Tue, Aug 19, 2014 at 03:48:51PM -0400, Tim Epkes wrote: All, I noticed in a few write-ups by Claudio that PWE3 and VPLS were next on the roadmap. This seemed to be a few years ago. Any progress in that regard? Is their a page that tracks that status? Very interested, Thanks Tim Yes, we (me and renato@) are working actively on this. There is no page tracking the status, but it has been discussed on misc@. http://marc.info/?l=openbsd-miscm=140744694729898w=2
Re: syslogd ipv6 getnameinfo
On Tue, Aug 19, 2014 at 01:59:42AM +0200, Alexander Bluhm wrote:
I will split this diff into smaller parts to make review and
discussion easier.
Replace gethostbyaddr(3) with getnameinfo(3).
Note that I remove the sigprocmask() that was added in rev 1.23
before privsep. It was necessary because gethostbyaddr() is not
signal safe.
ok?
bluhm
Index: usr.sbin/syslogd/privsep.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/privsep.c,v
retrieving revision 1.36
diff -u -p -u -p -r1.36 privsep.c
--- usr.sbin/syslogd/privsep.c 19 Aug 2014 00:53:01 - 1.36
+++ usr.sbin/syslogd/privsep.c 19 Aug 2014 20:01:12 -
@@ -68,7 +68,7 @@ enum cmd_types {
PRIV_OPEN_CONFIG, /* open config file for reading only */
PRIV_CONFIG_MODIFIED, /* check if config file has been modified */
PRIV_GETHOSTSERV, /* resolve host/service names */
- PRIV_GETHOSTBYADDR, /* resolve numeric address into hostname */
+ PRIV_GETNAMEINFO, /* resolve numeric address into hostname */
PRIV_DONE_CONFIG_PARSE /* signal that the initial config parse is done
*/
};
@@ -76,7 +76,7 @@ static int priv_fd = -1;
static volatile pid_t child_pid = -1;
static char config_file[MAXPATHLEN];
static struct stat cf_info;
-static int allow_gethostbyaddr = 0;
+static int allow_getnameinfo = 0;
static volatile sig_atomic_t cur_state = STATE_INIT;
/* Queue for the allowed logfiles */
@@ -100,12 +100,12 @@ static int may_read(int, void *, size_t
int
priv_init(char *conf, int numeric, int lockfd, int nullfd, char *argv[])
{
- int i, fd, socks[2], cmd, addr_len, addr_af, result, restart;
+ int i, fd, socks[2], cmd, addr_len, result, restart;
size_t path_len, hostname_len, servname_len;
char path[MAXPATHLEN], hostname[MAXHOSTNAMELEN];
char servname[MAXHOSTNAMELEN];
+ struct sockaddr_storage addr;
struct stat cf_stat;
- struct hostent *hp;
struct passwd *pw;
struct addrinfo hints, *res0;
struct sigaction sa;
@@ -191,11 +191,11 @@ priv_init(char *conf, int numeric, int l
if (stat(config_file, cf_info) 0)
err(1, stat config file failed);
- /* Save whether or not the child can have access to gethostbyaddr(3) */
+ /* Save whether or not the child can have access to getnameinfo(3) */
if (numeric 0)
- allow_gethostbyaddr = 0;
+ allow_getnameinfo = 0;
else
- allow_gethostbyaddr = 1;
+ allow_getnameinfo = 1;
TAILQ_INIT(lognames);
increase_state(STATE_CONFIG);
@@ -320,24 +320,24 @@ priv_init(char *conf, int numeric, int l
}
break;
- case PRIV_GETHOSTBYADDR:
- dprintf([priv]: msg PRIV_GETHOSTBYADDR received\n);
- if (!allow_gethostbyaddr)
- errx(1, rejected attempt to gethostbyaddr);
- /* Expecting: length, address, address family */
+ case PRIV_GETNAMEINFO:
+ dprintf([priv]: msg PRIV_GETNAMEINFO received\n);
+ if (!allow_getnameinfo)
+ errx(1, rejected attempt to getnameinfo);
+ /* Expecting: length, sockaddr */
must_read(socks[0], addr_len, sizeof(int));
- if (addr_len = 0 || addr_len sizeof(hostname))
+ if (addr_len = 0 || addr_len sizeof(addr))
_exit(1);
- must_read(socks[0], hostname, addr_len);
- must_read(socks[0], addr_af, sizeof(int));
- hp = gethostbyaddr(hostname, addr_len, addr_af);
- if (hp == NULL) {
+ must_read(socks[0], addr, addr_len);
+ if (getnameinfo((struct sockaddr *)addr, addr_len,
+ hostname, sizeof(hostname), NULL, 0,
+ NI_NOFQDN|NI_NAMEREQD|NI_DGRAM) != 0) {
addr_len = 0;
must_write(socks[0], addr_len, sizeof(int));
} else {
- addr_len = strlen(hp-h_name) + 1;
+ addr_len = strlen(hostname) + 1;
must_write(socks[0], addr_len, sizeof(int));
- must_write(socks[0], hp-h_name, addr_len);
+ must_write(socks[0], hostname, addr_len);
}
break;
default:
@@ -702,33 +702,33 @@ priv_gethostserv(char *host, char *serv,
/* Reverse address resolution; response is placed into res, and length of
* response is returned (zero on error) */
int
new rc.conf(8) manual
Hi, while working on rcctl(8), i noticed that the rc.conf(8) manual is of... err, how can i express it politely... somewhat doubtful quality. Here is a stab at it. As a first step, i moved all the examples from the DESCRIPTION to the EXAMPLES esction. After that, the DESCRIPTION section was basically empty, so i had clean earth to till. Do not attempt to read the diff. Just apply it and read the result. OK? Ingo Index: rc.conf.8 === RCS file: /cvs/src/share/man/man8/rc.conf.8,v retrieving revision 1.22 diff -u -r1.22 rc.conf.8 --- rc.conf.8 13 Jul 2014 10:05:49 - 1.22 +++ rc.conf.8 19 Aug 2014 20:30:41 - @@ -59,10 +59,162 @@ with comments designated by a hash mark .Pq Sq # . .Pp -Some variables are used to turn features on or off. -For example, whether the system runs the +There are four classes of variables: +.Bl -enum -compact +.It +.Sx Base system daemon configuration variables +.It +.Sx Package daemon configuration variables +.It +.Sx Base system service configuration variables +.It +.Sx Auxiliary configuration variables +.El +.Ss Base system daemon configuration variables +These variables are used to enable and disable daemon programs +that are installed by default, and to set their command line options. +.Pp +All of these variables follow the format +.Dq Ar daemon Ns _flags +where +.Ar daemon +is the name of one of the +.Xr rc.d 8 +daemon control scripts. +The list of base system daemons, including the information whether +they are enabled by default and what typical command line options +are, can be displayed with this command: +.Pp +.Dl grep _flags /etc/rc.conf +.Pp +If one of these variables is set to +.Cm NO , +the respective +.Ar daemon +is disabled. +If set to the empty string, the +.Ar daemon +is run with the default command line arguments defined in its +.Xr rc.d 8 +.Ar daemon +script, or without command line arguments if no such default exists. +If set to any other value, including a string containing +only a single blank character, the +.Ar daemon +is run with those command line arguments. +.Ss Package daemon configuration variables +These variables are used to enable and disable daemon programs installed from +.Xr packages 7 , +and to set their command line options. +.Pp +The special +.Cm pkg_scripts +variable lists +.Xr rc.d 8 +.Ar daemon +control scripts to be started in the specified order. +For each +.Ar daemon +listed, its default command line options can optionally be overridden +using the variable +.Ar daemon Ns _flags +as described for +.Sx Base system daemon configuration variables . +.Ss Base system service configuration variables +These variables control features available by default +that are not implemented as daemons. +They can be set to either +.Cm YES +or +.Cm NO . +When set to +.Cm YES , +they have the following effects: +.Bl -tag -width check_quotas +.It Cm accounting +.Xr rc 8 +calls: +.Xr accton 8 +.Pa /var/account/acct +.It Cm check_quotas +.Xr rc 8 +calls: +.Xr quotacheck 8 +.Fl a ; +.Xr quotaon 8 +.Fl a +.It Cm ipsec +.Xr rc 8 +calls: +.Xr ipsecctl 8 +.Fl f Pf $ Brq Ar ipsec_rules +.It Cm multicast_host , multicast_router +See +.Xr netstart 8 . +.It Cm pf +.Xr rc 8 +calls: +.Xr pfctl 8 +.Fl ef +.Pf $ Brq Ar pf_rules +.It Cm spamd_black +The script +.Pa /etc/rc.d/spamd +uses +.Fl b +in front of any other configured command line arguments when running +.Xr spamd 8 +and +.Xr spamd-setup 8 . +.El +.Ss Auxiliary configuration variables +The boot scripts use the following variables in the following ways. +Most of them determine the locations of specific configuration files. +.Bl -tag -width ipsec_rules +.It Cm amd_master +The +.Xr amd 8 +master map file. +The script +.Pa /etc/rc.d/amd +appends its content to the command line when starting the auto mounter daemon. +.It Cm pf_rules +The +.Xr pf 4 +packet filter rule file. +If the +.Cm pf +service is enabled, +.Xr rc 8 +calls: +.Xr pfctl 8 +.Fl ef +.Pf $ Brq Ar pf_rules +.It Cm ipsec_rules +The +.Xr ipsec 4 +configuration file. +If the +.Cm ipsec +service is enabled, +.Xr rc 8 +calls: +.Xr ipsecctl 8 +.Fl f +.Pf $ Brq Ar ipsec_rules +.It Cm shlib_dirs +Extra shared library search path entries. +.Xr rc 8 +calls: +.Xr ldconfig 8 +.Pa /usr/X11R6/lib +.Pa /usr/local/lib +.Pf $ Brq Ar shlib_dirs +.El +.Sh EXAMPLES +Do not start the .Xr dhcpd 8 -daemon is determined by the following line: +daemon when booting the system: .Bd -literal -offset indent dhcpd_flags=NO .Ed @@ -74,42 +226,31 @@ dhcpd_flags= .Ed .Pp -If instead some options are specified, -then the dhcpd daemon will be started with those options. -For example: +To start it with some options: .Bd -literal -offset indent dhcpd_flags=-A abandoned .Ed .Pp -Other variables specify a simple YES or NO, -or simply determine the location of a file. -For example, the location of the ruleset for -.Xr pf 4 -is given thus: -.Bd -literal -offset indent -pf_rules=/etc/pf.conf
Re: openospfd router-priority
On 08/19/14 21:45, Tim Epkes wrote: All, I had implemented a network using openospf and initially left router-priorities off. Problem is I kept coming up FULL/OTHER and would not get routes. I changed the router priority values (not to match as when I matched got the same). I changed one side of a line to 10, while the other was 5. When I reloaded the side I changed, it stayed in FULL/OTHER state when it came up again. To get it to change to FULL/DR or FULL/BCKUP I needed to reload both systems ospfd daemons. Then it recalced fine. This leads me to believe that their isn't a full renegotiation if the other side is still running. That would be hard to do in an environment where you have to bring down the entire network to make a change. Is this a bug or was this the intended deployment. Also if priorities match, shouldn't they then move to see who has the highest RID to determine DR and Backup. Cause coming up as OTHER by default was a real pain. Thanks P.S. once all reloaded it works fine. Tim Hi Tim, If you start two ospfd without any special router priority, the default priority of both routers is 1, one router becomes DR and the other one BDR. That's how it supposed to work and if it doesn't something is wrong. I have tried it with a very simple configuration and it works for me. If your network is up alreade and their is a DR in it and another ospfd goes up, the DR won't change regardless of it's priority. See RFC 2328 section 7.3: In general, when a router's interface to a network first becomes functional, it checks to see whether there is currently a Designated Router for the network. If there is, it accepts that Designated Router, regardless of its Router Priority. Why will you enforce a new DR if their is already one? Florian
Re: sk(4): jumbo mbufs and rxring accounting
I think sthen is referring to the original diff Kettenis had in the tree a few years ago. On 20/08/2014 4:44 am, Brad Smith b...@comstyle.com wrote: On 19/08/14 2:43 PM, Stuart Henderson wrote: From what I remember from last attempt to convert sk(4) to MCLGETI, there were problems which only showed up under load (possibly also involved NFS, I don't remember for sure) - I probably used netrate with something like netblast 11.22.33.44 12345 1 30 to generate a bunch of packets over it quickly, and tcpbench to generate high bandwidth use. The first diff he sent out didn't work at all. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 2014/08/20 07:06, David Gwynne wrote: I think sthen is referring to the original diff Kettenis had in the tree a few years ago. Yes - I just wanted to give ideas of things that might be worth testing that have been known to cause problems on those NICs in the past On 20/08/2014 4:44 am, Brad Smith b...@comstyle.com wrote: On 19/08/14 2:43 PM, Stuart Henderson wrote: From what I remember from last attempt to convert sk(4) to MCLGETI, there were problems which only showed up under load (possibly also involved NFS, I don't remember for sure) - I probably used netrate with something like netblast 11.22.33.44 12345 1 30 to generate a bunch of packets over it quickly, and tcpbench to generate high bandwidth use. The first diff he sent out didn't work at all. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: syslogd ipv6 getaddrinfo
On Tue, Aug 19, 2014 at 01:59:42AM +0200, Alexander Bluhm wrote:
I will split this diff into smaller parts to make review and
discussion easier.
Rename priv_gethostserv() to priv_getaddrinfo() as this is what the
function does. Change the return code semantics to match getaddrinfo(3).
ok?
bluhm
Index: usr.sbin/syslogd/privsep.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/privsep.c,v
retrieving revision 1.36
diff -u -p -u -p -r1.36 privsep.c
--- usr.sbin/syslogd/privsep.c 19 Aug 2014 00:53:01 - 1.36
+++ usr.sbin/syslogd/privsep.c 19 Aug 2014 21:06:35 -
@@ -67,7 +67,7 @@ enum cmd_types {
PRIV_OPEN_UTMP, /* open utmp for reading only */
PRIV_OPEN_CONFIG, /* open config file for reading only */
PRIV_CONFIG_MODIFIED, /* check if config file has been modified */
- PRIV_GETHOSTSERV, /* resolve host/service names */
+ PRIV_GETADDRINFO, /* resolve host/service names */
PRIV_GETHOSTBYADDR, /* resolve numeric address into hostname */
PRIV_DONE_CONFIG_PARSE /* signal that the initial config parse is done
*/
};
@@ -289,17 +289,19 @@ priv_init(char *conf, int numeric, int l
increase_state(STATE_RUNNING);
break;
- case PRIV_GETHOSTSERV:
- dprintf([priv]: msg PRIV_GETHOSTSERV received\n);
+ case PRIV_GETADDRINFO:
+ dprintf([priv]: msg PRIV_GETADDRINFO received\n);
/* Expecting: len, hostname, len, servname */
must_read(socks[0], hostname_len, sizeof(size_t));
- if (hostname_len == 0 || hostname_len
sizeof(hostname))
+ if (hostname_len == 0 ||
+ hostname_len sizeof(hostname))
_exit(1);
must_read(socks[0], hostname, hostname_len);
hostname[hostname_len - 1] = '\0';
must_read(socks[0], servname_len, sizeof(size_t));
- if (servname_len == 0 || servname_len
sizeof(servname))
+ if (servname_len == 0 ||
+ servname_len sizeof(servname))
_exit(1);
must_read(socks[0], servname, servname_len);
servname[servname_len - 1] = '\0';
@@ -657,7 +659,7 @@ priv_config_parse_done(void)
/* Name/service to address translation. Response is placed into addr, and
* the length is returned (zero on error) */
int
-priv_gethostserv(char *host, char *serv, struct sockaddr *addr,
+priv_getaddrinfo(char *host, char *serv, struct sockaddr *addr,
size_t addr_len)
{
char hostcpy[MAXHOSTNAMELEN], servcpy[MAXHOSTNAMELEN];
@@ -674,7 +676,7 @@ priv_gethostserv(char *host, char *serv,
errx(1, %s: overflow attempt in servname, __func__);
servname_len = strlen(servcpy) + 1;
- cmd = PRIV_GETHOSTSERV;
+ cmd = PRIV_GETADDRINFO;
must_write(priv_fd, cmd, sizeof(int));
must_write(priv_fd, hostname_len, sizeof(size_t));
must_write(priv_fd, hostcpy, hostname_len);
@@ -686,7 +688,7 @@ priv_gethostserv(char *host, char *serv,
/* Check there was no error (indicated by a return of 0) */
if (!ret_len)
- return 0;
+ return (-1);
/* Make sure we aren't overflowing the passed in buffer */
if (addr_len ret_len)
@@ -696,7 +698,7 @@ priv_gethostserv(char *host, char *serv,
memset(addr, '\0', addr_len);
must_read(priv_fd, addr, ret_len);
- return ret_len;
+ return (0);
}
/* Reverse address resolution; response is placed into res, and length of
Index: usr.sbin/syslogd/syslogd.c
===
RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/syslogd/syslogd.c,v
retrieving revision 1.112
diff -u -p -u -p -r1.112 syslogd.c
--- usr.sbin/syslogd/syslogd.c 19 Aug 2014 00:24:00 - 1.112
+++ usr.sbin/syslogd/syslogd.c 19 Aug 2014 21:09:15 -
@@ -1427,7 +1427,7 @@ find_dup(struct filed *f)
struct filed *
cfline(char *line, char *prog)
{
- int i, pri, addr_len;
+ int i, pri;
size_t rb_len;
char *bp, *p, *q, *cp;
char buf[MAXLINE], ebuf[100];
@@ -1538,11 +1538,10 @@ cfline(char *line, char *prog)
logerror(ebuf);
break;
}
- addr_len = priv_gethostserv(f-f_un.f_forw.f_hname,
+ if (priv_getaddrinfo(f-f_un.f_forw.f_hname,
cp == NULL ? syslog : cp,
- (struct sockaddr*)f-f_un.f_forw.f_addr,
- sizeof(f-f_un.f_forw.f_addr));
- if (addr_len 1) {
+ (struct sockaddr
Re: sk(4): jumbo mbufs and rxring accounting
On 20 Aug 2014, at 7:12 am, Stuart Henderson st...@openbsd.org wrote: On 2014/08/20 07:06, David Gwynne wrote: I think sthen is referring to the original diff Kettenis had in the tree a few years ago. Yes - I just wanted to give ideas of things that might be worth testing that have been known to cause problems on those NICs in the past indeed. i have tested high packet rates and vlans. ill kick the tyres on jumbos again and try a cvs co and kernel build on nfs if i get a spare moment at work. dlg On 20/08/2014 4:44 am, Brad Smith b...@comstyle.com wrote: On 19/08/14 2:43 PM, Stuart Henderson wrote: From what I remember from last attempt to convert sk(4) to MCLGETI, there were problems which only showed up under load (possibly also involved NFS, I don't remember for sure) - I probably used netrate with something like netblast 11.22.33.44 12345 1 30 to generate a bunch of packets over it quickly, and tcpbench to generate high bandwidth use. The first diff he sent out didn't work at all. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: sk(4): jumbo mbufs and rxring accounting
On 19/08/14 2:19 PM, Brad Smith wrote: On 18/08/14 6:24 PM, David Gwynne wrote: On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote: i think i'll try to find the sk at work and wire it up. its just annoying cos im pretty sure its sr optics with sc connectors. thanks for testing. how's this one? Only running regular MTU traffic so far but the NIC at least works and beating on it I haven't seen any noticeable issues so far. I'll see if I can do some test with Jumbos a little later on today. sk0 902019 2 25619 sk0 1500 Link 00:00:5a:98:b9:c0 29810991 0 23786214 0 0 skc0 at pci0 dev 5 function 0 Schneider Koch SK-98xx rev 0x13, GEnesis (0x0): ivec 0x784 sk0 at skc0 port A: address 00:00:5a:98:b9:c0 brgphy0 at sk0 phy 1: BCM5400 1000baseT PHY, rev. 7 Some minor cosmetic issues I noticed while diff'ing the two revisions of the diff... m-m_len = m-m_pkthdr.len = SK_JLEN; has spaces instead of a tab and the whitespace after if_rxr_ioctl(). Running either netrate or tcpbench targetted at the test system and its still working Ok. No packet loss. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: openospfd router-priority
Agree with once elected a DR he stays that way (eliminates a lot of bouncing). My issue was that both sides became FULL/OTHER. I stopped all and removed all router priorities and let them go default. When I brought it all back up, most went FULL/OTHER on both sides so I got nothing. I am using a /31 on the interfaces, I don't know if that messes anything up. In the past Linux use to have an issue with /31 links. Tim On Tue, Aug 19, 2014 at 4:52 PM, Florian Riehm m...@friehm.de wrote: On 08/19/14 21:45, Tim Epkes wrote: All, I had implemented a network using openospf and initially left router-priorities off. Problem is I kept coming up FULL/OTHER and would not get routes. I changed the router priority values (not to match as when I matched got the same). I changed one side of a line to 10, while the other was 5. When I reloaded the side I changed, it stayed in FULL/OTHER state when it came up again. To get it to change to FULL/DR or FULL/BCKUP I needed to reload both systems ospfd daemons. Then it recalced fine. This leads me to believe that their isn't a full renegotiation if the other side is still running. That would be hard to do in an environment where you have to bring down the entire network to make a change. Is this a bug or was this the intended deployment. Also if priorities match, shouldn't they then move to see who has the highest RID to determine DR and Backup. Cause coming up as OTHER by default was a real pain. Thanks P.S. once all reloaded it works fine. Tim Hi Tim, If you start two ospfd without any special router priority, the default priority of both routers is 1, one router becomes DR and the other one BDR. That's how it supposed to work and if it doesn't something is wrong. I have tried it with a very simple configuration and it works for me. If your network is up alreade and their is a DR in it and another ospfd goes up, the DR won't change regardless of it's priority. See RFC 2328 section 7.3: In general, when a router's interface to a network first becomes functional, it checks to see whether there is currently a Designated Router for the network. If there is, it accepts that Designated Router, regardless of its Router Priority. Why will you enforce a new DR if their is already one? Florian
Re: L2VPN in OpenBSD
Cool thanks. On Tue, Aug 19, 2014 at 4:12 PM, Rafael Zalamena rzalam...@gmail.com wrote: On Tue, Aug 19, 2014 at 03:48:51PM -0400, Tim Epkes wrote: All, I noticed in a few write-ups by Claudio that PWE3 and VPLS were next on the roadmap. This seemed to be a few years ago. Any progress in that regard? Is their a page that tracks that status? Very interested, Thanks Tim Yes, we (me and renato@) are working actively on this. There is no page tracking the status, but it has been discussed on misc@. http://marc.info/?l=openbsd-miscm=140744694729898w=2
Re: openospfd router-priority
On 2014/08/19 18:32, Tim Epkes wrote: Agree with once elected a DR he stays that way (eliminates a lot of bouncing). My issue was that both sides became FULL/OTHER. I get this sometimes, usually after a link has gone away for a bit but hasn't lost link, normally restarting ospfd on one router brings things back. (I seem to have to restart ospfd quite a lot, vlan additions often need it too.)
Re: new rc.conf(8) manual
On Tue, Aug 19, 2014 at 10:44:54PM +0200, Ingo Schwarze wrote: Hi, while working on rcctl(8), i noticed that the rc.conf(8) manual is of... err, how can i express it politely... somewhat doubtful quality. Here is a stab at it. As a first step, i moved all the examples from the DESCRIPTION to the EXAMPLES esction. After that, the DESCRIPTION section was basically empty, so i had clean earth to till. Do not attempt to read the diff. Just apply it and read the result. OK? Ingo Hi Ingo In the Base system daemon configuration variables section, in the last paragraph this is incorrect. ... including a string containing only a single blank character, ... Looking at the _rc_parse_conf() code in rc.subr says, that any leading and trailing blanks on the value side of key=value get stripped away. And maybe it's worth a note that in case of multiple lines with the same key, only the last is used. Besides that OK rpe@
let vlan(4) mtu be limited by the parents hardmtu instead of current mtu
this lets you have networks on the native vlan on an interface
at 1500, while setting a child vlan interfaces mtu to jumbos.
ok?
Index: if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.108
diff -u -p -r1.108 if_vlan.c
--- if_vlan.c 12 Jul 2014 18:44:22 - 1.108
+++ if_vlan.c 19 Aug 2014 23:52:15 -
@@ -528,9 +528,9 @@ vlan_ioctl(struct ifnet *ifp, u_long cmd
case SIOCSIFMTU:
if (ifv-ifv_p != NULL) {
if (ifv-ifv_p-if_capabilities IFCAP_VLAN_MTU)
- p_mtu = ifv-ifv_p-if_mtu;
+ p_mtu = ifv-ifv_p-if_hardmtu;
else
- p_mtu = ifv-ifv_p-if_mtu - EVL_ENCAPLEN;
+ p_mtu = ifv-ifv_p-if_hardmtu - EVL_ENCAPLEN;
if (ifr-ifr_mtu p_mtu || ifr-ifr_mtu ETHERMIN)
error = EINVAL;
Re: new rc.conf(8) manual
Hi Robert, Robert Peichaer wrote on Wed, Aug 20, 2014 at 12:39:51AM +0200: In the Base system daemon configuration variables section, in the last paragraph this is incorrect. ... including a string containing only a single blank character, ... Looking at the _rc_parse_conf() code in rc.subr says, that any leading and trailing blanks on the value side of key=value get stripped away. ischwarze@isnote $ grep ^tftpd /etc/rc.conf.local tftpd_flags= ischwarze@isnote $ sudo /etc/rc.d/tftpd -d start /dev/null usage: tftpd [-46cdv] [-l address] [-p port] [-r socket] directory ischwarze@isnote $ sudoedit /etc/rc.conf.local ischwarze@isnote $ grep ^tftpd /etc/rc.conf.local tftpd_flags= ischwarze@isnote $ sudo /etc/rc.d/tftpd -d start /dev/null ischwarze@isnote $ ps ax | grep tftp 8194 ?? Is 0:00.00 /usr/sbin/tftpd /tftpboot Works for me... I don't understand why it doesn't work for you. And maybe it's worth a note that in case of multiple lines with the same key, only the last is used. Well, you might already implicitly conclude that from the second paragraph: It is advisable to leave rc.conf untouched, and instead create and edit a new rc.conf.local file. Variables set in this file will override variables previously set in rc.conf. But we could make that more explicit: It is advisable to leave rc.conf untouched, and instead create and edit a new rc.conf.local file. Since only the last assignment to any variable takes effect, variables set in this file override variables previously set in rc.conf. Besides that OK rpe@ Thanks for checking! Yours, Ingo
Re: sk(4): jumbo mbufs and rxring accounting
jumbos seem find. nfs seems fine. im going to put this and the other jalloc driver changes in to see what happens. dlg On 20 Aug 2014, at 7:41, Brad Smith b...@comstyle.com wrote: On 19/08/14 2:19 PM, Brad Smith wrote: On 18/08/14 6:24 PM, David Gwynne wrote: On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote: i think i'll try to find the sk at work and wire it up. its just annoying cos im pretty sure its sr optics with sc connectors. thanks for testing. how's this one? Only running regular MTU traffic so far but the NIC at least works and beating on it I haven't seen any noticeable issues so far. I'll see if I can do some test with Jumbos a little later on today. sk0 902019 2 25619 sk0 1500 Link 00:00:5a:98:b9:c0 29810991 0 23786214 0 0 skc0 at pci0 dev 5 function 0 Schneider Koch SK-98xx rev 0x13, GEnesis (0x0): ivec 0x784 sk0 at skc0 port A: address 00:00:5a:98:b9:c0 brgphy0 at sk0 phy 1: BCM5400 1000baseT PHY, rev. 7 Some minor cosmetic issues I noticed while diff'ing the two revisions of the diff... m-m_len = m-m_pkthdr.len = SK_JLEN; has spaces instead of a tab and the whitespace after if_rxr_ioctl(). Running either netrate or tcpbench targetted at the test system and its still working Ok. No packet loss. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: ftp, proxies, and https
On 20 Aug 2014, at 11:53 am, David Gwynne da...@gwynne.id.au wrote:
can you fix this?
Begin forwarded message:
From: David Gwynne da...@gwynne.id.au
Subject: ftp, proxies, and https
Date: 20 August 2014 7:47:27 AEST
To: guent...@openbsd.org, js...@openbsd.org
ola. do you guys have any idea how i could fix this:
xdlg@eaitbsd56:~$ env
_=/usr/bin/env
http_proxy=http://proxy.eait.uq.edu.au:8080/
HOME=/server/home/xdlg
PWD=/server/home/xdlg
ftp_proxy=http://proxy.eait.uq.edu.au:8080/
SSH_TTY=/dev/ttyp1
SVN_EDITOR=vi
no_proxy=localhost,.uq.edu.au
MAIL=/var/mail/xdlg
SSH_CLIENT=130.102.79.52 39727 22
PATH=/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin
TMUX=/tmp/tmux-1014/default,791,0
TMUX_PANE=%0
https_proxy=http://proxy.eait.uq.edu.au:8080/
TERM=screen
SHELL=/bin/ksh
SSH_CONNECTION=130.102.79.52 39727 130.102.76.156 22
USER=xdlg
xdlg@eaitbsd56:~$ ftp
https://github.com/martine/ninja/archive/v1.5.1/85e13c163d0129216fb382df6a53d11393c4c0c2.tar.gz
Trying 130.102.71.129...
SSL failure: host `proxy.eait.uq.edu.au' not present in server certificate
This patch seems to fix it, with some quick testing (with and without proxy).
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.126
diff -u -r1.126 fetch.c
--- fetch.c 14 Jul 2014 09:26:27 - 1.126
+++ fetch.c 20 Aug 2014 02:10:50 -
@@ -343,6 +343,12 @@
}
path = newline;
+ } else {
+#ifndef SMALL
+ if (ishttpsurl) {
+ sslhost = host;
+ }
+#endif /* !SMALL */
}
if (isfileurl) {
@@ -604,7 +610,7 @@
ressl_error(ssl));
goto cleanup_url_get;
}
- if (ressl_connect_socket(ssl, s, host) != 0) {
+ if (ressl_connect_socket(ssl, s, sslhost) != 0) {
fprintf(ttyout, SSL failure: %s\n, ressl_error(ssl));
goto cleanup_url_get;
}
Re: /dev/crypto removal (3bis): DTYPE_CRYPTO
On Mon, Aug 18, 2014 at 8:02 AM, Mike Belopuhov m...@belopuhov.com wrote: I don't know if we recycle them somehow, but just in case... --- sys/sys/file.h +++ sys/sys/file.h ... -#defineDTYPE_CRYPTO5 /* crypto */ +/* was define DTYPE_CRYPTO5 */ When it goes, this is the way to document it, yep. ...but you better delete the code in usr.bin/fstat/fstat.c and usr.sbin/pstat/pstat.c before that. Philip
Re: /dev/crypto removal (3bis): DTYPE_CRYPTO
I don't know if we recycle them somehow, but just in case... --- sys/sys/file.h +++ sys/sys/file.h ... -#defineDTYPE_CRYPTO5 /* crypto */ +/* was define DTYPE_CRYPTO5 */ When it goes, this is the way to document it, yep. ...but you better delete the code in usr.bin/fstat/fstat.c and usr.sbin/pstat/pstat.c before that. I also approve of this way of cleaning up /dev/crypto. Just do make builds after every change.
