Re: panic "locking against myself"

[Aisha Tammy]

On 11/29/20 7:09 PM, Ed Ahlsen-Girard wrote:
> I've had a couple of panics:
> 
> mtx(something) (address)
> locking against myself
> 
> 
> in the last
> couple of days. The most recent address was 0x821c63c8
> 
> How do this get tracked down? No core files from anything in the
> applicable time window. dmesg below signature.
> 

Was fixed in latest snapshot
During boot select bsd.rd and sysupgrade.
Should be fine.

Re: pflogd: Corrupted log file, move it away

[Harald Dunkel]

Hi folks,

On 11/28/20 5:13 PM, Stuart Henderson wrote:


It is easy enough to add the filename, but adding that to the log
might suggest to users that things are setup to handle multiple pflogd
processes and that is not the case.

Various parts of the system would need changing in order to handle this.
Currently there is no way to distinguish between multiple "priv" processes
as the process title doesn't show the command-line flags. In order to
support multiple pflogd processes this would need adding, then the rc.d
scripts and default newsyslog.conf entry would need updating to use them.



I have to admit that this was my fault. There were 2 pflogd writing to
/var/log/pflog, AFAICS. The other 2 were not even started.

To support 4 pflog interfaces I had to create 4 symlinks in /sbin

ln -s pflogd /sbin/pflogd0
ln -s pflogd /sbin/pflogd1
ln -s pflogd /sbin/pflogd2
ln -s pflogd /sbin/pflogd3

and to create 4 rc scripts in /etc/rc.d, e.g /etc/rc.d/pflogd2:

#!/bin/ksh

daemon="/sbin/pflogd2"

. /etc/rc.d/rc.subr

pexp="pflogd2: \[priv\]"

rc_pre() {
if pfctl -si | grep -q Enabled; then
ifconfig pflog2 create
if ifconfig pflog2; then
ifconfig pflog2 up
else
return 1
fi
else
return 1
fi
}

rc_cmd $1

Each pflogd had to be configured accordingly using rcctl, e.g.

rcctl enable pflogd2
rcctl set pflogd2 flags "-i pflog2 -f /var/log/pflog2"
rcctl start pflogd2

(Be careful, if you disable and enable the service, then you have to
set the flags again.)

Finally I had to add the new log files to newsyslog.conf:

/var/log/pflog0 600 7   65536   24  ZB "pkill -HUP -u root -U 
root -t - -x pflogd0"
/var/log/pflog1 600 7   65536   24  ZB "pkill -HUP -u root -U 
root -t - -x pflogd1"
/var/log/pflog2 600 7   65536   24  ZB "pkill -HUP -u root -U 
root -t - -x pflogd2"
/var/log/pflog3 600 7   65536   24  ZB "pkill -HUP -u root -U 
root -t - -x pflogd3"


Hope this is helpful to anybody.


Regards
Harri

panic "locking against myself"

[Ed Ahlsen-Girard]

I've had a couple of panics:

mtx(something) (address)
locking against myself


in the last
couple of days. The most recent address was 0x821c63c8

How do this get tracked down? No core files from anything in the
applicable time window. dmesg below signature.

-- 

Edward Ahlsen-Girard
Ft Walton Beach, FL


OpenBSD 6.8-current (GENERIC.MP) #195: Fri Nov 27 02:08:21 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4176125952 (3982MB)
avail mem = 4034252800 (3847MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec530 (36 entries)
bios0: vendor AMI version "80.06" date 04/01/2015
bios0: Hewlett-Packard 550-036
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MSDM SSDT SSDT MCFG HPET SSDT SSDT DBGP
acpi0: wakeup devices RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) 
PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) 
EHC2(S3) XHC_(S3) [...]
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) Core(TM) i3-4170 CPU @ 3.70GHz, 3692.02 MHz, 06-3c-03
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
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.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.47 MHz, 06-3c-03
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.46 MHz, 06-3c-03
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-4170 CPU @ 3.70GHz, 3691.46 MHz, 06-3c-03
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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP06)
acpiprt4 at acpi0: bus 4 (RP07)
acpiprt5 at acpi0: bus -1 (PEG0)
acpiec0 at acpi0: not present
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), 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 a

