Re: ftp.openbsd.org: tlsv1 alert protocol version

[Rudolf Leitgeb]

Could be IPv6 related, because with IPv4 it works:

rudolf@variable-7400:~$ curl --verbose
https://ftp.openbsd.org/pub/OpenBSD/patches/7.4/common/001_xserver.patch.sig
*   Trying 199.185.178.81:443...
* Connected to ftp.openbsd.org (199.185.178.81) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=ftp.openbsd.org
*  start date: Sep 19 15:39:09 2023 GMT
*  expire date: Dec 18 15:39:08 2023 GMT
*  subjectAltName: host "ftp.openbsd.org" matched cert's
"ftp.openbsd.org"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/1.x
> GET /pub/OpenBSD/patches/7.4/common/001_xserver.patch.sig HTTP/1.1
> Host: ftp.openbsd.org
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK


On Wed, 2023-10-25 at 10:49 +0200, Martin Schröder wrote:
> Hi,
> downloading the latest patches on 7.4 fails with
> 
> > curl --verbose
> > https://ftp.openbsd.org/pub/OpenBSD/patches/7.4/common/001_xserver.patch.sig
> *   Trying [2620:3d:c000:178::81]:443...
> * Connected to ftp.openbsd.org (2620:3d:c000:178::81) port 443
> * ALPN: curl offers h2,http/1.1
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> *  CAfile: /etc/ssl/cert.pem
> *  CApath: none
> * LibreSSL/3.8.2: error:1400442E:SSL
> routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
> * Closing connection
> curl: (35) LibreSSL/3.8.2: error:1400442E:SSL
> routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version
> 
> Best
>  Martin
> 

Re: Understanding -current as 7.4 is released

[Rudolf Leitgeb]

On Fri, 2023-10-06 at 11:06 -0600, Theo de Raadt wrote:

> Other operating systems do not have a vast number of people using 
> daily snapshots in the way our users do, so it is only our users who
> have this experience.

Your expectation is, that people using snap shots, because they are 
part of the dev and test community interested in early and frequent
releases.

However, there are folks who use snap shots, because the stable release
doesn't yet support their hardware, and for these people it would be 
helpful to have a simple way to move from snap shot to stable. They are
typically new to the system overall, therefore what's complex for us 
may well be confusing to them.

Re: Require host-name from DHCP clients

[Rudolf Leitgeb]

On Wed, 2023-09-27 at 06:48 +, Tris wrote:
> 
> --- Original Message ---
> On Wednesday, September 27th, 2023 at 8:42 AM, Florian Obser
>  wrote:
> 
> 
> > On 2023-09-27 01:01 +02, Joel Carnat j...@carnat.net wrote:
> > 
> > > Hi,
> > > 
> > > Because of Apple Private Address feature, my static IP
> > > allocations based
> > > on MAC address (hardware ethernet) doesn't work anymore. Looking
> > > at
> > > dhcpd.leases, some devices provide a client-hostname value ; but
> > > not
> > > every one.
> > > 
> > > Is there a dhcpd.conf configuration parameter that forces DHCP
> > > clients
> > > to send a client-hostname information in their DHCP request?
> > 
> > 
> > My understanding of the dhcp protocol is that this can't work. The
> > client sends a bunch of things and requests a bunch of stuff. The
> > server
> > can honour that request or decline it. But it can't say: I'd give
> > you a
> > lease if you'd give me a hostname.
> > 
> > The server can decline to give a lease without a hostname in the
> > request, but then the client would be left guessing why it didn't
> > get a
> > lease.
> > 
> > > And if so, can this information be used by dhcpd(8) to apply a
> > > fixed-address to those device?
> > > 
> > > Thank you,
> > > Joel C.
> > 
> > 
> > --
> > In my defence, I have been left unsupervised.
> 
> From what I see on my network with the private address feature, is
> that it uses the same MAC address on the same WiFi network. It only
> uses a different one per network. 
> 
> My Apple devices "seem" to get the same IP address on the home
> network.
> 

So what you actually want is this:

1.) if client submits hostname, provide with IP address regardless of 
its MAC address

2.) if you didn't serve the client in step 1, look at the client's
MAC address and see, whether you have something in store

3.) host is not served yet, hand out address from pool.

Re: undocumented command switches -OR- fix documentation fully

[Rudolf Leitgeb]

"professional conferences and scientific education" typically 
employ a quite vigorous process to vet their speakers. This has
clearly not happened here ...

Regarding "Who do you think you're talking to": this has basically
devolved into a pointless dialog between the two of us, since there
is all but thundering silence from the actual devs here.




On Mon, 2023-09-25 at 21:59 +, Eponymous Pseudonym wrote:
> Every one, Every where, All ways, You too.  That's what professional
> conferences and scientific education is for.  Who do you think you're
> talking to, the mailing list archive readers of a social club for
> knitting for the elderly?  That is correct too.  Time will and does
> demonstrate it perfectly.
> 
> On 9/25/23, Rudolf Leitgeb  wrote:
> > Are you trying to teach the OpenBSD devs how to write good
> > software?
> > 
> > Unix software?
> > 
> > Really?
> > 
> > REALLY ?
> > 
> > On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote:
> > > Standardisation, specification and documentation as a starting
> > > point
> > > for software creation is a normal, reliable and mandated
> > > (formally)
> > > methodology used everywhere from business to scientific,
> > > industrial,
> > > medical and military applications.  It is not only normal but
> > > expected
> > > and even required that amateur free and open software follow the
> > > same
> > > processes and procedures as professional modelling and
> > > implementation,
> > > especially on historically significant long term projects that
> > > are
> > > also programming languages and interpreters.
> > > 
> > > It's not a surprise to you, everything in UNIX is a compiler
> > > construction reuse tooling and a small (and large) domain
> > > specific
> > > languages.  That is the essence of the system.  OpenBSD is a
> > > descendant of UNIX, not a free walk in the green pastures of
> > > experimental shareware.  Now, let's get back to more productive
> > > time
> > > and space utilisation, kids, good ideas.. third party re-imports
> > > are
> > > waiting their normalisation and stabilisation to robust and
> > > reliable
> > > distillations of core "base and extended" system modular
> > > componentry.
> > > Re-read the long version of the previous post after some
> > > specialised
> > > references again, and you will see and understand what I outlined
> > > clearly.
> > > 
> 
> https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text
> https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History
> https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles
> 
> > > 
> > > Thanks for the discussion and support, I've said my points and
> > > think
> > > we're in accord and agreement on all details referenced.
> > > 
> > > On 9/25/23, Rudolf Leitgeb  wrote:
> > > > If you document a switch, you are basically required to keep
> > > > that
> > > > functionality around forever. Given that the OpenBSD devs don't
> > > > like
> > > > these --options all that much, I don't see that happening.
> > > > Submitting
> > > > a patch won't change that.
> > > > 
> > > > IMHO there's nothing wrong, if software can do more than its
> > > > documentation shows. It's not like it breaks documented
> > > > behavior.
> > > > 
> > > > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote:
> > > > > Don't rant that long.
> > > > > 
> > > > > Sometimes, documentation and code get out-of-synch for a lot
> > > > > of
> > > > > reasons.
> > > > > 
> > > > > - trying out stuff and documenting later.
> > > > > - plain forgetting to update the documentation.
> > > > > - having some stuff for a transition period, and then killing
> > > > > it.
> > > > > 
> > > > > Your point that stuff that stays around, should ideally be
> > > > > documented,
> > > > > is a good point.
> > > > > 
> > > > > Now, you gotta realize that people have limited time to do
> > > > > everything.
> > > > > 
> > > > > In general, patches are welcome.
> > > > > 
> > > > > In my long tenure on various tools, I've learnt that
> > > > > documenting
> > > > > stuff is always always a good idea: if you get a new feature
> > > > > BUT
> > > > > you can't explain it cleanly, then you should go back to the
> > > > > drawing-board !

