Re: hidden services stopped working

[ares]

Ok, I'm not sure where how this thread went sideways quite so quickly but
just to be clear
I'm running as of right now the most current snapshot available on
ftp5.usa and the only things
I have installed are lynx and tor, I have made sure the system time is
correct and turn
tor's log doesn't throw any errors at all, and all clearnet address
connect just fine, I've tried
looking through dameon, messages, and pflog for any errors or misrouted
packets respectively, this
setup was working just fine and has been for quite a while until a few
days ago, I'm not trying
to gripe or install anything else I know I'm using snapshots and what that
means I'm simply asking
for help in other ways I can apprach this problem to try and find the
solution since
I was definitely call myself a noob or if maybe someone knew of some
changes between the snapshot versions
that might be related. If I can provide any other information that someone
thinks will
help I'm more than happy to do so.
P.S.- Sorry for the epic run on sentence.
>>
>> What do you mean by "checking the time"? It just jumps forward for about
>> 150s and immediately restores. So it's not so visible. Though it makes
>> Tor to break all built circuits. Have a look at your Tor log with
>> `notice` debug level. There are probably reports like this:
>>
>> "Your system clock just jumped 150 seconds forward; assuming established
>> circuits no longer work."
>
> I am really impressed by the analytical skills I observe here.
>
> I observe: "the system is complex, I can't figure it out, I'll blame
> everything, and use more stuff I don't understand".
>
> Maybe the fortress fell over because you didn't have enough Lego.

Re: hidden services stopped working

[Theo de Raadt]

> a...@riseup.net:
> > Thanks for the reply and the help Ivan but I'm actually already doing 
> > exactly
> > what you suggested. Checking the time is one of the first things I thought 
> > of
> > but this is not that unfortunately. I don't have this problem on 5.9 myself
> > and even snapshots were fine up until the update. Your problem is
> > interesting though.
> > Let me know if you come accross anything new on that, again thanks for you
> > time on this.
> 
> What do you mean by "checking the time"? It just jumps forward for about
> 150s and immediately restores. So it's not so visible. Though it makes
> Tor to break all built circuits. Have a look at your Tor log with
> `notice` debug level. There are probably reports like this:
> 
> "Your system clock just jumped 150 seconds forward; assuming established
> circuits no longer work."

I am really impressed by the analytical skills I observe here.

I observe: "the system is complex, I can't figure it out, I'll blame
everything, and use more stuff I don't understand".

Maybe the fortress fell over because you didn't have enough Lego.

Re: hidden services stopped working

[Ivan Markin]

Theo de Raadt:
> I am really impressed by the analytical skills I observe here.
> 
> I observe: "the system is complex, I can't figure it out, I'll blame
> everything, and use more stuff I don't understand".

The problem is definely with ntpd because ntpd reports about
invalid-then-valid peers to syslog right before Tor's complaints about
timewrap.

I don't see anything wrong about proposing a dirty fix that can solve
the problem for a while.

> Maybe the fortress fell over because you didn't have enough Lego.

Maybe.

--
Ivan Markin

Re: hidden services stopped working

[ares]

Thanks for the reply and the help Ivan but I'm actually already doing exactly
what you suggested. Checking the time is one of the first things I thought of
but this is not that unfortunately. I don't have this problem on 5.9 myself
and even snapshots were fine up until the update. Your problem is
interesting though.
Let me know if you come accross anything new on that, again thanks for you
time on this.
>> connections taken from the wiki @ https://trac.torproject.org/projects/
>> tor/wiki/doc/TransparentProxy#BSDPF. With the exception of using
>> divert-to rules istead of the rdr-to rules everything else is exactly
>> the same. It all worked fine up to the recent update. After a few days
>> and a few snapshot versions I can't seem to troubleshoot what's changed
>> or where it's failing. No errors or blocks in syslog or pflog
>> repectively.
>> Clearnet works fine and is all routed through tor and using tor-resolve
>> on hidden services resolves the address just fine but trying to connect
>> through irc or web browser to hidden services fails after timeout. Any
>> help would be greatly appreciated. Attached a ktrace of lynx trying to
>> connect to the duckduckgo hidden service. Thanks in advance guys!
>> P.S. Triple checked pf rules and entire tor config, system time, and
>> virtual address allocation
>
> I've encountered recently that system time jumps repeatedly thus
> breaking all curcuits and even more time-sensitive Onion Services as
> well. This is a problem that I'm now investigating.
> As you said, you're using snapshot version. But this problem also
> present in 5.9 release branch and started around the same time. Then it
> should not have roots in the recent code.
>
> At the moment the problem narrows down to `ntpd.conf` in the default
> install. According to this [1] commit, `ntpd` is enabled by default and
> uses contraints over TLS from `www.google.com` (do we trust Google
> now??). Same NTP peers work fine on another non-OpenBSD machines so my
> best guess at the moment that time taken from `www.google.com` is wrong
> (or the fetching method). Maybe Google changed their time logic.
>
> Another hint is that these OpenBSD machines do DNS over Tor ('DNSPort'
> option) and thus get different Google IP each time (Google tries to
> resolve IP addresses that are nearby). Then ntpd takes average of these
> clocks (different IPs) according to the manpage.
>
> As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
> [3] to fetch time over TLS. It works fine for me for several days by now.
>
>
> [1]
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/ntpd.conf.diff?r1=1.12=1.13
> [2] /etc/rc.d/ntpd stop
> rcctl disable ntpd
> [3] https://github.com/ioerror/tlsdate
>
> --
> Ivan Markin

