Re: OpenBSD Traning Docs / How Tos

[Theo de Raadt]

> both regarding content and markup (including pf.conf(5) and
> ifconfig(8)), and that is not a coincidence: The subject matter is
> unusually difficult, the number of features to explain is unusually
> large, the number of people qualified to judge the accuracy of the
> manual pages and proposed changes is unusually small, and many of
> them are unusually busy.

Let me try to provide some perspective why.

Simple uses are easy to document (ie. "do this, here is an example, copy
it.  you don't need to understand).

Complex usage cases eventually hit questions regarding
order-of-evaluation.  We made mostly correct decisions years ago, but
people trying to use the code don't immediately come to the same
conclusions since they are learning the field at the same time.  These
details should be documented, or someone must figure it out
themsleves.  But where?

Describing both simple behaviours and complicated behaviours together
is very difficult.  In all fields.

I'm also very wary of documentation changes in complicated areas,
because most of the proposals are focusing on "me" cases, rather
than trying to capture all the angles.

Re: OpenBSD Traning Docs / How Tos

[Ingo Schwarze]

Hi Tom,

you are aware that the term "HOWTO" is very strongly detested round
here, right?  It is considered a synonym for so-called documentation
that is imprecise, unsystematic, and tells the user to type some
random commands they won't understand because the HOWTO doesn't
really explain how things actually work.


Tom Smyth wrote on Mon, Aug 07, 2017 at 11:46:46PM +0100:

> Im currently working on internal training documentation for
> our operations and field teams for dealing with OpenBSD based
> equipment. These documents would focus on OpenBSDs Network stack
> and its capabilities, diagnostics and configuration manipulation

It would probably be hard to pick an area where working on the
documentation is harder than in the vicinity of the network stack.
Some important manual pages in that area are below-average quality
both regarding content and markup (including pf.conf(5) and
ifconfig(8)), and that is not a coincidence: The subject matter is
unusually difficult, the number of features to explain is unusually
large, the number of people qualified to judge the accuracy of the
manual pages and proposed changes is unusually small, and many of
them are unusually busy.

> Since Im going to that trouble I thought maybe my effort could
> be aligned with the goals of the project,

As a matter of principle, OpenBSD documentation is reference
documentation.  So if you want to help the project, that would mean
improving manual pages (or maybe occasionally the FAQ, but much
less frequently).  Both aim for exactness and conciseness above all
else, so writing substantial amounts of new text is unlikely to help.

> and perhaps reduce the workload from some of the developers

I'm not aware of any developers who currently spend significant
time on network stack documentation, so the effect would be improving
documentation, not reducing workload.  But that is fine, we consider
documentation important.

It will *increase* the workload on the developers in question because
they will have to check your diffs - jmc@ and myself will usually
be unable to do that alone because we don't understand the network
stack well enough.

> advocates of the OpenBSD Project.

I'm not aware of the existance of advocates, and there are certainly
no advocates who work on documentation.

> I was discussing this with some developers at BSDCan but I didnt
> come away with a clear view of how to approach it.

Give the manual pages to your field engineers as training documentation
for specific tasks, see how they fare with them, and if they fail
to set things up properly, figure out why.  If the reason is that
they don't read carefully enough (being used to low-quality
documentation), work with them to improve their reading skills.  If
the reason is that some features are not described, or with too
little precision, or wrongly, send patches to fix the gaps and bugs.
If the reason is that everything is described exactly but the subject
matter is so complicated that assembling actual commands or
configuration from the description alone is very hard, work on
adding or improving examples, focussing on *conciseness*.  In any
case, the shorter the patches you send, the better.  Anything
containing long newly-written text is probably of little use, at
least until you will have collected a lot of experience working on
OpenBSD documentation.

It seems likely to me that all three elements will be needed, and
that both the first and the second will require more time and effort
than the third.

> Could the members of OpenBSD who are responsible for OpenBSD
> Documentation, and indeed anyone who is interested in advancing /
> improving the documentation of OpenBSD get in touch so that I can
> adopt an approach that is compatible with the overall direction of
> the project and that I can finally provide practical support for
> a project that I have benefited from for so long.

There is only one way.  Get started, find bugs and gaps in the
manual pages, send patches (to tech@ or to developers who you know
are interested), gain experience that way, and consequently improve
the quality of your patches over time.

> My initial thinking is
> 1) learn mandoc

You mean mdoc(7), probably.  That certainly cannot hurt, but don't
waste too much time on that, focus on *content*.  When you send
patches, people like jmc@ and myself will point out markup details
to you, and then you can read up on the pieces you actually need.
Also, mdoc(7) isn't all that difficult.

If you want, look at the slides 15 to 21 of my Sofia EuroBSDCon talk:
  http://mandoc.bsd.lv/press.html  (2014 Sep 26)
and if you want, look at slides 1 to 13 for a general background.
But the markup language isn't critical, really.

> 2) work with interested parties who would like to see some concept
>driven / example driven documentation

I don't have the slightest idea what you are talking about.
I'm not aware of any such parties.

> 3) I really like the snappy slick presentation of the training slides

KARL broken on arm64?

[Joe Gidi]

I just dusted off my Raspberry Pi 3 and updated to the latest snapshot
(from this morning). /usr/share/compile/GENERIC/relink.log shows:

(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0xd4d4d4d4 gapdummy.o
ld: error: gap.link:11: unknown command ;
ld: error: gap.link:11: LONG(0xd4d4d4d4);
ld: error: gap.link:11:   ^
ld: error: cannot open gapdummy.o: No such file or directory
ld: error: target emulation unknown: -m or at least one .o file required
*** Error 1 in /usr/share/compile/GENERIC (Makefile:529 'newbsd')

Known issue? Worthy of a bug report?

Thanks,

-- 

Joe Gidi
j...@entropicblur.com

"You cannot buy skill." -- Ross Seyfried

Re: OpenBSD IPsec/L2TP to Android VPN?

[Daniel Mumford]

Thanks.  The links are helpful.  I am troubleshooting through the log messages.

Thanks again.

Dan.

From: owner-m...@openbsd.org  on behalf of R0me0 *** 

Sent: Monday, August 7, 2017 1:56:41 PM
To: aaron marcher
Cc: OpenBSD Misc
Subject: Re: OpenBSD IPsec/L2TP to Android VPN?

https://www.authbsd.com/blog/?p=20

2017-08-07 14:54 GMT-03:00 aaron marcher :

> hi dan,
>
> i recently set up something like that using the following two tutorials
> (note that this is l2tp/ipsec instead of raw ipsec):
>
> - http://bluepilltech.blogspot.co.at/2017/02/openbsd-l2tp-
> over-ipsec-android-601-ios.html
> - http://blog.fuckingwith.it/2016/04/openbsd-l2tpipsec-vpn-
> for-android.html
>
> regards,
> drkhsh
>
> On 17-08-07 Mon, Daniel Mumford wrote:
> >
> > First post on mail list.  Hope I do it correctly.
> >
> > Is there anyone able to assist setting up an IPsec VPN between Openbsd
> machine and an android device?
> >
> > I have worked on for a week or so to no avail.  I would like to get a
> good understanding of the  necessary configuration.
> >
> > Thanks in advance.
> > Dan
>
> --
> web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/
> gpg: 0x435BF54B
>
>

Re: Supporting OpenBSD

[Tom Smyth]

@ Radoslav Mirza

I should have read your mail thread before
writing the
OpenBSD Traning Docs / How Tos
If you are on for some doc work
im happy to work with you on it
Thanks
Tom

Re: odd segfault when adding -lutil

[Jeremie Courreges-Anglas]

On Mon, Aug 07 2017, "Peter J. Philipp"  wrote:
> Hi,

Hi,

> I'm writing to misc because I did a change with my programming project and
> it doesn't work, in fact the program does not start up but in the dynamic
> linking stage (it seems) cores on segmentation violation.  I have tried 
> different architectures (amd64 and octeon) and -current and both have the 
> same problem, but I develop mostly on 6.1.  When I run it through a debugger
> I get this:
>
> (gdb) run
> Starting program: /usr/local/sbin/delphinusdnsd 
> (no debugging symbols found)
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x18c933300c94 in ?? () from /usr/local/sbin/delphinusdnsd
> (gdb) bt
> #0  0x18c933300c94 in ?? () from /usr/local/sbin/delphinusdnsd
> #1  0x18c933300b3e in ?? () from /usr/local/sbin/delphinusdnsd
> #2  0x in ?? ()
>
> Apparently somewhere in the program something jumps to location 0 and from
> there it's downhill.
>
> Also the very first system call (a geteuid()) does not get called making me
> think it's before main() has been called.  I'm completely boggled by this.
>
> # kdump | grep -3 geteuid
> # 
>
> The last committed snapshot of my program is found here, and afaik it works:
>
> http://delphinusdns.org/delphinusdnsd-snapshot.tgz
>
> The changes I'm working on now which causes this weird behaviour is to tie in
> imsg into my program and that means linking -lutil with this program.  I've 
> checked if there was any macro collisions with TAILQ's or RB_HEAD's and tried 
> to move those out of the way but still I get the segmentation fault.
>
> If anyone has an idea as to what could be the cause of this I'd be grateful.

Your program blows up the stack right at the start of main(), and gdb
doesn't seem to handle this very nicely.  egdb from ports shows you
the faulty instruction in the listing of ''disas main'', gdb from base
doesn't seem to do that (but you can still find it out manually).

Increasing the max stack size with ulimit -s, reducing the size of the
parent_ibuf and child_ibuf arrays, or allocating them in a different way
would work around those issues.

[...]

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

OpenBSD Traning Docs / How Tos

[Tom Smyth]

Hello ladies and lads,

Im currently working on internal training documentation for our
operations and field teams for dealing with OpenBSD based
equipment. These documents would focus on OpenBSDs Network stack
and its capabilities, diagnostics and configuration manipulation
Since Im going to that trouble I thought maybe
My effort could be aligned with the goals of the project, and
perhaps reduce the workload from some of the developers / advocates
of the OpenBSD Project.

I was discussing this with some developers at BSDCan but I didnt
come away with a clear view of how to approach it.

Could the members of OpenBSD who are responsible for OpenBSD
Documentation, and indeed anyone who is interested in advancing /
improving the documentation of OpenBSD get in touch so that I can
adopt an approach that is compatible with the overall direction of
the project and that I can finally provide practical support for
a project that I have benefited from for so long.

My initial thinking is
1) learn mandoc   (Thanks to Philip & Reyk for pointing this out in
BSDCan ) and try to author/ improve Examples sections
   of existing man pages. One that comes to mind is a point to point
   addressing on GRE tunnels for example
   or perhaps
   providing alternate hostname.if configuration lines that equate
   to ifconfig command arguments,
   (as a humble user I sometimes find the subtle differences between
   ifconfig syntax and hostname.if syntax a barrier to fully
   utilising OpenBSD to achieve our objectives on our network.)
2) work with interested parties who would like to see some concept
   driven / example driven documentation
3) I really like the snappy slick presentation of the training slides
   at http://www.openbsdjumpstart.org
   however I have since learned CSS / HTLML with out JS is preferred.
   If someone has templates for creating training slides / that rely
   only on HTML and CSS I would love to use those to create HTML help
   pages as well as man pages.


in a nutshell Im writing content anyway... so maybe I can do it in a
way that is both accessible for users and is useful for the OpenBSD
Project.

thanks for your time,
All the best
Tom Smyth

Re: touchpad input driver: testing needed

[Ulf Brosziewski]

Hi,

unfortunately, the input driver won't work in this configuration,
but I hope we can change that soon  ;-)