Re: undocumented command switches -OR- fix documentation fully

[Rudolf Leitgeb]

Are you trying to teach the OpenBSD devs how to write good software?

Unix software?

Really?

REALLY ?

On Mon, 2023-09-25 at 21:11 +, Eponymous Pseudonym wrote:
> Standardisation, specification and documentation as a starting point
> for software creation is a normal, reliable and mandated (formally)
> methodology used everywhere from business to scientific, industrial,
> medical and military applications.  It is not only normal but
> expected
> and even required that amateur free and open software follow the same
> processes and procedures as professional modelling and
> implementation,
> especially on historically significant long term projects that are
> also programming languages and interpreters.
> 
> It's not a surprise to you, everything in UNIX is a compiler
> construction reuse tooling and a small (and large) domain specific
> languages.  That is the essence of the system.  OpenBSD is a
> descendant of UNIX, not a free walk in the green pastures of
> experimental shareware.  Now, let's get back to more productive time
> and space utilisation, kids, good ideas.. third party re-imports are
> waiting their normalisation and stabilisation to robust and reliable
> distillations of core "base and extended" system modular componentry.
> Re-read the long version of the previous post after some specialised
> references again, and you will see and understand what I outlined
> clearly.
> 
> https://en.wikipedia.org/wiki/Software_crisis?useskin=vector#mw-content-text
> https://en.wikipedia.org/wiki/Component-based_software_engineering?useskin=vector#History
> https://en.wikipedia.org/wiki/List_of_software_development_philosophies?useskin=vector#Rules_of_thumb,_laws,_guidelines_and_principles
> 
> Thanks for the discussion and support, I've said my points and think
> we're in accord and agreement on all details referenced.
> 
> On 9/25/23, Rudolf Leitgeb  wrote:
> > If you document a switch, you are basically required to keep that
> > functionality around forever. Given that the OpenBSD devs don't
> > like
> > these --options all that much, I don't see that happening.
> > Submitting
> > a patch won't change that.
> > 
> > IMHO there's nothing wrong, if software can do more than its
> > documentation shows. It's not like it breaks documented behavior.
> > 
> > On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote:
> > > Don't rant that long.
> > > 
> > > Sometimes, documentation and code get out-of-synch for a lot of
> > > reasons.
> > > 
> > > - trying out stuff and documenting later.
> > > - plain forgetting to update the documentation.
> > > - having some stuff for a transition period, and then killing it.
> > > 
> > > Your point that stuff that stays around, should ideally be
> > > documented,
> > > is a good point.
> > > 
> > > Now, you gotta realize that people have limited time to do
> > > everything.
> > > 
> > > In general, patches are welcome.
> > > 
> > > In my long tenure on various tools, I've learnt that documenting
> > > stuff is always always a good idea: if you get a new feature BUT
> > > you can't explain it cleanly, then you should go back to the
> > > drawing-board !

Re: undocumented command switches -OR- fix documentation fully

[Rudolf Leitgeb]

If you document a switch, you are basically required to keep that
functionality around forever. Given that the OpenBSD devs don't like
these --options all that much, I don't see that happening. Submitting
a patch won't change that.

IMHO there's nothing wrong, if software can do more than its 
documentation shows. It's not like it breaks documented behavior.

On Mon, 2023-09-25 at 20:58 +0200, Marc Espie wrote:
> Don't rant that long.
> 
> Sometimes, documentation and code get out-of-synch for a lot of
> reasons.
> 
> - trying out stuff and documenting later.
> - plain forgetting to update the documentation.
> - having some stuff for a transition period, and then killing it.
> 
> Your point that stuff that stays around, should ideally be
> documented,
> is a good point.
> 
> Now, you gotta realize that people have limited time to do
> everything.
> 
> In general, patches are welcome.
> 
> In my long tenure on various tools, I've learnt that documenting
> stuff is always always a good idea: if you get a new feature BUT
> you can't explain it cleanly, then you should go back to the
> drawing-board !
> 

Re: Unclear Memory Leakage since OpenBSD 7.3 upgrade (nginx and MariaDB; Not consistent)

[Rudolf Leitgeb]

Either this, or the TLS 1.3 code was always buggy, but now
it was actually used per default. Question: is there a similar
commit in your DNS server? Do you use this DNS server with 
anything like TLS?

On Sun, 2023-09-24 at 21:31 +0200, Tobias Fiebig wrote:
> 
> > But yes, getting a specific commit there will be helpful.
> Sadly it turns out that it is the commit i feared it would be:
> 
> > commit 7b24b93d67daa9c16d665129fd5d3e7dbc583e4f
> > Author: Maxim Dounin 
> > Date:   Fri Mar 24 02:57:43 2023 +0300
> > 
> >     SSL: enabled TLSv1.3 by default.
> 
> Feared, because it basically puts me back to start w.r.t. what the
> root
> cause might be; Could be anything that happened to TLSv1.3 code in
> either LibreSSL or Nginx.

Re: Unclear Memory Leakage since OpenBSD 7.3 upgrade (nginx and MariaDB; Not consistent)

[Rudolf Leitgeb]

This libpcre2 library seems to be the only one, which is not
used all over the place. The library itself may not even be buggy, it
may just return something, which the new versions of the caller can't 
handle, or it may be unhappy with something the new callers send.

Still: if you can tie this memory/cpu leak to the interaction between
application and that library, it should be much easier to identify
the offending commit in nginx and all the other affected programs.

I just saw, that the version 8 of libpcre2 seems to be quite a bit
behind the current version: 
https://github.com/PCRE2Project/pcre2/releases


Is this intentional?