Re: hidden services stopped working

[Ivan Markin]

a...@riseup.net:
> Thanks for the reply and the help Ivan but I'm actually already doing exactly
> what you suggested. Checking the time is one of the first things I thought of
> but this is not that unfortunately. I don't have this problem on 5.9 myself
> and even snapshots were fine up until the update. Your problem is
> interesting though.
> Let me know if you come accross anything new on that, again thanks for you
> time on this.

What do you mean by "checking the time"? It just jumps forward for about
150s and immediately restores. So it's not so visible. Though it makes
Tor to break all built circuits. Have a look at your Tor log with
`notice` debug level. There are probably reports like this:

"Your system clock just jumped 150 seconds forward; assuming established
circuits no longer work."

--
Ivan Markin

Re: hidden services stopped working

[Ivan Markin]

Theo de Raadt:
>> As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
>> [3] to fetch time over TLS. It works fine for me for several days by now.
> 
> That is the worst possible advice ever.
> 
> You are far better off letting your machines free-run.

Why it's so wrong?


ares,
using tlsdate to sync time is not required.

--
Ivan Markin

Re: hidden services stopped working

[Ivan Markin]

Hi ares,

a...@riseup.net:
> After a snapshot update on the 26th for amd64 I have lost the ability to
> connect to hidden services. I have pf rules to transparently proxy all
> connections taken from the wiki @ https://trac.torproject.org/projects/
> tor/wiki/doc/TransparentProxy#BSDPF. With the exception of using
> divert-to rules istead of the rdr-to rules everything else is exactly
> the same. It all worked fine up to the recent update. After a few days
> and a few snapshot versions I can't seem to troubleshoot what's changed
> or where it's failing. No errors or blocks in syslog or pflog repectively.
> Clearnet works fine and is all routed through tor and using tor-resolve
> on hidden services resolves the address just fine but trying to connect
> through irc or web browser to hidden services fails after timeout. Any
> help would be greatly appreciated. Attached a ktrace of lynx trying to
> connect to the duckduckgo hidden service. Thanks in advance guys!
> P.S. Triple checked pf rules and entire tor config, system time, and
> virtual address allocation

I've encountered recently that system time jumps repeatedly thus
breaking all curcuits and even more time-sensitive Onion Services as
well. This is a problem that I'm now investigating.
As you said, you're using snapshot version. But this problem also
present in 5.9 release branch and started around the same time. Then it
should not have roots in the recent code.

At the moment the problem narrows down to `ntpd.conf` in the default
install. According to this [1] commit, `ntpd` is enabled by default and
uses contraints over TLS from `www.google.com` (do we trust Google
now??). Same NTP peers work fine on another non-OpenBSD machines so my
best guess at the moment that time taken from `www.google.com` is wrong
(or the fetching method). Maybe Google changed their time logic.

Another hint is that these OpenBSD machines do DNS over Tor ('DNSPort'
option) and thus get different Google IP each time (Google tries to
resolve IP addresses that are nearby). Then ntpd takes average of these
clocks (different IPs) according to the manpage.

As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
[3] to fetch time over TLS. It works fine for me for several days by now.


