xenodm does not use Xsetup if autoLogin is set
The lack of Xsetup might be desired functionality but that's contrary
to xenodm(1):
After resetting the X server, xenodm runs the Xsetup script
to assist in setting up the screen the user sees along with
the xlogin widget.
The xlogin widget, which xenodm presents, offers the familiar
login and password prompts, unless autoLogin is set.
After the user logs in, xenodm runs the Xstartup script as
root.
The patch below makes this happen as per the documentation. Note
that for anybody using autoLogin this will have a material change
to their desktop environment as the default Xsetup script runs
xconsole (and xsetroot).
Incidentally the reason for 'if (!d->grabServer)' is explained in
GreetUser() that's used when autoLogin is NOT set but I felt it
wasn't necessary to duplicate the comment.
Matthew
Index: greeter/greet.c
===
RCS file: /src/datum/openbsd/cvs/xenocara/app/xenodm/greeter/greet.c,v
retrieving revision 1.9
diff -u -p -r1.9 greet.c
--- greeter/greet.c 11 Jul 2018 16:20:20 - 1.9
+++ greeter/greet.c 20 Feb 2021 20:17:26 -
@@ -359,6 +359,9 @@ greet_user_rtn AutoLogin(
struct greet_info *greet)
{
+if (!d->grabServer)
+ SetupDisplay (d);
+
if (!autoLoginEnv(d, verify, greet)) {
LogError("Autologin %s failed\n", d->autoLogin);
SessionExit(d, UNMANAGE_DISPLAY, true);
Possibly broken syspatch/relink but reports success
I've just run syspatch on a 6.5 box and obviously I've allocated the space
poorly but because of that, this happened:
drogo# syspatch
Get/Verify syspatch65-001_rip6cks... 100% |***| 196 KB
00:00
Installing patch 001_rip6cksum
Get/Verify syspatch65-002_srtp.tgz 100% |*| 4316 KB
00:00
Installing patch 002_srtp
Get/Verify syspatch65-003_mds.tgz 100% |**| 49488 KB
00:02
Installing patch 003_mds
/: write failed, file system is full
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/pmap.o: No space
left on devi
ce
/: write failed, file system is full
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/powernow-k8.o: No
space left
on device
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/ppp_tty.o: No
space left on d
evice
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/process_machdep.o:
No space l
eft on device
...
... Lots of this; doesn't need repeating.
...
tar: Unable to create usr/share/relink/kernel/GENERIC.MP/xen.o: No space left
on device
tar: Failed write to file var/syspatch/65-003_mds/003_mds.patch.sig: No space
left on devi
ce
Relinking to create unique kernel... done; reboot to load the new kernel
Errata can be reviewed under /var/syspatch
drogo# df -h
Filesystem SizeUsed Avail Capacity Mounted on
/dev/sd2a 254M153M 88.3M63%/
/dev/sd2d 3.4G1.7G1.6G52%/usr
/dev/sd2e 254M 18.0M223M 7%/var
/dev/sd3a 1.8T326G1.4T19%/srv
/dev/vnd3a19.7G3.2G 15.5G17%/var/www/htdocs/OpenBSD
drogo# ls -l /bsd*
-rwx-- 1 root wheel 15623498 Jun 6 18:57 /bsd
-rwx-- 1 root wheel 15629498 May 20 02:17 /bsd.booted
-rw--- 1 flak wheel 10224165 Apr 30 08:35 /bsd.rd
-rwx-- 1 root wheel 15527075 Apr 30 08:35 /bsd.sp
drogo# date
Thu Jun 6 18:58:23 UTC 2019
I'm not sure what this means it's stuffed into /bsd but I've kept it,
/bsd.booted and the relink directory and repaired and relinked manually. I'm
not attaching them to this because obviously they're too big but here's the
relink.log:
drogo# cat /srv/broken-20190606/kernel/GENERIC.MP/relink.log
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
12913621546360 671744 14131725d7a20d
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
rm -f bsd.gdb
mv -f newbsd bsd
umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h /var/db/kernel.SHA256
/bsd
Kernel has been relinked and is active on next reboot.
SHA256 (/bsd) = 40b52473bed49fca4f4d4218cd0d5062902d7f3398d3e833888b8494dc2f0b55
drogo# cat /srv/broken-20190606/kernel.SHA256
SHA256 (/bsd) = 40b52473bed49fca4f4d4218cd0d5062902d7f3398d3e833888b8494dc2f0b55
I didn't think to check what the return code from syspatch was but I suspect it
was zero.
In a little while I'll dig around in syspatch/relink to see if I can figure out
what's going on (I'm in the middle of something else now and system patching
was itself just a yak) but I wanted to post this in case anyone already
familiar with those two processes can jump straight to the problem.
Cheers,
Matthew
syspatch silently skipped patch 001_rip6cksum
Unrelated to my other syspatch email, I ran syspatch inside a chroot (same server so ignore the identical hostname) and this happened: drogo# syspatch Get/Verify syspatch65-002_srtp.tgz 100% |*| 4316 KB 00:04 Installing patch 002_srtp Get/Verify syspatch65-003_mds.tgz 100% |**| 49488 KB 01:03 Installing patch 003_mds Relinking to create unique kernel... failed! drogo# syspatch -l 002_srtp 003_mds drogo# ^D Failing to relink the kernel isn't a problem, obviously, because there isn't one but why did it skip 001_rip6cksum without so much as a comment? The chroot was created by simply extracting all the sets (and *etc.tgz), copying some /etc files and running MAKEDEV. Matthew
Re: syspatch silently skipped patch 001_rip6cksum
Antoine Jacoutot writes: > That is because 001 only includes kernel object files which you do not have > since you run under a chroot and didn't extract /usr/share/relink/kernel.tgz > So syspatch(8) considers you don't have that "set" installed. > syspatch-003 on the other end includes a header change and that header *is* > installed on your system. So syspatch installs it. But you are missing all the > other pieces to actually relink your kernel and that's why it fails. Thank-you that makes sense. It did throw me a little though; I would expect a tool such as this to report its inaction as well as its action. I take it that syspatch performs these checks also with the other sets? eg. It would skip an X patch if the X sets were not installed? > You are running syspatch under a totally unsupported setup. This is a common refrain and I do understand why it's used but it's not a concern. I'm not after support, I can put the pieces back together when I break them. But is 'all the sets' the only configuration which OpenBSD's tools consider valid in general? 'Supported'? In any case I still do think there's a bug here but now it's clear that it's one of: * syspatch doesn't report skipping patches (it also skipped a kernel patch when it recognised the lack of kernel but attempted to relink it later anyway for another patch, which will boil down to the same test). * syspatch's manpage doesn't fully describe its behaviour when one or more sets are mising. Please note that I'm not whinging that OpenBSD doesn't work the way I demand and insisting on change. I've noticed there's been a lot of that recently. I've found what I deem to be a fault and, if anyone else agrees, would like suggestions on how I could fix it (chiefly, which of the above is the real bug) and I will follow up with a patch. Or neither and I'll just deal with it locally. Matthew
Bypass doas password check with chroot
This isn't a bug per se, more of an incongruity in how security-centric tools work wrt root, specifically doas and chroot/su/other: joe@drogo$ doas -s drogo# doas -u chohag -s doas (root@drogo) password: doas: Authorization failed drogo# chroot -u chohag / drogo$ ^D drogo# su -l chohag drogo$ ^D Obviously a little one-liner or tiny C app could achieve the same result too. I assume this is more or less known, since each tool is working to its designed spec, so is the above ultimately the desired behaviour? Should doas ask even for root's password while myriad other ways of obtaining any user ID do and probably always will exist? On some servers root doesn't have a password. Matthew
Re: Bypass doas password check with chroot
Ingo Schwarze writes: > I see nothing wrong with it. It is easier to describe in the manual Indeed I was not suggesting that there was something wrong; being asked for a password when doing something which root could implicitly do simply confused me for a moment which prompted figuring out what the situation was. > The bikeshed has already been painted, and no matter whether you are > justified in calling the colour that tedu@ chose "pink", i wouldn't > see an obvious benefit in re-painting it now. I have no desire to change this behaviour or engage in bike-shedding. Please no. Perhaps instead 5 free lines? --- doas.1.~1.19.~ Sun Sep 4 18:20:37 2016 +++ doas.1 Thu Jul 4 01:26:21 2019 @@ -85,6 +85,12 @@ Execute the command as .Ar user . The default is root. +.Sh NOTE +Although the kernel imposes no restrictions on the root user's ability +to pose as any other user, +.Nm +will always require a password as per its configuration in order to +keep unnecessary complications out of a critical security utility. .El .Sh EXIT STATUS .Ex -std doas Not necessary of course but would have been nice for my peace of mind the other day when it happened (ie. to know that the situation has been duly considered). btw. I've never done anything with mdoc before so I expect there's a better macro to use to head this than .Sh but that's really not the point. > Please do not cross-post between different OpenBSD lists. Apologies and understood. Matthew
Re: Bypass doas password check with chroot
Theo de Raadt writes: > I don't see the point. > > If you get asked the question, and you know the answer, you answer it. > Why is that not the end of the story? When I used doas the other day to gain the rights of a user it asked me for a password which I didn't expect, as I was root. Confirming that there was no additional restriction somehow (I didn't think there would be but it doesn't hurt) made me wonder why doas was different. I couldn't find any acknowledgement of this state nor at a look through related documentation any indication of whether it was intentional or accidental. In short, words to the effect of what I wrote would have made it clear immediately that it's understood and for good reason, ie. not complicating a simple tool, and I've have moved on to the next thing happy. Frankly I thought no more of the issue after Ingo's response the other day but on the way home the wording I sent earlier (more or less) popped into my head and I thought I'd share. 'twould have been nice to see. Nothing more. Matthew
Re: Bypass doas password check with chroot
Ted Unangst writes: > Ted Unangst wrote: > > I think this is not the right note, but after some review I just realized we > > don't ever say that a password is required. It's merely hinted at in various > > options. I'll make a note of that. > > Just a simple sentence, but I think it makes explicit the behavior. Looks much better than my ham-fisted attempt. Matthew
[patch] Minor documentation tweak in ksh(1)
The description of ksh(1)'s handling of CDPATH is not quite complete and, worse, contradictory in the two locations it's mentioned. sh(1) barely touches on it but is Not Wrong so I've left it alone. (FWIW I also checked the CDPATH scanning code and actually poked at a real shell so I've confirmed that this is how it actually works) Matthew --- /usr/src/bin/ksh/ksh.1 Sat Oct 5 11:03:46 2019 +++ /tmp/ksh.1 Sun Nov 24 05:29:03 2019 @@ -1341,7 +1341,7 @@ .Ev CDPATH is set and does not contain .Sq \&. -or contains an empty path, the current directory is not searched. +or an empty path, the current directory is not searched. Also, the .Ic cd built-in command will display the resulting directory when a match is found @@ -2866,7 +2866,9 @@ .Ar dir . A .Dv NULL -path means the current directory. +path or +.Ql .\& +means the current directory. If .Ar dir is found in any component of the
Minor bug in xcb_connect
If the function implementing xcb_connect is called directly with a
custom xcb_auth_info_t then checking that the screen in $DISPLAY
is valid is skipped.
Matthew
Index: xcb_util.c
===
RCS file: /src/datum/openbsd/cvs/xenocara/dist/libxcb/src/xcb_util.c,v
retrieving revision 1.13
diff -u -p -r1.13 xcb_util.c
--- xcb_util.c 17 Jul 2022 08:31:10 - 1.13
+++ xcb_util.c 31 Jan 2023 22:20:24 -
@@ -528,10 +528,8 @@ xcb_connection_t *xcb_connect_to_display
if(auth) {
c = xcb_connect_to_fd(fd, auth);
-goto out;
}
-
-if(_xcb_get_auth_info(fd, &ourauth, display))
+else if(_xcb_get_auth_info(fd, &ourauth, display))
{
c = xcb_connect_to_fd(fd, &ourauth);
free(ourauth.name);
Odd X behaviour from root console (possible xauth bypass (but as root)?)
I haven't looked into what's causing this behaviour yet because I was cooking but I did manage to make it reproducable. Also it's very unlikely to show up in normal daily use. I was playing a series of flac files through mplayer (single process, many files) in a root shell on the text console (DISPLAY will not have been set, nor XAUTHORITY) and using X normally. When mplayer started a new track the X display acted as though a key was stuck down. Which key was stuck changes (it may have been related to keys I was pressing). The keyboard's state can be restored by switching to any console and back again (Ctrl-Alt-Fn). The apparently-stuck key happened in the xenodm login screen as well as the fvwm session. I'm not sure if all flac files also contain an image or only these ones. Notably mplayer did NOT open an X window. I will do a deeper dive later to figure out what's happening. In particular to try and remove mplayer from the loop and re-do my testing when I'm not distracted, but I wanted to get this out there in case anyone familiar with X has a clue what might be happening. The machine, for what it's worth, is a very uninteresting Dell Latitude laptop running a stock 7.2 with no customisation. Dmesg, logs and other data will come with a more thorough bug report (or not and a patch, if the stars align). One oddity I can think of is that xenodm isn't started normally on that laptop but by logging in as root and running xenodm (I could rcctl -f start xenodm but that's more typing). Mplayer was almost certainly running in the same console login session. I can't think how that matters. Cheers, Matthew ps. I'm well aware this deviates far from good practice. This is not my daily-use computer nor does it ever go anywhere near anything that might be called production.
Re: Minor bug in xcb_connect
Matthieu Herrb writes: > On Tue, Jan 31, 2023 at 10:31:34PM +, cho...@jtan.com wrote: > > If the function implementing xcb_connect is called directly with a > > custom xcb_auth_info_t then checking that the screen in $DISPLAY > > is valid is skipped. > > > > Matthew > > Hi, > > Thank you for this patch. Can you also file a Merge Request to > upstream libxcb project at gitlab.freedesktop.org so that this can get > reviewed by libxcb developpers ? No. You have a patch. You can apply it and fix your bug, or you can not. It's not my problem any more. Matthew
Trivial documentation patch
A grammatical error in login.conf(5): --- login.conf.5?rev=1.64 Sun Jan 6 15:27:44 2019 +++ login.conf.5Sun Jan 6 15:28:10 2019 @@ -104,7 +104,7 @@ .Pp .It auth Ta list Ta Dv passwd Ta Allowed authentication styles. -The first value is the default styles. +The first value is the default style. .\" .Pp .It auth- Ns Ar type Ta list Ta "" Ta Matthew
Typo (I think) in socket.h
In CTL_NET_NAMES, ECMA is added as "emca" which looks like a typo
even in French. The value won't be used anywhere though which is
likely why it slipped through. It's been there since day one.
Matthew
Index: sys/sys/socket.h
===
RCS file: /src/datum/openbsd/cvs/src/sys/sys/socket.h,v
retrieving revision 1.99
diff -u -p -r1.99 socket.h
--- sys/sys/socket.h29 Oct 2020 21:15:27 - 1.99
+++ sys/sys/socket.h6 Oct 2021 10:15:51 -
@@ -322,7 +322,7 @@ struct sockpeercred {
{ "chaos", CTLTYPE_NODE }, \
{ "xerox_ns", CTLTYPE_NODE }, \
{ "iso", CTLTYPE_NODE }, \
- { "emca", CTLTYPE_NODE }, \
+ { "ecma", CTLTYPE_NODE }, \
{ "datakit", CTLTYPE_NODE }, \
{ "ccitt", CTLTYPE_NODE }, \
{ "ibm_sna", CTLTYPE_NODE }, \
Another socket bug, documentation this time (with patch).
[gs]etsockopt(2) points out that SO_TYPE, SO_DOMAIN, SO_PROTOCOL and SO_ERROR are read-only but does not include SO_PEERCRED in that list. Also in the initial big list at the top of the page, SO_PEERCRED is not singled out as get only. This patch shuffles the lines around to put SO_PEERCRED with its peers. Matthew Index: lib/libc/sys/getsockopt.2 === RCS file: /src/datum/openbsd/cvs/src/lib/libc/sys/getsockopt.2,v retrieving revision 1.57 diff -u -p -r1.57 getsockopt.2 --- lib/libc/sys/getsockopt.2 4 Feb 2021 18:51:01 - 1.57 +++ lib/libc/sys/getsockopt.2 7 Oct 2021 09:00:21 - @@ -162,8 +162,6 @@ set timeout value for output set timeout value for input .It Dv SO_TIMESTAMP enables reception of a timestamp with datagrams -.It Dv SO_PEERCRED -get the credentials from other side of connection .It Dv SO_RTABLE set the routing table used for route lookups .It Dv SO_SPLICE @@ -178,6 +176,8 @@ get and clear error on the socket (get o get the domain of the socket (get only) .It Dv SO_PROTOCOL get the protocol of the socket (get only) +.It Dv SO_PEERCRED +get the credentials from other side of connection (get only) .El .Pp .Dv SO_DEBUG @@ -349,20 +349,6 @@ cmsg_level = SOL_SOCKET cmsg_type = SCM_TIMESTAMP .Ed .Pp -.Dv SO_PEERCRED -fetches the -.Va struct sockpeercred -credentials from the other side of the connection -(currently only possible on -.Dv AF_UNIX -sockets). -These credentials are from the time that -.Xr bind 2 , -.Xr connect 2 -or -.Xr socketpair 2 -were called. -.Pp The .Dv SO_RTABLE option gets or sets the routing table which will be used by the socket @@ -459,9 +445,10 @@ is set, overwrite kernel memory after se Finally, .Dv SO_TYPE , .Dv SO_DOMAIN , -.Dv SO_PROTOCOL -and +.Dv SO_PROTOCOL , .Dv SO_ERROR +and +.Dv SO_PEERCRED are options used only with .Fn getsockopt . .Dv SO_TYPE @@ -478,6 +465,19 @@ returns the protocol of the socket such returns any pending error on the socket and clears the error status. It may be used to check for asynchronous errors on connected datagram sockets or for other asynchronous errors. +.Dv SO_PEERCRED +fetches the +.Va struct sockpeercred +credentials from the other side of the connection +(currently only possible on +.Dv AF_UNIX +sockets). +These credentials are from the time that +.Xr bind 2 , +.Xr connect 2 +or +.Xr socketpair 2 +were called. .Sh RETURN VALUES .Rv -std .Sh ERRORS
Re: installation issue on x86_64
Bryan Steele writes: > https://www.openbsd.org/faq/faq4.html#Download > > > The install72.iso and install72.img images do not contain an SHA256.sig > > file, so the installer will complain that it can't check the signature > > of the included sets: > > > > Directory does not contain SHA256.sig. Continue without verification? [no] > > > > This is because it would make no sense for the installer to verify them. > > If someone were to make a rogue installation image, they could certainly > > change the installer to say the files were legitimate. Or they could just remove the check entirely. If you're not verifying the software that you run on your "raw" pre-operating-system processor, you're hardly going to verify the output from the installer to check that the right questions were asked and answered. Assuming you even know it's there. In a system now controlled by an attacker. How long has it been since this came up last? It seems like an interesting metric suggesting how readily the documentation (and source) is found and read. Have you considered SEO? Matthew
incorrect pledge error report
I decided late in an application's life to start using pledge, so
I put a call in at the top and started running it and adding the
requirements reported by dmesg on each iteration.
Eventually it reported that the tty promise was breached so I added
that and it reported again that the tty promise was breached.
From GDB the relevant part of the stack trace is:
(gdb) bt
#0 ioctl () at /tmp/-:2
#1 0x606521cbcd89301f in ?? ()
#2 0x03089d94d4a2 in drmGetVersion (fd=8) at
/usr/xenocara/lib/libdrm/mk/libdrm/../../xf86drm.c:708
#3 0x0308b1d3b7e1 in loader_get_driver_for_fd (fd=8) at
/usr/xenocara/lib/mesa/mk/libloader/../../src/loader/loader.c:108
#4 0x0308b1d02ed6 in dri3_create_screen (screen=0, priv=Unhandled
dwarf expression opcode 0xa3) at
/usr/xenocara/lib/mesa/mk/libGL/../../src/glx/dri3_glx.c:829
#5 0x0308b1cf5956 in __glXInitialize (dpy=0x3083034c000) at
/usr/xenocara/lib/mesa/mk/libGL/../../src/glx/glxext.c:800
#6 0x0308b1d080a5 in glXQueryVersion (dpy=Unhandled dwarf expression
opcode 0xa3) at /usr/xenocara/lib/mesa/mk/libGL/../../src/glx/glxcmds.c:483
loader_get_driver_for_fd is calling:
drmVersionPtr version = drmGetVersion(fd);
xf86drm.c at line 708 is in drmIoctl which I presume is the result
of some preprocessor magic, calling:
ret = ioctl(fd, request, arg);
dmesg reports (many times with different PID, same syscall):
turtle[32350]: pledge "tty", syscall 54
Clearly pledge is correct: whatever 'request' has this ioctl doing
doesn't use the tty promise (fd is probably the X connection). The
problem here is the error report in dmesg that the breach is in
something which is already included in the list of promises ("stdio
inet unix rpath recvfd tty", NULL).
I shall continue investigating to get my application to work and
follow up if I find anything useful but I hope this is enough
information for somebody familiar with the implementation of pledge
to quickly figure out where its, or my, misunderstanding is.
Cheers,
Matthew
Re: Minor doc-vs-implemention conflict in /etc/daily vs test(1)
Jason McIntyre writes:
> On Sun, Jun 16, 2024 at 03:05:24AM -0300, Crystal Kolipe wrote:
> > On Sat, Jun 15, 2024 at 06:45:21PM -0500, Tim Chase wrote:
> > > According to
> > >
> > > $ man [ | grep -A4 -e "-L.*f"
> > > -L file
> > > True if file exists and is a symbolic link. This operator is for
> > > compatibility purposes. Do not rely on its existence; use -h
> > > instead.
> >
> > There is definitely a discrepency between manual and source, because the
> > source contains a comment saying that -h is for backwards compatibility:
> >
> > {"-h", FILSYM, UNOP}, /* for backwards compat */
> >
> > and that comment has been there since the code was imported to NetBSD in
> > revision 1.13 in 1994.
When test's -h option was first added to OpenBSD's tree in 1995
that was the option marked as existing only for compatibility
purposes, this was switched in 2003:
Changes since 1.16: +6 -6 lines
encourage people to use -h rather than -L;
document -L as compatibility option;
slight sync with NetBSD description;
ok otto@ millert@
I'd guess there was some discussion about it but I can't be bothered
to look for it.
The ksh manpage lists both -h and -L without prioritising either.
I think it's safe to say we can rely on both flags existing now in
all variations of the tool. Supporting both is what? Half a dozen
opcodes?
[[ is more expressive anyway.
Matthew
ps. While we're on the subject, perl calls its (only) variant -l. ]]
--- /usr/src/bin/test/test.1Sat Aug 19 05:23:44 2023
+++ /tmp/test.1 Sun Jun 16 15:00:02 2024
@@ -118,11 +118,6 @@
True if
.Ar file
exists and is a symbolic link.
-This operator is for compatibility purposes.
-Do not rely on its existence;
-use
-.Fl h
-instead.
.It Fl n Ar string
True if the length of
.Ar string
Kernel panic fscking read-only / post-boot (5.9)
Machine is a new PC Engines apu.1d with / on the a 4GB SD card. Was yanked off the table and had its power pulled. When rebooting / was deemed uncheckable and when doing so myself the kernel paniced. # cat /etc/fstab 85ee1fbed3aff0b6.a / ffs ro,noatime 1 0 85ee1fbed3aff0b6.d /usr ffs ro,softdep,noatime,nodev 1 0 2bd0427459dce093.a /altroot ffs xx 1 0 2bd0427459dce093.d /tmp ffs rw,softdep,noatime,nodev,nosuid 1 2 2bd0427459dce093.e /var ffs rw,softdep,noatime,nodev,nosuid 1 2 2bd0427459dce093.b none swap sw swap /dev mfs rw,nosuid,noexec,-P=/proto/dev,-b=4096,-f=512,-i=512,-s=2048 0 0 Console output follows from start to crash. Let me know if anything's missing. fsck reported the filesystem as modified but I've yet to boot from or reformat the card which caused the failure (except for boot -s to grab the fstab above). cannot open hd0a:/etc/random.seed: No such file or directory booting hd0a:/bsd: 6882804+2174256+267272+0+647168 [72+577368+384321]=0xa6ef68 entry point at 0x1001000 [7205c766, 3404, 24448b12, 20a304] [ using 962408 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2016 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error ff real mem = 4245995520 (4049MB) avail mem = 4113113088 (3922MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus 4 (PBR7) acpiprt6 at acpi0: bus 6 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0: bus -1 (PE23) acpiprt10 at acpi0: bus 0 (PCI0) acpiprt11 at acpi0: bus 5 (PIBR) acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:88 rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:89 rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:8a rgephy2 at re2 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb3 at pci0 dev 7 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci4 at ppb3 bus 4 athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 19 athn0: AR
Reproducable but intermittent: CVS fails to check out large files on amd64
>Synopsis: CVS fails to check out large files on amd64, sometimes >Category: user amd64 >Environment: System : OpenBSD 5.8 Details : OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: When checking out large files using a local CVS server, the final 'ok' line is not printed about 2/3 of the time and the checkout subsequently fails. I heard through the grapevine (aka. #openbsd on freenode) that this is a known problem affecting amd64. Hopefully some diagnosis can shed some light on it. Personally I don't relish the thought of digging into cvs' source. >How-To-Repeat: (To forestall comments on the wisdom of doing things like this as root, this whole process was performed on a VM created specifically for the purpose. Security considerations are moot.) Given a cvsync of the openbsd tree at /root/openbsd/cvs: # cat input Root /root/openbsd/cvs Valid-responses ok error Valid-requests Mode M Mbinary E Checked-in Created Updated Merged Removed valid-requests UseUnchanged Argument -N Argument -P Argument -kk Argument -r Argument 1.27 Argument -- Argument xenocara/xserver/ChangeLog Directory . /root/openbsd/cvs co # grep . input | cvs server | tail -n1 ok < OR > 3297. Xterm patch #119 (#3335, Thomas Dickey). # Running (a variant on) the above 1000 times revealed the following: # sed 's/^[0-9]*: //' < cumul | sort | uniq -c 696 3297. Xterm patch #119 (#3335, Thomas Dickey). 304 ok So it does appear to be just the final 'ok' which is missing (or the 696 bad runs would be a mis-match of different responses). nb. I don't know which parts of the input are necessary but it doesn't look like it would matter anyway. It's extracted from what git-cvsimport sends to the cvs server. >Fix: The best I've got is to keep retrying until the last line is 'ok'. This sucks for obvious reasons. dmesg: OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056956416 (1007MB) avail mem = 1021083648 (973MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfd9c0 (10 entries) bios0: vendor Bochs version "Bochs" date 01/01/2007 bios0: Bochs Bochs acpi0 at bios0: rev 0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC HPET SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 1.1.2, 3503.87 MHz cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT,HV,NXE,LONG,LAHF cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 999MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 1 acpihpet0 at acpi0: 1 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 1 int 11 piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 1 int 10 iic0 at piixpm0 iic0: addr 0x18 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00= 01= 02= 03= 04= 05= 06= 07= iic0: addr 0x1a 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00= 01= 02= 03= 04= 05= 06= 07= iic0: addr 0x29 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00= 01= 02= 03= 04= 05= 06= 07= iic0: addr 0x2b 00=00 01=00 02=00 03=00 04=00 05=00 06=00 07=00 08=00 words 00=00
Re: Reproducable but intermittent: CVS fails to check out large files on amd64
Stuart Henderson writes: > On 2016/02/01 12:44, cho...@jtan.com wrote: > > >Synopsis: CVS fails to check out large files on amd64, sometimes > > >Category: user amd64 > > >Environment: > > System : OpenBSD 5.8 > > Details : OpenBSD 5.8 (GENERIC.MP) #1236: Sun Aug 16 02:31:04 MDT > > 2015 > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > Architecture: OpenBSD.amd64 > > Machine : amd64 > > >Description: > > When checking out large files using a local CVS server, the > > final 'ok' line is not printed about 2/3 of the time and the > > checkout subsequently fails. > > > > I heard through the grapevine (aka. #openbsd on freenode) that > > this is a known problem affecting amd64. Hopefully some > > diagnosis can shed some light on it. Personally I don't relish > > the thought of digging into cvs' source. > > Not seeing this here but you may be running into memory limits. > See dlimit in CVSROOT/config. If it's memory limits, it's not anything caused by dlimit, which complains correctly when it's reached (I think - see 8k). For reasons I don't care to find out right now, the dlimit in the originally sync'd version is 64*1024-1. I've kept up the pattern. No dlimit line without:# for k in `jot 100 1`; do grep . < in | cvs server | tail -n1; done | sort | uniq -c without: 11 3297. Xterm patch #119 (#3335, Thomas Dickey). without: 89 ok dlimit=262143 256k:# for k in `jot 100 1`; do grep . < in | cvs server | tail -n1; done | sort | uniq -c 256k: 17 3297. Xterm patch #119 (#3335, Thomas Dickey). 256k: 83 ok dlimit=65535 64k:# for k in `jot 100 1`; do grep . < in | cvs server | tail -n1; done | sort | uniq -c 64k: 16 3297. Xterm patch #119 (#3335, Thomas Dickey). 64k: 84 ok dlimit=32767 32k:# for k in `jot 100 1`; do grep . < in | cvs server | tail -n1; done | sort | uniq -c 32k: 13 3297. Xterm patch #119 (#3335, Thomas Dickey). 32k: 87 ok dlimit=8191 8k:# grep . < in | cvs server 8k:Valid-requests Root Valid-responses valid-requests Repository Directory Max-dotdot Static-directory Sticky Checkin-prog Update-prog Entry Kopt Checkin-time Modified Is-modified UseUnchanged Unchanged Notify Questionable Case Argument Argumentx Global_option Gzip-stream wrapper-sendme-rcsOptions Set expand-modules ci co update diff log rlog add remove update-patches gzip-file-contents status rdiff tag rtag import admin export history release watch-on watch-off watch-add watch-remove watchers editors init annotate rannotate noop version 8k:ok 8k:E Terminated with fatal signal 11 8k:E Core dumped; preserving /tmp/cvs-serv25310 on server. 8k:E CVS locks may need cleaning up. 8k:error Cheers, Matthew
athn PCI card (AR9281) AP not found by scan on some devices
>Synopsis: athn PCI card (AR9281) AP not found by scan on some devices >Category: wifi driver? >Environment: System : OpenBSD 5.8 Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Architecture: OpenBSD.amd64 Machine : amd64 >Description: /etc/hostname.athn0 contains: inet 192.168.42.1 255.255.255.0 mediaopt hostap chan 56 nwid Testies wpakey insecure Most computers (2 Androids and a linux laptop with a broadcom 43xx device) cannot see the AP when scanning for networks although my main laptop - a Lenovo T410 with an Intel "Ultimate-N 6300 AGN" (in Linux) - can on some channels (eg. 56 works, 1 (the default) and 2 don't). Apart from that, various different channel, media and mediaopt settings made no difference. The hardware seems to not be a problem - it's brand new and The Other OS running hostapd could be found by all 4 devices. Of course it's quite possible that the software is working as it should and I've configured it incorrectly, in which case the bug is incomplete documentation if it's not just pebkac. ifconfig athn0 shows: athn0: flags=8843 mtu 1500 lladdr 04:f0:21:17:45:95 priority: 4 groups: wlan media: IEEE802.11 autoselect hostap (autoselect mode 11a hostap) status: active ieee80211: nwid Testies chan 56 bssid 04:f0:21:17:45:95 wpakey 0xa3740805d47fadbe51401073cdc11764a052ada555d4d19b3274e8aa3c48fdba wpaprotos wpa1,wpa2 wpaakms psk wpaciphers tkip,ccmp wpagroupcipher tkip inet 192.168.42.1 netmask 0xff00 broadcast 192.168.42.255 >How-To-Repeat: Virgin 5.8 installation on a PC Engines apu1d4 with a wle200nx. /etc/hostname.athn0 created as above (and fiddle with media* settings to no avail). Scan for wifi networks on other devices. >Fix: Yes please. The machine is not anywhere close to production yet so I'm happy to poke at it in weird ways to facilitate debugging. dmesg: OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC RTC BIOS diagnostic error ff real mem = 4245995520 (4049MB) avail mem = 4113465344 (3922MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.14 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus 4 (PBR7) acpiprt6 at acpi0: bus 6 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0: bus -1 (PE23) acpiprt10 at acpi0: bus 0 (PCI0) acpiprt11 at acpi0: bus 5 (PIBR) acpicpu0 at acpi0: !C2(0@100 io@0x841), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:88 rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:89 rgephy1 at re1 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb2 at pci0 dev 6 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci3 at ppb2 bu
Re: athn PCI card (AR9281) AP not found by scan on some devices
Stefan Sperling writes:
> On Sun, Mar 06, 2016 at 10:22:17PM +0200, cho...@jtan.com wrote:
> > >Synopsis: athn PCI card (AR9281) AP not found by scan on some devices
> > >Category: wifi driver?
> > >Environment:
> > System : OpenBSD 5.8
> > Details : OpenBSD 5.8 (GENERIC) #1170: Sun Aug 16 02:26:00 MDT 2015
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/comp
> ile/GENERIC
> >
> > Architecture: OpenBSD.amd64
> > Machine : amd64
> > >Description:
> > /etc/hostname.athn0 contains:
> > inet 192.168.42.1 255.255.255.0
> > mediaopt hostap chan 56
>
> I'd recommend sticking to 11a "indoor channels" 36, 38, 40, 42, 44,
> and 48, unless you have a good reason to do otherwise.
>
> In most countries, channel 50 and above ("outdoor channels") require DFS
> support for proper operation, which OpenBSD doesn't provide.
> Many client devices won't support any of the "outdoor" channels.
I didn't even choose one until I found out that it didn't work. I'm
right in the middle of nowhere so I've not paid attention to the
regulatory settings yet. Choosing the right settings would have happened
right after I'd verified basic functionality on.
> > The hardware seems to not be a problem - it's brand new and The
> > Other OS running hostapd could be found by all 4 devices.
>
> Which channel does the other os use?
I ripped off a hostapd.conf that I found somewhere online. It sets the
country code to US and channel to 2.
I've been poking at it (and little more than poking in ignorance) and a
few more symptoms have cropped up:
* If I include any chan setting in hostname.athn0 and reboot, I can't
set the chan at runtime to anything between 1 and 11 though can to
(some) values >11: ifconfig: SIOCS80211CHANNEL: Invalid argument
Some values result in my 'good' laptop being able to find the AP and
some don't. Booting with anything <= 11 can't be seen; 36, 56 and 44
can.
* If I remove the chan option from hostname.athn0 ifconfig shows that
chan 1 was selected but nothing (not even my 'good' laptop) finds the
network. However I can now change the chan at runtime, and doing so
allows (all) the other devices to find the AP, even after switching
back to chan 1.
I don't know what either of these things means, but they're odd.
I would rather perform more rigorous tests but I don't know which tests
would be meaningful and which would be a massive waste of time so all
I'm doing now is playing with it.
Matthew
Re: athn PCI card (AR9281) AP not found by scan on some devices
Stefan Sperling writes: > On Sun, Mar 06, 2016 at 10:22:17PM +0200, cho...@jtan.com wrote: > > >Description: > > /etc/hostname.athn0 contains: > > inet 192.168.42.1 255.255.255.0 > > mediaopt hostap chan 56 > > nwid Testies > > wpakey insecure > > Note that setting an address puts the interface UP implicitly. > So you'll want to configure all the wireless bits first, and set the > address afterwards! Otherwise, your wireless settings will race the > automatic mode/channel selection I described in my other reply from > a few minutes ago. > > So try this something like this instead: > > media autoselect mediaopt hostap mode 11g > chan 1 > inet 192.168.42.1 255.255.255.0 > > or: > > media autoselect mediaopt hostap mode 11a > chan 36 > inet 192.168.42.1 255.255.255.0 That, and the process for switching mode at runtime in your other mail, clears things up a lot and the AP seems to be working as it should now. More testing will ensue. Note that I got the order of configuration lines directly from athn(4) and some other wireless driver manpages also have examples with inet lines prior to media settings. It does seem that the control tools will try and do things which are impossible but it looks like documentation can clear most of that up and at least they're easier to fix than mysterious driver bugs happening 2 continents away, which thankfully doesn't seem to be the case. Thanks, Matthew
Terrible athn performance after upgrade to 6.2
>Synopsis: Terrible athn performance after upgrade to 6.2 >Category: kernel >Environment: System : OpenBSD 6.2 Details : OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct 3 21:22:29 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: I have two PC Engines apu2c4 devices with a wle200nx (mini-PCI "Atheros AR9281"). One has been happily running 6.0 for a while and I decided to put 6.2 on the other (a fresh install) in the hope of switching them and ideally taking advantage of the new 11n support. My laptop, running Linux 4.8.8 with 'Intel Corporation Centrino Advanced-N 6230 [Rainbow Peak] (rev 34)', could not connect at all when 11n support was enabled. I suspect this is due to the need for WME which I haven't looked into beyond noting that it's a thing. With 'mode 11g' in hostname.athn0 I can connect and obtain an IP but performance is horrifically bad. Ping times between the laptop and router are highly erratic, bouncing between 4ms and 820ms or more. Very few responses were <20ms. Passing real traffic through basically grinds the card to a halt. Ping times with the 6.0 box average about 2ms and it passes traffic happily. I tried each OS variant in each box to rule out hardware differences. I did not have any other wifi-capable client machines available to test with. I have another box happily in service so I can perform whatever tests on this one are necessary or useful. >How-To-Repeat: /etc/hostname.athn0: description "public/wifi" media autoselect mediaopt hostap mode 11g nwid Test wpakey insecure up >Fix: Put the box with 6.0 back into service. dmesg: OpenBSD 6.2 (GENERIC.MP) #134: Tue Oct 3 21:22:29 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4245995520 (4049MB) avail mem = 4110290944 (3919MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.13 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: TSC frequency 1000131750 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus 4 (PBR7) acpiprt6 at acpi0: bus 6 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0: bus -1 (PE23) acpiprt10 at acpi0: bus 0 (PCI0) acpiprt11 at acpi0: bus 5 (PIBR) acpicpu0 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@100 io@0x841), C1(@1 halt!), PSS acpibtn0 at acpi0: PWRB cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 14h Host" rev 0x00 ppb0 at pci0 dev 4 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:40:0a:a8 rgephy0 at re0 phy 7: RTL8169S/8110S/8211 PHY, rev. 4 ppb1 at pci0 dev 5 function 0 "AMD AMD64 14h PCIE" rev 0x00: msi pci2 at ppb1 bu
Trivial documentation bug in rc.d(8)
The description of the -d flag states that it prevents the redirection of stdin to /dev/null but it should say stdout. Matthew