On Sun, 2023-09-24 at 12:59 +0200, Tobias Fiebig wrote:
> They do, but nothing special. The common set between nginx and mysqld
> is:
> 
> /usr/local/lib/libpcre2-8.so.0.6
> /usr/lib/libssl.so.53.2
> /usr/lib/libcrypto.so.50.2
> /usr/lib/libz.so.7.0
> /usr/lib/libc.so.97.0
> /usr/libexec/ld.so
> 
> However, an affected nginx (1.24.0) does not differ from an
> unaffected
> nginx (1.23.1). 
> 
> I somewhat hope that my testing through nginx commits will yield what
> calls are actually involved, and may allow me to see whether mysql is
> pushed into similar codepaths on affected systems (and not on
> unaffected ones), likely giving a better hint as to where the issue
> is.
> 
> With best regards,
> Tobias
> 
> On Sun, 2023-09-24 at 12:53 +0200, Rudolf Leitgeb wrote:
> > Do the affected programs use the same libraries?
> > 
> > On Sun, 2023-09-24 at 09:32 +0200, Tobias Fiebig wrote:
> > > After upgrading to 7.3 and nginx-1.24.0, i started to see heavy
> > > memory
> > > leakage over time. I initially attributed this to nginx, and
> > > solved
> > > the
> > > issue by ignoring it/throwing a bit more memory at the box for
> > > some
> > > time. However, I started debugging it now and could trace it to
> > > some
> > > commit between nginx 1.23.3 and 1.23.4; Currently, I am going
> > > through
> > > all commits to see with which version it first appears.
> > > 
> > > However, clicking around this morning, i noticed that my primary
> > > NS
> > > shows a similar memory leakage for mysql/mariadb (runs powerdns
> > > with
> > > a
> > > mysql backend, both from packages) since the upgrade to 7.3 in
> > > May
> > > as
> > > well. One further host seems to show a significantly higher use
> > > of
> > > inactive memory since 7.3. I found one more host with mariadb
> > > that
> > > now
> > > shows a higher utilization of inactive memory (gitea+maria);
> > > However,
> > > other maria+X instances on 7.3 run fine.
> > 
> 

Re: Unclear Memory Leakage since OpenBSD 7.3 upgrade (nginx and MariaDB; Not consistent)

[Rudolf Leitgeb]

Do the affected programs use the same libraries?

On Sun, 2023-09-24 at 09:32 +0200, Tobias Fiebig wrote:
> After upgrading to 7.3 and nginx-1.24.0, i started to see heavy
> memory
> leakage over time. I initially attributed this to nginx, and solved
> the
> issue by ignoring it/throwing a bit more memory at the box for some
> time. However, I started debugging it now and could trace it to some
> commit between nginx 1.23.3 and 1.23.4; Currently, I am going through
> all commits to see with which version it first appears.
> 
> However, clicking around this morning, i noticed that my primary NS
> shows a similar memory leakage for mysql/mariadb (runs powerdns with
> a
> mysql backend, both from packages) since the upgrade to 7.3 in May as
> well. One further host seems to show a significantly higher use of
> inactive memory since 7.3. I found one more host with mariadb that
> now
> shows a higher utilization of inactive memory (gitea+maria); However,
> other maria+X instances on 7.3 run fine.

Re: Checking OpenBSD host type

[Rudolf Leitgeb]

See this response for the same command on my EdgeRouter:


edgy# sysctl hw   
hw.machine=octeon
hw.model=Cavium OCTEON (rev 0.2) @ 1000 MHz
hw.ncpu=4
hw.byteorder=4321
hw.pagesize=16384
hw.disknames=sd0:3b7d06c5b561182c
hw.diskcount=1
hw.cpuspeed=1000
hw.product=cavium,ubnt_e300
hw.physmem=1073741824
hw.usermem=1073709056
hw.ncpufound=4
hw.allowpowerdown=1
hw.ncpuonline=4
hw.power=1


Whatever hypervisor you may use, the output will be substantially
different from a regular CPU.



On Tue, 2023-09-19 at 17:17 +0200, Alessandro Baggi wrote:
> 
> 
> Il 19/09/23 16:51, Denis Fondras ha scritto:
> > Le Tue, Sep 19, 2023 at 03:13:21PM +0200, Alessandro Baggi a écrit
> > :
> > > Hi list,
> > > there is a way to check if  OpenBSD runs on VM or physical
> > > hardware?
> > > 
> > > Something like in sysctl or similar.
> > > 
> > > Thank you in advance.
> > > 
> > 
> > You may want to check the `hw` variable :
> > 
> > $ sysctl hw
> > [...]
> > hw.model=Common KVM processor
> > hw.vendor=QEMU
> > [...]
> > 
> 
> Hi and thank you for your answer.
> 
> I already seen this in sysctl but what if another hypervisor is used?
> Like VMWare or other?
> 
> Thank you in advance.
> 

Re: desire for journaled filesystem

[Rudolf Leitgeb]

If push comes to shove, then the journaling file system may lose
more data, but it will be consistent. FFS will have written as much
as possible, sometimes without association with an inode, that's when
people encounter full lost+found directories.

Neither file system will correctly record the most recent additions,
but will most likely hold on to all the old stuff. Backup is therefore
of little help in most situations like this.

>From this perspective the main difference is, that a journaling FS
will be consistent and bootable after each and every crash (and I've 
seen hundreds), whereas I have positively seen instances, in which FFS
would throw me into root console and ask for manual fsck.

The latter is not much of a problem in a desktop (assuming you know 
how to clean up), but definitely a big nuissance for routers or off site
machines. I do agree, that home routers (like my EdgeRouter) should run on
a readonly FS to avoid this problem the right way, not scream for FS
journals.

On Wed, 2023-09-06 at 08:05 +0200, Janne Johansson wrote:
> Den tis 5 sep. 2023 kl 20:53 skrev John Holland :
> > 
> > I have a backup that is at least 2 days old offsite at a friend’s house. It 
> > would be a
> > bit of a pain to go retrieve it, but I could do that.
> > 
> >  Short of that, I have 4000+ files in lost+found with names like #1094827. 
> > What can I
> > do with those? I tried running “file” on the first 50 via xargs and they 
> > mostly at
> > least purport to be some sort of intact file. How can I determine what they 
> > are?
> > Please don’t suggest that I manually use “file” and then an appropriate 
> > program to
> > examine each one in turn
> > 
> 
> Those "files" are fragments of files, named after the inode number,
> which you get when fsck finds a not-complete chain of
> directory-entry/filename -> inode -> linked list of file-contents.
> 
> While fsck can't figure out the filename and where in the directory
> structure it is meant to belong, or possibly if it is only some part
> of a whole file, it will give you a chance to recover at least partial
> contents from the lost+found folder. Sometimes this might be awesome
> if you can dig out some key or pw needed for something super
> important, sometimes you get half of a database file and that is
> probably close to zero usefulness.
> 
> That said, if it was (as written later) browser cache and partial
> downloads, it is not very surprising that data files exist which are
> not yet linked during the download, or temp files unlinked for later
> deletion by the FS, had the computer not crashed. If you had something
> like zfs, those half-written or half-deleted files might just have
> been totally missing instead of ending up in lost+found, since they
> represent a point-in-time in which the FS is not in a consistent
> state, so the end result would mostly have been the same, this data is
> not visible under your home account after the crash.
> 
> Journaling has some great advantages, like write aggregation if your
> journal can be placed on a faster device and when it comes to quick
> checkups after crashes, an empty journal often means the fs was not in
> a broken state and probably needs less or no total checkup by fsck
> tools, which is nice.
> It will not fix a half-downloaded ISO or unlinked temp files that you
> for some reason want to look at afterwards, nor will the journal fix
> any kind of broken sectors, though checksumming file systems will of
> course help you find the errors before handing the bad sectors over to
> your applications.
> 

Re: desire for journaled filesystem

[Rudolf Leitgeb]