On 08/07/2017 09:16 PM, Michele Curti wrote:
> On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote:
>>
>> If you have a new snapshot (from July 27 or later) on a laptop with a
>> Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with
>> tests, more tests, and tests.  In order to activate the driver, add the
> 
> Hi,
> I'm using an August 3 snapshot on an asus x205ta where the touchpad 
> never worked really well.  It's an elantech touchpad detected as HID 
> over I2C bus, through the ims driver.
> 
> Partial dmesg:
> dwiic4 at acpi0: I2C4 addr 0x9092c000/0x1000 irq 35
> iic3 at dwiic4
> ihidev1 at iic3 addr 0x15 irq 72, vendor 0x4f3 product 0x401, ELAN0100
> ihidev1: 93 report ids
> ims0 at ihidev1 reportid 1: 2 buttons, Z dir
> wsmouse0 at ims0 mux 0
> hid at ihidev1 reportid 11 not configured
> hid at ihidev1 reportid 12 not configured
> hid at ihidev1 reportid 13 not configured
> hid at ihidev1 reportid 93 not configured
> "ELAN0100" at acpi0 not configured
> "INTCFD9" at acpi0 not configured
> 
> It's a a version 4 touchpad?  Will tests on this hardware be of any 
> help?
> 
> Regargs,
> Michele
> 
> 
> 
> Full dmesg:
> 
> OpenBSD 6.1-current (GENERIC.MP) #44: Thu Aug  3 12:12:07 MDT 2017
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error 3f
> real mem = 2056572928 (1961MB)
> avail mem = 1987952640 (1895MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7c31a010 (16 entries)
> bios0: vendor American Megatrends Inc. version "X205TA.212" date 09/04/2015
> bios0: ASUSTeK COMPUTER INC. X205TA
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S5
> acpi0: tables DSDT FACP TCPA UEFI OEM0 DBG2 HPET LPIT APIC MCFG SSDT SSDT 
> SSDT SSDT FPDT SSDT SSDT SSDT SSDT TPM2 BGRT CSRT MSDM
> acpi0: wakeup devices WLAN(S0)
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.58 MHz
> cpu0: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu0: 1MB 64b/line 16-way L2 cache
> cpu0: TSC frequency 1333579040 Hz
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 83MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
> cpu1: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu1: 1MB 64b/line 16-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 4 (application processor)
> cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
> cpu2: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu2: 1MB 64b/line 16-way L2 cache
> cpu2: smt 0, core 2, package 0
> cpu3 at mainbus0: apid 6 (application processor)
> cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
> cpu3: 
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
> cpu3: 1MB 64b/line 16-way L2 cache
> cpu3: smt 0, core 3, package 0
> ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 87 pins
> acpimcfg0 at acpi0 addr 0xe000, bus 0-255
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiec0 at acpi0: not present
> acpicpu0 at acpi0
> C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 
> mwait.1), PSS
> acpicpu1 at acpi0
> C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 
> mwait.1), PSS
> acpicpu2 at acpi0
> C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 
> mwait.1), PSS
> acpicpu3 at acpi0
> C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 
> mwait.1), PSS
> acpipwrres0 at acpi0: PLPE
> acpipwrres1 at acpi0: USBC, resource for XHC1, EHC1, OTG1
> acpipwrres2 at acpi0: CLK0, resource for CAM1
> acpipwrres3 at 

Re: touchpad input driver: testing needed

[Ulf Brosziewski]

Hi Paul,

thanks for the feedback.

With respect to tapping, I'm already running out of hypotheses
that can be tested without fine-grained debugging.  You might
check whether pressure thresholds play a role, but I wouldn't be
too optimistic about it.  You could clear them as follows:
   # wsconsctl mouse.tp.param=2:0,3:0
and see whether it helps.  This command restores the defaults:
   # wsconsctl mouse.tp.param=2:25,3:30

As to your observations concerning click-and-drag, I might have
thought of that, it concerns some basics:  If you want to move
the pointer while there are two or more contacts on the touchpad,
which one should control the movement?  I think that's not totally
trivial.  Linux gives a simple, but somewhat problematic answer:
The "oldest" touch controls the pointer.  But if a driver does
nothing else about it, this has the effect that the outcomes of
your two-finger gestures can depend on the order in which you make
the contacts.  You can still observe that on some Linux laptops
when your are scrolling with two fingers, but leave one finger
simply resting on the surface.

In your case, it's the firmware, not the driver, that does this
work, but the principle seems to be the same.  But how are users
supposed to know it?  It's not evident.

The synaptics driver adds up the differences of the coordinates
when it receives multi-touch data, and moves the pointer by those
"accumulated" values.  Older versions applied the method to
click-and-drag operations, newer versions to both click-and-drag
and two-finger scrolling.

The wsmouse driver implements a different approach: when it
receives multi-touch data - up to now, from Apple or Elantech-4
models - it assigns pointer-control to touches that are moving (if
such a touch exists).

Regards,
Ulf

