Re: Kernel error with March 20th amd64 snapshot
On Sun, Mar 23, 2014 at 10:49 PM, Peter Kane pwk...@gmail.com wrote: However, the problem of an automatic resume when a USB drive is attached on suspend still persists. This is the problem that started some time ago, unrelated to mpi@'s recent changes, right? So, what's the latest snapshot or cvs update you're sure did *not* have the problem, and what's the first you're sure *did* have the problem? (Regressions should be reported AFSAP) Philip Guenther
Re: Unbound in base, yes, what about ldns?
On Sun, 23 Mar 2014, Chris Smith wrote:
From: Chris Smith obsd_m...@chrissmith.org
To: Stuart Henderson s...@spacehopper.org
Cc: OpenBSD-Misc misc@openbsd.org
Date: Sun, 23 Mar 2014 22:09:00
Subject: Re: Unbound in base, yes, what about ldns?
...
How about this line added to rc.conf.local when using the package:
syslogd_flags=${syslogd_flags} -a /var/unbound/dev/log
Is it still needed or should it be removed?
Probably. If you're running chrooted and logging to syslog, you
should still need this line.
See the manual page for unbound.conf. A cursory reading indicates
it doesn't seem to have materially changed from the version in the
port/package. *But* cursory reading has let me and others down
badly in the past :-(
--
Dennis Davis dennisda...@fastmail.fm
nist-p ecdsa default factors
This was posted on the debian list and I was thinking of mentioning OpenSSH having ed25519 recently added. Is the latest OpenSSH using ecdsa potentially vulnerable to the alledged reduction to 32 bits of security. __ Also ECDSA shares with DSA the serious disadvantage over RSA that making signatures on a system with a broken RNG can reveal the key. I believe that we should avoid ECDSA gnupg keys and subkeys like the plague for the time being. You'd most likely get ECDSA keys using the NIST p-curves out of gnupg, and these p-curves are suspected to be backdoored. AFAIK, better curves are available only on the latest development versions of gnupg 2.1, and the difficulties do not end there: the keyservers are also going to be a problem for such keys and subkeys for a while yet. IMHO, we should stick with 4096-bit RSA for the main key for the time being, and use short expire dates for the *subkeys* (2 years or less). Refer to http://safecurves.cr.yp.to/ for more details on elliptic curves for crypto. PS: NIST p-curves are also a potential problem on OpenSSH and DNSSEC. ___ -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___
Re: crypto vnd(4) question
On Sun, 23 Mar 2014, Robert wrote: Hi, I have two external USB disks, 3TB and 4TB, in use like that. So far no problems, even after hard reboots (power outage). They are used for backups, and it's USB 2.0 - so I can't really say much about intense writing... Hi, thanks for your response. Did you tune the host filesystem in any way? What mount options do you use for both the host filesystem and the one on the vnd image? By intensive writing I mean usage like tar xzf ports.tar.gz and such. It is not so much intensive, but it possibly may cause problems nonetheless. I already did some experiments with a 40 GB vnd image. I saw a little slow tranfers over NFS (~ 6 MB/s and less when reading from the filesystem on a vnd) and one complete lock up when the vnd was under read/write load. But I was not able to reproduce the lock up later. Regards, David
Re: {r,s}mkx entries in terminfo db missing
Hi On OpenBSD, the curse and termcap library use *only* pre-compiled databases to search for a TERM entry. Every mention to the /usr/share/misc/terminfo/*/* or ~/.terminfo/*/* scheme in OpenBSD's own manpages or on instructions written for system that do use that scheme (Linux) are invalid. Not quite. OpenBSD ncurses will also search all of ~/.terminfo, /usr/share/terminfo, and /usr/local/share/terminfo. So you can install files with tic as normal. The manpages say /usr/share/misc/terminfo, but this is not searched (only /usr/share/misc/terminfo.db). ISTR changing it in the manpages but apparently not.
Re: pf and nat
Em 18-03-2014 15:19, Friedrich Locke escreveu: Hi folks, i am studying pf and a doubt arose! Since my state policy if if-bound (set state-policy if-bound) i need two rules for each traffic i want to pass. Is that understanding right ? For instance, for nat i could : pass out on tl0 from dc0:network to any nat-to tl0 pass in on dc0 from dc0:network to any Is this understanding correct ? Or only the first rule is ok? Thanks. First of all, I hardly see why you want or need to use if-bound, since it most likely hurts pf performance. Secondly, the proper way of doing nat, is using match rules, not pass. And, even with match rules, you need 2 rules anyway: match out on tl0 from dc0:network to any nat-to (tl0), tl0, gw ip, whatever pass in on dc0 from dc0:network to any If you want better control of what passes in which interfaces, I believe you are better served using tags than using if-bound and always duplicating yourself. You're less error prone. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: OpenBSD email provider
Em 21-03-2014 21:48, Stuart Henderson escreveu: On 2014-03-19, Giancarlo Razzolini grazzol...@gmail.com wrote: Em 19-03-2014 09:41, Stuart Henderson escreveu: you have more trust in ISP DNS servers honouring TTLs than I do. if you can only get a dynamic IP at home and would like to host mail there yourself, in a machine which only you have physical access to, etc. (i.e. do *not* want to keep your email archive on a VPS), you could rent a VPS and use it as a tunnel endpoint instead. I don't. I do not use any of my ISP's dns servers. Also, in this case, I have to trust the other mta's dns servers honoring TTL's, not mine. That is exactly what I mean. You trust other ISPs, who you don't even have a business relationship with, to tell their customers/mtas to deliver your mail to the correct address... Some places deliberately place a minimum restriction on TTLs to save on bandwidth. Others do it to mitigate DNS rebinding attacks. So you can have problems caused by both good *and* bad ISPs... The bottom line is, we have today an email system that is broken, and I don't see it getting any better in the near future. Part is because it relies on another broken system which is dns, and part because the mta's are supposed to talk with each other and the standard is set on very low levels of security when it should be the other way around. You can host your own mail, but do not trust it to be really only your mail. Cheers, -- Giancarlo Razzolini GPG: 4096R/77B981BC
Re: Kernel error with March 20th amd64 snapshot
Hello gents, and thanks to all involved, it's fixed in the latest snapshot. Here are the snapshots I've used lately and marked whether it works: 24-03-2014/ [Works] 20-03-2014/ [Crashes] 24-02-2014/ [Works] Hope this helps even a bit. -- Regards, Ville On 24 March 2014 08:09, Philip Guenther guent...@gmail.com wrote: On Sun, Mar 23, 2014 at 10:49 PM, Peter Kane pwk...@gmail.com wrote: However, the problem of an automatic resume when a USB drive is attached on suspend still persists. This is the problem that started some time ago, unrelated to mpi@'s recent changes, right? So, what's the latest snapshot or cvs update you're sure did *not* have the problem, and what's the first you're sure *did* have the problem? (Regressions should be reported AFSAP) Philip Guenther
Typo in current.html...
There's a minor typo in current.html -- diff below. Thanks, --avj Index: current.html === RCS file: /home/cvsync/www/faq/current.html,v retrieving revision 1.484 diff -u -p -r1.484 current.html --- current.html23 Mar 2014 23:53:33 - 1.484 +++ current.html24 Mar 2014 16:07:13 - @@ -732,7 +732,7 @@ And _unbound group. _unbound:*:53: /pre -On or before March 19, sysmerge(8) was unable to do the /ec/group +On or before March 19, sysmerge(8) was unable to do the /etc/group crossing automatically. Manual intervention will be required in those situations.
Re: {r,s}mkx entries in terminfo db missing
Hugo Villeneuve schrieb am 23.03.2014 02:24:
On Fri, Mar 21, 2014 at 03:20:42PM +0100, Nils R wrote:
After replacing the st-entries in /usr/share/mish/termcap and
recreating the db with cap_mkdb, i also had to rename the terminfo.db
to make it work. I could not find any program to rebuild the
terminfo db, how is it done? Or is terminfo.db not needed at all?
Still looking for a simpler solution :)
Nils
The easiest is to go into:
/usr/src/share/termtypes
and edit OpenBSD's original file directly: termtypes.master
That file is mostly in terminfo format. (But you can put unsupported
termcap capabilities directly too, I think. Might be other stuff.)
And then you just use the included Makefile to update the system
databases.
# cd /usr/src/share/termtypes
# make obj make clean make make install
BUT NOW YOU ARE RUNNING A MODIFIED AND UNSUPPORTED VERSION OF OPENBSD.
IF YOU BREAK SOMETHING, YOU ARE ON YOUR OWN.
Every time you will update by source, termtype.master will show up
as modified^1 and you'll have to verify it against the official version
to see whether the your personal changes are still needed, valid
and don't break anything.
If you update from tarballs, your personal modified term{cap,info}.db
will be lost and you'll have to remember to recreate your changes.
^1: In practice, every one should check the output from any cvs
up for lines that starts with M or C.
Thanks, that worked. I checked the Makefile, and all three related files
(terminfo.db, termcap.db and termcap) are created from termtype.master. What
confuses me is that infocmp still reports it reads entries from
/usr/share/misc/terminfo, even though that file doesn't exist:
$ infocmp st | head -1
# Reconstructed via infocmp from file: /usr/share/misc/terminfo
I looked at the code at /usr/src/usr.bin/infocmp, the filename is not hardcoded
in there -- i couldn't figure out where it comes from.
Thanks again for that advice.
Best,
Nils
Re: {r,s}mkx entries in terminfo db missing
Nicholas Marriott schrieb am 24.03.2014 14:06: Hi On OpenBSD, the curse and termcap library use *only* pre-compiled databases to search for a TERM entry. Every mention to the /usr/share/misc/terminfo/*/* or ~/.terminfo/*/* scheme in OpenBSD's own manpages or on instructions written for system that do use that scheme (Linux) are invalid. Not quite. OpenBSD ncurses will also search all of ~/.terminfo, /usr/share/terminfo, and /usr/local/share/terminfo. So you can install files with tic as normal. The manpages say /usr/share/misc/terminfo, but this is not searched (only /usr/share/misc/terminfo.db). ISTR changing it in the manpages but apparently not. Well, i doubt it does, because even with a newer st.info installed (with tic) to ~/.terminfo/s/st*, infocmp always reported entries from (the nonexisting) /usr/share/misc/terminfo -- which really was /usr/share/misc/terminfo.db, and entries from it were always preferred to /usr/share/misc/termcap.db. Without changing termtypes.master and rebuilding the databases as Hugo suggested, st misbehaved. So if you are dead certain that local terminfo files should be queried, there is a bug somewhere. Best, Nils
Re: {r,s}mkx entries in terminfo db missing
IIRC the directories are searched after the db. Install it as stnew or
something instead.
Original message
From: Nils R m...@hxgn.net
Date: 24/03/2014 17:11 (GMT+00:00)
To: nicholas.marri...@gmail.com
Cc: misc@openbsd.org
Subject: Re: {r,s}mkx entries in terminfo db missing
Nicholas Marriott schrieb am 24.03.2014 14:06:
Hi
On OpenBSD, the curse and termcap library use *only* pre-compiled
databases to search for a TERM entry.
Every mention to the /usr/share/misc/terminfo/*/* or ~/.terminfo/*/*
scheme in OpenBSD's own manpages or on instructions written for
system that do use that scheme (Linux) are invalid.
Not quite. OpenBSD ncurses will also search all of ~/.terminfo,
/usr/share/terminfo, and /usr/local/share/terminfo.
So you can install files with tic as normal.
The manpages say /usr/share/misc/terminfo, but this is not searched
(only /usr/share/misc/terminfo.db). ISTR changing it in the manpages but
apparently not.
Well, i doubt it does, because even with a newer st.info installed (with
tic) to ~/.terminfo/s/st*, infocmp always reported entries from (the
nonexisting) /usr/share/misc/terminfo -- which really was
/usr/share/misc/terminfo.db, and entries from it were always preferred to
/usr/share/misc/termcap.db. Without changing termtypes.master and
rebuilding the databases as Hugo suggested, st misbehaved.
So if you are dead certain that local terminfo files should be queried,
there is a bug somewhere.
Best,
Nils
Re: Where is this device attached?
Jonathan, this looks promising. David Coppa had said It should expose a ucom*, e.g.: ucom0 at uftdi0 portno 1 The dmesg now shows: moscom0 at uhub1 port 3 HP Company HPx9G+ Device rev 1.10/1.00 addr 2 ucom0 at moscom0 portno 0 How do I relate this to a filename? Thanks, /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: Where is this device attached?
See ucom(4) man page. Short answer: /dev/ttyU0 (ucom? should match up with /dev/ttyU?) -Adam On March 24, 2014 12:58:20 PM CDT, John Long codeb...@inbox.lv wrote: Jonathan, this looks promising. David Coppa had said It should expose a ucom*, e.g.: ucom0 at uftdi0 portno 1 The dmesg now shows: moscom0 at uhub1 port 3 HP Company HPx9G+ Device rev 1.10/1.00 addr 2 ucom0 at moscom0 portno 0 How do I relate this to a filename? Thanks, /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Where is this device attached?
John Long codeb...@inbox.lv wrote: Jonathan, this looks promising. David Coppa had said It should expose a ucom*, e.g.: ucom0 at uftdi0 portno 1 The dmesg now shows: moscom0 at uhub1 port 3 HP Company HPx9G+ Device rev 1.10/1.00 addr 2 ucom0 at moscom0 portno 0 How do I relate this to a filename? That would be /dev/ttyU0 and /dev/cuaU0 as the FILES section of ucom(4) shows. It is always a good idea to read device manual pages, as they usually contain a lot of helpful information. - Martin
Re: Where is this device attached?
On Mon, Mar 24, 2014 at 01:23:32PM -0500, Adam Thompson wrote: See ucom(4) man page. Short answer: /dev/ttyU0 (ucom? should match up with /dev/ttyU?) -Adam Thank you! /jl
Re: Where is this device attached?
On Fri, Mar 21, 2014 at 03:08:31AM +1100, Jonathan Gray wrote: It seems this needs a new driver, here is a quick test that modifies an existing one that might work: snip Your patch works great. Kermit is talking to the device. Thank you so much for the help! /jl -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary/ \http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04
Re: {r,s}mkx entries in terminfo db missing
Nicholas Marriott schrieb am 24.03.2014 18:51:
IIRC the directories are searched after the db. Install it as stnew or
something
instead.
You're right, installing the terminfo entries as stnew works (if the
terminal name is changed as well)! I grepped the sources a bit, and
found this file:
/usr/src/lib/libcurses/tinfo/read_bsd_terminfo.c
In there, you find a hardcoded string pointing to the nonexistent file:
#define _PATH_TERMINFO /usr/share/misc/terminfo
and this function:
int
_nc_read_bsd_terminfo_entry(tn, filename, tp)
const char *const tn;
char *const filename;
TERMTYPE *const tp;
{
char **fname, *p;
char envterm[PATH_MAX]; /* local copy of $TERMINFO */
char hometerm[PATH_MAX]; /* local copy of $HOME/.terminfo */
char *pathvec[4]; /* list of possible terminfo files */
size_t len;
fname = pathvec;
/* $TERMINFO may hold a path to a terminfo file */
if (use_terminfo_vars() (p = getenv(TERMINFO)) != NULL) {
len = strlcpy(envterm, p, sizeof(envterm));
if (len sizeof(envterm))
*fname++ = envterm;
}
/* Also check $HOME/.terminfo if it exists */
if (use_terminfo_vars() (p = getenv(HOME)) != NULL *p != '\0') {
len = snprintf(hometerm, sizeof(hometerm), %s/.terminfo, p);
if (len 0 len sizeof(hometerm))
*fname++ = hometerm;
}
/* Finally we check the system terminfo file */
*fname++ = _PATH_TERMINFO;
*fname = NULL;
/*
* Lookup ``tn'' in each possible terminfo file until
* we find it or reach the end.
*/
for (fname = pathvec; *fname; fname++) {
if (_nc_lookup_bsd_terminfo_entry(tn, *fname, tp) == 1) {
/* Set copyout parameter and return */
(void)strlcpy(filename, *fname, PATH_MAX);
return (1);
}
}
return (0);
}
If i understand correctly, this program is used to read terminfo files
and to lookup entries later, though i have no idea how it is done. From
this code, it seems that a dir given with TERMINFO and ~/.terminfo are
checked as well, but always *before* the systemwide db is checked, and
therefore, all previous entries are overridden if the same terminal id
is found there in the system db. Maybe changing the order of checks will
allow entries in ~ to dominate entries from the system db, and even
though i don't really know what i'm doing, i think i will try it out and
see if it helps :)
Best,
Nils
Re: crypto vnd(4) question
On Mon, 24 Mar 2014 13:52:52 +0100 (CET) David Vasek va...@fido.cz wrote: On Sun, 23 Mar 2014, Robert wrote: Hi, I have two external USB disks, 3TB and 4TB, in use like that. So far no problems, even after hard reboots (power outage). They are used for backups, and it's USB 2.0 - so I can't really say much about intense writing... Hi, thanks for your response. Did you tune the host filesystem in any way? What mount options do you use for both the host filesystem and the one on the vnd image? By intensive writing I mean usage like tar xzf ports.tar.gz and such. It is not so much intensive, but it possibly may cause problems nonetheless. I already did some experiments with a 40 GB vnd image. I saw a little slow tranfers over NFS (~ 6 MB/s and less when reading from the filesystem on a vnd) and one complete lock up when the vnd was under read/write load. But I was not able to reproduce the lock up later. Regards, David No tuning whatsoever. The powers that be said thou shall not twist knobs ;) Mount options for the file and VND: noatime, nodev, nosuid, softdep Performance: I get 6MB/sec, but I guess that's the USB2.0 limit. Those 8MB/sec over NFS is what I get as well (gbit LAN) for the internal disks - no matter if the server disk is softraid/crypto, or VND/crypto. On the client side all the nfsio start eating the CPU, and on the server side the nfsd. At some point the server/nfsd starts waiting for inodebiowait, and everything comes to a halt - until all the data is written to the disk. E.g., try to dd if=/dev/zero of=/nfs/file bs=4k and wait for a while (I guess until some cache fills up), or use ctrl-c. Good luck tuning NFS... Otherwise it works fine; as I said, I'm using it for backup with rsync (locally, not over NFS). Writing 1TB+ of files in one go was no problem. kind regards, Robert
set MTU on ipv6 protocol only ?
Hi list, As i've already seen on Linux Kernel, MTU can be specified by network interface and by IP protocol through sysctl (don't know if it is the best way to do, but it's efficient) . For instance : sysctl -w net.ipv6.conf.eth0.mtu=1280 This does not apply to L2 MTU on network interface itself but only on IPv6 traffic/packets. Is there a way to handle this on OpenBSD ? Regards, Christophe.
Re: set MTU on ipv6 protocol only ?
On Mon, Mar 24, 2014 at 22:28, Christophe wrote: sysctl -w net.ipv6.conf.eth0.mtu=1280 This does not apply to L2 MTU on network interface itself but only on IPv6 traffic/packets. Is there a way to handle this on OpenBSD ? You can set an mtu using route. Maybe it works.
Re: {r,s}mkx entries in terminfo db missing
int
_nc_read_bsd_terminfo_entry(tn, filename, tp)
const char *const tn;
char *const filename;
TERMTYPE *const tp;
{
char **fname, *p;
char envterm[PATH_MAX]; /* local copy of $TERMINFO */
char hometerm[PATH_MAX]; /* local copy of $HOME/.terminfo */
char *pathvec[4]; /* list of possible terminfo files */
size_t len;
fname = pathvec;
/* $TERMINFO may hold a path to a terminfo file */
if (use_terminfo_vars() (p = getenv(TERMINFO)) != NULL) {
len = strlcpy(envterm, p, sizeof(envterm));
if (len sizeof(envterm))
*fname++ = envterm;
}
/* Also check $HOME/.terminfo if it exists */
if (use_terminfo_vars() (p = getenv(HOME)) != NULL *p != '\0')
{
len = snprintf(hometerm, sizeof(hometerm), %s/.terminfo, p);
if (len 0 len sizeof(hometerm))
*fname++ = hometerm;
}
/* Finally we check the system terminfo file */
*fname++ = _PATH_TERMINFO;
*fname = NULL;
/*
* Lookup ``tn'' in each possible terminfo file until
* we find it or reach the end.
*/
for (fname = pathvec; *fname; fname++) {
if (_nc_lookup_bsd_terminfo_entry(tn, *fname, tp) == 1) {
/* Set copyout parameter and return */
(void)strlcpy(filename, *fname, PATH_MAX);
return (1);
}
}
return (0);
}
If i understand correctly, this program is used to read terminfo files
and to lookup entries later, though i have no idea how it is done. From
this code, it seems that a dir given with TERMINFO and ~/.terminfo are
checked as well, but always *before* the systemwide db is checked, and
therefore, all previous entries are overridden if the same terminal id
is found there in the system db. Maybe changing the order of checks will
allow entries in ~ to dominate entries from the system db, and even
though i don't really know what i'm doing, i think i will try it out and
see if it helps :)
Best,
Nils
I was wrong here, the for-loop returns as soon as it finds a valid
entry. I left the order as it is and just added a few debug statements.
After installing the new compiled libcurses, when i start a new terminal,
it tries to lookup existing information in existing databases, and
once an entry is found, it is used immediately. Only when no database
contains an entry for the terminal, a terminfo file is read:
_nc_read_bsd_terminfo_entry: Description of stnew-256color in
/home/nils/.terminfo
_nc_lookup_bsd_terminfo_entry: tn=stnew-256color,
filename=/home/nils/.terminfo
_nc_lookup_bsd_terminfo_entry: Read entries for stnew-256color
from /home/nils/.terminfo
_nc_read_bsd_terminfo_entry: not found! Should continue.
_nc_read_bsd_terminfo_entry: Description of stnew-256color in
/usr/share/misc/terminfo
_nc_lookup_bsd_terminfo_entry: tn=stnew-256color,
filename=/usr/share/misc/terminfo
_nc_lookup_bsd_terminfo_entry: Read entries for stnew-256color
from /usr/share/misc/terminfo
_nc_read_bsd_terminfo_entry: not found! Should continue.
_nc_read_bsd_terminfo_file:
filename=/home/nils/.terminfo/s/stnew-256color
_nc_lookup_bsd_terminfo_entry: tn=stnew-256color,
filename=/home/nils/.terminfo
Is this intended?
Nils
Re: set MTU on ipv6 protocol only ?
Hi Ted, Le 24/03/2014 22:33, Ted Unangst a écrit : On Mon, Mar 24, 2014 at 22:28, Christophe wrote: sysctl -w net.ipv6.conf.eth0.mtu=1280 This does not apply to L2 MTU on network interface itself but only on IPv6 traffic/packets. Is there a way to handle this on OpenBSD ? You can set an mtu using route. Maybe it works. Perhaps (I will search for this / seems also interesting for another case ;) ), but, in this case : # route -n show -inet6|grep ^2|wc -l 44 and all routes are learned by dynamic routing (RIPng and BGP). Only one of the 8 network interfaces seems to have a problem with MTU. That's why I try to set it, on this network interface and on IPv6 only. Christophe.
Re: pf and nat
On 03/24/14 15:44, Giancarlo Razzolini wrote: Secondly, the proper way of doing nat, is using match rules, not pass. Why would you say that? 'pass ... nat-to ...' makes perfect sense to me. Using match was an easy transition from the old nat rules, but being *the* proper way, no way. /Alexander
Re: crypto vnd(4) question
David Vasek [va...@fido.cz] wrote: Hello, I would like to ask you. Does anybody have a real life experience with a few TB large encrypted vnd(4) image which hosts a filesystem which is intensively written to and read from? In such a setup where the host device is a 4k-byte sector drive and the vnd(4) emulates a 512-byte sector device, is it robust enough? I suppose the vnd sectors would be used in groups of eight or more (4096-byte fragments) and would be aligned to the host drive sectors. Are there any issues? Is the double filesystem overhead and double buffering a problem? Keep in mind, vnd emulates 512 byte sectors because that's the default disklabel that it uses You are free to specify a different disklabel in /etc/disktab and use vnconfig -t xyz to get vnd to recognize the CHS, sector size and total sector parameters. I believe you also have to use vnconfig -t ... when you mount this image.
Re: {r,s}mkx entries in terminfo db missing
This comment implies yes:
/*
* Lookup ``tn'' in each possible terminfo file until
* we find it or reach the end.
*/
for (fname = pathvec; *fname; fname++) {
And this one from read_entry.c:
#ifdef __OpenBSD__
/* First check the BSD terminfo.db file */
if (_nc_read_bsd_terminfo_entry(name, filename, tp) == 1)
return (1);
#endif /* __OpenBSD__ */
.
On Mon, Mar 24, 2014 at 10:33:43PM +0100, Nils R wrote:
int
_nc_read_bsd_terminfo_entry(tn, filename, tp)
const char *const tn;
char *const filename;
TERMTYPE *const tp;
{
char **fname, *p;
char envterm[PATH_MAX]; /* local copy of $TERMINFO */
char hometerm[PATH_MAX]; /* local copy of $HOME/.terminfo */
char *pathvec[4]; /* list of possible terminfo files */
size_t len;
fname = pathvec;
/* $TERMINFO may hold a path to a terminfo file */
if (use_terminfo_vars() (p = getenv(TERMINFO)) != NULL) {
len = strlcpy(envterm, p, sizeof(envterm));
if (len sizeof(envterm))
*fname++ = envterm;
}
/* Also check $HOME/.terminfo if it exists */
if (use_terminfo_vars() (p = getenv(HOME)) != NULL *p != '\0')
{
len = snprintf(hometerm, sizeof(hometerm), %s/.terminfo, p);
if (len 0 len sizeof(hometerm))
*fname++ = hometerm;
}
/* Finally we check the system terminfo file */
*fname++ = _PATH_TERMINFO;
*fname = NULL;
/*
* Lookup ``tn'' in each possible terminfo file until
* we find it or reach the end.
*/
for (fname = pathvec; *fname; fname++) {
if (_nc_lookup_bsd_terminfo_entry(tn, *fname, tp) == 1) {
/* Set copyout parameter and return */
(void)strlcpy(filename, *fname, PATH_MAX);
return (1);
}
}
return (0);
}
If i understand correctly, this program is used to read terminfo files
and to lookup entries later, though i have no idea how it is done. From
this code, it seems that a dir given with TERMINFO and ~/.terminfo are
checked as well, but always *before* the systemwide db is checked, and
therefore, all previous entries are overridden if the same terminal id
is found there in the system db. Maybe changing the order of checks will
allow entries in ~ to dominate entries from the system db, and even
though i don't really know what i'm doing, i think i will try it out and
see if it helps :)
Best,
Nils
I was wrong here, the for-loop returns as soon as it finds a valid
entry. I left the order as it is and just added a few debug statements.
After installing the new compiled libcurses, when i start a new terminal,
it tries to lookup existing information in existing databases, and
once an entry is found, it is used immediately. Only when no database
contains an entry for the terminal, a terminfo file is read:
_nc_read_bsd_terminfo_entry: Description of stnew-256color in
/home/nils/.terminfo
_nc_lookup_bsd_terminfo_entry: tn=stnew-256color,
filename=/home/nils/.terminfo
_nc_lookup_bsd_terminfo_entry: Read entries for stnew-256color
from /home/nils/.terminfo
_nc_read_bsd_terminfo_entry: not found! Should continue.
_nc_read_bsd_terminfo_entry: Description of stnew-256color in
/usr/share/misc/terminfo
_nc_lookup_bsd_terminfo_entry: tn=stnew-256color,
filename=/usr/share/misc/terminfo
_nc_lookup_bsd_terminfo_entry: Read entries for stnew-256color
from /usr/share/misc/terminfo
_nc_read_bsd_terminfo_entry: not found! Should continue.
_nc_read_bsd_terminfo_file:
filename=/home/nils/.terminfo/s/stnew-256color
_nc_lookup_bsd_terminfo_entry: tn=stnew-256color,
filename=/home/nils/.terminfo
Is this intended?
Nils
5.4 hanging when used as hostap
hello - i've been using a soekris net5501 as a home gateway since early 2008, starting w/openbsd 4.2 and upgrading through 5.4. for most of that time it's also been serving as a wireless access point. the wireless card is a SparkLAN WMIR-168AG WLAN 802.11a/b/g Mini PCI Module with the Ralink RT2561T chipset (ral driver; dmesg.boot attached). the system has been working reliably for years. however, the box started to hang within days of upgrading to 5.4. it stays responsive for a variable length of time after reboot, ranging from minutes to a week or more (but not much more). and unfortunately, it hangs w/o writing anything to syslog or serial console. i enabled ddb.console in sysctl.conf but found it to be completely unresponsive when hung (i successfully tested sending a break in normal operation). i've merged the patches from the 5.4 release errata patch list and rebuilt the os to no effect. there was some correlation between the hangs and increased wireless usage; i tried disabling pf and squid but the hangs continued. eventually i ran `ifconfig ral0 down` and hooked the laptops up to a switch. rock-solid for weeks. brought ral0 back up and within days of usage the box hung again. i see at least one person w/similar symptoms from 2011[1] but nothing more recent. if my searches have missed any relevant documentation, threads, bug reports, etc. please let me know. otherwise, any suggestions on how to resolve / troubleshoot / workaround or how to gather add'l information for a bug report if necessary? tia... andy /etc/hostname.ral0: inet 192.168.3.1 255.255.255.0 NONE \ media autoselect mode 11g mediaopt hostap \ nwid diatribes chan 3 \ nwkey [...] 1 http://marc.info/?l=openbsd-miscm=130827912412200 -- andy and...@diatribes.org OpenBSD 5.4-stable (GENERIC) #5: Wed Feb 12 17:33:29 PST 2014 a...@tirith.diatribes.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Geode(TM) Integrated Processor by AMD PCS (AuthenticAMD 586-class) 434 MHz cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW real mem = 267972608 (255MB) avail mem = 252141568 (240MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 20/80/26, BIOS32 rev. 0 @ 0xfac40 pcibios0 at bios0: rev 2.0 @ 0xf/0x1 pcibios0: pcibios_get_intr_routing - function not supported pcibios0: PCI IRQ Routing information unavailable. pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc8000/0xa800 cpu0 at mainbus0: (uniprocessor) amdmsr0 at mainbus0 pci0 at mainbus0 bus 0: configuration mode 1 (bios) 0:20:0: io address conflict 0x6100/0x100 0:20:0: io address conflict 0x6200/0x200 pchb0 at pci0 dev 1 function 0 AMD Geode LX rev 0x30 glxsb0 at pci0 dev 1 function 2 AMD Geode LX Crypto rev 0x00: RNG AES vr0 at pci0 dev 6 function 0 VIA VT6105M RhineIII rev 0x96: irq 11, address 00:00:24:c9:5e:8c ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr1 at pci0 dev 7 function 0 VIA VT6105M RhineIII rev 0x96: irq 5, address 00:00:24:c9:5e:8d ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr2 at pci0 dev 8 function 0 VIA VT6105M RhineIII rev 0x96: irq 9, address 00:00:24:c9:5e:8e ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 vr3 at pci0 dev 9 function 0 VIA VT6105M RhineIII rev 0x96: irq 12, address 00:00:24:c9:5e:8f ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063, model 0x0034 ral0 at pci0 dev 17 function 0 Ralink RT2561S rev 0x00: irq 15, address 00:12:0e:61:7f:a8 ral0: MAC/BBP RT2561C, RF RT5225 glxpcib0 at pci0 dev 20 function 0 AMD CS5536 ISA rev 0x03: rev 3, 32-bit 3579545Hz timer, watchdog, gpio, i2c gpio0 at glxpcib0: 32 pins iic0 at glxpcib0 pciide0 at pci0 dev 20 function 2 AMD CS5536 IDE rev 0x01: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 1: HTE721080G9AT00 wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors wd0(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 ignored (disabled) ohci0 at pci0 dev 21 function 0 AMD CS5536 USB rev 0x02: irq 7, version 1.0, legacy support ehci0 at pci0 dev 21 function 1 AMD CS5536 USB rev 0x02: irq 7 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 AMD EHCI root hub rev 2.00/1.00 addr 1 isa0 at glxpcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pcppi0 at isa0 port 0x61 spkr0 at pcppi0 nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS gpio1 at nsclpcsio0: 29 pins npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb1 at ohci0: USB revision 1.0 uhub1 at usb1 AMD OHCI root hub rev 1.00/1.00 addr 1 mtrr: K6-family MTRR support (2 registers)
Re: pf and nat
Secondly, the proper way of doing nat, is using match rules, not pass. Why would you say that? 'pass ... nat-to ...' makes perfect sense to me. Using match was an easy transition from the old nat rules, but being *the* proper way, no way. I also believe that one-way-ism is disease. I don't need to prove the concept. Things change. One-way-ist's often succumb.
SpamAssassin Consult
We have a mailserver that will not post email, and it appears that SpamAssassin is not running [via Mailscanner]. Load isn't the problem, something apparently changed this evening. Looking for someone that can take a look [paid gig] now, .. if possible. [Not a current system.] Thanks! Lee