On Tue, 2023-09-05 at 14:16 -0400, John Holland wrote:
> So this gave me the list of the files with what they seem to be in 
> groups. I think a lot of them are browser cache, jpegs, pngsI
> looked 
> at some of the gzipped ones and they were web pages and css files.
> 
> There are some that don't make sense, for instance #16251989 is
> listed 
> as "ISO Media " and contains binary data and then some HTML.

So: great surprise, most of these lost+found files are browser cache 
stuff, which was created just before the big crash. This is the kind of
stuff which hasn't been written to disk yet. It's extremely unlikely,
that you'll find a file in lost+found, which you haven't touched in 
jours/days before the crash.

I would suggest, you ignore this lost+found directory for now, and only
if you can't find some important data you can search this directory 
based on strings which should be in the missing file.

Maybe that's, why OpenBSD never cared about a journaling FS ...

Re: Possible off-by-one bug in usr.sbin/rad/engine.c

[Rudolf Leitgeb]

Coming from a C/C++ background, I would assume, that a range from
200 to 600 comprises numbers would start at 200 and reach as far
as 599. This would be in sync with all STL functions for iterating
through collections or for extracting ranges.

As long as you need two random numbers to craft seconds and
microseconds values, it will be anything but easy to create
a uniform distribution going from 200.000 all the way up
to and including 600.00. As others have already pointed
out, your initially proposed fix certainly does not achieve this.

> Gesendet: Sonntag, 01. Januar 2023 um 15:33 Uhr
> Von: "Alejandro Colomar" 
> An: "Florian Obser" , "Ingo Schwarze" 
> Cc: misc@openbsd.org
> Betreff: Re: Possible off-by-one bug in usr.sbin/rad/engine.c
>
> 
> 
> On 1/1/23 14:48, Alejandro Colomar wrote:
> > Hello Florian, Ingo,
> > 
> > On 1/1/23 08:24, Florian Obser wrote:
> >> On 2022-12-31 23:54 +01, Ingo Schwarze  wrote:
> 
> [...]
> 
> >>>
> >>> With your change, the timeout could go up to 600.99, i.e. almost 601
> >>> seconds.  I don't know the protocol and can't say whether the change
> >>> would matter, but naively, exceeding the MAX_ feels surprising to me.
> 
> Oops, I missed this part.  That's where it makes sense. :)
> 
> >>>
> >>> Really, this doesn't look like a bug to me...
> >>
> >> Unfortunately the OP did not explain why they think this is a bug.
> > 
> > Sorry; my bad; I should have explained it.
> > 
> > The thing that led me to believe that it was a bug is that variables or 
> > constants called *max* (normally) refer to the maximum value allowed in a 
> > range, 
> > for which there usually is a *min* counterpart (when it's not simply 0).
> > 
> > In this case, it seems MAX_* is really the maximum+1.  I don't know what 
> > the 
> > code is about, so 200 and 600 just look like magic numbers to me, and I 
> > don't 
> > know if the maximum is 600 or actually 599.
> > 
> >>
> >>>
> >>> Yours,
> >>>    Ingo
> >>
> > 
> > Cheers,
> > Alex
> > 
> 
> -- 
> 
>

Re: news from my hacked box

[Rudolf Leitgeb]

> Yes could be, he has a "social engineering" approach to people. He places 
> people and
> himself on the same level of machines. Then he searches vulnerability on 
> persons.
> He makes extensive use of corruption to take advantage on his personal war. 
> From this
> point of view also a vpn provider could be very vulnerable because as many 
> people know
> vpn providers are not big rich companies.

You would use a VPN to escape the claws of your own government, but not the 
claws of
some corrupt individual in your country. Therefore I see no reason, why you 
would use
a VPN, and its required software to use it would just increase your attack 
surface.

> About authorities it would be my next step when I'll find proofs of what I'm 
> saying.
> Because as you saw the first thing they think it will be "this guy is 
> paranoid".

That's the great benefit of virtual machines with snap shoting: unless the 
"evil hackers"
can not only control your running system, but can also break through the 
boundaries set
by your virtual machine, you have reasonable ways to collect evidence. Just 
create snaps
whenever your system feels strange, and you can inspect these snapshots at a 
later, more
convenient moment. You can also perform comparisons between snap shots.

> Yes I thought to try to use vm on linux, but you know the linux kernel is 
> hole with some
> code around.

Yes, they say all kinds of nasty stuff about linux, but overall it works well, 
and the
vast majority of public facing servers run linux.

Your best bet will probably be some kind of variety of systems: linux, windows, 
freebsd,
maybe throw some openbsd into the pool. if "evil hackers" have to check your 
system first,
and probably throw some non-working exploits at it before breaking through, 
then you have
a good chance of catching them in the act. make your setup as unpredictable as 
you can,
and "they" will leave undeniable traces.

Once you have these traces, you can probably learn more about the hacker's 
methods and
develop a strategy to get rid of them for good.

PS: It would probably attract more helpful talent here, if people had reason to 
assume,
that your efforts serve some common goal and are not some private quest for 
free security
consulting. Care to share, why you think your computers are under attack?

Re: secure MTA

[Rudolf Leitgeb]

> Conversely, if everything was easily hackable then we probably wouldn't use
> computers, at all.

Being hacked is a risk everybody is ready to accept, some knowingly, some 
unknowingly.
There may be people here, who have never done business with any of these 
entities
listed here, but they are certainly a minority:

https://informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/

Some of these companies were probably run by incompetent monkeys, but most 
definitely
not all of them. Some other companies may not show up here, because they 
managed to
brush the issue under the rug, or because they haven't even learned about an 
ongoing
incident yet.

On the other side I am reasonably sure, that I personally haven't gotten hacked 
yet,
but that has more to do with me being quite uninteresting than with hax0r mad 
skillz.

Now this whole debate boils down to "how much effort is someone willing to 
invest
into hacking Cord's computers?", and that's something I can't answer. Cord at 
least
claims there is someone out there to get him. Let's see, how this whole story 
unfolds.

Re: secure MTA (was: news from ...)

[Rudolf Leitgeb]

On Wed, 2020-04-08 at 13:55 -0400, Allan Streib wrote:
> My (default) smtpd.conf says:
>
> listen on lo0
>
> So how might that be remotely exploitable?

I can disable all network connections on an unpatched Windows 95
laptop - oh, this would make it s secure ... Hint: a server,
which provides no services to the outside, is very secure and at
the same time completely useless! I personally welcome OpenBSD's
decision to turn off most services per default, but that's not
the point here.

Even as a client you are exposed, since most browsers are bug fests
of their own. The same is true of office productivity software and
just about anything else.

My point was, that security is an ongoing effort. Flaws and new
exploit venues are discovered. There will be different numbers
of flaws for different operating systems, but none remains unscathed
for years. As soon as your server does anything useful, it will
present an attack vector to the outside world, and one needs to
be aware of it.

Re: news from my hacked box

[Rudolf Leitgeb]

> yes exactly, I know who is the attacker and he has really great of resources 
> and power.
> Most probably he is responsible of the death of a guy in my country.
> Many people have preconceived ideas about security and about the attackers.
> Many people think that an hacker is pushed by money or some kind of interest 
> and
> attack just people that he doesn't know. If the attacker fail with a target 
> he just
> change target. Then a victim that describe a situation outside of this schema 
> most
> probably will be classified as a paranoid or a troll.

Do you have reason to believe, that this evil person has control over your 
hardware
deliveries? Do you have some procurement process in place, which guarantees, 
that this
person can not intercept and xompromise such a shipment? To which extent would 
you
trust authorities to protect you?

Once this is done: what is your attack surface? What are the applications 
facing the
big bad internet? Do you have to run public facing services? Is there a way to 
restrict
the level of "public"? DO you have to run applications which connect to random 
servers
on the internet? Have you thought about running these in a virtual machine with 
snap
shoting enabled, which allows you to return to a known safe state?

Re: news from my hacked box

[Rudolf Leitgeb]

> OpenSMTPD does not listen to the internet, by default and even if you do set 
> it
> to, it only affected certain configurations.

A server, which does not listen to the outside is pretty useless, don't
you think? I did not bring up opensmtp, because it is particularly bad,
quite to the contrary: even in very hardened systems bugs happen. You can
patch these bugs and have a reasonable secure system, but it's an ongoing
effort, not something you do just once.

> How the heck sshd has such as good security record, considering all that it
> does, interface wise, is rather astounding. I guess a remotely critical bug 
> may
> be found there one day, but it does not affect my point!

sshd has a good security record on openbsd, but even with sshd there were
problems on other platforms, not caused by the core sshd or the openbsd team,
but nonetheless a real issue.

Closely related to openssh was openssl, which had a gaping hole that became
known just a few years ago. I was not so much shocked about the fact, that
there was a security hole in openssl, but how really stupid and unnecessary
this whole issue was, what a stupid feature actually caused this bug to be
deployed on so many platforms.


Again, this is nothing specific to OpenBSD, but let's not delude outselves,
that one can rollout some server and leave it as it is for years to come.


> If your project, like most could; has made sane design choices for simple
> interfaces then it certainly can be made very secure, remotely unhackable is
> easier than you think for a modest project.

A public facing server with ftp, http, smtp and sshd would have had to be 
patched
in regular intervals to remain reasonably secure. Add a content management 
service
to this configuration, and these "regular intervals" turn into very frequent
occurrances. This is valid for low profile stuff, though. If you are something
high profile, like a bank, it's a constant and ongoing effort to deal with 
hackers
of all flavors.

Cheers,

Rudi

Re: news from my hacked box

[Rudolf Leitgeb]

> True if you consider physical attacks and for most hardware, otherwise mostly
> false. Anything can be hacked is also one of my biggest annoyances as a mantra
> from "infosec", that gets more money than it deserves in comparison to real
> security, like OpenBSD works on.

We know from Snowden, that supply chain attacks are a common thing. If someone
can modify the hardware sent to certain people on your list, then operating
system security is no longer the most pressing concern.

"Cord" claims, that people with great resources are out there to get his boxes
hacked. Obviously I can not verify his claim.

And I stand by my statement: ordering a computer and setting it up with a secure
operating system is insufficient to maintain control over your server.

I do concur with your assessment, that 99% of concerned people are way to
unimportant to attract any government attacks. These 99% certainly include me.
Attacking a server always comes with a risk of discovery, therefore I do not
believe, that these agencies conduct mass hacks of random servers.

> > Even OpenBSD had a remote root hole just a few weeks ago.

> I believe that is false too.

You're kidding, yes? Did you somehow miss the opensmtp hole?

https://poolp.org/posts/2020-01-30/opensmtpd-advisory-dissected/

Cheers,

Rudi

Re: news from my hacked box

[Rudolf Leitgeb]

> I understand you perfectly but there are some points I want highlight:
> Then there is a huge number of hacked site and hackaed desktop out there. 
> Many people
> didn't know that their pc or phone is not under their control anymore.
> The new frontier of hacking is espionage. None want be discovered.

Hacking for espionage is not exactly a new trend.

> 2) Sometime the old schema to pull out evidence of hacking are not valid 
> anymore.
> For example if you are Edward Snowden all that little and subjective things 
> that are not
> important for a common person become very important because the context is 
> very
> different.

