Re: flaky network connection after 6.1 upgrade
I tried channels 2, 5, and 10 with no better luck. Could you explain what made you think interference? My computer and AP have been in their current spots for months with no issue, and no new sources of come around to the best of my knowledge. I had no networking trouble with 6.0 and booting Linux from a CD is likewise without issue. My BSD system will fail to ping my AP with "sendmsg: Host is down", yet I can bring a laptop to that same chair and have no problem. On Mon, Apr 17, 2017 at 2:35 AM, Stefan Sperling wrote: > On Sun, Apr 16, 2017 at 05:31:58PM -0500, Colton Lewis wrote: >> Stephan, >> >> > I would guess you are running into some issue with 802.11n support which >> > was added to this driver in 6.1. You should be able to restore the previous >> > behaviour with: ifconfig athn0 mode 11g >> >> Your hunch was almost right. 11g had the same problem, but 11b worked >> as expected. > > Looks like too much interference from other networks (try a different channel) > or too large distance from the AP. > >> Attached is the info you asked for. >> 17:05:52.707822 802.11 flags=0<>: beacon, >> caps=12021, ssid (Stormlord), >> rates 1M* 2M* 5M 11M 18M 24M 36M 54M, ds (chan 9), tim 0x0102, erp 0x04, >> xrates 6M 9M 12M 48M, rsn 0x010fac04010fac04010fac020c00, 6 >> stations, 4% utilization, admission capacity 0us/s, 70:5 0x320801, >> htcaps=<20MHz,LDPC,SGI@20MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 7935,A-MPDU max >> 65535,A-MPDU spacing 4.00us,RxMCS 0xff00>, htop=<20MHz chan >> 9,STA chanw 20MHz,RIFS,htprot none,non-greenfield STA,basic MCS set >> 0x>, 74:14 0x14000a002c01c800140005001900, 127:8 >> 0x05000840, vendor 0x00146c00, vendor >> 0x0050f204104a0001101044000102104700102a1ecc3b122c82e30b19d406361deb33103c0001031049000600372a000120, >> vendor 0x00904c0408bf0cb259820feaffeaffc005000900c3020002, >> vendor 0x0010180206001c, vendor >> 0x0050f2020101880003a427a44243bc0062326600, > chan 9, 11n, sig 13dBm, antenna 1> >> athn0: flags=8843 mtu 1500 >> lladdr 00:15:af:cd:f2:4f >> index 2 priority 4 llprio 3 >> groups: wlan egress >> media: IEEE802.11 autoselect (HT-MCS1 mode 11n) >> status: active >> ieee80211: nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm wpakey >> wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher >> ccmp >> inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255 >> nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm HT-MCS23 >> privacy,short_slottime,radio_measurement,wpa2 >> inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255 >>
Re: Is randomizing UID/GUID would make sense?
> > Correct that it's not designed for that. But we looked into this a lot > > when introducing srand_determinstic(3). > > Are there any applications out there that explicitly require the PRNG > to be deterministic? It doesn't make sense to have that kind of thing > there for minute corner cases, such as if someone decides it's a > brilliant idea to use the contents of a deterministic PRNG as a hash. It's really unfortunate that we aren't running an open source project and making available all the source for the tool called grep. So that it can be studied, rather than questioned by an idiot uninterested in the exercise of selflearning. Maybe those source files even have commit logs - even better PUBLIC COMMIT LOGS - which might explain the rationale! No, that's unlikely. So let's just yak about it, right? Rest of your email deleted because what's the point
Re: Is randomizing UID/GUID would make sense?
On Sun, 16 Apr 2017 12:01:48 + (UTC)
Stuart Henderson wrote:
> On 2017-04-15,
> wrote:
> > OpenBSD still randomizes PIDs, but I don't see the point these days:
> > https://security.stackexchange.com/questions/88692/do-randomized-pids-bring-more-security/89961
> >
>
> 'Protect against PID prediction vulnerabilities affecting mostly
>software which use the PID value to generate temporary file names.
>This was a common concern at that time, but today I think it would
>be quite rare to encounter production-level software still not
>using a proper method.'
>
> Between some of the less common software that is still used, and
> various sysadmin shell scripts people might have around, I don't
> think it's all that unlikely.
>
> 'A PID is not designed to seed a random number generator or generate
>session ID or cookies.'
>
> Correct that it's not designed for that. But we looked into this a lot
> when introducing srand_determinstic(3).
Are there any applications out there that explicitly require the PRNG
to be deterministic? It doesn't make sense to have that kind of thing
there for minute corner cases, such as if someone decides it's a
brilliant idea to use the contents of a deterministic PRNG as a hash.
> It's still *very* common to
> seed based on pid, time, or a combination of the two, either as the
> main method, or as a fallback if /dev/urandom can't be opened (as may
> happen as a result of FD exhaustion [possibly attacker-triggered] or
> in a chroot jail).
>
> t = (unsigned char)getpid();
> while (i < size) {
> do {
> buf[i] = ((unsigned char)rand()) ^ t;
> } while (buf[i] == 0);
> t = buf[i++] << 1;
>
> The srand_deterministic change makes this less of a problem on OpenBSD
> for programs using rand(), but sometimes programs have their own PRNG
> and aren't seeding it nicely, any extra protection we can give these
> seems useful.
Surely looking up a pointer to some have O(n) or O(log n) worst case,
since it has to traverse the list? Quite close for a list full of
random PIDs.
Surely this creates a bit more complacency, "Oh the OS generates random
PIDs anyway, let's use that to seed our RNG." Hopefully such practices
is abolished in favour of more robust methods.
Not suggesting the random PIDs are a bad thing, but I am curious as to
how much extra code and cost is needed to implement this over a
"sequential" PID that's just an index to an array.
>
> 'As a general preventive measure, "If something can be random, make
> it random."'
>
> With OpenBSD's random subsystem it is intentional to have many
> consumers. See http://www.openbsd.org/papers/hackfest2014-arc4random/.
> The idea is to slice up the chacha20 (formerly arc4) stream as much
> as possible.
>
I do like the way this is implemented, and it is well integrated within
the system too.
Shame the function was called arc4random() and not sorandom() or
something. Little too late to change it now though I guess.
Re: Does CARP need Layer 2 ?
> On 18 Apr 2017, at 03:54, Bob Jones > wrote: > > Hi, > > Looking at the docs, unlike pfsync, sasyncd and everything else, you > seem to be unable to define a "different" interface to CARP for the > purposes of monitoring. Everything seems to need to go over the one > carpdev. > > My question arises is because I have a couple of OpenBSD units due to > be plugged into upstream router ports (direct patch, not via > intermediate switch). > > Obviously for most things, OSPF and BGP will take care of redundancy. > But for the purposes of VPN failover, I would like to use CARP on my > "external" interfaces, but as far as my interpretation of the docs go, > CARP protocol won't work over Layer 3 ? that's correct. > Could someone provide further insight into whether my interpretation > is correct, and whether I have any other options available ? I don't > really want to go adding a layer 2 switch on my side because that just > introduces extra point of failure. off the top of my head, you have two paths you could take. firstly, you could advertise the vpn service as the same ip addresses bound to loopback (lo(4)) interfaces on each of the hosts. ie, a cheap and cheerful anycast setup. bgp as your routing protocol should work well for this if you're interested in an active/passive setup. the second option could be to set up a l2 medium between your hosts, specifically, you can set up etherip tunnels between them and land your carp interface on that. just some ideas. cheers, dlg
Re: xenodm autologin
I have not tried it but have a look at http://man.openbsd.org/xenodm.1 DisplayManager.DISPLAY.autoLogin This resource specifies the name of an user that will be logged in automatically, without displaying the xlogin widget. You find more things there. Am 18. April 2017 05:11:27 MESZ schrieb Tuyosi T : >hi all . > >it is not difficult to start xfce4 via xenodm . >is there anyone who can succeed autologin via xenodm ? >--- >regards
Re: [vmm] SSL read error: read failed: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt
On Mon, Apr 17, 2017 at 10:29:31AM +, Paul Chakravarti wrote: > >On 2017-04-17, David Coppa wrote: > >> On Sun, Apr 16, 2017 at 11:17 AM, Paul Chakravarti > >> wrote: > >>> Hello, > >>> > >>> I am trying out vmm on 6.1 and can setup/boot vm etc. however when I try > >>> to > >>> download a large file using SSL I consistenetly get the following error: > >>> > SSL read error: read failed: error:06FFF064:digital envelope > >>> routines:CRYPTO_internal:bad decrypt > >>> > >>> This occasionally (but not always) correlates with the following message > >>> in > >>> the vmd log: > >>> > vionet queue notify - no space, dropping packet > >>> > >>> Strangely non-SSL and smaller SSL downloads seem to work ok (see below). > >>> > >>> Originally spotted this using installer but can recreate from shell. > >>> > >>> Any ideas? > >> > >> See http://marc.info/?l=openbsd-misc&m=148858752003261 > >> > >> It's a known problem. > > > >I've seen corruption with non-SSL network transfers too. It's just more > >obvious with SSL because in that case the session gets killed, whereas > >otherwise the corrupt input is silently accepsilently accepted. > > > > It does seem more prevalent with SSL transfers - the SHA256s of the files > transferred vis http are correct (over several transfers) while there is > always an always an error on the https transfers from the same site. > > Interestingly the problem only seems to come up on 'fast' connections - > possibly something CPU related (cpu load exacerbated by SSL?). I'm still not > sure why the TCP layer doesn't sort out the dropped packets though. > > # ftp -Vo- https://ftp.openbsd.org/pub/OpenBSD/6.1/amd64/bsd | sha256 > > 440311305f27f0efcfcc88116299a21cb3f890fb91ee611c2a79cc9163e8fceb > # > # > # ftp -Vo- https://mirrorservice.org/pub/OpenBSD/6.1/amd64/bsd | sha256 > ftp: SSL read error: read failed: error:06FFF064:digital envelope > routines:CRYPTO_internal:bad decrypt I think I know what's going on, I just haven't had time to sort through it yet. I don't think it's related to the network stack, FWIW. -ml
Re: xenodm autologin
in my case ３）cat .xsession startxfce4 ４）cat /etc/rc.conf.local xenodm_flags= i want to do autologin such as slim . but slim is too old tu use . regards
Re: [vmm] SSL read error: read failed: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt
>On 2017-04-17, David Coppa wrote: >> On Sun, Apr 16, 2017 at 11:17 AM, Paul Chakravarti wrote: >>> Hello, >>> >>> I am trying out vmm on 6.1 and can setup/boot vm etc. however when I try to >>> download a large file using SSL I consistenetly get the following error: >>> SSL read error: read failed: error:06FFF064:digital envelope >>> routines:CRYPTO_internal:bad decrypt >>> >>> This occasionally (but not always) correlates with the following message in >>> the vmd log: >>> vionet queue notify - no space, dropping packet >>> >>> Strangely non-SSL and smaller SSL downloads seem to work ok (see below). >>> >>> Originally spotted this using installer but can recreate from shell. >>> >>> Any ideas? >> >> See http://marc.info/?l=openbsd-misc&m=148858752003261 >> >> It's a known problem. > >I've seen corruption with non-SSL network transfers too. It's just more >obvious with SSL because in that case the session gets killed, whereas >otherwise the corrupt input is silently accepsilently accepted. > It does seem more prevalent with SSL transfers - the SHA256s of the files transferred vis http are correct (over several transfers) while there is always an always an error on the https transfers from the same site. Interestingly the problem only seems to come up on 'fast' connections - possibly something CPU related (cpu load exacerbated by SSL?). I'm still not sure why the TCP layer doesn't sort out the dropped packets though. # ftp -Vo- https://ftp.openbsd.org/pub/OpenBSD/6.1/amd64/bsd | sha256 440311305f27f0efcfcc88116299a21cb3f890fb91ee611c2a79cc9163e8fceb # # # ftp -Vo- https://mirrorservice.org/pub/OpenBSD/6.1/amd64/bsd | sha256 ftp: SSL read error: read failed: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt
Re: xenodm autologin
On 04/17/17 22:11, Tuyosi T wrote: hi all . it is not difficult to start xfce4 via xenodm . is there anyone who can succeed autologin via xenodm ? --- regards You are probably missing .xsession which should be a symlink to .xinitrc so possibly: ln -s ~/.xinitrc ~/.xsession I haven't used xfce4 in a while, but I'm guessing .xinitrc should have something like: exec startxfce4
xenodm autologin
hi all . it is not difficult to start xfce4 via xenodm . is there anyone who can succeed autologin via xenodm ? --- regards
mousedrv(4x) man vs environment under X
The mousedrv(4x) man page says Option "ButtonMapping" "N1 N2 [...]" Specifies how physical mouse buttons are mapped to logical buttons. Physical button 1 is mapped to logical button N1, physical button 2 to N2, and so forth. This enables the use of physical buttons that are obscured by ZAxisMapping. Default: "1 2 3 8 9 10 ...". The code in mouse.c for that initialization is identical in FreeBSD and OpenBSD. Under FreeBSD "xinput get-button-map" shows 1 2 3 8 9 10 Under OpenBSD somewhere between the mousedrv code and the environment when X is started leaves the mapping "1 2 3 4 5 6..." This is on a 6.0 freshly upgraded to 6.1 with an empty xorg.conf.d, no .xinitrc This behavior, of course, perplexes the user. Trying to xmodmap physical button 4 (supposedly now button 8) to a middle button fails. xmodmap physical 4 to middle button does work. I -think- the FreeBSD behavior is correct, since the usage of button events 4-7 is very murky given the universe of wildly different pointing devices. Is there a configuration file somewhere I overlooked? thanks Geoff Steckel
softraid mirror & large drives (3T)
Hello, I'm planning on replacing an old fileserver that has a single 1T drive with something a little newer having 3T of space. I have two 3T drives and have installed OpenBSD 6.0 to both as a softraid mirror. Works well and I simulated a drive failure by shutting it down, removing a drive, and rebooting. The drive has been re-installed and it is now rebuilding the mirror. After 17 hours it is 24% complete, so it'll be about three days to complete. The system is: AMD E2-3200 2.40 GHz 4G RAM 2 x 3T Seagate Barracuda 7200rpm SATA With this much disk space, should I be looking at another way of achieving data redundancy? The goal is to increase redundancy of the data and the mirror would be periodically backed up to another server in a different building. My only concern here is the suitability of the softraid mirror for a large filesystem. I've thought of using the second drive as a backup and rsync'ing it nightly, but then failure of the primary drive would mean more downtime before it's operational again. A long rebuild time isn't a major problem; just want to make sure I'm not overlooking a more sensible option. FWIW, I used the following info to get set up: https://www.openbsd.org/faq/faq14.html#softraidDI http://openbsd-archive.7691.n7.nabble.com/Large-3TB-HDD-support-td95308.html Thanks, -- Ian
Re: Partition Input/output error
On Mon, Apr 17, 2017 at 8:54 PM, Evgeniy Sudyr wrote: > Yes, sorry my bad > # dd if=/dev/rsd1a of=/dev/null bs=1m count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 6.088 secs (172228383 bytes/sec) > > Unfortunately this not solves mount problem. > > Also tried mount to other mount point: > > # mount > /dev/sd0a on / type ffs (local) > /dev/sd1a on /tmp/1 type ffs (local) > > # ls -lah /tmp/1 > ls: /tmp/1: Input/output error > > -- > Evgeniy > > > > -- > -- > With regards, > Eugene Sudyr > The disklabel on the drive doesn't seem right to me: ># disklabel sd1 ... >16 partitions: >#size offset fstype [fsize bsize cpg] > a: 34359787520 4.2BSD 8192 65536 1 # /open > c: 34359787520 unused The offset for both a and c is 0. I would try re-initialising the drive with fdisk and creating a new disklabel.
Re: Python and wxallow in 6.1
On 2017-04-17, Steve Shockley wrote: > After upgrading my OpenNMS box to 6.1 (from 6.0) I noticed that the > polling scripts weren't running. I tracked it down to needing wxallow > on /usr/local so python2.7 would run (otherwise "access denied"). I > think python2.7 wasn't marked as needing wxallow, or I don't know how to > check. Is this expected? The python interpreter binaries are marked as needing w+x. They don't actually need w+x themselves but you might load a module which needs it (webkit, maybe others). The kernel enforces that such binaries can only be run from a wxallow filesystem. > Also, I didn't see anything in syslog about it. Is there a way to > enable logging when a program attempts to run but can't? The output > message was just "access denied". Not without patching the kernel - it's not logged.
Re: Partition Input/output error
Yes, sorry my bad # dd if=/dev/rsd1a of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 6.088 secs (172228383 bytes/sec) Unfortunately this not solves mount problem. Also tried mount to other mount point: # mount /dev/sd0a on / type ffs (local) /dev/sd1a on /tmp/1 type ffs (local) # ls -lah /tmp/1 ls: /tmp/1: Input/output error -- Evgeniy On Mon, Apr 17, 2017 at 5:03 PM, Sterling Archer wrote: > > > On Mon, Apr 17, 2017 at 4:22 PM, Evgeniy Sudyr > wrote: > > snip > >> # dd if=/dev/sd1a of=/dev/null bs=1m >> dd: /dev/sd1a: Input/output error >> 0+0 records in >> 0+0 records out >> 0 bytes transferred in 0.012 secs (0 bytes/sec) >> > > Use /dev/rsd1a > > -- -- With regards, Eugene Sudyr
Re: Python and wxallow in 6.1
On Mon, Apr 17, 2017 at 08:01:29AM -0400, Steve Shockley wrote: > After upgrading my OpenNMS box to 6.1 (from 6.0) I noticed that the polling > scripts weren't running. I tracked it down to needing wxallow on /usr/local > so python2.7 would run (otherwise "access denied"). I think python2.7 > wasn't marked as needing wxallow, or I don't know how to check. Is this > expected? > > Also, I didn't see anything in syslog about it. Is there a way to enable > logging when a program attempts to run but can't? The output message was > just "access denied". > > Thanks. Is this python itself, or some libraries used by your script ?...
Does CARP need Layer 2 ?
Hi, Looking at the docs, unlike pfsync, sasyncd and everything else, you seem to be unable to define a "different" interface to CARP for the purposes of monitoring. Everything seems to need to go over the one carpdev. My question arises is because I have a couple of OpenBSD units due to be plugged into upstream router ports (direct patch, not via intermediate switch). Obviously for most things, OSPF and BGP will take care of redundancy. But for the purposes of VPN failover, I would like to use CARP on my "external" interfaces, but as far as my interpretation of the docs go, CARP protocol won't work over Layer 3 ? Could someone provide further insight into whether my interpretation is correct, and whether I have any other options available ? I don't really want to go adding a layer 2 switch on my side because that just introduces extra point of failure. Thanks ! Bob
Re: Partition Input/output error
On Mon, Apr 17, 2017 at 4:22 PM, Evgeniy Sudyr wrote: snip # dd if=/dev/sd1a of=/dev/null bs=1m > dd: /dev/sd1a: Input/output error > 0+0 records in > 0+0 records out > 0 bytes transferred in 0.012 secs (0 bytes/sec) > > Use /dev/rsd1a
Partition Input/output error
I have OpenBSD 6.1 DomU installed on Debian Dom0 host. Today I found issue with one of partitions (where mirror files were). It says Input/output error when I'm trying access it after mount. However fsck does not complain: # fsck_ffs -f /dev/sd1a ** /dev/rsd1a ** File system is already clean ** Last Mounted on /open ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 725254 files, 94046365 used, 119012257 free (213185 frags, 14849884 blocks, 0.1% fragmentation) And dd gives me an error: # dd if=/dev/sd1a of=/dev/null bs=1m dd: /dev/sd1a: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.012 secs (0 bytes/sec) I tried to copy with dd on Dom0 and it was successful. Dom0 config (I'm using LVM logical volumes for hda and hdb): cat /etc/xen/mirror.openbsd.org.cfg builder = "hvm" memory = 2048 vcpus = 2 name = "mirror.openbsd.org" disk = [ '/dev/xen_domU/mirror.openbsd.org-disk,raw,hda,w', '/dev/xen_domU/mirror.openbsd.org-storage,raw,hdb,w'] boot = "c" # Boot to hard disk image vif = [ mac=00:17:3E:50:FD:99,bridge=xenbr0' ] usbdevice = 'tablet' vnc = 1 stdvga=1 videoram=16 # cat /etc/fstab 9c43dedec3141fca.b none swap sw 9c43dedec3141fca.a / ffs rw 1 1 9cee670113714c9d.a /open ffs rw 1 1 # ls -lah /open/ total 8 drwxr-xr-x 2 root wheel 512B Apr 3 2016 . drwxr-xr-x 15 root wheel 512B Apr 17 15:15 .. # vi /etc/fstab # disklabel sd0 # /dev/rsd0c: type: ESDI disk: ESDI/IDE disk label: QEMU HARDDISK duid: 9c43dedec3141fca flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 652 total sectors: 10485760 boundstart: 64 boundend: 10474380 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 8401920 64 4.2BSD 2048 16384 1 # / b: 2072396 8401984swap# none c: 104857600 unused # disklabel sd1 # /dev/rsd1c: type: ESDI disk: ESDI/IDE disk label: QEMU HARDDISK duid: 9cee670113714c9d flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 213879 total sectors: 3435978752 boundstart: 0 boundend: 3435978752 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 34359787520 4.2BSD 8192 65536 1 # /open c: 34359787520 unused # mount /open/ # ls -lah /open/ ls: /open/: Input/output error # umount /open umount: /open: Input/output error # ls -lah / ls: open: Input/output error total 60720 drwxr-xr-x 15 root wheel 512B Apr 17 15:15 . drwxr-xr-x 15 root wheel 512B Apr 17 15:15 .. -rw-r--r-- 1 root wheel 578B Apr 2 2016 .cshrc -rw-r--r-- 1 root wheel 468B Apr 2 2016 .profile drwxr-xr-x 2 root wheel 512B Apr 1 22:38 altroot drwxr-xr-x 2 root wheel 1.0K Apr 1 22:38 bin -rw-r--r-- 1 root wheel 84.6K Apr 17 15:15 boot -rw-r--r-- 1 root wheel 10.3M Apr 17 15:10 bsd -rw-r--r-- 1 root wheel 9.0M Apr 17 15:10 bsd.rd -rw-r--r-- 1 root wheel 10.2M Apr 17 15:10 bsd.sp drwxr-xr-x 3 root wheel 19.5K Apr 17 15:57 dev drwxr-xr-x 25 root wheel 2.0K Apr 17 15:20 etc drwxr-xr-x 5 root wheel 512B Apr 1 22:38 home drwx-T 2 root wheel 2.0K Apr 17 14:35 lost+found drwxr-xr-x 2 root wheel 512B Apr 1 22:38 mnt drwx-- 7 root wheel 512B Apr 1 22:38 root drwxr-xr-x 2 root wheel 1.5K Apr 1 22:38 sbin lrwxrwx--- 1 root wheel11B Apr 1 22:38 sys -> usr/src/sys drwxrwxrwt 6 root wheel 512B Apr 17 16:00 tmp drwxr-xr-x 16 root wheel 512B Apr 1 23:05 usr drwxr-xr-x 23 root wheel 512B Apr 1 23:05 var # mount /dev/sd0a on / type ffs (local) /dev/sd1a on /open type ffs (local) # dmesg OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2113925120 (2015MB) avail mem = 2045243392 (1950MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xfc001000 (12 entries) bios0: vendor Xen version "4.8.1-pre" date 01/23/2017 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2793.35 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,HTT,SSE3,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: api
Re: What does it mean this error when I try install a package?
On Mon, Apr 17, 2017 at 09:37:56PM +1000, Steven McDonald wrote: > On Mon, 17 Apr 2017 11:02:37 + > "C. L. Martinez" wrote: > > > pkg_add -v python-2.7 > > There is no package called python-2.7. The package you want is called > python-2.7.13p0. You have a few options: > > 1. pkg_add python, then select the version you want. > 2. pkg_add python-2.7.13p0 > 3. pkg_add -z python-2.7 (fuzzy matching, see pkg_add(1)) ^ or use 'python%2.7' j.
Python and wxallow in 6.1
After upgrading my OpenNMS box to 6.1 (from 6.0) I noticed that the polling scripts weren't running. I tracked it down to needing wxallow on /usr/local so python2.7 would run (otherwise "access denied"). I think python2.7 wasn't marked as needing wxallow, or I don't know how to check. Is this expected? Also, I didn't see anything in syslog about it. Is there a way to enable logging when a program attempts to run but can't? The output message was just "access denied". Thanks.
Re: What does it mean this error when I try install a package?
On Mon, Apr 17, 2017 at 01:39:22PM +0200, Christoph R. Murauer wrote: > > Hi all, > > > > After install an OpenBSD 6.1, I am trying to install some packages, > > for example python-2.7. When I launch the following command: > > > > pkg_add -v python-2.7 > > > > ... returns the following errors: > > > > http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/: Read short > > file. > > http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/python-2.7.tgz: > > ftp: Error retrieving file: 404 Not Found > > signify: gzheader truncated > > Can't find python-2.7 > > Extracted 11548847 from 11550420 > > > > What does these errors mean?? My PKG_PATH variable is > > "PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64"; > > It means, that the package you try to install does not exist. Run > > pkg_info -Q python > > See FAQ https://www.openbsd.org/faq/faq15.html#PkgFind > > you see something like (in my case it is already installed) > > ... > python-2.7.13p0 (installed) > ... > > You can also check the list of packages at > http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/index.txt > > So, try > > pkg_add -v python-2.7.13p0 > > or, check the -z switch of pkg_add (man pkg_add) > > pkg_add -v -z python-2.7.13 > Yep, undertood. Many thanks. -- Greetings, C. L. Martinez
Re: What does it mean this error when I try install a package?
> Hi all, > > After install an OpenBSD 6.1, I am trying to install some packages, > for example python-2.7. When I launch the following command: > > pkg_add -v python-2.7 > > ... returns the following errors: > > http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/: Read short > file. > http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/python-2.7.tgz: > ftp: Error retrieving file: 404 Not Found > signify: gzheader truncated > Can't find python-2.7 > Extracted 11548847 from 11550420 > > What does these errors mean?? My PKG_PATH variable is > "PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64"; It means, that the package you try to install does not exist. Run pkg_info -Q python See FAQ https://www.openbsd.org/faq/faq15.html#PkgFind you see something like (in my case it is already installed) ... python-2.7.13p0 (installed) ... You can also check the list of packages at http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/index.txt So, try pkg_add -v python-2.7.13p0 or, check the -z switch of pkg_add (man pkg_add) pkg_add -v -z python-2.7.13
Re: What does it mean this error when I try install a package?
On Mon, 17 Apr 2017 11:02:37 + "C. L. Martinez" wrote: > pkg_add -v python-2.7 There is no package called python-2.7. The package you want is called python-2.7.13p0. You have a few options: 1. pkg_add python, then select the version you want. 2. pkg_add python-2.7.13p0 3. pkg_add -z python-2.7 (fuzzy matching, see pkg_add(1))
What does it mean this error when I try install a package?
Hi all, After install an OpenBSD 6.1, I am trying to install some packages, for example python-2.7. When I launch the following command: pkg_add -v python-2.7 ... returns the following errors: http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/: Read short file. http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64/python-2.7.tgz: ftp: Error retrieving file: 404 Not Found signify: gzheader truncated Can't find python-2.7 Extracted 11548847 from 11550420 What does these errors mean?? My PKG_PATH variable is "PKG_PATH=http://ftp.openbsd.org/pub/OpenBSD/6.1/packages/amd64"; -- Greetings, C. L. Martinez
Re: opening bugs for OpenBSD 6.0
On 2017-04-17, Alceu Rodrigues de Freitas Junior wrote: > Em 16/04/2017 09:16, Stuart Henderson escreveu: >> >> The local perl build that is showing "undefined symbol 'recallocarray'" >> is broken. > > How so? I mean, what can I check in the compile process to make it right? > > I compiled the interpreter with perlbrew, used different versions and > the results are the same. > > Should I review any specific notes about compiling perl for OpenBSD? > Please let me know if there are any references about it. I have no idea about perlbrew or locally compiled versions of perl, I just build it as part of the OpenBSD source build. But whatever perlbrew is doing isn't working correctly on your system, something is getting mixed up with library versions. recallocarray(3) is in libc but was only added recently.
Re: [vmm] SSL read error: read failed: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt
On 2017-04-17, David Coppa wrote: > On Sun, Apr 16, 2017 at 11:17 AM, Paul Chakravarti wrote: >> Hello, >> >> I am trying out vmm on 6.1 and can setup/boot vm etc. however when I try to >> download a large file using SSL I consistenetly get the following error: >> >>> SSL read error: read failed: error:06FFF064:digital envelope >> routines:CRYPTO_internal:bad decrypt >> >> This occasionally (but not always) correlates with the following message in >> the vmd log: >> >>> vionet queue notify - no space, dropping packet >> >> Strangely non-SSL and smaller SSL downloads seem to work ok (see below). >> >> Originally spotted this using installer but can recreate from shell. >> >> Any ideas? > > See http://marc.info/?l=openbsd-misc&m=148858752003261 > > It's a known problem. I've seen corruption with non-SSL network transfers too. It's just more obvious with SSL because in that case the session gets killed, whereas otherwise the corrupt input is silently accepted.
Re: iwm0: could send power command (error 35), cd0 SENSE KEY: Not Ready
Thanks for your fast answer. > On Mon, Apr 17, 2017 at 12:15:58AM +0200, Christoph R. Murauer wrote: >> Hello ! >> >> I installed OpenBSD 6.1-current on a ThinkPad w541 (last 2 dmesgs >> are >> below) without problems. iwm works without problems and from time to >> time I see the message >> >> cd0(ahci0:5:0): Check Condition (error 0x70) on opcode 0x0 >> SENSE KEY: Not Ready >> >> at the console. I use the drive only to rip audio cds also without >> problems. Do I have to care about the message ? > > I don't know how to interpret this message. It definitely has nothing > to do with iwm though. You are right but I thought I put booth questions in 1 message to misc@ as all other things work for me without problems and I have nothing else to report / to ask about. >> During the last 3 upgrades using bsd.rd I got at boot the following >> boot messages >> >> iwm0: could not read firmware iwm-7260-16 (error 2) >> iwm0: failed to load init firmware >> >> and during the upgrade script after mounting the root filesystem > > This is a known issue. It seems to trigger mostly in bsd.rd but I > suspect this bug affects GENERIC as well and is somehow masked there. In GENERIC it works without error messages and without problems. > Since the driver usually recovers on its own (just wait a while until > it gets link) this isn't at the top of my list of things to fix. > It would be very nice to get it fixed, though. I tried the recovery only at my day to day use where it works very fast. During upgrade I did not think on that but I try it with the next upgrade. No need to hurry as things works, I only thought I report it. If you need more informations, let me know. > >> iwm0: hw rev 0x140, fw ver 16.242414.0, address cc:3d:82:52:2b:5a >> iwm0: could send power command (error 35) >> iwm0: device timeout >> iwm0: device timeout >> SIOCSIFFLAGS: Resource temporarily unavailable >> iwm0: no link sleeping
Re: [vmm] SSL read error: read failed: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt
On Sun, Apr 16, 2017 at 11:17 AM, Paul Chakravarti wrote: > Hello, > > I am trying out vmm on 6.1 and can setup/boot vm etc. however when I try to > download a large file using SSL I consistenetly get the following error: > >> SSL read error: read failed: error:06FFF064:digital envelope > routines:CRYPTO_internal:bad decrypt > > This occasionally (but not always) correlates with the following message in > the vmd log: > >> vionet queue notify - no space, dropping packet > > Strangely non-SSL and smaller SSL downloads seem to work ok (see below). > > Originally spotted this using installer but can recreate from shell. > > Any ideas? See http://marc.info/?l=openbsd-misc&m=148858752003261 It's a known problem. Ciao! David
[vmm] SSL read error: read failed: error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt
Hello,
I am trying out vmm on 6.1 and can setup/boot vm etc. however when I try to
download a large file using SSL I consistenetly get the following error:
> SSL read error: read failed: error:06FFF064:digital envelope
routines:CRYPTO_internal:bad decrypt
This occasionally (but not always) correlates with the following message in
the vmd log:
> vionet queue notify - no space, dropping packet
Strangely non-SSL and smaller SSL downloads seem to work ok (see below).
Originally spotted this using installer but can recreate from shell.
Any ideas?
# cat /etc/vm.conf
vm vm0 {
disable
memory 512M
disk /home/vm/vm0.img
kernel /bsd.rd
interface { switch uplink }
}
switch uplink {
interface bridge0
add vether0
}
# vmctl start vm0
vmctl: started vm 11 successfully, tty /dev/ttyp6
# vmctl status
ID PID VCPUS MAXMEM CURMEM TTYOWNER NAME
11 85026 1512M 97.3M ttyp6 root vm0
# cu -l /dev/ttyp6
Connected to /dev/ttyp6 (speed 9600)
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? s
# dhclient vio0
DHCPDISCOVER on vio0 - interval 1
DHCPOFFER from 10.0.0.1 (fe:e1:ba:d3:55:34)
DHCPREQUEST on vio0 to 255.255.255.255
DHCPACK from 10.0.0.1 (fe:e1:ba:d3:55:34)
bound to 10.0.0.105 -- renewal in 21600 seconds.
#
# ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/bsd | sha256
440311305f27f0efcfcc88116299a21cb3f890fb91ee611c2a79cc9163e8fceb
# ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/SHA256 | fgrep
'(bsd)'
SHA256 (bsd) =
440311305f27f0efcfcc88116299a21cb3f890fb91ee611c2a79cc9163e8fceb
# ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/base61.tgz |
sha256
5c467ea369b5632d3b057283857d1998fb3dcd26179365291f16c70785a65282
# ftp -Vo- http://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/SHA256 | fgrep
'(base61.tgz)'
SHA256 (base61.tgz) =
5c467ea369b5632d3b057283857d1998fb3dcd26179365291f16c70785a65282
#
# ftp -Vo- https://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/bsd | sha256
ftp: SSL read error: read failed: error:06FFF064:digital envelope
routines:CRYPTO_internal:bad decrypt
27ad92f2aaf0279dd125ed54d0b7fbf330a3ecbe2e919b4d2d0ed1d07dccc087
# ftp -Vo- https://www.mirrorservice.org/pub/OpenBSD/6.1/amd64/base61.tgz |
sha256
ftp: SSL read error: read failed: error:06FFF064:digital envelope
routines:CRYPTO_internal:bad decrypt
d79f6fd884a839d1fc62dc1b5d40de21f97fd5a50b28319a7b25dd8cd82da887
[On host]
# top -d1 all
load averages: 1.14, 1.16, 1.16x230 10:06:31
68 processes: 67 idle, 1 on processor up 2 days, 11:19
CPU0 states: 0.2% user, 0.0% nice, 0.5% system, 0.2% interrupt, 99.1%
idle
CPU1 states: 4.6% user, 0.0% nice, 8.3% system, 0.0% interrupt, 87.2%
idle
CPU2 states: 1.2% user, 0.0% nice, 2.2% system, 0.0% interrupt, 96.6%
idle
CPU3 states: 0.8% user, 0.0% nice, 1.1% system, 0.0% interrupt, 98.1%
idle
Memory: Real: 470M/1376M act/tot Free: 6261M Cache: 652M Swap: 0K/3562M
PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
85026 _vmd 280 514M 14M idle thrslee 1:19 13.53% vmd
55104 paulc 20 399M 301M sleep/3 poll 4:09 7.86% firefox
1136 paulc 20 1180K 9156K sleep/3 poll 0:23 0.05% i3bar
91148 paulc 20 14M 50M sleep/2 select0:24 0.00% Xorg
48836 paulc 100 752K 1988K sleep/2 nanosle 0:05 0.00% i3status
24227 paulc 20 1032K 2820K sleep/2 select0:04 0.00% sshd
66378 paulc 20 1564K 10M idle poll 0:02 0.00% i3
67867 paulc 20 5032K 13M idle select0:02 0.00% urxvt
22018 _syslogd 20 904K 1544K sleep/2 kqread0:02 0.00% syslogd
1 root 100 380K 416K idle wait 0:01 0.00% init
43749 _pflogd40 668K 428K sleep/1 bpf 0:01 0.00% pflogd
27702 _ntp 2 -20 888K 2344K sleep/2 poll 0:01 0.00% ntpd
49491 paulc 20 4972K 13M idle select0:01 0.00% urxvt
76489 _vmd 20 1176K 1672K idle kqread0:00 0.00% vmd
6009 root 20 620K 528K idle poll 0:00 0.00% dhclient
39926 paulc 20 4912K 12M idle select0:00 0.00% urxvt
3807 paulc 180 604K 732K idle pause 0:00 0.00% ksh
76917 root 20 220K 780K sleep/1 kqread0:00 0.00% apmd
33176 _smtpd 20 1280K 3444K idle kqread0:00 0.00% smtpd
51016 root 30 736K 796K idle ttyin 0:00 0.00% ksh
86730 _smtpd 20 1368K 3492K idle kqread0:00 0.00% smtpd
5062 root 20 1556K 2128K idle kqread0:00 0.00% smtpd
59926 root 20 868K 1368K idle select0:00 0.00% sshd
46705 root 180 668K 756K idle pause 0:00 0.00% ksh
92059 _smtpd 20 1420K 3616K idle kqread
Re: iwm0: could send power command (error 35), cd0 SENSE KEY: Not Ready
On Mon, Apr 17, 2017 at 12:15:58AM +0200, Christoph R. Murauer wrote: > Hello ! > > I installed OpenBSD 6.1-current on a ThinkPad w541 (last 2 dmesgs are > below) without problems. iwm works without problems and from time to > time I see the message > > cd0(ahci0:5:0): Check Condition (error 0x70) on opcode 0x0 > SENSE KEY: Not Ready > > at the console. I use the drive only to rip audio cds also without > problems. Do I have to care about the message ? I don't know how to interpret this message. It definitely has nothing to do with iwm though. > During the last 3 upgrades using bsd.rd I got at boot the following > boot messages > > iwm0: could not read firmware iwm-7260-16 (error 2) > iwm0: failed to load init firmware > > and during the upgrade script after mounting the root filesystem This is a known issue. It seems to trigger mostly in bsd.rd but I suspect this bug affects GENERIC as well and is somehow masked there. Since the driver usually recovers on its own (just wait a while until it gets link) this isn't at the top of my list of things to fix. It would be very nice to get it fixed, though. > iwm0: hw rev 0x140, fw ver 16.242414.0, address cc:3d:82:52:2b:5a > iwm0: could send power command (error 35) > iwm0: device timeout > iwm0: device timeout > SIOCSIFFLAGS: Resource temporarily unavailable > iwm0: no link sleeping
Re: flaky network connection after 6.1 upgrade
On Sun, Apr 16, 2017 at 05:31:58PM -0500, Colton Lewis wrote: > Stephan, > > > I would guess you are running into some issue with 802.11n support which > > was added to this driver in 6.1. You should be able to restore the previous > > behaviour with: ifconfig athn0 mode 11g > > Your hunch was almost right. 11g had the same problem, but 11b worked > as expected. Looks like too much interference from other networks (try a different channel) or too large distance from the AP. > Attached is the info you asked for. > 17:05:52.707822 802.11 flags=0<>: beacon, caps=12021, ssid (Stormlord), rates 1M* 2M* 5M 11M 18M 24M 36M 54M, ds (chan 9), tim 0x0102, erp 0x04, xrates 6M 9M 12M 48M, rsn 0x010fac04010fac04010fac020c00, 6 stations, 4% utilization, admission capacity 0us/s, 70:5 0x320801, htcaps=<20MHz,LDPC,SGI@20MHz,TXSTBC,RXSTBC 1 stream,A-MSDU 7935,A-MPDU max 65535,A-MPDU spacing 4.00us,RxMCS 0xff00>, htop=<20MHz chan 9,STA chanw 20MHz,RIFS,htprot none,non-greenfield STA,basic MCS set 0x>, 74:14 0x14000a002c01c800140005001900, 127:8 0x05000840, vendor 0x00146c00, vendor 0x0050f204104a0001101044000102104700102a1ecc3b122c82e30b19d406361deb33103c000 1031049000600372a000120, vendor 0x00904c0408bf0cb259820feaffeaffc005000900c3020002, vendor 0x0010180206001c, vendor 0x0050f2020101880003a427a44243bc0062326600, > athn0: flags=8843 mtu 1500 > lladdr 00:15:af:cd:f2:4f > index 2 priority 4 llprio 3 > groups: wlan egress > media: IEEE802.11 autoselect (HT-MCS1 mode 11n) > status: active > ieee80211: nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm wpakey > wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp > inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255 > nwid Stormlord chan 9 bssid 10:da:43:96:15:6d -13dBm HT-MCS23 privacy,short_slottime,radio_measurement,wpa2 > inet 192.168.1.17 netmask 0xff00 broadcast 192.168.1.255
Re: ordering
On 16 Apr 2017 8:12 am, "Theo de Raadt" wrote: Hi Vijay and everyone else, > I had sent an email to ord...@openbsdstore.com regarding this > yesterday and they replied that "there isn't a 6.1 cd, please check > out the obsd.org site to persuade them to make one...". However I did > not want to bother the list and the developers in case CDs are not the > way to go. I did a search on mailing list messages but did not see > anything about 6.1 CDs. True. The 6.1 ANNOUNCEMENT does not list an upcoming CD. 6.0 was announced as the last CD release. 6.0 says so in the liner notes. It is hard to believe OpenBSD followers missed that. 6.0 had 6 songs. It was meant to be over the top, a celebration. I sung the lyrics for the 6th song: Goodbye CDs I'm done with you today Goodbye Goodbye Goodbye No more pre-production And no more long delays So I have peace Of mind Goodbye. I am a sorry for people who missed the cues, but this change is personal. I made 40 CD releases in 20 years, investing personal effort and risk to build and sustain the costs of this project and sub-projects. I do not want to keep making CDs to sustain myself and the project anymore. Other ways need to work now. The decision is not only economical. I don't want the "friction" of trying to achieve high-quality production of collector item data CDs twice a year, in 2017. 6.0 was a high-quality CD release like previous ones, but don't want to expend the effort of producing and testing to make sure 6.1, 6.2 etc are up to that standard. It is better to call it quits on a high note. Having done 6.1 without a CD, we learn that incorporating CDs into the production cycle has been a big drag, basically 1 month out of 6. Other project developers and processes were locked to that cycle. It is shocking how easy a release cycle is without a CD. Generally our tree is always ready, we may be able to do future releases at the drop of a hat. As long as we produce a release the developers can be proud of. That is more important than making a CD -- by far. > So I am thinking that the CD's may be ready only by May 1 and the > release date was pushed earlier for some reason (just a guess > because in 2015 and before, CDs were released in May and November) The shop will not be selling 6.1 CDs. Most things come to an end, sorry. > If no OpenBSD CDs are going to be released, then probably it is better > to just send a donation to the OpenBSD foundation and/or to Theo de > Raadt. Vijay, that is the correct way to sustain the software. The CDs haven't pulled in sustaining revenue for many years. Based upon income from contributors the Foundation performs a fantastic function -- making worries and problems disappear. > If CD's are going to be released, of course, I would be first > in line since I have all CD's since 2.8 :) That is a good collection. I have one of each, and ones before that. I've heard that 2.5 is the most difficult to acquire. I think the audio CDs are undervalued. They contain no dorky software -- they are lyrics + music + drawing, just art. Dorky art sure, but no software... Sorry guys. Anyone want to buy some well-used CD burners? I have a pair of questions. Are there any plan to release audio CD at more or less regular intervals ? I only bought the last one and I really like it Could the project offer a ballpark estimate of the difficulty to release a token object with each release ? I'm thinking of something like a blank usb key, maybe in a box similar to the one used for the release CD. The idea would be to offer a physical token which could be produced without any impact to the core project. Just like the song, which are not released yet as far as I know.
Re: OpenBSD on HPE DL20 G9
hi, From: BARDOU Pierre Subject: OpenBSD on HPE DL20 G9 Date: Mon, 10 Oct 2016 15:12:04 + > I have a brand new HPE DL20 G9, on which I am trying to boot OpenBSD (version > 6.0). > > 1s try : UEFI. The boot loader does its work, and then the screen remains > blank. > I can't see any line with blue background. > I tried to see what happend via console, but there is no serial port on these > little beasts :( Can you try to disable "UEFI Optimized Boot"? http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=7481826&docId=mmr_kc-0123842&docLocale=en_US It works for me. # I have no idea why it works... Best Regards, -- FUKAUMI Naoki