On 08/07/2017 09:48 AM, Paul de Weerd wrote:
> On Mon, Aug 07, 2017 at 01:13:22AM +0200, Ulf Brosziewski wrote:
> | On 08/05/2017 11:10 PM, Paul de Weerd wrote:
> | > Hi Ulf,
> | > 
> | > On Fri, Aug 04, 2017 at 11:26:12PM +0200, Ulf Brosziewski wrote:
> | > | Hi Paul,
> | > | 
> | > | thanks for your help.  Does tapping work when you use
> | > | the synaptics driver?
> | > 
> | > Nope, it doesn't.
> | > 
> | 
> | which probably means there is either something happening that
> | our hardware driver doesn't cover, or there is a hardware/firmware
> | bug.  Anyhow, it's strange because the drivers only need very
> | basic data to identify a tap: the start of a contact, its
> | end, and the duration.  Have you checked - with the synaptics
> | driver - whether a higher tap timeout helps?  If not, would you
> | mind to make a short test?  Could you increase the tap timeout
> | to a very high value, say, two seconds, and test whether a tap
> | works (with a slight delay)?  For the wsmouse-internal driver,
> | the following command will set a two-second timeout:
> | # wsconsctl mouse.tp.param=137:2000
> | Of course you could not work reasonably with such a timeout,
> | you might want to check then whether something between 200
> | 350 milliseconds would do.  The default is 180.
> 
> I tried that:
> 
> [weerd@drop] $ doas wsconsctl mouse.tp.param=137:2000
> mouse.tp.param -> 137:999
> 
> But I still can't tap.
> 
> | > | > This doesn't work on my touchpad.  Also, I can't click-and-drag (never
> | > | > worked, in any combination I while playing with the driver settings).
> | > 
> | > This 'click-and-drag' behaviour does work if I click, keep the button
> | > depressed and then move that same finger around.  [...]
> | 
> | Does this also work if you put a second finger on the touchpad (which
> | does nothing)?
> 
> No, but you helped me find something useful / interesting:
> 
> 1. click button (keep depressed)
> 2. second finger doesn't do anything
> 
> however
> 
> 1. touch 'second finger' first
> 2. click button (keep depressed); now the 2nd finger can drag (1st
>finger doesn't work for dragging now)
> 
> This in addition to
> 
> 1. click button (keep depressed)
> 2. move 1st finger around on small clickable area to drag
> 
> So, with this new approach, I have more surface area to drag around
> and I can release my second finger to scroll beyond the end of the
> touchpad.  Never knew this was an option, I feel like an idiot now :)
> 
> Thanks!
> 
> Paul
> 

OpenBSD IPsec/L2TP to Android VPN?

[Daniel Mumford]

First post on mail list.  Hope I do it correctly.

Is there anyone able to assist setting up an IPsec VPN between Openbsd machine
and an android device?

I have worked on for a week or so to no avail.  I would like to get a good
understanding of the  necessary configuration.

Thanks in advance.
Dan

Re: touchpad input driver: testing needed

[Michele Curti]

On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote:
> 
> If you have a new snapshot (from July 27 or later) on a laptop with a
> Synaptics, Apple, Alps, or Elantech-4 touchpad, you could help with
> tests, more tests, and tests.  In order to activate the driver, add the

Hi,
I'm using an August 3 snapshot on an asus x205ta where the touchpad 
never worked really well.  It's an elantech touchpad detected as HID 
over I2C bus, through the ims driver.

Partial dmesg:
dwiic4 at acpi0: I2C4 addr 0x9092c000/0x1000 irq 35
iic3 at dwiic4
ihidev1 at iic3 addr 0x15 irq 72, vendor 0x4f3 product 0x401, ELAN0100
ihidev1: 93 report ids
ims0 at ihidev1 reportid 1: 2 buttons, Z dir
wsmouse0 at ims0 mux 0
hid at ihidev1 reportid 11 not configured
hid at ihidev1 reportid 12 not configured
hid at ihidev1 reportid 13 not configured
hid at ihidev1 reportid 93 not configured
"ELAN0100" at acpi0 not configured
"INTCFD9" at acpi0 not configured

It's a a version 4 touchpad?  Will tests on this hardware be of any 
help?

Regargs,
Michele



Full dmesg:

