Re: github

[Brent Cook]

On Mon, Aug 8, 2016 at 7:56 PM, David Schmidt 
wrote:

> Nick Holland wrote:
> >Nowhere on the OpenBSD website mentions github as anything official.
>
> It does on this page: https://www.openbsd.org/libressl/. Its even
> above the cvs link. Of course this is just for libressl not for the
> rest of openbsd.
>
>
We use github as a mirror​ for LibreSSL-portable and OpenNTPD-portable too.
It's not unlike the official python github mirror, which is synced from
that project's Mercurial repo: https://github.com/python/cpython

If you have patches for the openbsd@ side of these projects, it is best to
just email them to tech@, since the OpenBSD devs only have so many places
they will look for patches on a regular basis. Using git format-patch,
send-email or similar work well in my experience.

On the 'portable' side, github PRs are fine, since I'm using git natively
and can fetch from the github mirror directly.

Re: GPIO for P8 Expansion Header on Beaglebone Black

[Theo de Raadt]

> > OpenBSD has no clue what it is wired to.  Except on a lot of machines,
> > some pin has been wired to something on the board itself.
> > 
> 
> So it was, kernel being clueless, before FDT became mandatory, no?
> I'd guess we're more likely to run into a u-boot build in the future not
> providing safe voltages or such on some not-yet-existing board, that might
> really fry things given OpenBSD has no clue about adjusting the voltages
> nor input to sensors it could support.

Vendors are making arm boards at a rapid pace.  That pace will
increase.  FDT files will become inaccurate, mistakes will be made,
things will get fried.  Mark my words.   All of this stuff is designed
to be installed, and two months later a different one comes out,
and who's paying for attention to be focused on the old ones?

Re: GPIO for P8 Expansion Header on Beaglebone Black

[Artturi Alm]

> > > Most hardware + firmware combinations provide insufficient detail
> > > to know what pins are used for what, reserved for what, or wired
> > > to an auto-destruct.
> > 
> > But that's by design.  GPIO is simply an interface to a digital I/O pin =
> > on the CPU.  Everything after that is up to the end-user.
> 
> That is not true.
> 
> OpenBSD has no clue what it is wired to.  Except on a lot of machines,
> some pin has been wired to something on the board itself.
> 

So it was, kernel being clueless, before FDT became mandatory, no?
I'd guess we're more likely to run into a u-boot build in the future not
providing safe voltages or such on some not-yet-existing board, that might
really fry things given OpenBSD has no clue about adjusting the voltages
nor input to sensors it could support.

-Artturi

> > Especially so since they are the ones controlling what is connected
> > to those pins.
> 
> That is not true.
> 
> I have an armv7 machine here.  It has no pins on the outside.  It has
> a pile of gpio devices.
> 
> Are they all wired to nothing??  No, some of them are wired to things,
> I can promise you that.
> 
> > I bit-bang the RPI all the time, and no two of them ever uses the =
> > available pins in the same way.
> 
> That's nice.  The RPI is one machine, out of a growing catagory of
> machines numbering a 100+
> 
> Many of those machines wire pins pins to internal things.  When they
> do that, OpenBSD does not know.  It depends on someone reading the
> manual.
> 
> Really, I suggest you go read the start of the thread.

Re: GPIO for P8 Expansion Header on Beaglebone Black

[Theo de Raadt]

> > Most hardware + firmware combinations provide insufficient detail
> > to know what pins are used for what, reserved for what, or wired
> > to an auto-destruct.
> 
> But that's by design.  GPIO is simply an interface to a digital I/O pin =
> on the CPU.  Everything after that is up to the end-user.

That is not true.

OpenBSD has no clue what it is wired to.  Except on a lot of machines,
some pin has been wired to something on the board itself.

> Especially so since they are the ones controlling what is connected
> to those pins.

That is not true.

I have an armv7 machine here.  It has no pins on the outside.  It has
a pile of gpio devices.

Are they all wired to nothing??  No, some of them are wired to things,
I can promise you that.