[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/ntpd.conf.diff?r1=1.12=1.13
[2] /etc/rc.d/ntpd stop
rcctl disable ntpd
[3] https://github.com/ioerror/tlsdate

--
Ivan Markin

Re: hidden services stopped working

[Theo de Raadt]

> As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
> [3] to fetch time over TLS. It works fine for me for several days by now.

That is the worst possible advice ever.

You are far better off letting your machines free-run.

Re: Flaw in ipsec.conf(5)?

[Jason McIntyre]

On Fri, May 27, 2016 at 01:21:55PM +0200, Bruno Flueckiger wrote:
> After discussing this with Philipp Buehler off list I have reworked my
> diff to make things easier in the example.
> 
> The paragraph which contains set skip on enc0 just before the ruleset
> is removed. All filtering in the rule set is done on sk0, skipping enc0
> entirely.
> 
> The new rule set looks like this:
> 
> block on sk0
> set skip on enc0
> 
> pass  in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
>   port {500, 4500}
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
>   port {500, 4500}
> 
> pass  in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
> 
> pass  in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \
>   keep state (if-bound)
> pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \
>   keep state (if-bound)
> 

what then is the point of this section? to tell us to not filter
ipsec traffic?

what really needs to happen is for developers concerned with ipsec to
either recognise a change and adjust the filter rules accordingly, or
to say the idea of filtering enc traffic no longer makes sense and to
remove the section. or to tell you what's in ipsec.conf(5) is correct,
and why.

until that happens, the text will remain, i think.

jmc

> 
> Index: sbin/ipsecctl/ipsec.conf.5
> ===
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.151
> diff -u -p -r1.151 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.59 Dec 2015 21:41:50 -   1.151
> +++ sbin/ipsecctl/ipsec.conf.527 May 2016 11:07:55 -
> @@ -493,20 +493,12 @@ Match traffic of phase 2 SAs using the
>  keyword.
>  .El
>  .Pp
> -If the filtering rules specify to block everything by default,
> -the following rule
> -would ensure that IPsec traffic never hits the packet filtering engine,
> -and is therefore passed:
> -.Bd -literal -offset indent
> -set skip on enc0
> -.Ed
> -.Pp
>  In the following example, all traffic is blocked by default.
>  IPsec-related traffic from gateways {192.168.3.1, 192.168.3.2} and
>  networks {10.0.1.0/24, 10.0.2.0/24} is permitted.
>  .Bd -literal -offset indent
>  block on sk0
> -block on enc0
> +set skip on enc0
>  
>  pass  in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \e
>   port {500, 4500}
> @@ -516,13 +508,9 @@ pass out on sk0 proto udp from 192.168.3
>  pass  in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
>  pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>  
> -pass  in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
> - keep state (if-bound)
> -pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \e
> - keep state (if-bound)
> -pass  in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \e
> +pass  in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \e
>   keep state (if-bound)
> -pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \e
> +pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \e
>   keep state (if-bound)
>  .Ed
>  .Pp

Re: CRYPTO volume created, but appears as full

[Philip Guenther]

On Sat, May 28, 2016 at 9:15 AM, Robert Campbell
 wrote:
>...
> # bioctl -c C -l sd0a softraid0
> New passphrase:
> Re-type passphrase:
> sd3 at scsibus3 targ 1 lun 0:  SCSI2 0/direct fixed
> sd3: 114470MB, 512 bytes/sector, 234435953 sectors
> softraid0: CRYPTO volume attached as sd3
> # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> uid 0 on /: file system full
>
> /: write failed, file system is full
> dd: /dev/rsd3c: No space left on device
> 1+0 records in
> 0+0 records out
> 0 bytes transferred in 0.007 secs (0 bytes/sec)

The FAQ has another command between the bioctl and the dd...to create
the device in /dev.  /dev/rsd3c didn't exist when you ran the dd, so
instead of opening and writing to a device, you created a normal file
named "rsd3c" on the ramdisk, thus the error messages about "file
system is full".


Philip Guenther

Re: hardware recommendation for openbsd-based thin client?

[frantisek holop]

i don't have experience with the compute
sticks, but i would start with updating the BIOS.

https://downloadcenter.intel.com/download/25917/BIOS-Update-SCCHTAX5-86A-

noah pugsley, 26 May 2016 20:59:
> bios0: vendor Intel Corp. version "SCCHTAX5.86A.0014.2015.1119.1410" date 
> 11/19/2015
> bios0: Intel Corporation STK1AW32SC

-f
-- 
i have an exceptionally high q.i.

"Cleared:" in pfctl interface statistics

[frantisek holop]

what is the purpose of the Cleared line of the
interface statistics?  if i read pfctl(8) correctly,
only tables can have their statistics cleared/zeroed
(the table command is "zero", and not "clear", perhaps
because the latter could evoke "removing all elements
of the table", although in other parts of the manpage
"flush" is used for this kind of operation)


# pfctl -vvsI -i re0
re0
Cleared: Thu Jan  1 01:00:01 1970
References:  [ States:  0  Rules: 1  ]
In4/Pass:[ Packets: 59988900   Bytes: 74459951479]
In4/Block:   [ Packets: 13991  Bytes: 1645774]
Out4/Pass:   [ Packets: 39058098   Bytes: 5850353660 ]
Out4/Block:  [ Packets: 3167   Bytes: 467994 ]
In6/Pass:[ Packets: 18 Bytes: 1152   ]
In6/Block:   [ Packets: 0  Bytes: 0  ]
Out6/Pass:   [ Packets: 0  Bytes: 0  ]
Out6/Block:  [ Packets: 0  Bytes: 0  ]
# pfctl -F info
pf: statistics cleared
# pfctl -vvsI -i re0
re0
Cleared: Thu Jan  1 01:00:01 1970
References:  [ States:  0  Rules: 1  ]
In4/Pass:[ Packets: 60374772   Bytes: 74945788280]
In4/Block:   [ Packets: 14028  Bytes: 1647622]
Out4/Pass:   [ Packets: 39392791   Bytes: 6029106115 ]
Out4/Block:  [ Packets: 3185   Bytes: 468786 ]
In6/Pass:[ Packets: 18 Bytes: 1152   ]
In6/Block:   [ Packets: 0  Bytes: 0  ]
Out6/Pass:   [ Packets: 0  Bytes: 0  ]
Out6/Block:  [ Packets: 0  Bytes: 0  ]

-f
-- 
he's teflon brain (nothing sticks).

Re: CRYPTO volume created, but appears as full

[Ivan Markin]

Stefan Sperling:
> On Sat, May 28, 2016 at 06:03:48PM +, Ivan Markin wrote:
>> Sebastien Marie:
>>> Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the
>>> /dev/sd* aren't created by default.
>>
>> Why it is so? Can this be found somewhere in documentation?
> 
> If the ramdisk shipped with all possible device nodes, the small
> ramdisk filesystem would run out of inodes.
> 
> The installer script compensates for this by creating device nodes it
> knows will be needed, so normally you don't have to think about this.
> Because the install script does not support FDE installs at present,
> the /dev/rsd3c device node is not created automatically.
> 

Thanks for the explanation!
It would be great if someone can add this note to the FAQ [1].

[1] https://www.openbsd.org/faq/faq14.html#softraidFDE

--
Ivan Markin

Re: CRYPTO volume created, but appears as full

[Ivan Markin]

Sebastien Marie:
> Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the
> /dev/sd* aren't created by default.

Why it is so? Can this be found somewhere in documentation?

--
Ivan Markin

Re: CRYPTO volume created, but appears as full

[Theo Buehler]

On Sat, May 28, 2016 at 08:03:47PM +0200, Stefan Sperling wrote:
> On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote:
> > I followed the steps in the FAQ for setting up full disk encryption.
> > Everything goes according to plan until I attempt to write zeros to the
> > first megabyte of the new pseudo-device; as you can see below, dd informs
> > me that the file system is full, that there is no space left on the device.
> > Interestingly, the last line of dmesg is also "uid 0 on /: file system
> > full". I've retried this with 5.9 and -current, but the outcome is the
> > same. I've also tried rebooting after disklabel and bioctl. I have pasted
> > below the relevant sequence, followed by the full dmesg.
> 
> > # bioctl -c C -l sd0a softraid0
> > New passphrase:
> > Re-type passphrase:
> > sd3 at scsibus3 targ 1 lun 0:  SCSI2 0/direct fixed
> > sd3: 114470MB, 512 bytes/sector, 234435953 sectors
> > softraid0: CRYPTO volume attached as sd3
> 
> Here you need to do this first:
> 
>   cd /dev
>   sh MAKEDEV sd3

That's not the first time someone is bitten by this. I tweaked the FDE
rundown a little and it now contains a line to that effect. Sorry for
the inconvenience.

> > # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> > uid 0 on /: file system full
> 
> If you skip the above step, /dev/rsd3c is created as a regular file and fills
> up the root fs.

Re: CRYPTO volume created, but appears as full

[Stefan Sperling]

On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote:
> I followed the steps in the FAQ for setting up full disk encryption.
> Everything goes according to plan until I attempt to write zeros to the
> first megabyte of the new pseudo-device; as you can see below, dd informs
> me that the file system is full, that there is no space left on the device.
> Interestingly, the last line of dmesg is also "uid 0 on /: file system
> full". I've retried this with 5.9 and -current, but the outcome is the
> same. I've also tried rebooting after disklabel and bioctl. I have pasted
> below the relevant sequence, followed by the full dmesg.

> # bioctl -c C -l sd0a softraid0
> New passphrase:
> Re-type passphrase:
> sd3 at scsibus3 targ 1 lun 0:  SCSI2 0/direct fixed
> sd3: 114470MB, 512 bytes/sector, 234435953 sectors
> softraid0: CRYPTO volume attached as sd3

Here you need to do this first:

cd /dev
sh MAKEDEV sd3

> # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> uid 0 on /: file system full

If you skip the above step, /dev/rsd3c is created as a regular file and fills
up the root fs.

Re: CRYPTO volume created, but appears as full

[Stefan Sperling]

On Sat, May 28, 2016 at 06:03:48PM +, Ivan Markin wrote:
> Sebastien Marie:
> > Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the
> > /dev/sd* aren't created by default.
> 
> Why it is so? Can this be found somewhere in documentation?

If the ramdisk shipped with all possible device nodes, the small
ramdisk filesystem would run out of inodes.

The installer script compensates for this by creating device nodes it
knows will be needed, so normally you don't have to think about this.
Because the install script does not support FDE installs at present,
the /dev/rsd3c device node is not created automatically.

Re: CRYPTO volume created, but appears as full

[Theo de Raadt]

> On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote:
> > I followed the steps in the FAQ for setting up full disk encryption.
> > Everything goes according to plan until I attempt to write zeros to the
> > first megabyte of the new pseudo-device; as you can see below, dd informs
> > me that the file system is full, that there is no space left on the device.
> > Interestingly, the last line of dmesg is also "uid 0 on /: file system
> > full". I've retried this with 5.9 and -current, but the outcome is the
> > same. I've also tried rebooting after disklabel and bioctl. I have pasted
> > below the relevant sequence, followed by the full dmesg.
> 
> > # bioctl -c C -l sd0a softraid0
> > New passphrase:
> > Re-type passphrase:
> > sd3 at scsibus3 targ 1 lun 0:  SCSI2 0/direct fixed
> > sd3: 114470MB, 512 bytes/sector, 234435953 sectors
> > softraid0: CRYPTO volume attached as sd3
> 
> Here you need to do this first:
> 
>   cd /dev
>   sh MAKEDEV sd3
> 
> > # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> > uid 0 on /: file system full
> 
> If you skip the above step, /dev/rsd3c is created as a regular file and fills
> up the root fs.

I'll tell everyone the secret.

The ramdisk does not contain disk device nodes.  We potentially need
too many.  So it creates them on the fly, in the script.

As soon as you go into do-things-by-hand, you are on your own.

Re: CRYPTO volume created, but appears as full

[Sebastien Marie]

On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote:

[...]
> # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
> uid 0 on /: file system full
> 
> /: write failed, file system is full
> dd: /dev/rsd3c: No space left on device
> 1+0 records in
> 0+0 records out
> 0 bytes transferred in 0.007 secs (0 bytes/sec)
> 
[...]
> OpenBSD 6.0-beta (RAMDISK_CD) #1915: Wed May 25 12:32:35 MDT 2016
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD

Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the
/dev/sd* aren't created by default.

You could check that with:
# ls -l /dev/rsd3c

I think you create a new (regular) file /dev/rsd3c in / partition (and
so filling / partition).

To make sd3 device:
# cd /dev && ./MAKEDEV sd3

-- 
Sebastien Marie

Re: CRYPTO volume created, but appears as full

[Ivan Markin]

Robert Campbell:
> I followed the steps in the FAQ for setting up full disk encryption.
> Everything goes according to plan until I attempt to write zeros to the
> first megabyte of the new pseudo-device; as you can see below, dd informs
> me that the file system is full, that there is no space left on the device.
> Interestingly, the last line of dmesg is also "uid 0 on /: file system
> full". I've retried this with 5.9 and -current, but the outcome is the
> same. I've also tried rebooting after disklabel and bioctl. I have pasted
> below the relevant sequence, followed by the full dmesg.

I've experienced same behavior. It always happened when sd(4) driver is
in use and never with wd(4). I managed to enable FDE using random
disklabel(8) tricks. This is probably a bug in sd(4).
Try to initialize your disk with standard disklabel without CRYPTO first
(e.g. via installation program then exit to shell). Then perform the
steps from FDE guide.

--
Ivan Markin

Re: hardware recommendation for openbsd-based thin client?

[Henri Kemppainen]

I have a Shuttle DS437 and DS57U7 for desktop.  Fanless, small, and the former
in particular is pretty affordable.  These are sold as barebones so you only add
the components you need -- in your case, probably nothing but RAM.

Do note that the case must stand upright, so they're not as convenient as an APU
lying flat in an environment where random people can knock things over.

CRYPTO volume created, but appears as full

[Robert Campbell]

I followed the steps in the FAQ for setting up full disk encryption.
Everything goes according to plan until I attempt to write zeros to the
first megabyte of the new pseudo-device; as you can see below, dd informs
me that the file system is full, that there is no space left on the device.
Interestingly, the last line of dmesg is also "uid 0 on /: file system
full". I've retried this with 5.9 and -current, but the outcome is the
same. I've also tried rebooting after disklabel and bioctl. I have pasted
below the relevant sequence, followed by the full dmesg.

# dd if=/dev/random of=/dev/rsd0c bs=1m
dd: /dev/rsd0c: short write on character device
dd: /dev/rsd0c: end of device
114474+0 records in
114473+1 records out
120034123776 bytes transferred in 3217.122 secs (37311023 bytes/sec)
# fdisk -iy sd0
Writing MBR at offset 0.
# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
> a a
offset: [64]
size: [234436481] *
FS type: [4.2BSD] RAID
> w
> q
No label changes.
# bioctl -c C -l sd0a softraid0
New passphrase:
Re-type passphrase:
sd3 at scsibus3 targ 1 lun 0:  SCSI2 0/direct fixed
sd3: 114470MB, 512 bytes/sector, 234435953 sectors
softraid0: CRYPTO volume attached as sd3
# dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
uid 0 on /: file system full

/: write failed, file system is full
dd: /dev/rsd3c: No space left on device
1+0 records in
0+0 records out
0 bytes transferred in 0.007 secs (0 bytes/sec)


DMESG:


OpenBSD 6.0-beta (RAMDISK_CD) #1915: Wed May 25 12:32:35 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 4261072896 (4063MB)
avail mem = 4130086912 (3938MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffb7020 (7 entries)
bios0: vendor coreboot version "88a4f96" date 03/07/2016
bios0: PC Engines apu2
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD GX-412TC SOC, 998.28 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC
NT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,
ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB
64b/line 16-
way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins
ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PBR4)
acpiprt2 at acpi0: bus 1 (PBR5)
acpiprt3 at acpi0: bus 2 (PBR6)
acpiprt4 at acpi0: bus 3 (PBR7)
acpiprt5 at acpi0: bus 4 (PBR8)
acpicpu at acpi0 not configured
"PNP0C0C" at acpi0 not configured
"PNP0501" at acpi0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Root Complex" rev 0x00
pchb1 at pci0 dev 2 function 0 "AMD AMD64 16h Host" rev 0x00
ppb0 at pci0 dev 2 function 2 "AMD AMD64 16h PCIE" rev 0x00: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi, address
00:0d:b9:41:5f:
30
ppb1 at pci0 dev 2 function 3 "AMD AMD64 16h PCIE" rev 0x00: msi
pci2 at ppb1 bus 2
em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03: msi, address
00:0d:b9:41:5f:
31
ppb2 at pci0 dev 2 function 4 "AMD AMD64 16h PCIE" rev 0x00: msi
pci3 at ppb2 bus 3
em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03: msi, address
00:0d:b9:41:5f:
32
ppb3 at pci0 dev 2 function 5 "AMD AMD64 16h PCIE" rev 0x00: msi
pci4 at ppb3 bus 4
vendor "Atheros", unknown product 0x003c (class network subclass
miscellaneous,
rev 0x00) at pci4 dev 0 function 0 not configured
"AMD CCP" rev 0x00 at pci0 dev 8 function 0 not configured
xhci0 at pci0 dev 16 function 0 "AMD Bolton xHCI" rev 0x11: msi
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 "AMD xHCI root hub" rev 3.00/1.00 addr 1
ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: apic 4 int
19, AHC
I 1.3
ahci0: port 0: 6.0Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI3 0/direct
fixed
naa.5002538d40b63943
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
ehci0 at pci0 dev 19 function 0 "AMD Hudson-2 USB2" rev 0x39: apic 4 int 18
usb1 at ehci0: USB revision 2.0
uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1
"AMD Hudson-2 SMBus" rev 0x42 at pci0 dev 20 function 0 not configured
"AMD Hudson-2 LPC" rev 0x11 at pci0 dev 20 function 3 not configured
sdhc0 at pci0 dev 20 function 7 "AMD Bolton SD/MMC" rev 0x01: apic 4 int 16
sdhc0: SDHC 2.0, 63 MHz base clock
sdmmc0 at sdhc0: 4-bit, 

Re: hardware recommendation for openbsd-based thin client?

[Stuart Henderson]

On 2016-05-28, Carson Chittom  wrote:
> Stuart Henderson  writes:
>
>> On 2016-05-27, Marko Cupać  wrote:
>>> Hi,
>>>
>>> I have just noticed that pcengines has alix models with VGA ports:
>>>
>>> http://www.pcengines.ch/alix3d3.htm
>>> http://www.pcengines.ch/alix1e.htm
>>>
>>> Anyone tried OpenBSD on them?
>>
>> Yep. It worked, including X - I used one with autologin to a browser to
>> display a job schedule on a wallscreen. This was some years ago though,
>> I wouldn't buy one for that job now.
>
> OK, I'll bite:  what *would* you buy for that job now?

Depends. And caveat: for that particular job I wouldn't care
about accelerated X and would be willing to use the framebuffer.

If I was buying just one and wanted higher chances of it working
I'd probably look at a broadwell NUC, but they're expensive.

If it was something where I could afford to buy one to try with
a higher risk of it not working I'd probably get some braswell
box (NUC, asrock beebox, etc) to play with as they're a lot
cheaper, and offer it to a developer working in that area if
it didn't work out at all.

Last time I needed a bunch of machines for a somewhat similar
task I *did* need accelerated X, didn't quite negotiate the
minefield of graphics chip models and started with a N2830
NUC which wasn't accelerated. Then switched to Haswell NUCs
which are working nicely, but they were just going EoL and
we only just managed to scrape together enough stock from
among a couple of distributors for the deployment ;)