You have no chance defending your desktop against each and every attacker, no 
matter
which operating system you have running. Even OpenBSD had a remote root hole 
just
a few weeks ago. Even if your operating system is impeccable, the code running 
on
your mother board and your network card is probably anything but. It's no 
wonder,
that professional services still rely on air gaps to protect their most valuable
assets against compromise.

Note: professional crypto services deploy their algos on dedicated hardware, 
not on
random personal computer systems. Low security means, that stuff runs on an 
FPGA,
high security stuff runs on discrete logic.

Going to a professional crypto outfit still doesn't buy you much, if that crypto
outfit turns out to be owned and controlled by a government agency.

To make a long story short: there is no such thing as a system, which is secure 
out
of the box. If you think, that your system is actively exploited, revert it 
back to
a known, secure state, wait for the exploit to hit you again, and have a network
sniffer ready to figure out, how the exploit works.

PS: Since you referred to Edward Snowden: the exploits published by him and 
later
by wikileaks were not really breathtakingly innovative. Do not expect to find a
completely new attack procedure in your investigation, whatever turns up.

PPS: Like others, I have seen quite a few computer systems with "evil viruses", 
that
turned out to have faulty memory or a failing hard disk. I expect you ran a 
complete
offline check of your hardware before you started suspecting foul play. Yes?

Re: How to hide my server's IP?

[Rudolf Leitgeb]

On Mon, 2020-02-03 at 13:23 +0100, Janne Johansson wrote:
> And refine the risk strategies, since the above conversation seem to be
> centered around the concept of a hacker that
>
> 1. Someone successfully attacks your site over the internet, using your
> outward facing IP A.A.A.A
> 2. Manages to run code on your webserver

That outward facing address A.A.A.A seems to be hidden behind a tor web,
which means the attacker can access a server without knowing its real IP
address. Knowledge of this real IP address may be the ultimate aim of the hack.

> 3. May or may not divinate your internal IP B.B.B.B from that code.

If that address B.B.B.B is an internal IP address, the hacker may not be able
to succeed in the original quest. Note, that the hacker may also find the MAC
address of the device, and all connected devices, which may give away the owner
of the device.

> 4. The communicates information back to a server of their choice, perhaps
> using a third (external) ip C.C.C.C or not

This appears to be the crucial part. If the hacker can initiate connections from
the hacked device, the public facing IP address is prone to discovery.

Therefore I propose the following solution:

1. Put the potentially vulnerable device behind a firewall. The firewall 
forwards
requests to the device and back, but allows no outgoing connections from the
protected device to the firewall or beyond.

2. Lock down the vulnerable device. If the device does not allow changing its 
MAC
address, patch the kernel to report something else. Also make sure, that 
your
vulnerable device creates no logs. Make sure, that the user account running
the potentially vulnerable application can not write to any directory, from
which executables can be started or dynamic libraries can be linked against.

3. Barriers are only effective, if they are properly defended. Your firewall 
must
monitor and reliably unusual network activity from the vulnerable host, and 
shut
down all network connections, if suspicious stuff happens. Consider a 
configuration,
in which all disk access goes to a RAM disk, such that a simple reboot 
restores
normal operation.

4. Obviously, no other device must be in the same network, especially not 
devices,
which could provide hints about your identity.