bridge(4) Problems when running under ESXi ?

[Heinrich Rebehn]

Hi all,

I am trying to setup an OpenBSD 6.7 virtual machine under VMware ESXi 6.7 to 
use as a filtering bridge between two virtual networks. I enabled promiscuous 
mode for both virtual switches.
One network is the VMnet network, which is connected to the “outside world”.

“A” ——> “B” ——> “R”

“A” is a test machine   192.168.1.152
“B” is the bridge   No IP. em0 connects to R, em1 connects to A
“R” is the router provided by the hoster192.168.1.1

The addresses are only examples, the actual addresses a public IPs.

When A tries to ping R, ist sends an arp request for R’s lladr. R responds with 
its lladr. Tcpdump on R’s em1 suggests that it is sent out on the virtual 
network. However, A does not see the arp reply, hence ping(8) fails.

What am I missing? While browsing the mailing list archive, I just saw that 
vmx(4) might be a better choice, but I had not yet time to try it out.


Any other known issues around bridge(4) or promiscuous mode under ESXi ?

Thanks for any insights,

Heinrich

Re: bridge(4) Problems when running under ESXi ?

[Tom Smyth]

Hello Heinrich,
it is not OpenBSD  it is a Vmware issue ...

virtualnets / vswitches in ESXI are not proper switches... they forward
packets based on static mac- virtual port entries.   (they do not do proper
mac learning)

you can set the vwswitch in the networking configuration section ... there
are 2 places  you can set it ... in the vmnet and the vswitch setup in the
vmnet setup config  in vsphere

there are 3 workarounds

1) use promiscuous mode (you can set the promiscuous setting on the
vswitch)  you will also need to allow mac changes and forged transmits
(from memory)
Upside (it works) and is Free

downside each vm on that vswitch receives a copy of the frames sent and
received   ...  promiscuous makes a vhub rather than a vswitch
so it is slower than one would like

2) there is a lab test switch (it was in vmware labs I think)  that does
mac learning however it does not do mac aging
upside it works and is faster than promiscuous
downside not againg out macs is just f**king dumb ...

3) get the enterprise enterprise enterprise +  licence and they will give
you proper mac learning on the virtual switches

and that is the reason I migrated to a different Virtual machine solution
...