OpenBSD 6.1-current (GENERIC.MP) #44: Thu Aug  3 12:12:07 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 3f
real mem = 2056572928 (1961MB)
avail mem = 1987952640 (1895MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7c31a010 (16 entries)
bios0: vendor American Megatrends Inc. version "X205TA.212" date 09/04/2015
bios0: ASUSTeK COMPUTER INC. X205TA
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP TCPA UEFI OEM0 DBG2 HPET LPIT APIC MCFG SSDT SSDT SSDT 
SSDT FPDT SSDT SSDT SSDT SSDT TPM2 BGRT CSRT MSDM
acpi0: wakeup devices WLAN(S0)
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.58 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 1333579040 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz, 1333.34 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,SENSOR,ARAT
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 87 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiec0 at acpi0: not present
acpicpu0 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpicpu1 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpicpu2 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpicpu3 at acpi0
C3: state 7: substate 4 >= num 3: C2(10@500 mwait.1@0x51), C1(1000@1 mwait.1), 
PSS
acpipwrres0 at acpi0: PLPE
acpipwrres1 at acpi0: USBC, resource for XHC1, EHC1, OTG1
acpipwrres2 at acpi0: CLK0, resource for CAM1
acpipwrres3 at acpi0: CLK1, resource for CAM0
acpipwrres4 at acpi0: P28X
acpipwrres5 at acpi0: P18X
acpipwrres6 at acpi0: P28P
acpipwrres7 at acpi0: P18P
acpipwrres8 at acpi0: P28T, resource for CAM0, CAM1
acpipwrres9 at acpi0: P18T, resource for CAM0, CAM1
acpipwrres10 at acpi0: P1XT
acpitz0 at acpi0: no critical temperature defined
"INT3396" at acpi0 not 

Re: OpenBSD IPsec/L2TP to Android VPN?

[R0me0 ***]

https://www.authbsd.com/blog/?p=20

2017-08-07 14:54 GMT-03:00 aaron marcher :

> hi dan,
>
> i recently set up something like that using the following two tutorials
> (note that this is l2tp/ipsec instead of raw ipsec):
>
> - http://bluepilltech.blogspot.co.at/2017/02/openbsd-l2tp-
> over-ipsec-android-601-ios.html
> - http://blog.fuckingwith.it/2016/04/openbsd-l2tpipsec-vpn-
> for-android.html
>
> regards,
> drkhsh
>
> On 17-08-07 Mon, Daniel Mumford wrote:
> >
> > First post on mail list.  Hope I do it correctly.
> >
> > Is there anyone able to assist setting up an IPsec VPN between Openbsd
> machine and an android device?
> >
> > I have worked on for a week or so to no avail.  I would like to get a
> good understanding of the  necessary configuration.
> >
> > Thanks in advance.
> > Dan
>
> --
> web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/
> gpg: 0x435BF54B
>
>

Re: OpenBSD IPsec/L2TP to Android VPN?

[aaron marcher]

hi dan,

i recently set up something like that using the following two tutorials
(note that this is l2tp/ipsec instead of raw ipsec):

- 
http://bluepilltech.blogspot.co.at/2017/02/openbsd-l2tp-over-ipsec-android-601-ios.html
- http://blog.fuckingwith.it/2016/04/openbsd-l2tpipsec-vpn-for-android.html

regards,
drkhsh

On 17-08-07 Mon, Daniel Mumford wrote:
> 
> First post on mail list.  Hope I do it correctly.
> 
> Is there anyone able to assist setting up an IPsec VPN between Openbsd 
> machine and an android device?
> 
> I have worked on for a week or so to no avail.  I would like to get a good 
> understanding of the  necessary configuration.
> 
> Thanks in advance.
> Dan

-- 
web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/
gpg: 0x435BF54B

OpenBSD IPsec/L2TP to Android VPN?

[Daniel Mumford]

First post on mail list.  Hope I do it correctly.

Is there anyone able to assist setting up an IPsec VPN between Openbsd machine 
and an android device?

I have worked on for a week or so to no avail.  I would like to get a good 
understanding of the  necessary configuration.

Thanks in advance.
Dan

odd segfault when adding -lutil

[Peter J. Philipp]

Hi,

I'm writing to misc because I did a change with my programming project and
it doesn't work, in fact the program does not start up but in the dynamic
linking stage (it seems) cores on segmentation violation.  I have tried 
different architectures (amd64 and octeon) and -current and both have the 
same problem, but I develop mostly on 6.1.  When I run it through a debugger
I get this:

(gdb) run
Starting program: /usr/local/sbin/delphinusdnsd 
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x18c933300c94 in ?? () from /usr/local/sbin/delphinusdnsd
(gdb) bt
#0  0x18c933300c94 in ?? () from /usr/local/sbin/delphinusdnsd
#1  0x18c933300b3e in ?? () from /usr/local/sbin/delphinusdnsd
#2  0x in ?? ()

Apparently somewhere in the program something jumps to location 0 and from
there it's downhill.

Also the very first system call (a geteuid()) does not get called making me
think it's before main() has been called.  I'm completely boggled by this.

# kdump | grep -3 geteuid
# 

The last committed snapshot of my program is found here, and afaik it works:

http://delphinusdns.org/delphinusdnsd-snapshot.tgz

The changes I'm working on now which causes this weird behaviour is to tie in
imsg into my program and that means linking -lutil with this program.  I've 
checked if there was any macro collisions with TAILQ's or RB_HEAD's and tried 
to move those out of the way but still I get the segmentation fault.

If anyone has an idea as to what could be the cause of this I'd be grateful.
What follows after my signature is the diff I'm working on and my dmesg.boot:

Thanks,
-peter


Index: axfr.c
===
RCS file: /var/cvsroot/delphinusdns/delphinusdnsd/axfr.c,v
retrieving revision 1.10
diff -u -p -u -r1.10 axfr.c
--- axfr.c  11 Jul 2017 15:57:16 -  1.10
+++ axfr.c  7 Aug 2017 16:30:31 -
@@ -30,7 +30,7 @@
 #include "ddd-db.h"
 
 
-void   axfrloop(int *, int, char **, ddDB *);
+void   axfrloop(int *, int, char **, ddDB *, struct imsgbuf *ibuf);
 void   axfr_connection(int, char *, int, ddDB *);
 intbuild_header(ddDB *, char *, char *, struct question *, int);
 intbuild_soa(ddDB *, char *, int, struct domain *, struct question *);
@@ -101,8 +101,8 @@ static struct notifyentry {
 
 extern int domaincmp(struct node *e1, struct node *e2);
 RB_HEAD(domaintree, node) rbhead;
-RB_PROTOTYPE_STATIC(domaintree, node, entry, domaincmp)
-RB_GENERATE_STATIC(domaintree, node, entry, domaincmp)
+RB_PROTOTYPE_STATIC(domaintree, node, rbentry, domaincmp)
+RB_GENERATE_STATIC(domaintree, node, rbentry, domaincmp)
 
 
 static const char rcsid[] = "$Id: axfr.c,v 1.10 2017/07/11 15:57:16 pjp Exp $";
@@ -301,7 +301,7 @@ insert_notifyslave(char *address, char *
 }
 
 void 
-axfrloop(int *afd, int sockcount, char **ident, ddDB *db)
+axfrloop(int *afd, int sockcount, char **ident, ddDB *db, struct imsgbuf *ibuf)
 {
fd_set rset;
 
Index: db.c
===
RCS file: /var/cvsroot/delphinusdns/delphinusdnsd/db.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 db.c
--- db.c28 Jun 2017 09:40:54 -  1.2
+++ db.c7 Aug 2017 16:30:31 -
@@ -46,8 +46,8 @@ domaincmp(struct node *e1, struct node *
 
 
 RB_HEAD(domaintree, node) rbhead = RB_INITIALIZER();
-RB_PROTOTYPE(domaintree, node, entry, domaincmp)
-RB_GENERATE(domaintree, node, entry, domaincmp)
+RB_PROTOTYPE(domaintree, node, rbentry, domaincmp)
+RB_GENERATE(domaintree, node, rbentry, domaincmp)
 
 
 
Index: dd-convert.c
===
RCS file: /var/cvsroot/delphinusdns/delphinusdnsd/dd-convert.c,v
retrieving revision 1.70
diff -u -p -u -r1.70 dd-convert.c
--- dd-convert.c27 Jun 2017 05:41:02 -  1.70
+++ dd-convert.c7 Aug 2017 16:30:31 -
@@ -148,7 +148,7 @@ extern char * base32hex_encode(u_char *i
 
 extern int domaincmp(struct node *e1, struct node *e2);
 RB_HEAD(domaintree, node) rbhead;
-RB_GENERATE_STATIC(domaintree, node, entry, domaincmp)
+RB_GENERATE_STATIC(domaintree, node, rbentry, domaincmp)
 
 
 
Index: ddd-db.h
===
RCS file: /var/cvsroot/delphinusdns/delphinusdnsd/ddd-db.h,v
retrieving revision 1.4
diff -u -p -u -r1.4 ddd-db.h
--- ddd-db.h26 Jun 2017 20:28:50 -  1.4
+++ ddd-db.h7 Aug 2017 16:30:31 -
@@ -463,7 +463,7 @@ typedef struct __dddb {
sizeof(struct domain_nsec3param) + sizeof(struct domain_ds) )
 
 struct node {
-RB_ENTRY(node) entry;  /* the node entry */
+RB_ENTRY(node) rbentry;/* the node entry */
char domainname[256];   /* domain name key name */
 int len;   /* length of domain name */
char *data; /* data it points to */
@@ -476,6 +476,11 @@ struct cfg {
  

Re: Problems import ctypes in Python on 6.1

[Matt Hamilton]

OK, I think I fixed this. Seems some un-marked dependancy needed updating. But 
forcing all packages to be updated with: 

pkg_add -D installed -u

has cause python to start working again.

-Matt

> On 7 Aug 2017, at 14:19, Matt Hamilton  wrote:
> 
> Hi All,
>  I upgraded a machine to 6.1 and now having trouble importing the ctypes 
> module in python2.7. I've tried reinstalling the python package, no luck. I'm 
> running this with /usr mounted wxallowed.
> 
> Any ideas?
> 
 import ctypes
> # trying ctypes.so
> # trying ctypesmodule.so
> # trying ctypes.py
> # trying ctypes.pyc
> import ctypes # directory /usr/local/lib/python2.7/ctypes
> # trying /usr/local/lib/python2.7/ctypes/__init__.so
> # trying /usr/local/lib/python2.7/ctypes/__init__module.so
> # trying /usr/local/lib/python2.7/ctypes/__init__.py
> # /usr/local/lib/python2.7/ctypes/__init__.pyc matches 
> /usr/local/lib/python2.7/ctypes/__init__.py
> import ctypes # precompiled from /usr/local/lib/python2.7/ctypes/__init__.pyc
> # trying /usr/local/lib/python2.7/ctypes/os.so
> # trying /usr/local/lib/python2.7/ctypes/osmodule.so
> # trying /usr/local/lib/python2.7/ctypes/os.py
> # trying /usr/local/lib/python2.7/ctypes/os.pyc
> # trying /usr/local/lib/python2.7/ctypes/sys.so
> # trying /usr/local/lib/python2.7/ctypes/sysmodule.so
> # trying /usr/local/lib/python2.7/ctypes/sys.py
> # trying /usr/local/lib/python2.7/ctypes/sys.pyc
> # trying /usr/local/lib/python2.7/ctypes/_ctypes.so
> # trying /usr/local/lib/python2.7/ctypes/_ctypesmodule.so
> # trying /usr/local/lib/python2.7/ctypes/_ctypes.py
> # trying /usr/local/lib/python2.7/ctypes/_ctypes.pyc
> # trying _ctypes.so
> # trying _ctypesmodule.so
> # trying _ctypes.py
> # trying _ctypes.pyc
> # trying /usr/local/lib/python2.7/_ctypes.so
> # trying /usr/local/lib/python2.7/_ctypesmodule.so
> # trying /usr/local/lib/python2.7/_ctypes.py
> # trying /usr/local/lib/python2.7/_ctypes.pyc
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.so
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypesmodule.so
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.py
> # trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.pyc
> # trying /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> dlopen("/usr/local/lib/python2.7/lib-dynload/_ctypes.so", 2);
> #   clear[1] _os
> #   clear[1] _sys
> #   clear[2] __file__
> #   clear[2] __package__
> #   clear[2] __path__
> #   clear[2] __name__
> #   clear[2] __version__
> #   clear[2] __doc__
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "/usr/local/lib/python2.7/ctypes/__init__.py", line 7, in 
>from _ctypes import Union, Structure, Array
> ImportError: Cannot load specified object
 
> 
> # ls -l /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> -rwxr-xr-x  1 root  bin  151375 Apr  1 21:51 
> /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> # file /usr/local/lib/python2.7/lib-dynload/_ctypes.so
> /usr/local/lib/python2.7/lib-dynload/_ctypes.so: ELF 64-bit LSB shared 
> object, x86-64, version 1
> 
> # uname -a
> OpenBSD krang.quernus.co.uk 6.1 GENERIC#0 amd64
> 
> # mount
> /dev/sd0a on / type ffs (local)
> /dev/sd0g on /home type ffs (local, nodev, nosuid)
> mfs:71126 on /tmp type mfs (asynchronous, local, nodev, noexec, nosuid, 
> size=102400 512-blocks)
> /dev/sd0f on /usr type ffs (local, nodev, wxallowed)
> /dev/sd0e on /var type ffs (local, noatime, nodev, nosuid)
> 
> -Matt
> 
> — 
> Matt Hamilton
> Quernus
> m...@quernus.co.uk
> +44 117 325 3025
> 64 Easton Business Centre
> Felix Road, Easton
> Bristol, BS5 0HE
> 
> Quernus Ltd is a company registered in England and Wales. Registered number: 
> 09076246
> 


— 
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
64 Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number: 
09076246

Problems import ctypes in Python on 6.1

[Matt Hamilton]

Hi All,
  I upgraded a machine to 6.1 and now having trouble importing the ctypes 
module in python2.7. I've tried reinstalling the python package, no luck. I'm 
running this with /usr mounted wxallowed.

Any ideas?

>>> import ctypes
# trying ctypes.so
# trying ctypesmodule.so
# trying ctypes.py
# trying ctypes.pyc
import ctypes # directory /usr/local/lib/python2.7/ctypes
# trying /usr/local/lib/python2.7/ctypes/__init__.so
# trying /usr/local/lib/python2.7/ctypes/__init__module.so
# trying /usr/local/lib/python2.7/ctypes/__init__.py
# /usr/local/lib/python2.7/ctypes/__init__.pyc matches 
/usr/local/lib/python2.7/ctypes/__init__.py
import ctypes # precompiled from /usr/local/lib/python2.7/ctypes/__init__.pyc
# trying /usr/local/lib/python2.7/ctypes/os.so
# trying /usr/local/lib/python2.7/ctypes/osmodule.so
# trying /usr/local/lib/python2.7/ctypes/os.py
# trying /usr/local/lib/python2.7/ctypes/os.pyc
# trying /usr/local/lib/python2.7/ctypes/sys.so
# trying /usr/local/lib/python2.7/ctypes/sysmodule.so
# trying /usr/local/lib/python2.7/ctypes/sys.py
# trying /usr/local/lib/python2.7/ctypes/sys.pyc
# trying /usr/local/lib/python2.7/ctypes/_ctypes.so
# trying /usr/local/lib/python2.7/ctypes/_ctypesmodule.so
# trying /usr/local/lib/python2.7/ctypes/_ctypes.py
# trying /usr/local/lib/python2.7/ctypes/_ctypes.pyc
# trying _ctypes.so
# trying _ctypesmodule.so
# trying _ctypes.py
# trying _ctypes.pyc
# trying /usr/local/lib/python2.7/_ctypes.so
# trying /usr/local/lib/python2.7/_ctypesmodule.so
# trying /usr/local/lib/python2.7/_ctypes.py
# trying /usr/local/lib/python2.7/_ctypes.pyc
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.so
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypesmodule.so
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.py
# trying /usr/local/lib/python2.7/plat-openbsd6/_ctypes.pyc
# trying /usr/local/lib/python2.7/lib-dynload/_ctypes.so
dlopen("/usr/local/lib/python2.7/lib-dynload/_ctypes.so", 2);
#   clear[1] _os
#   clear[1] _sys
#   clear[2] __file__
#   clear[2] __package__
#   clear[2] __path__
#   clear[2] __name__
#   clear[2] __version__
#   clear[2] __doc__
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/ctypes/__init__.py", line 7, in 
from _ctypes import Union, Structure, Array
ImportError: Cannot load specified object
>>> 

# ls -l /usr/local/lib/python2.7/lib-dynload/_ctypes.so
-rwxr-xr-x  1 root  bin  151375 Apr  1 21:51 
/usr/local/lib/python2.7/lib-dynload/_ctypes.so
# file /usr/local/lib/python2.7/lib-dynload/_ctypes.so
/usr/local/lib/python2.7/lib-dynload/_ctypes.so: ELF 64-bit LSB shared object, 
x86-64, version 1

# uname -a
OpenBSD krang.quernus.co.uk 6.1 GENERIC#0 amd64

# mount
/dev/sd0a on / type ffs (local)
/dev/sd0g on /home type ffs (local, nodev, nosuid)
mfs:71126 on /tmp type mfs (asynchronous, local, nodev, noexec, nosuid, 
size=102400 512-blocks)
/dev/sd0f on /usr type ffs (local, nodev, wxallowed)
/dev/sd0e on /var type ffs (local, noatime, nodev, nosuid)

-Matt

— 
Matt Hamilton
Quernus
m...@quernus.co.uk
+44 117 325 3025
64 Easton Business Centre
Felix Road, Easton
Bristol, BS5 0HE

Quernus Ltd is a company registered in England and Wales. Registered number: 
09076246

OpenSSL in Debian Unstable drops TLS 1.0/1.1 support

[Ilya Abimael]

Hello, 

fyi: 

https://news.ycombinator.com/item?id=14944849

https://lists.debian.org/debian-devel-announce/2017/08/msg4.html

--
Hi,

I've just uploaded a version of OpenSSL to unstable that disables
the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
only supported SSL/TLS protocol version.

This will likely break certain things that for whatever reason
still don't support TLS 1.2. I strongly suggest that if it's not
supported that you add support for it, or get the other side to
add support for it.

OpenSSL made a release 5 years ago that supported TLS 1.2. The
current support of the server side seems to be around 90%. I hope
that by the time Buster releases the support for TLS 1.2 will be
high enough that I don't need to enable them again.


Kurt
--

AFAIK LibreSSL still supports TLS 1.0; 1.1. 

When will these two old versions be removed? Or still to much stuff uses them? 

Thanks!

Re: A survey of BSD kernel vulnerabilities (DEF CON) [pdf]

[Ilya Abimael]

Hello, 

As I can see many fixes came out because of Ilja van Sprundel: 

https://www.openbsd.org/errata61.html

https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf

Thanks Ilja for pointing out the problems and for the OpenBSD team to fix them 
so fast! :)

> Sent: Saturday, July 29, 2017 at 4:50 AM
> From: "Theo de Raadt" 
> To: "Ilya Abimael" 
> Subject: Re: A survey of BSD kernel vulnerabilities (DEF CON) [pdf]
>
> > The maintainers of various BSDs should talk more among each other
> 
> Hey Ilya,
> 
> That happens very rarely.
> 
> In particular, they view us as competition.  We aren't competition;
> this is a research OS.
> 
> Most of their developers work in corporate environments, pretty
> tightly tied to things that happen in California.
> 
> For the millions that FreeBSD collected over the years, not one penny
> has been contributed towards OpenSSH or any of our other efforts.
> 
> We've taken almost no code from them.  Maybe a driver here or there.
> They've taken gobs of code from us, which does make us happy.
> 
> But over the years some of their developers have played sockpuppet
> games denouncing us.
> 
> The attacks on against our efforts of trying to audit the whole tree,
> build mitigations, etc, got really bad about 10 years ago.
> 
> I decided years ago that anything important, I won't share with them
> by talking to them.  That's my choice.  I told other people of my
> choice.  Other people act the same way, I suppose.
> 
> However, all our fixes as commited in a public repo.  You may have
> heard, but we were the first codebase with a public repo -- ie.
> anoncvs.  Before that, everyone was even more private, only releasing
> final tarballs with "changelogs".
> 
> However the reasons for changes sometimes don't show up in commitlogs.
> When our developers skip explaining the reasons, I give them heck.
> I dislike commit messages which don't explain the reason.
> 
> I think you oversimplify the situation.  There are fewer people than
> you might assume.  OpenBSD is about 80 people at a time, but 40 of them
> work in the ports tree.  Then about 10 people working in drivers, and
> the remaining 30 have a mix of kernel and userland experience, though
> it tends towards userland.
> 
> In FreeBSD the total numbers are about 2x as much, but their low-level
> grouping is even smaller than ours.
> 
> Surely you realize how large these codebases are.  People get spread
> out all over the place.
> 
> 7-day moving average of OpenBSD commits at
> http://www.oxide.org/cvs/OpenBSD.html appears to be about 50/day.
> 
> Where would people find the time to talk about anything?
> 
> 190,000 commits of divergence in the base trees.  Finding common ground
> is harder than you think.
> 
> After more than 20 years, there is no such thing as BSD.  Deep inside, the
> differences are greater than the commonalities.
> 

Re: gmail and hotmail blocking mail sent from my IP

[Jesper Wallin]

On Sun, Aug 06, 2017 at 04:42:09PM -0500, Eric Johnson wrote:
> It can be very aggravating when an ISP still blocks port 25.  With the
> great expansion of smart phones and people getting e-mail on them, it gets
> in the way far more than it helps.  You can't expect every smart phone
> user to change the SMTP settings for every hot spot where they want to use
> it.

Correct, and that's what submission (587) is used for, which normally is
open as it most likely require authentication.

Re: gmail and hotmail blocking mail sent from my IP

[Eric Johnson]

On Sun, 6 Aug 2017, Jesper Wallin wrote:

> On Sun, Aug 06, 2017 at 05:29:04PM +0200, Walter Alejandro Iglesias wrote:
> Like Martijn pointed out, you're sending mail from a IP which is not
> intended for mail-servers. Most ISPs block outgoing traffic on port 25
> to prevent their customers sending spam when they get infected with
> viruses and such. Even if your ISP allow you to send mail, most
> providers will most likely classify it as spam/junk.

It can be very aggravating when an ISP still blocks port 25.  With the
great expansion of smart phones and people getting e-mail on them, it gets
in the way far more than it helps.  You can't expect every smart phone
user to change the SMTP settings for every hot spot where they want to use
it.

Eric

Re: touchpad input driver: testing needed

[Paul de Weerd]

On Mon, Aug 07, 2017 at 01:13:22AM +0200, Ulf Brosziewski wrote:
| On 08/05/2017 11:10 PM, Paul de Weerd wrote:
| > Hi Ulf,
| > 
| > On Fri, Aug 04, 2017 at 11:26:12PM +0200, Ulf Brosziewski wrote:
| > | Hi Paul,
| > | 
| > | thanks for your help.  Does tapping work when you use
| > | the synaptics driver?
| > 
| > Nope, it doesn't.
| > 
| 
| which probably means there is either something happening that
| our hardware driver doesn't cover, or there is a hardware/firmware
| bug.  Anyhow, it's strange because the drivers only need very
| basic data to identify a tap: the start of a contact, its
| end, and the duration.  Have you checked - with the synaptics
| driver - whether a higher tap timeout helps?  If not, would you
| mind to make a short test?  Could you increase the tap timeout
| to a very high value, say, two seconds, and test whether a tap
| works (with a slight delay)?  For the wsmouse-internal driver,
| the following command will set a two-second timeout:
| # wsconsctl mouse.tp.param=137:2000
| Of course you could not work reasonably with such a timeout,
| you might want to check then whether something between 200
| 350 milliseconds would do.  The default is 180.

I tried that:

[weerd@drop] $ doas wsconsctl mouse.tp.param=137:2000
mouse.tp.param -> 137:999

But I still can't tap.

| > | > This doesn't work on my touchpad.  Also, I can't click-and-drag (never
| > | > worked, in any combination I while playing with the driver settings).
| > 
| > This 'click-and-drag' behaviour does work if I click, keep the button
| > depressed and then move that same finger around.  [...]
| 
| Does this also work if you put a second finger on the touchpad (which
| does nothing)?

No, but you helped me find something useful / interesting:

1. click button (keep depressed)
2. second finger doesn't do anything

however

1. touch 'second finger' first
2. click button (keep depressed); now the 2nd finger can drag (1st
   finger doesn't work for dragging now)

This in addition to

1. click button (keep depressed)
2. move 1st finger around on small clickable area to drag

So, with this new approach, I have more surface area to drag around
and I can release my second finger to scroll beyond the end of the
touchpad.  Never knew this was an option, I feel like an idiot now :)

Thanks!

Paul

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: Does pf's Sources table ever get cleared?

[Markus Wernig]

On 03.08.2017 06:42, Emille Blanc wrote:

> 005: RELIABILITY FIX: May 6, 2017
> Expired pf source tracking entries never got removed, leading to memory
> exhaustion.
> ref: https://www.openbsd.org/errata61.html
Thanks for the pointer! Problem gone after running syspatch (such a cool
tool!).

/m