BTW I just tried booting that Bay Trail N2830 and it's now
working nicely in -current.

Re: I need to get a Russian keyboard

[ropers]

On 28 May 2016 at 02:33, Brandon Vincent  wrote:

> When I saw this thread, I was reminded of my attempts to get a
> keyboard as cool (although inaccurate) as the one in Tomorrow Never
> Dies (1997).
>

I once knew a feller called Tom Morrow who was a draper by trade. He had a
roll of white cotton fabric and a supply of carmine, but he refused to sell
me red cloth.

Re: hardware recommendation for openbsd-based thin client?

[Carson Chittom]

Stuart Henderson  writes:

> On 2016-05-27, Marko Cupać  wrote:
>> Hi,
>>
>> I have just noticed that pcengines has alix models with VGA ports:
>>
>> http://www.pcengines.ch/alix3d3.htm
>> http://www.pcengines.ch/alix1e.htm
>>
>> Anyone tried OpenBSD on them?
>
> Yep. It worked, including X - I used one with autologin to a browser to
> display a job schedule on a wallscreen. This was some years ago though,
> I wouldn't buy one for that job now.

OK, I'll bite:  what *would* you buy for that job now?

Re: the balance between OpenBSD and life

[Peter N. M. Hansteen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

On 05/28/16 14:24, Teng Zhang wrote:
> I can't adjust  the time for OpenBSD and my life appropriately.
> Could you please share your experience with me about how you adjust
> your time between OpenBSD and your life.

That is a very, very odd question to ask.

In my experience, keeping an OpenBSD system (or multitudes) running
requires significantly less effort than most Unixish systems I've
encountered.

If you feel that OpenBSD is consuming too much of your time, I would
recommend checking what it is you're doing wrong. Following outdated
HOWTOs that insist that upgrades of both base system and ports
(pakcages) must be done by cvs checkout and rebuild on each individual
system, perhaps?

That's just a wild guess, or course.

On the other hand, if you're aiming to master the internals of the
system, you should expect to spend significant time studying,
experimenting, making mistakes and fixing them.

> thanks for any reply.

I'm sure replies will be more constructive if you offer up some more
information about the actual problem.

- -- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
iQIcBAEBCAAGBQJXSag7AAoJELJiGF9h4DyeqOYQALiGrmanTSLTzAHHTEx59Gn6
7pCzq8KWAgu+d5J2nWXiVD3TXhbKr/+lLr6L8eGOu6VYLOJwoMjWExtZNYRun3O3
htawgHvJKhmWYcP+/nUBow2Tglq7a4fyUp3Om1c6HKRqDz0UuRteRCbcknuuHOGs
WWzgUj0ktYU1xrkvApzV34sCXEtkf2mhnuWFWAErZZK5DBpTH+TmCZnautKCNdJA
jKQUQM0EB2JWp1VCFqLoYAIlZhUCYC0i6n8XiHQPpZFRDFGRE3OeRgVZq22rmYbD
NFBQ+JmGh5MXmlVMte4VWNouRENkrbaLFzDOhQA0jM6LKVD2YzIiWYxv9pOSO+DC
Fvj4qfavbRBhkmtBD3C74Vd4h2a28niCKih1FDU+70DXzNSCNVaqvM1g5dS5iRrb
ggyav+v089qPmCf8YSaVd5ImOQy0JSreJOzftB3ykWIQ3Ei5uehiuJvEQx4fFq1K
aH+3HY5GzixCQzffgD83dekOuv0IBFGNOYsIpE/0RSdu4UNjNZFxhgn00aS70uEg
VhtKOlppDyp/BBHgk7oHi/8t0/Dl065Xb/MKg8CNQicjWEX++14Cm6U3tLkai50N
COCQgkLYLYrfCm6Z6UfE48HONDI6a16B5BhWxkUkwfOZnUun2uSCFp6MpQY5GhEf
t8bbAF1uS+hbJlM5BfB2
=hu0v
-END PGP SIGNATURE-

Re: the balance between OpenBSD and life

[Joseph Oficre]

Lmao. kk, i just use snapshots and packages, no compilation, no headache.

2016-05-28 15:24 GMT+03:00 Teng Zhang :

> I can't adjust  the time for OpenBSD and my life appropriately. Could you
> please share your experience with me about how you adjust your time between
> OpenBSD and your life.
> thanks for any reply.

Re: the balance between OpenBSD and life

[Raul Miller]

On Sat, May 28, 2016 at 8:24 AM, Teng Zhang  wrote:
> I can't adjust  the time for OpenBSD and my life appropriately. Could you
> please share your experience with me about how you adjust your time between
> OpenBSD and your life.
> thanks for any reply.

I am not at all sure what you mean by "appropriately", but one trick
might be to limit posts to the lists to constructive topics?

-- 
Raul

the balance between OpenBSD and life

[Teng Zhang]

I can't adjust  the time for OpenBSD and my life appropriately. Could you
please share your experience with me about how you adjust your time between
OpenBSD and your life.
thanks for any reply.

Re: Suspend / hibernate does not work

[Martin Oppegaard]

On Fri, May 27 2016, Mike Larkin wrote:
> On Fri, May 27, 2016 at 04:09:21PM +, Martin Oppegaard wrote:
>> Hi,
>> 
>> I can't get suspend or hibernate to work with this computer.  It has
>> encrypted root hdd and apmd is running (-A).  When I suspend the screen
>> goes into standby and the power LED starts blinking, but nothing spins
>> down (same amount of power is drawn from the UPS), and it will not
>> resume.  In this state if I press the restart button the CPU fan calms
>> down and less power is drawn from the UPS, but I have to hold the power
>> button to shut it down.
>> 
>> With hibernate, it restarts immediately.
>> 
>> Any tips?
>> 
>> Regards,
>> 
>> Martin Oppegaard
>
> When I was first starting the initial hibernate coding, I used this exact
> same machine (P6T Deluxe V2), and ran into the exact same problems you did.
> I even had a similar radeon (I think mine was a 5950). It worked occasionally,
> but was never stable.
>
> I was never able to track down what was failing. This MB was one of
> the first ones to support the core-i* series and had a fair number of BIOS
> bugs. I upgraded the BIOS, and things got worse (random reboots and hangs)
> and when I downgraded the BIOS, I bricked the machine. After that, it got
> tossed in the trash.
>
> Sorry I don't have better news for you.
>
> -ml

Thank you for the quick reply!  Unfortunate news, but now at least I can
stop spending time on this.

Regards,

Martin Oppegaard

PS.: After I disabled something Intel Speedturbo in the bios I've never
had any problems with this machine.