Re: build error on octeon, 6.6

[Rudolf Leitgeb]

Somewhere in his error output it says:

Target: mips64-unknown-openbsd6.6

This would not work with octeon AFAIK. Maybe this is the
reason the build fails ? It would at least make sense regarding
the "unable to execute command" message.


On Fri, 2019-11-08 at 14:50 +0100, Janne Johansson wrote:
> I wonder if this part is relevant:
> c++: error: unable to execute command
>
> Is there any permissions on /net that prevents execution?
>
> I seems it wants to run stuff from here:
>
> ...
> *** Error 254 in
> /net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang/libLLVM
> (:67 'AMDGPUTargetMachine.o': @c++ -O2 -pipe -...)
> *** Error 1 in /net/sirius/temp/routie-build/6.6/src/gnu/usr.bin/clang
>
>
> > I've noticed that my /tmp partition might be too small (64M). I'm going
> > to reinstall with bigger /tmp (1GB) and try again...
> >
>
>

Re: Errors when I try to configure multiple DNS search suffixes in dhcpd.conf

[Rudolf Leitgeb]

Had to try this myself, and yes, a configuration option with this
name does not even exist in the source code of dhcpd. This caused
me to reread the manpage:

"Note that dhcpd(8) calls this option option-119 instead of
 domain-search and only supports the rfc1035 variant."

So indeed, you can't use the option name "domain-search", but have
to use a line like:

option option-119 "dmz.dom.org";

I was unable to figure out, what exactly is meant with RFC1035 type
string, but came to the conclusion, that dhcpd in its current iteration
only supports one domain name here. Oh well.

Cheers,

Rudi

On Tue, 2019-09-24 at 08:32 +, Carlos Lopez wrote:
>
> Regards,
> C. L. Martinez
>
> On 24/09/2019 10:22, Rudolf Leitgeb wrote:
> > Could this be a case of missing semicolon at the end ?
> >
>
> Thanks Rudolf, but not ... My complete config is:
>
> subnet 172.22.55.0 netmask 255.255.255.224 {
>   option routers 172.22.55.30;
>   range 172.22.55.17 172.22.55.27;
>   option subnet-mask 255.255.255.224;
>   option broadcast-address 172.22.55.31;
>   option domain-search "internal.dom.org", "dmz.dom.org";
> }
>

Re: Errors when I try to configure multiple DNS search suffixes in dhcpd.conf

[Rudolf Leitgeb]

Could this be a case of missing semicolon at the end ?

On Tue, 2019-09-24 at 08:11 +, Carlos Lopez wrote:
> Hi all,
>
>   When I try to configure multiple search DNS suffixes in dhcpd.conf, I
> am receiving the following error:
>
> /etc/dhcpd.conf line 21:
>   option domain-search "custom.domain.org"
>  ^
> fatal in dhcpd: Configuration file errors encountered
>
>   According to man page:
>
> option domain-search rfc1035; | string [, string ...];
>   The domain-search option specifies a list of the domain names
>   that should be used during DNS name resolution.
>
>   When dhclient(8) constructs resolv.conf(5) it will use
> this list
>   of domains in preference to any information provided by the
>   domain-name option.
>
>   Note that dhcpd(8) calls this option option-119 instead of
>   domain-search and only supports the rfc1035 variant.
>
>   If my config is ok, maybe is this a bug?
>
> Regards

Re: OpenBSD crypto and NSA/Bruce Schneier

[Rudolf Leitgeb]

 Second, low hanging fruit.

Contrary to what some hysterical reports may claim, and some violations
of rules aside, NSA is mostly after bad guys, some of which know quite
well what they are doing. These bad guys will not necessarily be kind
enough to present NSA with unpatched Windows desktops.

 why bother with us ? people are most generally NOT careful. So, hey, 
 what if you can't break in OpenBSD ?

This is not a marketing operation run by NSA which can claim success if
they catch the 90% dumbest. Quite to the contrary, they should be most
interested in the most sophisticated ones, and why wouldn't bad guys
use OpenBSD if they had the impression it was more secure?


As I have mentioned before: what good is perfect security in an OS if you
have no control over the hardware? Put some back doors into the CPU or the
networking hardware and OpenSSH will fall. There is really no point in 
trying to outwit three letter agencies with our laptops.

Re: Why I abandoned OpenBSD, and why you should too...

[Rudolf Leitgeb]

NSA would be foolish to go through all the effort it takes to place a
back door into OpenBSD. I find it funny how people focus on potential
back doors in software and completely ignore that all this software is
executed on micro processors that are made by a select handful of US
companies. We also have no idea what's really going on in peripheral
components of our computers or in networking hardware.

Use OpenBSD if you want to keep out the common criminal but don't fool
yourself that you can outwit three letter agencies with your laptops.

Re: how to use cpu affinity from user space

[Rudolf Leitgeb]

 under such load server is experience somewhat to general network
 delays, network conections become slow (both incoming and outgoing),
 sometimes even 5 sec on 1G network.

It sounds unlikely that CPU congestion is responsible for 5 s network
delays unless your hardware is significantly underrated. Are you 100%
sure that manually reserving CPUs for specific tasks is going to solve
this dilemma? Note that most of the time when you seemingly run out of
CPU horse power you actually clog your memory bus, and assigning one CPU
to one task won't solve this.

Re: OpenBSD - UEFI Secure Boot

[Rudolf Leitgeb]

 Well, are you sure UEFI disable button will turn off ALL of UEFI
 functions?
 
 With that virtualization, both hardware bugs and attacks against
 hypervisors are real world cases. So don't be naive.
 
 Trust me, I'll try hard to avoid virtualization and Fedora@UEFI on my
 firewalls, no matter what they did to circumvent UEFI issues.
 
 Heck, I simply have no extra 5 years to spend on that hide-and-seek
 games.

For 15+ years I read these regular Cassandra calls that this and that 
innovation will kill free operating systems on commodity hardware,
remember Adaptec SCSI controllers, 3D video cards, I2O, trusted
computing and whatever the feature of the day is called.

For some reason or another these apocalypses never materialize, 
increasingly due to the fact that free operating systems are a major
factor in the server world, and a manufacturer trying to exclude them
will lose business both in the short run and long term. There are few
threats to server manufacturers worse than Ok, I'll hang on to my old 
hardware then until it either falls apart or until this is resolved.

Rudi

Re: Ways to handle DNS amplification attacks with OpenBSD

[Rudolf Leitgeb]

Am Sonntag, den 10.06.2012, 00:37 + schrieb Stuart Henderson:
 On 2012-06-09, Kostas Zorbadelos kzo...@otenet.gr wrote:
  I am interested to hear possible solutions in other layers as well.
 
 http://fanf.livejournal.com/122111.html seems a nice approach...

This seems to work nicely if the attacker spoofs random addresses or
if the real target is not the DNS server but the endpoint receiving
its replies (therefore the term amplification attack).

In Kostas's case it appears the attacker spoofs legit client addresses,
which means rate limiting would likely cut off these clients.

Rudi

Re: Ways to handle DNS amplification attacks with OpenBSD

[Rudolf Leitgeb]