I love Vmware but they are optimistic when they call their vswitches
switches ...  they are efficeint for non forwarding workloads and I can
understand why they do the static map by default
but for networking  (they dont even give you LACP on their enterprise
licence you have to go for their top line license enterprise Plus (last
time i checked)

it is a pitty because I do like Vmware and moving off it was tough as
breaking an addiction...

Hope this helps

Tom Smyth



On Sun, 29 Nov 2020 at 22:10, Heinrich Rebehn 
wrote:

> Unfortunately, switching to vmx(4) did *not* do the trick
>
> -Heinrich
>
>
> > On 29. Nov 2020, at 22:38, Heinrich Rebehn 
> wrote:
> >
> > Some things I forgot:
> >
> > All interfaces are UP
> > pf(4) ist disabled
> > bridge0 sees a bunch of lladdrs on em0 and one on em1, which is that of
> “A”
> >
> > -Heinrich
> >
> >
> >> On 29. Nov 2020, at 22:29, Heinrich Rebehn  > wrote:
> >>
> >> Hi all,
> >>
> >> I am trying to setup an OpenBSD 6.7 virtual machine under VMware ESXi
> 6.7 to use as a filtering bridge between two virtual networks. I enabled
> promiscuous mode for both virtual switches.
> >> One network is the VMnet network, which is connected to the “outside
> world”.
> >>
> >> “A” ——> “B” ——> “R”
> >>
> >> “A” is a test machine192.168.1.152
> >> “B” is the bridgeNo IP. em0 connects to R, em1 connects to A
> >> “R” is the router provided by the hoster 192.168.1.1
> >>
> >> The addresses are only examples, the actual addresses a public IPs.
> >>
> >> When A tries to ping R, ist sends an arp request for R’s lladdr. R
> responds with its lladdr. Tcpdump on R’s em1 suggests that it is sent out
> on the virtual network. However, A does not see the arp reply, hence
> ping(8) fails.
> >>
> >> What am I missing? While browsing the mailing list archive, I just saw
> that vmx(4) might be a better choice, but I had not yet time to try it out.
> >>
> >>
> >> Any other known issues around bridge(4) or promiscuous mode under ESXi ?
> >>
> >> Thanks for any insights,
> >>
> >>  Heinrich
>
>

-- 
Kindest regards,
Tom Smyth.

Re: bridge(4) Problems when running under ESXi ?

[Heinrich Rebehn]

Some things I forgot:

All interfaces are UP
pf(4) ist disabled
bridge0 sees a bunch of lladdrs on em0 and one on em1, which is that of “A”

-Heinrich


> On 29. Nov 2020, at 22:29, Heinrich Rebehn  wrote:
> 
> Hi all,
> 
> I am trying to setup an OpenBSD 6.7 virtual machine under VMware ESXi 6.7 to 
> use as a filtering bridge between two virtual networks. I enabled promiscuous 
> mode for both virtual switches.
> One network is the VMnet network, which is connected to the “outside world”.
> 
> “A” ——> “B” ——> “R”
> 
> “A” is a test machine 192.168.1.152
> “B” is the bridge No IP. em0 connects to R, em1 connects to A
> “R” is the router provided by the hoster  192.168.1.1
> 
> The addresses are only examples, the actual addresses a public IPs.
> 
> When A tries to ping R, ist sends an arp request for R’s lladdr. R responds 
> with its lladdr. Tcpdump on R’s em1 suggests that it is sent out on the 
> virtual network. However, A does not see the arp reply, hence ping(8) fails.
> 
> What am I missing? While browsing the mailing list archive, I just saw that 
> vmx(4) might be a better choice, but I had not yet time to try it out.
> 
> 
> Any other known issues around bridge(4) or promiscuous mode under ESXi ?
> 
> Thanks for any insights,
> 
>   Heinrich
> 
> 
> 

Re: bridge(4) Problems when running under ESXi ?

[Heinrich Rebehn]

Unfortunately, switching to vmx(4) did *not* do the trick

-Heinrich


> On 29. Nov 2020, at 22:38, Heinrich Rebehn  wrote:
> 
> Some things I forgot:
> 
> All interfaces are UP
> pf(4) ist disabled
> bridge0 sees a bunch of lladdrs on em0 and one on em1, which is that of “A”
> 
> -Heinrich
> 
> 
>> On 29. Nov 2020, at 22:29, Heinrich Rebehn > > wrote:
>> 
>> Hi all,
>> 
>> I am trying to setup an OpenBSD 6.7 virtual machine under VMware ESXi 6.7 to 
>> use as a filtering bridge between two virtual networks. I enabled 
>> promiscuous mode for both virtual switches.
>> One network is the VMnet network, which is connected to the “outside world”.
>> 
>> “A” ——> “B” ——> “R”
>> 
>> “A” is a test machine192.168.1.152
>> “B” is the bridgeNo IP. em0 connects to R, em1 connects to A
>> “R” is the router provided by the hoster 192.168.1.1
>> 
>> The addresses are only examples, the actual addresses a public IPs.
>> 
>> When A tries to ping R, ist sends an arp request for R’s lladdr. R responds 
>> with its lladdr. Tcpdump on R’s em1 suggests that it is sent out on the 
>> virtual network. However, A does not see the arp reply, hence ping(8) fails.
>> 
>> What am I missing? While browsing the mailing list archive, I just saw that 
>> vmx(4) might be a better choice, but I had not yet time to try it out.
>> 
>> 
>> Any other known issues around bridge(4) or promiscuous mode under ESXi ?
>> 
>> Thanks for any insights,
>> 
>>  Heinrich

Re: Redistribution between ospfd and ripd

[Jason Tubnor]

On Sat, 28 Nov 2020 at 11:14, Sebastian Benoit  wrote:

> Hi,
>
>
>
>   route add -label FOOBAR 172.16.1.0/24 172.16.2.5
>   route show -label FOOBAR
>
> I am only aware of these mechanisms to set labels on routes added by
> routing daemons:
>
> bgpd (rtlabel  keyword in filter "set")
> ospfd/ospf6d (rtlabel label external-tag number)
>
> Neither would help in your situation.
>
> Can you explain a bit more what you are planing to do?
>

Thanks for that Benno.  I did see another rtlabel reference in ifconfig(8)
but I don't think that will work as expected either
https://man.openbsd.org/ifconfig#rtlabel

During the migration, there will be OpenBSD routers in the network that
will have some routes coming in from OSPF and RIPv2 so both daemons will be
running on these hosts so network segments can continue to talk to each
other.  In the usual commercial offerings, you simply imply what you want
to redistribute and this can be another routing protocol, static, connected
etc. as the routing stack is aware of other protocols being used.

| OSPF 0.0.0.1 | <-> | OpenBSD Router | <-> | RIPv2 |

Cheers.

Re: Reinstall to upgrade

[Stuart Henderson]

On 2020-11-28, Gregory Edigarov  wrote:
> #!/bin/sh
> rm -rf /usr/local/*  /var/db/pkg/* /var/db/pkg/.* /etc/rc.d/*_daemon

There are only 3 packages with /etc/rc.d/*_daemon files.. also
you aren't putting /usr/local/lib/X11/app-defaults back how it should
be, and you miss creating the directory structure under /usr/local
which may mean that dirs get readded with inappropriate ownership/
permissions. You can fix these up like so,

mtree -qdef /etc/mtree/4.4BSD.dist -p / -U
mkdir -p /usr/local/lib/X11
ln -fs /etc/X11/app-defaults /usr/local/lib/X11/app-defaults
ldconfig -RU

though none of this should be necessary unless files have become
corrupted beyond what pkg_check can cope with.

(also some packages install files in various places under /var that
you'll miss with your rm).

Normally pkg_add -u, pkg_delete -a, and removing most files suggested
by sysclean will do the trick nicely.

> xpdf \
> zsh ; do pkg_add  -v $i; done

this will run a bit more quickly if you add all packages in a single
pkg_add command, otherwise it will have to re-run triggers multiple
times that would otherwise just be run once.

Re: support new

[Ingo Schwarze]

Hi,

supo...@mdfsoftware.com.br wrote on Sun, Nov 29, 2020 at 01:40:18PM -0300:

> 0
> C Brazil
> P Ceará
> T FORTALEZA
> Z 60410442
> O MDFSoftware
> I Oliveira Filho, D. A.
> A Av. Eduardo Girão 355
> M supo...@mdfsoftware.com.br
> U http://www.mdfsoftware.com.br/
> B +55-85-9-89739017
> X +55-85-9-96110010
> N Auditoria, Desenvolvimento, Suporte comercial para FreeBSD e
> OpenBSD, gateways de Internet, firewalls em cluster, sistemas de
> detecção de intrusão e VPNs.

Your web site does not contain any mention of OpenBSD as far as i can
see, so i'm not adding it right now.

Also, there is almost no content on the web site and none of the
buttons that appear to explain the company's products lead anywhere.
The little text that is there mostly consists of web-scale buzzwords.

Feel free to resubmit after collecting some references to completed
projects and/or some success stories related to OpenBSD.

Yours,
  Ingo

support new

[porte, su]

0
C Brazil
P Ceará
T FORTALEZA
Z 60410442
O MDFSoftware
I Oliveira Filho, D. A.
A Av. Eduardo Girão 355
M supo...@mdfsoftware.com.br
U http://www.mdfsoftware.com.br/
B +55-85-9-89739017
X +55-85-9-96110010
N Auditoria, Desenvolvimento, Suporte comercial para FreeBSD e
OpenBSD, gateways de Internet, firewalls em cluster, sistemas de
detecção de intrusão e VPNs.

Re: incorrect pf rule?

[Родин Максим]

It turns out that my caring ISP really has a free firewall service
which is enabled by default.
I asked my ISP to disable it completely and now everything is OK.
Thank you!

29.11.2020 13:08, Stuart Henderson пишет:

On 2020-11-29, Родин Максим  wrote:

The problem is that only port 80 seems to be open from the outside.
I used several online port scanners to check this.
All of them tell:
port 80 OPEN
port 443 CLOSED


Could it be blocked by your ISP? Do you receive packets on your external
interface at all when you test port 443?




--
С уважением,
Родин Максим

Re: Reinstall to upgrade

[Eric Furman]

On Sat, Nov 28, 2020, at 9:40 AM, Gregory Edigarov wrote:
> 
> 
> On 11/25/20 3:26 PM, Manuel Giraud wrote:
> > Hi,
> >
> > I'd like to upgrade (on -current) and, in the process, remove some cruft
> > accumulated over the years. I usually do sysupgrade and sysclean for
> > system.
> >
> > But for packages, I think I would be better to reinstall everything
> > since "pkg_check -F" does not seems to complain and I can see I have,
> > for example, some firefox-57 files left.
> >
> > I think I could do the following but I don't know if it is safe:
> > - sysupgrade (+ sysclean)
> > - pkg_info -mz > mypkg
> > - umount /usr/local
> > - newfs partition_of_usr_local
> > - mount /usr/local
> > - pkg_add -l mypkg
> >
> > Or maybe, I should dump, do a complete reinstall, pkg_add -l mypkg,
> > restore /home and, tediously, restore some /etc files.
> > How would you do this?
> Here's what I found easy to do periodically on my home computers, when I
> feel it is a time to de-clutter:
> 
> #!/bin/sh
> rm -rf /usr/local/*  /var/db/pkg/* /var/db/pkg/.* /etc/rc.d/*_daemon
> /etc/rc.d/avahi* 
> for i in \
> adobe-source-code-pro \
> ansible \
> borgbackup \
> chromium \
> emacs--gtk3 \
> gnupg-- \
> dmenu \
> firefox \
> thunderbird \
> rsync-- \
> git \
> gpicview \
> go \
> rust \
> inconsolata-font \
> ipcalc \
> mplayer \
> mtr-- \
> nmap \
> ntfs_3g \
> openvpn \
> pidgin-- \
> pv \
> spectrwm \
> splint \
> tcptraceroute \
> telegram-purple \
> terminus-font \
> transmission \
> vim--gtk2 \
> xpdf \
> zsh ; do pkg_add  -v $i; done
> 
> so when I am running it I am easily getting the system which I have most
> essential software installed.
> 
>

If you are going to do all that you might as well just re-install from scratch.

Re: incorrect pf rule?

[Родин Максим]

It turns out that my caring ISP really has a free firewall service
which is enabled by default.
I asked my ISP to disable it completely and now everything is OK.
Thank you!

29.11.2020 14:30, Stuart Henderson пишет:

On 2020-11-29, Stuart Henderson  wrote:

On 2020-11-29, Родин Максим  wrote:

The problem is that only port 80 seems to be open from the outside.
I used several online port scanners to check this.
All of them tell:
port 80 OPEN
port 443 CLOSED


Could it be blocked by your ISP? Do you receive packets on your external
interface at all when you test port 443?





Or...if this is behind nat, do you need to add a port-forwarding on your ISP 
router?



--
С уважением,
Родин Максим

Re: incorrect pf rule?

[Stuart Henderson]

On 2020-11-29, Stuart Henderson  wrote:
> On 2020-11-29, Родин Максим  wrote:
>> The problem is that only port 80 seems to be open from the outside.
>> I used several online port scanners to check this.
>> All of them tell:
>> port 80 OPEN
>> port 443 CLOSED
>
> Could it be blocked by your ISP? Do you receive packets on your external
> interface at all when you test port 443?
>
>
>

Or...if this is behind nat, do you need to add a port-forwarding on your ISP 
router?

Re: pflogd: Corrupted log file, move it away

[Stuart Henderson]

On 2020-11-28, Jan Stary  wrote:
> If I'm reading you right, the rotation sends a SIGHUP to each
> of the pflogd processes; twice, in fact: after rotating each
> of the two files. Is that the case?

Yes, you have the same command for restarting pflogd on both
newsyslog.conf lines so it will send signals to both daemons twice in
short succession. I don't know if that will cause corruption (maybe
pflogd doesn't care if it gets two signals in short succession) but
it's clearly not ideal.

> That would indeed be a problem; namely, it would break the nice
> sequence of one rotated logfile per day.

The rotation is done by newsyslog (once per file) so the sequence
would still work. 

> If I read the newsyslog lines right, each of
>
>   13680 pflogd: [running] -s 1500 -i pflog0 -f /var/log/pflog
>   84985 pflogd: [priv]
>   10562 pflogd: [running] -s 1500 -i pflog1 -f /var/log/siplog
>   94396 pflogd: [priv]
>
> is getting HUP'd, right?

Only the priv processes are sent HUP.

>  Would it be enough to HUP the [running] child?

no idea, but someone obviously went to the trouble to make it signal
only the priv process so there's probably a reason for this.

> |-+= 84985 root pflogd: [priv] (pflogd)
> | \--- 13680 _pflogd pflogd: [running] -s 1500 -i pflog0 -f /var/log/pflog 
> (pflogd)
>
> |-+= 94396 root pflogd: [priv] (pflogd)
> | \--- 10562 _pflogd pflogd: [running] -s 1500 -i pflog1 -f /var/log/siplog 
> (pflogd)
>
> Probably not, based on what you said about [priv]; but the [running]
> processes can be distinguished in newsyslog.conf with "pkill -xf pflog0".

yes those are easy to differentiate :)

iterm2 tmux integration with OpenBSD 6.8 failing?

[Sean Kamath]

Hi.

Just wondering if anyone else has seen any problems with tmux integration with 
iterm2 on 6.8.  I updated two i386 machines (alix 2c13) to 6.8 using 
sysupgrade, and both of them seem to be unresponsive to tmux integration using 
the latest version (3.4.2) of iterm2.  In 6.7 and earlier, I’ve had to hit ^C 
in the initial window, but other than that it worked as expect.  In 6.8, 
nothing will make it responsive.

I tested 6.7 up to syspatch 029_rpki (works fine), and 6.8 with no patches and 
also 006_rpki (both fail to work).

Not asking for a fix, just if anyone else has seen this.

Sean

Re: incorrect pf rule?

[Stuart Henderson]

On 2020-11-29, Родин Максим  wrote:
> The problem is that only port 80 seems to be open from the outside.
> I used several online port scanners to check this.
> All of them tell:
> port 80 OPEN
> port 443 CLOSED

Could it be blocked by your ISP? Do you receive packets on your external
interface at all when you test port 443?

question regarding PF_INET/ttl sysctl

[Peter J. Philipp]

Hi,

I had made a program in 2014, but forgot whether I made it for FreeBSD or
OpenBSD.  This program (found here: https://centroid.eu/public/ttldaemon.c.txt)
changes the default ttl in the system's network stack in order to read out
steganographically a christmas or new years message.

The sysctl(2) manpage says that this value is changeable but it doesn't seem to
have an effect on a 6.8 system.  Did this change in the last 6 years possibly?
Is it a bug?  or intended?  In that case I can remove my ttldaemon.c program.

One way I tested this program was watching the ttl's of a socket connected on
port 25 of my vps and pressing return every X seconds.  (X is around 10 secs)
It didn't change.  Perhaps TCP isn't the right way to monitor this, I forgot
what I used in 2014... could be that I used DNS.  Anyhow the program is not
running for now.

Can someone with knowledge of the IP stack enlighten me whats up with the
ttl sysctl?  Shoudl it at least say no for changeable in the manpage?

Thanks!

-peter