> I bit-bang the RPI all the time, and no two of them ever uses the =
> available pins in the same way.

That's nice.  The RPI is one machine, out of a growing catagory of
machines numbering a 100+

Many of those machines wire pins pins to internal things.  When they
do that, OpenBSD does not know.  It depends on someone reading the
manual.

Really, I suggest you go read the start of the thread.

Re: GPIO for P8 Expansion Header on Beaglebone Black

[Lyndon Nerenberg]

> Most hardware + firmware combinations provide insufficient detail
> to know what pins are used for what, reserved for what, or wired
> to an auto-destruct.

But that's by design.  GPIO is simply an interface to a digital I/O pin on the
CPU.  Everything after that is up to the end-user.  Especially so since they
are the ones controlling what is connected to those pins.  I bit-bang the RPI
all the time, and no two of them ever uses the available pins in the same way.
Because I'm prototyping, so this changes all the time.  That makes it *my*
responsibility to know WTF I am doing (including which pins to stay away from
on that specific device).  As it should be.

Bottom line is if you are banging on low-level hardware interfaces like this,
you better know what your hardware is doing.  At this level, just like with
device drivers, you have all the tools at your disposal to destroy everything
in sight.  This is why gpio device interfaces require (or at least should
require) root perms to access in any way.

Of course, you're much more likely to destroy your device (or a good portion
of those ports, at least) by plugging a 5V peripheral into a 3V port.  No OS
assistance required :-P

[demime 1.01d removed an attachment of type application/pgp-signature which had 
a name of signature.asc]

Fwd: Nvidia GeForce 8400 GS not working with nv(4)

[cwlmb3]

After some time without a response, I realized I didn't include
some relevant logs. Sorry, misc@.

 Original Message 
Date: Mon, 8 Aug 2016 21:58:45 -0500
Subject: Nvidia GeForce 8400 GS not working with nv(4)
From: Colton Lewis 
To: misc@openbsd.org

Hello,

I am puzzled why I cannot use this graphics card with the nvidia
driver since nv(4) claims to support it.

I'm on the 5.9 release.

Starting X was falling back to the vesa driver so I wrote the
following to xorg.conf

Section "Device"
Identifier "GeForce 8400GS"
Driver "nv"
EndSection

With this file, X fails to start. Xorg.0.log reports "NV: skipping
unsupported device".

dmesg reports the device as "unrecognized product 0x10c3", which
is the correct PCI Device ID for the 8400 GS. Does kernel recognition
matter for devices that are handled by X drivers?

What is happening? Can I do something different or am I stumped?

-- 
Sincerely,
Colton Lewis