Am Samstag, den 09.06.2012, 14:11 +0300 schrieb Kostas Zorbadelos:
 The situation is similar but not the same as the one discribed here:
 
 https://isc.sans.edu/diary.html?storyid=13261
 
 We used IPtables and the string module to match a specific signature of
 the problematic queries and it worked quite well (in our attack case the
 problematic queries had a very specific and simple pattern). 

Mitigating this with snort looks much uglier than the beautiful and
elegant iptables counter measure posted in this list. Not sure how it
holds up under load, though.

Since the attacker uses fixed patterns, he/she seems to be a script 
kiddy, and there is a good chance that the TTL can be used to identify
his/her packets. My approach would be to check what TTLs the packets
have vs. those from your clients and see whether you can filter based
on that.

Rudi

Re: Ways to handle DNS amplification attacks with OpenBSD

[Rudolf Leitgeb]

Am Samstag, den 09.06.2012, 19:17 +0300 schrieb Kostas Zorbadelos:
 What do you mean identify and filter based on TTL? In our case the
 attacker used a specific query for a single domain.

I mean the TTL field from the IP header of these packets. While the
attacker's packets spoof the sender address, they might not spoof
the TTL, and probably being away more hops from your servers than
your clients, their packets should have lower TTL values.

A network traffic dump could show quickly whether this approach
could possibly work.

Cheers,

Rudi

PS: Obviously a skilled attacker can also crank up TTL values to
compensate for their longer route, but fixed pattern indicates 
to me that you deal with a script kiddie here.

Re: Trusting the Installation

[Rudolf Leitgeb]

Am Montag, 5. MC$rz 2012, 10:12:02 schrieb PP;QQ P(P8P?P8QP8P=:
 P.S. I'm not a paranoic, but I respect people to be paranoic if they want
 to.

You can be paranoid about the sources and binaries all you want, but you still
don't know the CPU which executes all that code. Even if Intel/AMD would give
you full access to their CPU blue prints, the chip foundry could add things
you
would not notice.

That's the reason why companies which make secure encryption devices would
never trust any CPU/OS combo. Depending on paranoia they offer you either
an FPGA based solution or a hard wired one from logic ICs.

And even if you create the most trusted device, using nothing but 100 year
old
relays and passive components, you are still prone to the we will whack you
with
a wrench if you don't give me your keys attack. Very, very effective.

Re: Trusting the Installation

[Rudolf Leitgeb]

Am Montag, 5. Mdrz 2012, 12:36:56 schrieb Henning Brauer:
 * Rudolf Leitgeb rudolf.leit...@gmx.at [2012-03-05 12:01]:
  That's the reason why companies which make secure encryption devices
would
  never trust any CPU/OS combo. Depending on paranoia they offer you either
  an FPGA based solution or a hard wired one from logic ICs.

 dream on.

Feel free to trust an Intel Core 2 :)

Theo, for whatever reason, doesn't 

Re: Trusting the Installation

[Rudolf Leitgeb]

Am Montag, 5. Mdrz 2012, 13:30:14 schrieb Henning Brauer:

 you completely missed the point of my remark.

 most secure encryption devices on the market run linux. their
 security is snake oil. you don't wanna know what I have seen (and I
 can't talk about it in most cases)...

This mailing list is not about snake oil products on sale somewhere.
The post I replied to asked how one can be sure he runs trusted
software and my reply was it doesn't help you if you aren't 100%
sure your hardware is kosher. And for all practical purposes you can't.

One doesn't have to be 100% paranoid to distrust hardware. Look where
almost all desktop and laptop CPUs come from. And where these devices
plus their peripherals are made.

And again: even 100% secure hardwaresoftware won't protect you
against extortion/torture/whatever means to get that piece of info.

Re: How to deal with DDoS ?

[Rudolf Leitgeb]

Am Mittwoch, 22. Februar 2012, 08:36:49 schrieb Jan Stary:
  $ sysctl net.inet.udp.{recvspace,sendspace}
  net.inet.udp.recvspace=131072
  net.inet.udp.sendspace=131072
 
 I don't think it's gonna help with handling a DDOS, anyway.

Especially not in this particular case. He drops UDP anyway and 
reportedly fights a SYN flood attack.

Re: Automatic fsck -y at Boot

[Rudolf Leitgeb]

Am Freitag, 16. Dezember 2011, 21:49:18 schrieb Henning Brauer:
 in these cases - where runs is the top priority and manual
 intervention is hard - you most probably want to run with ro / and an
 mfs or three.

This is one nice approach but doesn't cover features like user changeable
settings and parameters, much less local error logs.

 this is still a bit like fixing holey condoms with duct tape.

You fixed the holey condoms issue by replacing them with 5mm thick kevlar. 
Your solution is certainly very l33t, but only few will want to use it ;)

I agree that there are lots of situations where an automated fsck -y in the
boot scripts is a bad idea (think of faulty RAM on a file server). I also agree
that it's a good idea to use fsck -p as the safe default on a fresh install.

There are, however, countless situations where fsck -y or similar is the
most workable solution, and attacking people who use fsck -y after
careful consideration as irresponsible cheapskates is neither helpful nor
professional.

Of all the experts here: how many of you have ever intervened in a failed 
fsck -p situation with anything else than an fsck and a barrage of y ?

Re: Automatic fsck -y at Boot

[Rudolf Leitgeb]

Am Freitag, 16. Dezember 2011, 10:26:27 schrieb Henning Brauer:
 there is no solution but a proper remote console access, i. e. cereal.
 it is completely beyond me why some people accept anything else.
 yes yes, some/many providers don't offer any. so pick one that does.
 you don't buy condoms with holes either, no matter how cheap.

Some devices are embedded devices and placed in environments 
where remote access from the outside is not an option. Of the many
times I have seen computers requiring a manual file system check after a
crash or power outage, I have never seen a device that would not
fix its file system after someone mindlessly pressed y a gazillion times.

There are setups where the stored data is the most important thing
and there are setups where the task is the most important thing, and
for the latter ones an automatic fsck -y is the way to go.

Re: Narcicism?

[Rudolf Leitgeb]

Am Freitag, 2. Dezember 2011, 06:13:42 schrieb Richard Thornton:
 I came to openbsd only recently trying to find a modern OS which will run on
 my old sun blade 100.  I wanted to use a linux but the only current linux
 for sparc64 is debian 6.03 and it seems incompatible with the rage xl video
 on the sun blade  giving me out of sync errors.  Openbsd seems to have 
 better drivers since it works fine.  R will not work though and this annoys
 me.  Also no recent browser support.  Seamonkey 2.04 is old.

And in common tradition hoardes of OpenBSD devs shall come to the rescue
and spend hours of unpaid time so you won't have to spend US$300 on
a new computer. :rolleyes:

Re: Narcicism?

[Rudolf Leitgeb]

Am Freitag, den 02.12.2011, 17:40 +0100 schrieb Anonymous Remailer
(austria):
 Fuck you man! Who needs a new computer? Blades rule! ;-)

The idea of OpenBSD, as far as I have understood this, is that
you rule the computer and not that you are ruled by a computer, 
much less a blade :-P

Re: microsoft and UEFI boot

[Rudolf Leitgeb]