Senior in Computer Engineering
Missouri University of Science and Technology
573.202.4219
OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8428531712 (8038MB)
avail mem = 8168890368 (7790MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec3b0 (78 entries)
bios0: vendor American Megatrends Inc. version "V10.9" date 04/21/2015
bios0: MSI MS-7817
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SSDT SSDT MCFG HPET SSDT SSDT ASF! BGRT
acpi0: wakeup devices PS2K(S3) PS2M(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) 
PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) 
PXSX(S4) RP07(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz, 3000.37 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,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz, 2999.99 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,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 4 (RP04)
acpiprt4 at acpi0: bus 6 (RP06)
acpiprt5 at acpi0: bus 1 (PEG0)
acpiprt6 at acpi0: bus -1 (PEG1)
acpiprt7 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(350@117 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(350@117 mwait.1@0x20), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 105 degC
acpitz1 at acpi0: critical temperature is 105 degC
acpibat0 at acpi0: BAT0 not present
acpibat1 at acpi0: BAT1 not present
acpibat2 at acpi0: BAT2 not present
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3000 MHz: speeds: 3000, 2900, 2700, 2600, 2400, 2300, 
2100, 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06
ppb0 at pci0 dev 1 function 0 "Intel Core 4G PCIE" rev 0x06: msi
pci1 at ppb0 bus 1
vendor "NVIDIA", unknown product 0x10c3 (class display subclass VGA, rev 0xa2) 
at pci1 dev 0 function 0 not configured
azalia0 at pci1 dev 0 function 1 vendor "NVIDIA", unknown product 0x0be3 rev 
0xa1: msi
azalia0: no supported codecs
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x06
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1920x1080
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia1 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x06: msi
azalia1: No codecs found
xhci0 at pci0 dev 20 function 0 "Intel 8 

Re: GPIO for P8 Expansion Header on Beaglebone Black

[Theo de Raadt]

> I was surprised by Theo's answer because I recall BeagleBone Black was
> open hardware, at least as a design.

The word "Open" means nothing in this instance.

Most hardware + firmware combinations provide insufficient detail
to know what pins are used for what, reserved for what, or wired
to an auto-destruct.

Even on PCs, we have encountered situations where critical clock
controller chips are at placed at ISA addresses on one machine,
but wired to a fan controller / temperature sensor on another.

> But I won't bet my hand on the board's ARM cpu.

It has nothing to do with the cpu.  It is about what is around the
cpu, and how these platforms lack a way to tell us what is what.

And even if they dcreated 

> Anyway, I am not using it, I consider it for fun, but I checked it
> again and here it is:
> 
> Excerpt from the hardware support:
> 
> "BeagleBone Black ships with two virtual capes already on it, one for
> the on-board eMMC storage and one for the HDMI output. When configured
> for use these virtual capes consume actual resources.
> 
> If the eMMC is not placed in reset, the MMC1* signals may not be used
> without potentially corrupting the contents of your on-board
> eMMC---and possibly damaging the physical circuit as well."
> 
> The pins used by MMC1* are shown in the picture: 3, 4, 5, 6, 21, 22, 23, 24, 
> 25.

What it says in a book is not relevant.  The kernel has to be told somehow.

This "enumeration" problem is why PCIBIOS showed up, it is why ACPI
showed up, it is why openfirware showed up, etc.

Something has to tell you what is what, in a portable fashion for when
the platforms change.  Which THEY DO.  Every day.

Re: GPIO for P8 Expansion Header on Beaglebone Black

[Mihai Popescu]

> Pins 3 through 46 on P8 are listed in the hardware
> information as available for GPIO.  Indeed, I can set any of them but
> I notice that on pins 25 (gpio1_0), 21 (gpio1_30), and 20 (gpio1_31)
> seem to be reserved by OpenBSD and great trouble is caused if I try to
> set them with gpioctl(8) like I would for any other pin, e.g. like pin
> 46 here:

> /usr/sbin/gpioctl gpio2  7 set out p8pin46;

> Trial and error shows that setting pins 25, 21, and 20 causes trouble
> right away.

I was surprised by Theo's answer because I recall BeagleBone Black was
open hardware, at least as a design. But I won't bet my hand on the
board's ARM cpu.
Anyway, I am not using it, I consider it for fun, but I checked it
again and here it is:

Excerpt from the hardware support:

"BeagleBone Black ships with two virtual capes already on it, one for
the on-board eMMC storage and one for the HDMI output. When configured
for use these virtual capes consume actual resources.

If the eMMC is not placed in reset, the MMC1* signals may not be used
without potentially corrupting the contents of your on-board
eMMC---and possibly damaging the physical circuit as well."

The pins used by MMC1* are shown in the picture: 3, 4, 5, 6, 21, 22, 23, 24, 25.

Re: Colour man pages via ssh + tmux on 5.9?

[Craig Skinner]

On 2016-08-10 Wed 04:10 AM |, li...@wrant.com wrote:
> Better carry around a small sub-notebook running OpenBSD like everyone.
> 

Aye, it would be good if everybody done that Anton.

Until then,
-- 
http://www.youtube.com/watch?v=U7BPfF6j5Mo

Re: Colour man pages via ssh + tmux on 5.9?

[Craig Skinner]

Hi again Philip,

On 2016-08-08 Mon 13:33 PM |, Philip Guenther wrote:
> 
> You can probably emulate this by defining your own terminfo entry
> under ~/.terminfo/ with the desired overrides.
> 

This is what I've done (inspired by Mark Nudelman's post on
http://linuxtidbits.wordpress.com/2009/03/23/less-colors-for-man-pages/):


$ cat ~/.terminfo/Makefile
#
#   $Id: Makefile,v 1.13 2016/08/10 17:40:04 craig Exp $
#
#   Public domain
#

DIR!=   print ${TERM} | cut -c 1

.SILENT:


all:${DIR}/${TERM}


${DIR}/${TERM}: ${@F}.ti
tic ${@F}.ti


${TERM}.ti:
print "${@:R}," > $@
put=$$(tput blink && tput setaf 1) && print "\tblink=$${put}," >> $@
put=$$(tput bold && tput setaf 2) && print "\tbold=$${put}," >> $@
-put=$$(tput dim && tput setaf 5) && print "\tdim=$${put}," >> $@
put=$$(tput smso && tput setaf 3) && print "\tsmso=$${put}," >> $@
put=$$(tput rmso && tput setaf 7) && print "\trmso=$${put}," >> $@
put=$$(tput smul && tput setaf 6) && print "\tsmul=$${put}," >> $@
put=$$(tput rmul && tput setaf 7) && print "\trmul=$${put}," >> $@
print "\tuse=${@:R}," >> $@

# EOF




$ find ~/.terminfo
/home/me/.terminfo
/home/me/.terminfo/Makefile
/home/me/.terminfo/Makefile,v
$ for t in screen xterm xterm-new xterm-color tmux
> do
> export TERM=$t
> make
> done
tput: Unknown terminfo capability `dim'
*** Error 4 in target 'xterm-color.ti' (ignored)
$ find .
.
./Makefile
./Makefile,v
./screen.ti
./s
./s/screen
./tmux.ti
./t
./t/tmux
./xterm.ti
./xterm-new.ti
./xterm-color.ti
./x
./x/xterm
./x/xterm-new
./x/xterm-color


Then test for each terminal in screen xterm xterm-new xterm-color tmux:

$ export TERM=blah
$ man ls
$ less /var/log/messages# Search for bsd & see coloured highlighting.
$ colorls -GF / # Check colours.
$ vim -R /usr/libexec/security  # Check syntax colouring, etc.
$ lynx www.OpenBSD.Org

Seems OK.



To install the made terminfo files for everybody (after backing up):

$ cd /usr/share/terminfo && \
sudo cp -pi t/tmux t/tmux-OpenBSD && \
sudo cp -pi s/screen s/screen-OpenBSD && \
sudo cp -pi x/xterm x/xterm-OpenBSD && \
sudo cp -pi x/xterm-new x/xterm-new-OpenBSD && \
sudo cp -pi x/xterm-color x/xterm-color-OpenBSD

$ sudo install -b -S -p -o root -g bin -m 444 ~me/.terminfo/t/tmux t/tmux
$ sudo install -b -S -p -o root -g bin -m 444 ~me/.terminfo/s/screen s/screen
$ sudo install -b -S -p -o root -g bin -m 444 ~me/.terminfo/x/xterm x/xterm
$ sudo install -b -S -p -o root -g bin -m 444 ~me/.terminfo/x/xterm-new 
x/xterm-new
$ sudo install -b -S -p -o root -g bin -m 444 ~me/.terminfo/x/xterm-color 
x/xterm-color


Disable my local overrides:

$ cd
$ mv ~/.terminfo ~/.terminfo~
$ man ls# and run the other tests above again.


Cheers!
-- 
http://www.youtube.com/watch?v=RT3zUy_kXTE

Re: GPIO for P8 Expansion Header on Beaglebone Black

[Theo de Raadt]

>How can I find all pins are reserved by OpenBSD and should not be
>changed or used?
>Of the pins reserved, what are their purposes?

We don't know.  For any of these platforms.

If we knew what specific pins did -- for certain -- there would
be a driver using them.

I think the entire subsystem is misnamed.  They are not general
purpose pins.  They are SPECIAL PURPOSE pins, hooked up to WTF
knows what.  Not general purpose at all.

If we had hardware where we knew for CERTAIN that a block of pins
were ONLY wired to specific a specific "general-purpose" header on
the board -- fine.  But we don't know, on nearly every platform with
this retarded featureset.

Frankly, if those drivers were removed, very few people would
miss them.  And fewer people would be tempted to fry their boards.

Now you have potentially half-fried your board.  Will you file
bug reports in the future for things you observe on that machine?

I could go on for a while, but I'll let this sit for consideration..

GPIO for P8 Expansion Header on Beaglebone Black

[Lars Noodén]

I've been walking through the GPIO pins for expansion header P8 on a
Beaglebone Black, checking actual pin output with the hardware [1] [2]
information.  Pins 3 through 46 on P8 are listed in the hardware
information as available for GPIO.  Indeed, I can set any of them but
I notice that on pins 25 (gpio1_0), 21 (gpio1_30), and 20 (gpio1_31)
seem to be reserved by OpenBSD and great trouble is caused if I try to
set them with gpioctl(8) like I would for any other pin, e.g. like pin
46 here:

/usr/sbin/gpioctl gpio2  7 set out p8pin46;

Trial and error shows that setting pins 25, 21, and 20 causes trouble
right away.  I've looked in INSTALL.armv7 and the GPIO-related manual
pages.  Are there other pins in use by the system which are less
immediate in making their effects known? I don't want to let the magic
blue smoke out of any hardware components.

How can I find all pins are reserved by OpenBSD and should not be
changed or used?
Of the pins reserved, what are their purposes?

Regards,
Lars

[1] Figure: "65 Possible Digital I/Os" http://beagleboard.org/Support/bone101
[2] Table 10. "P8 Mux Options Modes 4-7" BONE_SRM.pdf

-

OpenBSD 6.0-current (GENERIC) #11: Mon Aug  8 21:05:56 MDT 2016
dera...@armv7.openbsd.org:/usr/src/sys/arch/armv7/compile/GENERIC
real mem  = 536870912 (512MB)
avail mem = 517963776 (493MB)
mainbus0 at root: TI AM335x BeagleBone Black
cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache
omap0 at mainbus0
prcm0 at omap0 rev 0.2
sitaracm0 at omap0: control module, rev 1.0
omap0: device edma unit 0 not configured
dmtimer0 at omap0 rev 3.1
dmtimer1 at omap0 rev 3.1
omgpio0 at omap0: rev 0.1
gpio0 at omgpio0: 32 pins
omgpio1 at omap0: rev 0.1
gpio1 at omgpio1: 32 pins
omgpio2 at omap0: rev 0.1
gpio2 at omgpio2: 32 pins
omgpio3 at omap0: rev 0.1
gpio3 at omgpio3: 32 pins
simplebus0 at mainbus0: "ocp"
simplebus1 at simplebus0: "l4_wkup"
simplebus2 at simplebus1: "scm"
intc0 at simplebus0 rev 5.0
com0 at simplebus0: ti16750, 64 byte fifo
com0: console
tiiic0 at simplebus0 rev 0.11
iic0 at tiiic0
"ti,tps65217" at iic0 addr 0x24 not configured
"at,24c256" at iic0 addr 0x50 not configured
"nxp,tda998x" at iic0 addr 0x70 not configured
tiiic1 at simplebus0 rev 0.11
iic1 at tiiic1
"at,24c256" at iic1 addr 0x54 not configured
"at,24c256" at iic1 addr 0x55 not configured
"at,24c256" at iic1 addr 0x56 not configured
"at,24c256" at iic1 addr 0x57 not configured
ommmc0 at simplebus0
sdmmc0 at ommmc0: 1-bit, mmc high-speed
ommmc1 at simplebus0
sdmmc1 at ommmc1: 1-bit, mmc high-speed
omdog0 at simplebus0 rev 0.1
cpsw0 at simplebus0: version 1.12 (0), address 68:9e:19:8f:85:fa
ukphy0 at cpsw0 phy 0: Generic IEEE 802.3u media interface, rev. 1: OUI 0x0001f0
, model 0x000f
sdmmc0: can't enable card
scsibus0 at sdmmc1: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI2 0/direct fixed
sd0: 3648MB, 512 bytes/sector, 7471104 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (d499bd6a7c8df27c.a) swap on sd0b dump on sd0b
WARNING: CHECK AND RESET THE DATE!

Re: opportunity to help: %s audit in mandoc

[attila]

Hi everybody,

Here is an updated list after doing what I said yesterday.  One nit: I
count 25 instances in cgi.c, not 27.

  // 27 cgi.c: all ok
  //   317: msg is only NULL when status == 200
  //   351,353,379,405,409,421,425,497,499,527: compile-time string
  // constants and/or scriptname
  //   552: neither r[i].file nor req->q.manpath can be NULL if we got this far
  //   564,585,809,814: constants or cannot be NULL
  //   878: made it through validate_manpath
  //   915: req.q.manpath is set by caller
  //  1002,1149: compile-time string constant
  //  1163,1164,1169,1170: compile-time constant, dp cannot be NULL there
  //  1180: compile-time string constant
  // 4 dbm.c: all ok
  //85,92,96,102: dbm_map(fname) won
  // 5 dbm_map.c: all ok
  //60,73,80,87,97: open(fname) won
  // // 3 eqn.c: agree with Dariusz
  //305: p cannot be NULL
  //679: def->key is set above if def is NULL
  //   1077: eqnsyms[i].sym cannot be NULL

So I guess I'll start on these next:

   5 html.c:
  20 main.c:
   2 man.c:
   2 man_html.c:
   5 man_macro.c:

... and check you here:

   // 2 man_term.c:

Please check me, too.

   9 man_validate.c:
  37 mandocdb.c:
   2 manpath.c:
  23 mansearch.c:
   4 mdoc_html.c:
   // 10 mdoc_macro.c:
   1 mdoc_man.c:
   2 mdoc_term.c:
  43 mdoc_validate.c:
   6 read.c:
  13 roff.c:
   // 1 tag.c:
   // 1 tbl_layout.c:
   // 1 tbl_opts.c:
   6 term_ps.c:
  11 tree.c:

One thing I noticed in cgi.c, line 1015: what if there are multiple
slashes at the head of path?  I think this can happen unless I'm
missing something.

Pax, -A
--
http://haqistan.net/~attila | att...@stalphonsos.com | 0x62A729CF

Re: pf filter problem: cannot connect to external SMB share from LAN

[Marko Cupać]

On Wed, 10 Aug 2016 09:50:38 -0400
William Wallace  wrote:

> I am trying to connect to an SMB share outside of the office.  I have
> confirmed that the share works and others on the Internet can connect
> to it fine, but connections from within my office do not go through.
>
> I am guessing I have something wrong with the office's pf filters or
> NATing but I cannot identify the problem -- my pf.conf is fairly
> simple.  All machines on the network can get to other services (http,
> https, rdp, ssh, ... anything, really) but cannot establish an SMB
> connection.  Nothing of interest shows up in the pf log.

Can you connect to the same share from the same client but from the
different (unrestricted) network?

Does IP address belong to restricted IP pools?

I see you aren't scrubbing, clearing no-df bits and adjusting max-mss -
this is definitely a must on some ADSL links, including mine.

Perhaps you could reorganize rules and turn on logging for all blocked
packets, this could help you troubleshoot with tcpump.

Here's example of my rules, maybe they'll help:

---snip---
# QUICK BLOCKS
antispoof for $if_int
antispoof for $if_ext
block log quick inet6
block log quick from 

# SCRUB & NAT & FTP
match in all scrub ( no-df random-id max-mss 1440 )
match out on egress inet from !(egress:network) to any nat-to (egress:0)
pass quick on lo0

# RULES
block log all

pass in  on $if_ext inet proto tcp  from any \
 to ($if_ext:0) port ssh
pass in  on $if_ext inet proto tcp  from any \
 to ($if_ext:0) port $fw_svc1 rdr-to $svc1
pass in  on $if_ext inet proto tcp  from any \
 to ($if_ext:0) port $fw_svc2 rdr-to $svc2
pass in  on $if_ext inet proto icmp from
 any to ($if_ext:0) icmp-type 8

pass in quick on $if_int inet proto tcp from $if_int:network to any \
 port ftp divert-to 127.0.0.1 port 8021
pass in on $if_int inet proto tcp
pass in on $if_int inet proto udp
pass in on $if_int inet proto icmp

pass out on $if_ext
pass out on $if_int
---snip---

The above ruleset is easy to troubleshoot, as all the blocked packets
can be seen in real time with:

tcpdump -n -e -q -ttt -i pflog0

...and history of blocked packets can be seen with:

tcpdump -n -e -q -ttt -r /var/log/pflog

Regards,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: pf filter problem: cannot connect to external SMB share from LAN

[Vivek Vinod]

‎Sorry... Just couldn't resist this one...

you've won so many huge battles, yet need help with pf/ NAT?

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: William Wallace
Sent: Wednesday 10 August 2016 19:34
To: misc@openbsd.org
Subject: pf filter problem: cannot connect to external SMB share from LAN

I am trying to connect to an SMB share outside of the office. I have
confirmed that the share works and others on the Internet can connect
to it fine, but connections from within my office do not go through.

I am guessing I have something wrong with the office's pf filters or
NATing but I cannot identify the problem -- my pf.conf is fairly
simple. All machines on the network can get to other services (http,
https, rdp, ssh, ... anything, really) but cannot establish an SMB
connection. Nothing of interest shows up in the pf log.

pf.conf pasted below. Thank you for your time.

Sincerely,
william

## macros
# interfaces
intIf = "fxp0"
extIf = "fxp1"
# inside machines
dvrIp = "192.168.10.7"
scannerIp = "192.168.10.20"
pc2Ip = "192.168.10.21"
pc3Ip = "192.168.10.32"
# public IPs
natOutIp = "single.public.ip.address"
serviceInIp = "d.i.tt.o"
# internal services
rdpPort = "3389"
rdpPort2 = "3390"
rdpPort3 = "3391"
dvrWebPubPort = 82
dvrServicePort = 6036

## block list
APNIC = '"1.0.0.0/8" "43.0.0.0/8"'
RIPE = '"31.0.0.0/8" "109.230.240.0/20"'
CHINA = '"121.8.0.0/13"'
blockList = "{ " $APNIC $RIPE $CHINA " }"

## options
set block-policy return
set skip on lo

## filter rules
block in log quick on $extIf from $blockList
block in log on $extIf
pass in quick on $intIf
pass out
# NATing
pass out on $extIf from 192.168.10.0/24 to any nat-to $natOutIp
# internal services
pass in on $extIf inet proto tcp to $serviceInIp port $dvrWebPubPort
rdr-to $dvrIp port 80
pass in on $extIf inet proto tcp to $serviceInIp port $dvrServicePort
rdr-to $dvrIp
pass in on $extIf inet proto tcp to $serviceInIp port $rdpPort rdr-to
$scannerIp port $rdpPort keep state
pass in on $extIf inet proto tcp to $serviceInIp port $rdpPort2 rdr-to
$pc2Ip port $rdpPort keep state
pass in on $extIf inet proto tcp to $serviceInIp port $rdpPort3 rdr-to
$pc3Ip port $rdpPort keep state
# ssh
pass in on $extIf inet proto tcp to $serviceInIp port ssh

pf filter problem: cannot connect to external SMB share from LAN

[William Wallace]

I am trying to connect to an SMB share outside of the office.  I have
confirmed that the share works and others on the Internet can connect
to it fine, but connections from within my office do not go through.

I am guessing I have something wrong with the office's pf filters or
NATing but I cannot identify the problem -- my pf.conf is fairly
simple.  All machines on the network can get to other services (http,
https, rdp, ssh, ... anything, really) but cannot establish an SMB
connection.  Nothing of interest shows up in the pf log.

pf.conf pasted below.  Thank you for your time.

Sincerely,
william

## macros
# interfaces
intIf = "fxp0"
extIf = "fxp1"
# inside machines
dvrIp = "192.168.10.7"
scannerIp = "192.168.10.20"
pc2Ip = "192.168.10.21"
pc3Ip = "192.168.10.32"
# public IPs
natOutIp = "single.public.ip.address"
serviceInIp = "d.i.tt.o"
# internal services
rdpPort = "3389"
rdpPort2 = "3390"
rdpPort3 = "3391"
dvrWebPubPort = 82
dvrServicePort = 6036

## block list
APNIC = '"1.0.0.0/8" "43.0.0.0/8"'
RIPE = '"31.0.0.0/8" "109.230.240.0/20"'
CHINA = '"121.8.0.0/13"'
blockList = "{ " $APNIC $RIPE $CHINA " }"

## options
set block-policy return
set skip on lo

## filter rules
block in log quick on $extIf from $blockList
block in log on $extIf
pass  in quick on $intIf
pass  out
# NATing
pass out on $extIf from 192.168.10.0/24 to any nat-to $natOutIp
# internal services
pass in on $extIf inet proto tcp to $serviceInIp port $dvrWebPubPort
rdr-to $dvrIp port 80
pass in on $extIf inet proto tcp to $serviceInIp port $dvrServicePort
rdr-to $dvrIp
pass in on $extIf inet proto tcp to $serviceInIp port $rdpPort  rdr-to
$scannerIp port $rdpPort keep state
pass in on $extIf inet proto tcp to $serviceInIp port $rdpPort2 rdr-to
$pc2Ip port $rdpPort keep state
pass in on $extIf inet proto tcp to $serviceInIp port $rdpPort3 rdr-to
$pc3Ip port $rdpPort keep state
# ssh
pass in on $extIf inet proto tcp to $serviceInIp port ssh

Re: github

[Marko Cupać]

On Mon, 8 Aug 2016 17:56:30 -0700
David Schmidt  wrote:

> Nick Holland wrote:
> >Nowhere on the OpenBSD website mentions github as anything
> >official.
>
> It does on this page: https://www.openbsd.org/libressl/. Its even
> above the cvs link. Of course this is just for libressl not for the
> rest of openbsd.
>

Nice observation David :)

Now regarding those libressl n00bz... I mean github... really? REALLY?

*disclaimer*
This is sarcasm, I'm just trolling. Personally I don't like github in
the same way I don't like any other 'cloud' service, but that's just me.
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: Relayd and stateful tracking options

[Mathieu BLANC]

On Tue, Aug 09, 2016 at 04:33:33PM +0200, Sebastian Benoit wrote:
> Mathieu BLANC(mathieu.bl...@smile.fr) on 2016.08.09 11:18:57 +0200:
> > Hello,
> > 
> > I'm using relayd with Redirections (OpenBSD 5.9)
> > Relayd creates these rdr-to rules :
> > anchor "_http" all {
> >   pass in quick on rdomain 0 inet proto tcp from any to A.B.C.D port = 80 
> > flags S/SA keep state (tcp.established 600) rdr-to  port 80 
> > round-robin
> > }
> > 
> > Is there a way to modify the Stateful Tracking Options after keep state ? 
> > (I'd
> > want to add a max state on a specific redirection)
> > 
> > Thanks !
> 
> Use the "pftag name" option.
> 
> That will change the inserted rule to not have the quick keyword. Also it
> gets a "tagged name" added.
> 
> Then, in pf.conf add another rule
> 
>  pass in tagged name keep state (max 3)
> 

Just tried your solution, it's perfect ;)
I've used "match pftag name".

Thank you !

(in the man :
 [match] pftag name
 Automatically tag packets passing through the pf(4) rdr-to rule
 with the name supplied.  This allows simpler filter rules.  The
 optional match keyword will change the default rule action from
 `pass in quick' to `match in' to allow further evaluation in the
 pf ruleset using the tagged name rule option.
)

-- 
Mathieu