Am Montag, den 26.09.2011, 11:09 +0200 schrieb Paolo Aglialoro:
 Actually I'm way more optimist about OEM motherboard manufacturers rather
 than PC companies.
 The weak spot will in fact be laptops and other portable equipment, as these
 are all proprietary design.
 
 Considering that laptop sales have overdone standard fixed PCs ones since
 years, the ecosystem, unless some heavyweight authority will strike hard,
 could be severely affected

Since the early days of open source operating systems there is 
a continuous flow of scare messages that some hardware innovation
will kill open source operating systems. Remember I2O anyone?

No serious motherboard manufacturer except maybe at the very bottom end
can afford to lock out open source operating systems in the long run.
Way too many businesses, even those which appear to be 100.0% Microsoft
from the outside, depend on linux and *BSD. If anyone wanted to kill
FOSS unixes, 1995 would have been the right time. It's way too late for
that now and let's please not spread FUD about this issue.

Re: OPenBSD 4.9 i386, Asus EEE 701, no network

[Rudolf Leitgeb]

Am Montag, den 25.07.2011, 13:00 +0100 schrieb Owain Ainsworth:
 
 Did you up the interface?
 
 ifconfig lii0 up


Thanks a lot, Owain, that was the problem. Network fully
operational now!

Cheers,

Rudi

OPenBSD 4.9 i386, Asus EEE 701, no network

[Rudolf Leitgeb]

Hi folks,

I wanted to give OpenBSD a new try and installed it on my
Asus EEEPC 701. Install went well, but for some reason
the network interface lii0 reports no carrier.

Since I have no network in the OpenBSD computer, please forgive
me for not going through the regular sendbug routine but
posting the bug report directly to this mailing list. 

Just to make sure this is not a hardware problem: I test
booted Ubuntu 10.04.1 i386 desktop from CD ROM and network
was fully functional. I did not change anything in the hardware
between boots, and the network cable remained untouched.

Here is what I did after startup:

- log in as root
- type ifconfig lii0 192.168.1.55

Result:

- ifconfig lii0 returns:
lii0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr correct MAC address
priority: 0
media: Ethernet autoselect (none)
status: no carrier
inet6 

- if I instruct ifconfig to use a particular media type, the media
line reflects this correctly, but the status: no carrier stays
the same.


Here are the lines /var/run/dmesg.log contains about the lii0 device:
lii0 at pci2 dev 0 function 0 Attansic Technology L2 rev 0xa0: apic 1
int 17 (irq 11), address my MAC address
atphy0 at lii0 phy1: F2 10/100 PHY, rev. 2


I hope this helps you, please contact me if you need further info
or if you want me to try some experiments.

Cheers,

Rudi

Re: OPenBSD 4.9 i386, Asus EEE 701, no network

[Rudolf Leitgeb]

 Rudi, post a complete dmesg, always.  There can be interactions that might
 not be obvious, so always post the complete dmesg.

Here it comes, included in the body and as an attachment.

Cheers,

Rudi

OpenBSD 4.9 (GENERIC) #671: Wed Mar  2 07:09:00 MST 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) M processor 900MHz (GenuineIntel 686-class)
631 MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF
real mem  = 527527936 (503MB)
avail mem = 508768256 (485MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/03/08, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.5 @ 0xf06e0 (37 entries)
bios0: vendor American Megatrends Inc. version 0910 date 03/03/2008
bios0: ASUSTeK Computer INC. 701
acpi0 at bios0: rev 0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC OEMB MCFG
acpi0: wakeup devices P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4)
MC97(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EUSB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 70MHz
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (P0P3)
acpiprt2 at acpi0: bus 3 (P0P5)
acpiprt3 at acpi0: bus 1 (P0P6)
acpiec0 at acpi0
acpicpu0 at acpi0: C3, C2
acpitz0 at acpi0: critical temperature 90 degC
acpibat0 at acpi0: BAT0 model 701 serial   type LION oem ASUS
acpiac0 at acpi0: AC unit offline
acpiasus0 at acpi0
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibtn2 at acpi0: PWRB
acpivideo0 at acpi0: VGA_
acpivout0 at acpivideo0: CRTD
acpivout1 at acpivideo0: TVOD
acpivout2 at acpivideo0: LCDD
bios0: ROM list: 0xc/0xf800!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 Intel 82915GM Host rev 0x04
vga1 at pci0 dev 2 function 0 Intel 82915GM Video rev 0x04
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1: apic 1 int 16 (irq 5)
drm0 at inteldrm0
Intel 82915GM Video rev 0x04 at pci0 dev 2 function 1 not configured
azalia0 at pci0 dev 27 function 0 Intel 82801FB HD Audio rev 0x04:
apic 1 int 16 (irq 5)
azalia0: codecs: Realtek ALC662
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801FB PCIE rev 0x04: apic 1 int
16 (irq 5)
pci1 at ppb0 bus 4
ppb1 at pci0 dev 28 function 1 Intel 82801FB PCIE rev 0x04: apic 1 int
17 (irq 11)
pci2 at ppb1 bus 3
lii0 at pci2 dev 0 function 0 Attansic Technology L2 rev 0xa0: apic 1
int 17 (irq 11), address 00:1f:c6:e8:d0:8d
atphy0 at lii0 phy 1: F2 10/100 PHY, rev. 2
ppb2 at pci0 dev 28 function 2 Intel 82801FB PCIE rev 0x04: apic 1 int
18 (irq 10)
pci3 at ppb2 bus 1
uhci0 at pci0 dev 29 function 0 Intel 82801FB USB rev 0x04: apic 1 int
23 (irq 7)
uhci1 at pci0 dev 29 function 1 Intel 82801FB USB rev 0x04: apic 1 int
19 (irq 3)
uhci2 at pci0 dev 29 function 2 Intel 82801FB USB rev 0x04: apic 1 int
18 (irq 10)
uhci3 at pci0 dev 29 function 3 Intel 82801FB USB rev 0x04: apic 1 int
16 (irq 5)
ppb3 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xd4
pci4 at ppb3 bus 5
ichpcib0 at pci0 dev 31 function 0 Intel 82801FBM LPC rev 0x04: PM
disabled
pciide0 at pci0 dev 31 function 2 Intel 82801FBM SATA rev 0x04: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 1 drive 0: SILICONMOTION SM223AC
wd0: 1-sector PIO, LBA, 3815MB, 7815024 sectors
wd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 4
ichiic0 at pci0 dev 31 function 3 Intel 82801FB SMBus rev 0x04: apic 1
int 19 (irq 0)
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 512MB DDR2 SDRAM non-parity PC2-3200CL3
SO-DIMM
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 Intel UHCI root hub rev 1.00/1.00 addr 1
usb1 at uhci1: USB revision 1.0
uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1
usb2 at uhci2: USB revision 1.0
uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1
usb3 at uhci3: USB revision 1.0
uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
mtrr: Pentium Pro MTRR support
umass0 at uhub2 port 1 configuration 1 interface 0 ENE UB6225 rev
2.00/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0: USB2.0, CardReader SD0, 0100 SCSI0
0/direct removable
sd0: drive offline
uvideo0 at uhub3 port 2 configuration 1 interface 0 eMPIA Technology
EeePC701 camera rev