Re: OpenBSD 7.6 released, Oct 8, 2024
On 09/10/2024 00:55, Jesse Lawton wrote: > Thats great, lots of improvements and the artwork looks super cool :D This ! G
Re: dhcpd with failover
On 01/10/2024 08:36, Otto Moerbeek wrote: > On Mon, Sep 30, 2024 at 10:50:06PM +0300, Kapetanakis Giannis wrote: > >> How did you solve the problem of initial sync? >> >> Suppose one server goes down for maintenance. When it comes up it does not >> know what new leases have been given by the other server which was all the >> time up. >> >> There are chances that later it gives an IP already given by the other dhcp >> server. The leases (while down) were not synced. >> >> I don't think there is an option for initial sync (like pfsync) and even if >> you scp the lease file you can't be 100% sure since you might miss something >> while copying and starting service. >> >> This is the primary reason I've sticked with isc-dhcpd and failover peer. >> >> G >> > IIRC on dhcpd statup all leases from the lease db are advertized to > the other dhcpds. > > -Otto Didn't know about this but I don't think it solves the problem. The starting server is behind and missing entries from the lease file. Does the starting server also request a full lease advertisement from the other server? What happens with the other server (which is NOT restarting) and how will it notify the starting server that there are new leases (without a restart)? Unless a server startup triggers full advertizement on all sides. G
Re: dhcpd with failover
How did you solve the problem of initial sync? Suppose one server goes down for maintenance. When it comes up it does not know what new leases have been given by the other server which was all the time up. There are chances that later it gives an IP already given by the other dhcp server. The leases (while down) were not synced. I don't think there is an option for initial sync (like pfsync) and even if you scp the lease file you can't be 100% sure since you might miss something while copying and starting service. This is the primary reason I've sticked with isc-dhcpd and failover peer. G
Re: default route for a subset of addresses
On 17/07/2024 23:50, Sonic wrote: > On Wed, Jul 17, 2024 at 11:55 AM Sonic wrote: >> The wg interface using an rdomain: > Got it to work, although it seems a bit convoluted. > The wg interface config: > == > rdomain 4 > inet 10.2.0.2/32 > wgkey > wgpeer wgaip 0.0.0.0/0 wgendpoint 51868 > !route -T4 -n add default 10.2.0.2 > wgrtable 0 > == > I started to realize that that wg interface had no clue how to get > back to the hosts on the vlan. Attempting to add routes did not work > so I added the "wgrtable 0" to the interface as that rtable knew the > routes. > > Thanks! > Chris makes sense. You communicate with peer on rdomain 0 and not rdomain 4. tunneled traffic goes on rdomain 4 G
pf tables questions
Hi, I have a couple of questions about pf tables. 1) Does it use radix tree and especially Patricia tree? Trying to read the code and searches on web pointed to that. 2) I've found this tool yesterday (iprange) that it's job is to optimize large sets of IPs/Networks https://github.com/firehol/iprange/wiki tldr; Given a large set of IPs/Networks/ranges, it aggregates prefixes to fewer and larger prefixes, in order for the kernel to do less lookups. For instance, running it on my attackers input file table which has ranges from /10 to /32 (21 different CIDR prefixes - 288 distinct CIDRs), proposes a reduction to 3 CIDR prefixes of /16, /24, /32 (3489 distinct CIDRs). Much more entries but only 3 different prefixes instead of 21. This is supposed to work for ipset and Linux which uses hash:net Could this principle of balancing the tree - but with increased number of nodes, be also beneficial for large pf tables? Thanks, G
Re: Missing vlan interfaces in OPENBSD-PF-MIB::pfIfTable
On 11/06/2024 15:34, Martijn van Duren wrote: > On Tue, 2024-06-11 at 14:56 +0300, Kapetanakis Giannis wrote: >> On 10/06/2024 18:43, Marc Boisis wrote: >>> Hello, >>> >>> I've a 7.5 openBSD router, when I'm asking OPENBSD-PF-MIB I have only 64 >>> physicals and carp interfaces but not my 45 vlan interfaces. >>> >>> My /etc/snmpd.conf >>> ROOT:amdrg2:/root > cat /etc/snmpd.conf >>> listen on 127.0.0.1 snmpv2c >>> read-only community public >>> >>> >>> "pfctl -sI" list all interfaces (carp and vlan). >>> >>> Is there a setting or a limit to configure to see vlan interfaces in >>> OPENBSD-PF-MIB and especialy in OPENBSD-PF-MIB::pfIfTable ? >>> >>> Ps: In openbsd 6.5, OPENBSD-PF-MIB::pfIfTable contain all interfaces >>> >>> Regards >>> >>> Marc >>> >> Indeed. >> >> snmpwalk -v2c -c xx localhost OPENBSD-PF-MIB::pfIfDescr | wc -l >> 64 >> >> pfctl -sI | wc -l >> 99 (groups included) >> >> ifconfig | grep flags | wc -l >> 85 >> >> that is on 7.5 release. >> >> snmpwalk is showing only "vlan" and not the vlan interfaces. That is >> probably the group vlan. >> >> There is also an empty one at the end. >> >> OPENBSD-PF-MIB::pfIfDescr.63 = STRING: vlan >> OPENBSD-PF-MIB::pfIfDescr.64 = STRING: >> >> G > $ snmp walk -v2c -cpublic 127.0.0.1 pfIfDescr | wc -l > 15 > $ doas pfctl -sI | wc -l > 15 > > pfIfDescr.13 = STRING: vlan > pfIfDescr.14 = STRING: vlan6 > > > I'm not seeing it. I'm willing to dig into this, but without giving me a > way to reproduce saying "me too" isn't going to help. > > martijn@ > How about creating more than 64 interfaces? G
Re: Missing vlan interfaces in OPENBSD-PF-MIB::pfIfTable
On 10/06/2024 18:43, Marc Boisis wrote: > Hello, > > I've a 7.5 openBSD router, when I'm asking OPENBSD-PF-MIB I have only 64 > physicals and carp interfaces but not my 45 vlan interfaces. > > My /etc/snmpd.conf > ROOT:amdrg2:/root > cat /etc/snmpd.conf > listen on 127.0.0.1 snmpv2c > read-only community public > > > "pfctl -sI" list all interfaces (carp and vlan). > > Is there a setting or a limit to configure to see vlan interfaces in > OPENBSD-PF-MIB and especialy in OPENBSD-PF-MIB::pfIfTable ? > > Ps: In openbsd 6.5, OPENBSD-PF-MIB::pfIfTable contain all interfaces > > Regards > > Marc Indeed. snmpwalk -v2c -c xx localhost OPENBSD-PF-MIB::pfIfDescr | wc -l 64 pfctl -sI | wc -l 99 (groups included) ifconfig | grep flags | wc -l 85 that is on 7.5 release. snmpwalk is showing only "vlan" and not the vlan interfaces. That is probably the group vlan. There is also an empty one at the end. OPENBSD-PF-MIB::pfIfDescr.63 = STRING: vlan OPENBSD-PF-MIB::pfIfDescr.64 = STRING: G
Re: IPv6 routing problems with vether and vmm
On 04/06/2024 11:59, Stuart Henderson wrote: > On 2024-06-04, Kapetanakis Giannis wrote: >> On 04/06/2024 08:50, jrmu wrote: >>>> When you manage a hypervisor, using only 1x/64 is less than ideal. It's >>>> just >>>> not enough because you can have more than 1 'type of usage'. I always >>>> request at least 1x/56. >>> Thanks. I spoke with the ISP and he gave me a larger subnet, >>> >>> 2602:fccf:4::/48, I've been experimenting it by manually adding the >>> route and it seems to have worked. >> >> ::/48 is probably the provider's network, not yours. > Unlikely. If the provider have their own assignment from an RIR it's > probably at least a /32. /48 is common for a single user running > multiple networks, many providers (even just end-user DSL/FTTP ISPs) > give their users a /48 that they can subnet as they wish. Well, our University's whole network is /48, so I thought this is the normal. G
Re: IPv6 routing problems with vether and vmm
On 04/06/2024 08:50, jrmu wrote: >> When you manage a hypervisor, using only 1x/64 is less than ideal. It's just >> not enough because you can have more than 1 'type of usage'. I always >> request at least 1x/56. > Thanks. I spoke with the ISP and he gave me a larger subnet, > > 2602:fccf:4::/48, I've been experimenting it by manually adding the > route and it seems to have worked. ::/48 is probably the provider's network, not yours. G
bgpd group announce property not respected
I'm trying to set announce none property inside a group and it's not
enforced/respected unless it's under neighbor.
conf is:
group "ibgp" {
remote-as $myAS
announce IPv4 none
announce IPv6 none
neighbor 10.0.0.1 {
#announce IPv4 none
#announce IPv6 none
}
neighbor :x:x:::2 {
#announce IPv4 none
#announce IPv6 none
}
}
this gives a bgpd -n -v
group "ibgp" {
neighbor 10.0.0.1 {
remote-as 65001
enforce neighbor-as no
enforce local-as yes
announce IPv4 unicast
}
neighbor :x:x:::2 {
remote-as 65001
enforce neighbor-as no
enforce local-as yes
announce IPv6 unicast
}
}
If I remove the comments inside neighbors then announce none is respected.
Is this ok?
According to bgpd.conf(5)
"Neighbors placed within a group section inherit the properties common
to that group"
G
custom syspatch
Suppose I want to add a custom patch to a release system (backport patch from
current and compile on release),
but keep the system able to load more official syspatches:
is it enough to put the relevant new object file (say pf.o) in
/usr/share/relink/kernel/GENERIC.MP/
and just do reorder_kernel?
The new object will come from manually compiling release sources kernel with
specific patch backported from current (on another machine).
I took for example syspatch74-009_pf.tgz
Apart from the pf.o I also see vers.o and gap.o
Should I also provide a new gap.o? I don't understand what this does.
In Makefile I see
newbsd:
${MAKE_GAP}
${SYSTEM_LD_HEAD}
${SYSTEM_LD} swapgeneric.o
${SYSTEM_LD_TAIL}
rm -f bsd.gdb
mv -f newbsd bsd
so makegap.sh is run from ${MAKE_GAP} which seems to provide a new gap.o
Thanks,
G
Re: Q: Problems forwarding traffic using pf ...
On 23/05/2024 20:18, Peter N. M. Hansteen wrote: On Thu, May 23, 2024 at 11:14:20AM +0200, Why 42? The lists account. wrote: I need to quickly create a solution for forwarding multicast traffic between two systems, so I though perhaps I could use pf to do just that by writing some rules along the lines of: 1. pass in on iface A proto UDP ... tag mcast 2. pass out on iface B tagged mcast And another pair of rules for the reverse direction B -> A. (Obviously I'd add more options to filter specific addresses, etc.) Possibly stupid question, but did you set the sysctl(s) to enable forwarding? $ sysctl net.inet.ip.forwarding and $ sysctl net.inet6.ip6.forwarding will provide the answer (as in, if those values are not 1, forwarding between interfaces is not enabled) And there is also mforwarding net.inet.ip.forwarding net.inet.ip.mforwarding net.inet6.ip6.forwarding net.inet6.ip6.mforwarding G
Re: pf anchors attached to irrelevant states
On 19/05/2024 19:35, Kapetanakis Giannis wrote: > On 19/05/2024 14:37, Stuart Henderson wrote: >> On 2024-05-19, Kapetanakis Giannis wrote: >>> This is a bit strange. pf works normal, but rules after an enchor an >>> being attached to the anchor (somehow). >>> >>> All states that are created from rules after the anchor, show the anchor >>> (pf rule) number instead of (only) the rule number in pfctl -vv and in >>> pflog. >> I can confirm this is a problem, definitely seen in 7.4, I can't remember >> if 7.3 was affected. 7.2 from Dec 22 seems ok. > > 7.3 release was also affected, just tested on a vm. > > G It seems that this was introduced with 1.1169 of pf.c (2023/01/05) https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.1168&r2=1.1169&sortby=date&f=h reverting to 1.1168 shows then rules numbers correct both in pflog and pfctl. Rest of kernel is on 2023-01-12 G
Re: kernel rebuild to debug problem
On 20/05/2024 00:03, Kirill A. Korinsky wrote: > On Sun, 19 May 2024 20:52:56 +0100, > Kapetanakis Giannis wrote: >> I'm trying to bisect a bug and compile an older kernel from cvs >> >> cvs checkout -D "2023-01-05" src/sys >> >> and following https://www.openbsd.org/faq/faq5.html#Options >> + make install >> >> New kernel compiles and boots but I get: >> >> # pfctl -f /etc/pf.conf >> pfctl: DIOCADDRULE: Operation not supported by device >> >> # pfctl -sr >> pfctl: Permission denied >> >> # pfctl -si | head -1 >> Status: Enabled for 0 days 00:05:03 Debug: err >> >> any ideas about this? >> > You need to build / use no only old kernel but the whole system. > > The simplest way is to use archived version of snapshots from > https://openbsd.cs.toronto.edu/archive/ or another mirror. Thanks for the reply. I did also build pfctl. Unfortunately the date I'm looking for is older than the archives on toronto or hostserver.de Anyway I'll try a build the whole system. Any hints of what specific is needed would be nice, since building the whole system every time until I find the commit I'm looking for would be a pain. G
kernel rebuild to debug problem
I'm trying to bisect a bug and compile an older kernel from cvs cvs checkout -D "2023-01-05" src/sys and following https://www.openbsd.org/faq/faq5.html#Options + make install New kernel compiles and boots but I get: # pfctl -f /etc/pf.conf pfctl: DIOCADDRULE: Operation not supported by device # pfctl -sr pfctl: Permission denied # pfctl -si | head -1 Status: Enabled for 0 days 00:05:03 Debug: err any ideas about this? G
Re: pf anchors attached to irrelevant states
On 19/05/2024 14:37, Stuart Henderson wrote: On 2024-05-19, Kapetanakis Giannis wrote: This is a bit strange. pf works normal, but rules after an enchor an being attached to the anchor (somehow). All states that are created from rules after the anchor, show the anchor (pf rule) number instead of (only) the rule number in pfctl -vv and in pflog. I can confirm this is a problem, definitely seen in 7.4, I can't remember if 7.3 was affected. 7.2 from Dec 22 seems ok. 7.3 release was also affected, just tested on a vm. G
pf anchors attached to irrelevant states
This is a bit strange. pf works normal, but rules after an enchor an
being attached to the anchor (somehow).
All states that are created from rules after the anchor, show the anchor
(pf rule) number instead of (only) the rule number in pfctl -vv and in
pflog.
Here is a quite simple example.
# pfctl -sr -a'*' -vv | egrep -v "Evaluations|Inserted" | head -6
@0 match in all scrub (no-df random-id)
@1 pass in quick on vio0 from to any flags S/SA set (prio 6) keep
state (if-bound, pflow) tag from_external
@2 anchor "test" quick all {
@0 pass out log quick on egress inet proto tcp from any to any port = 2000
flags S/SA keep state (if-bound) rdr-to 127.0.0.1
}
@3 pass out log quick inet proto tcp from any to yy.yy.yy.yy port = 22 flags
S/SA keep state (if-bound, pflow)
Test traffic for anchor rule works fine (xx.xx.xx.xx is my external ip)
# telnet 8.8.8.8 2000
pflog: May 19 13:54:03.427024 rule 2.test.0/(match) pass out on vio0: xx.xx.xx.36179
> 8.8.8.8.2000: S 4080176752:4080176752(0) win 16384 (DF) [tos 0x10]
# pfctl -ss -vv | grep -A3 8.8.8.8
vio0 tcp xx.xx.xx.xx:36179 -> 127.0.0.1:2000 (8.8.8.8:2000)
SYN_SENT:CLOSED
[4080176752 + 2] [0 + 1]
age 00:00:01, expires in 00:01:59, 1:0 pkts, 64:0 bytes, anchor 2, rule 0
<<<--- this rule 0 of anchor which is correct
id: 661391580039aaa3 creatorid: bfd893f9
See what happens if I try to triger rule @3 and ssh to yy.yy.yy.yy
pflog: May 19 13:55:42.386186 rule 2/(match) pass out on vio0: xx.xx.xx.xx.23564 >
yy.yy.yy.yy.22: S 3631867116:3631867116(0) win 16384 (DF) [tos 0x48]
pfctl -ss -vv|grep -A3 yy.yy.yy.yy
vio0 tcp xx.xx.xx.xx:23564 -> yy.yy.yy.yy:22 ESTABLISHED:ESTABLISHED
[3631869502 + 37760] wscale 6 [3744464382 + 16384] wscale 7
age 00:01:10, expires in 23:58:54, 16:19 pkts, 3229:3857 bytes, anchor 2,
rule 3, pflow
id: 661391580039ab07 creatorid: bfd893f9
pflog, logs "rule 2" which is the anchor instead of "rule 3"
pfctl, shows "anchor 2, rule 3" instead of just "rule 3"
Traffic works normally but there is something fishy here.
quick on anchor does not make any difference, although to my understanding it
shouldn't matter either set or not set in this case.
G
match rules and relayd rdr
Hi, I want to convert a pf rule to rdr-to via relayd (add load balancer in the mix to multiple servers). My hesitation is how to pass the extra tcp options I pass in the rule. I believe this should be done via match rules, but I'm not sure if the pass rule should be on the pf or the relayd side. The rule looks like this: pass in quick on egress proto tcp from any to $server port = 80 flags S/SA set (prio(1, 2)) keep state (pflow, tcp.first 10, tcp.opening 10, tcp.established 18000, tcp.closing 30, tcp.finwait 30, tcp.closed 30) tag from_ext Should I change the pf pass rule to match (with no quick) and add the relayd anchor after that (with pass in relayd, default) or the other way around: relayd anchor first, match in relayd and then pass in quick on the pf side. I want to keep both the prio and tcp options as well as the rdr-to inserted from relayd. Is it essentially the same either way? Thanks, G
Re: RELAY_MAXHOSTS for relayd
On 26/04/2024 20:48, Tobias Fiebig wrote: Moin, I am currently playing around with some relayd things, and noticed that relayd has a #define for RELAY_MAXHOSTS 32 (defined in 2007); Currently planning to give 64 a shot. Does somebody recall why this value was chosen? (Kind of trying to not shoot myself in the foot there, if it is preventable. ;-)) With best regards, Tobias I'm near that limit and interested to see what you come up with. G
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 17/04/2024 17:37, Federico Giannici wrote: > On 4/17/24 15:19, Stuart Henderson wrote: >> This is most likely because of: >> >> https://www.openbsd.org/74.html >> "Disabled TLSv1.0 and TLSv1.1 in libssl so that they may no longer be >> selected for use." >> >> I don't think there's anything simple you can do to reenable it. > > They are "disabled" or completely "removed" from the source/compilation? > > Thanks. https://github.com/libressl/openbsd/commit/ddcb4efd6551a982bf29b2e8e83c9c808a1670dc G
Re: Since upgrade to OpenBSD 7.5 the FreeRADIUS EAP authentication no longer works
On 17/04/2024 16:19, Stuart Henderson wrote: > On 2024-04-17, Federico Giannici wrote: >> Since we upgraded from OpenBSD amd64 7.3 to 7.5 (passing through 7.4) >> the FreeRadius EAP authentication no longer works! >> >> We are using a custom version of FreeRadius (because we had to do some >> little changes and a module of our own), and everything worked correctly >> for many years. >> >> Now, with 7.5, it gives the following errors for EAP authentications >> (everything else is OK): >> >> Apr 14 11:29:24 Eldarion radiusd[73262]: TLS Alert write:fatal:protocol >> version >> Apr 14 11:29:24 Eldarion radiusd[73262]: TLS_accept: error in SSLv3 >> read client hello B >> Apr 14 11:29:24 Eldarion radiusd[73262]: rlm_eap: SSL error >> error:1402610B:SSL routines:ACCEPT_SR_CLNT_HELLO:wrong version number >> Apr 14 11:29:24 Eldarion radiusd[73262]: SSL: SSL_read failed in a >> system call (-1), TLS session fails. >> Apr 14 11:29:24 Eldarion radiusd[73262]: Login incorrect (TLS Alert >> write:fatal:protocol version): [anonym...@myisp.com/> EAP>] (from client wdsl_neomedia nas 10.10.215.101 port 0 cli >> FC-EC-DA-2A-F5-7F service wdsl-neomedia) >> >> I guess that the new LibreSSL version have some new restricted >> requirements. And we CANNOT change the client's OpenSSL version or certs >> (they are Ubiquiti devices). >> >> Some time ago (I think upgrading to 7.3) we had to add >> "SSL_CTX_set_security_level( ctx, 0 );" to make it work. So we already >> have set Security Level to 0. >> >> Is there something else we can do to make LibreSSL accept everything it >> accepted in previous release? > This is most likely because of: > > https://www.openbsd.org/74.html > "Disabled TLSv1.0 and TLSv1.1 in libssl so that they may no longer be > selected for use." > > I don't think there's anything simple you can do to reenable it. One idea if you have old devices that cannot upgrade to a newer SSL/TLS protocol would be to run some kind of proxy between the client and the radius server (stunnel?) Don't know how well this plays with EAP. Maybe this will only work with EAP-TTLS ? Another idea, since you run your own custom freeradius, is to recompile it and link with another openssl library that has old SSL/TLS enabled. G
Re: Dell PERC H745
On 28/03/2024 20:17, Stuart Henderson wrote: > On 2024-03-28, Hrvoje Popovski wrote: >> On 28.3.2024. 11:01, Kapetanakis Giannis wrote: >>> I'm looking for a new server to replace our firewall/routing. >>> >>> Would like to ask if PERC H745 is supported. >>> >>> mfi(4) lists >>> - Dell PERC 5/e, PERC 5/i, PERC 6/e, PERC 6/i, PERC H310, PERC >>> H700, PERC H800 >>> >>> Is this ok? >>> >>> Trying bsd.rd on a newer server with H755, it was NOT detected. >>> On Linux it is shown as >>> 65:00.0 RAID bus controller: Broadcom / LSI MegaRAID 12GSAS/PCIe Secure >>> SAS39xx >>> DeviceName: SL3 RAID >>> Subsystem: Dell PERC H755 Front >>> >>> That is on 7.4, didn't try current. >>> >>> However the BOSS-S1 adapter with 2 x M.2 sticks was detected >>> >>> How about HBA330 Mini and/or PERC H730P Mini ? >>> >>> About CPUs, I'm between Intel Xeon Gold 5315Y @ 3.20GHz vs AMD EPYC 72F3 >>> Both are 8 cores, I will put 2 x cpus. Haven't tried EPYC at all but looks >>> more performant. >>> >>> G >>> >> Hi, >> >> don't go with BOSS adapter or HBA330. I have both adapters in lab and >> they just don't work. >> I have working OpenBSD on PERC H740p, PERC H740P Mini, PERC H330 mini, >> PERC H310 Mini. I can't remember but I think that H730p should work. > also working: PERC H710 Mini, PERC H755 Front (both mfii) Thanks Hrvoje and Stuart all for the valuable info. There are so many adapters given/updated by Dell every year, maybe we should update the man pages to add the working ones? My BOSS-S1 Modular adapter is detected both on 7.4 and current. PERC H755 Front is indeed also detected with current. I'm sure it was not with 7.4 when I tried yesterday. This is today dmesg with current (20 Mar) from R650xs: OpenBSD 7.5 (RAMDISK_CD) #76: Wed Mar 20 15:53:54 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 136804360192 (130466MB) avail mem = 132653326336 (126508MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x69534000 (65 entries) bios0: vendor Dell Inc. version "1.12.1" date 09/13/2023 bios0: Dell Inc. PowerEdge R650xs acpi0 at bios0: ACPI 6.2 ahci2 at pci1 dev 0 function 0 "Marvell 88SE9230 AHCI" rev 0x11: msi, AHCI 1.2 ahci2: port 0: 6.0Gb/s ahci2: port 2: 1.5Gb/s scsibus2 at ahci2: 32 targets ahci2: stopping the port, softreset slot 31 was still active. ahci2: failed to stop port, cannot softreset ahci2: failed to stop port, cannot softreset ahci2: failed to stop port, cannot softreset sd0 at scsibus2 targ 0 lun 0: t10.ATA_DELLBOSS_VD_c2d0e37927240010_ sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin ahci2: stopping the port, softreset slot 31 was still active. ahci2: failed to stop port, cannot softreset mfii0 at pci10 dev 0 function 0 "Symbios Logic MegaRAID SAS39XX" rev 0x00: msi mfii0: "PERC H755 Front", firmware 52.26.0-5179, 8192MB cache scsibus3 at mfii0: 240 targets sd1 at scsibus3 targ 239 lun 0: naa.6f4ee0806477b5002d04b844d6503c0e sd1: 2288640MB, 512 bytes/sector, 4687134720 sectors scsibus4 at mfii0: 256 targets sd0> p OpenBSD area: 0-937571968; size: 937571968; free: 3712 #size offset fstype [fsize bsize cpg] c:9375719680 unused i: 2097152 2048 ext2fs j:935471104 2099200 unknown sd0> l # /dev/rsd0c: type: SCSI disk: SCSI disk label: DELLBOSS VD duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 58361 total sectors: 937571968 boundstart: 0 boundend: 937571968 sd1> p OpenBSD area: 64-4294961685; size: 4294961621; free: 4294961621 #size offset fstype [fsize bsize cpg] c: 46871347200 unused sd1> l # /dev/rsd1c: type: SCSI disk: SCSI disk label: PERC H755 Front duid: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 291760 total sectors: 4687134720 boundstart: 64 boundend: 4294961685 G
Dell PERC H745
I'm looking for a new server to replace our firewall/routing. Would like to ask if PERC H745 is supported. mfi(4) lists - Dell PERC 5/e, PERC 5/i, PERC 6/e, PERC 6/i, PERC H310, PERC H700, PERC H800 Is this ok? Trying bsd.rd on a newer server with H755, it was NOT detected. On Linux it is shown as 65:00.0 RAID bus controller: Broadcom / LSI MegaRAID 12GSAS/PCIe Secure SAS39xx DeviceName: SL3 RAID Subsystem: Dell PERC H755 Front That is on 7.4, didn't try current. However the BOSS-S1 adapter with 2 x M.2 sticks was detected How about HBA330 Mini and/or PERC H730P Mini ? About CPUs, I'm between Intel Xeon Gold 5315Y @ 3.20GHz vs AMD EPYC 72F3 Both are 8 cores, I will put 2 x cpus. Haven't tried EPYC at all but looks more performant. G
Re: Need advice on “tcp proxy”
On 02/03/2024 12:46, Kasak wrote: Hello misc! There is a good manual on OpenBSD faq about redirection and reflection, here it is: https://www.openbsd.org/faq/pf/rdr.html#tcpproxy I’m using nginx as tcp and udp proxy, but maybe there is another software, more suitable for this task? I need to redirect and reflect near 15 tcp ports and couple of udp. I know I can do this with only pf, but I switched to nginx intentionally, because this amount of ports made my pf config hard readable. Thank you in advance! You probably need relayd G
HUNSN routers - N100 I226-V
Has anyone tried these HUNSN mini pcs/routers with multiple interfaces? I'm thinking of getting one for home routing. Does it work with OpenBSD? (dmesg?) Performance? Will it route/firewall at 1Gbps? Intel N100 seems to be low on TDP and gives numbers. Any problems with I226? I've read about issues with I225 in the past. Thanks, Giannis
gre over carp
I was wondering if anyone runs gre tunnels over carp. We have an OpenBSD router that does ipsec over gre tunnels with remote location routers in order to pass voip traffic. Routing is done with ospf on top of gre. I'd like to add sasyncd in the mix and a 2nd router for higher availability. Will gre over carp work? I'd prefer to use the carped IP in the tunnel and not the real IP of each server, so eventually 1 tunnel (active) per remote router. How will this work when I demote master and go via backup? Thanks, G
relayd checks and uses disabled hosts
Hi,
I have a strange behavior on my relayd servers. Relayd continues checking
disabled hosts. I see it on backend server's logs.
If relayd detects a down -> up of the service it re-adds the hosts in the table
and passes traffic to the disabled hosts.
Status remains disabled.
Setup is with redirects.
table { ldap1 retry 2, ldap2 retry 2 }
redirect ldap {
listen on $ldap_addr port ldaps
pftag RELAYD_ldap
forward to port 1636 mode least-states check icmp check script
"/usr/local/sbin/check_ldap_c" demote 0relay timeout 2000
session timeout 432600
}
On load balancer hosts I see:
pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP
ldap2_IP
If I do
relayctl host dis ldap2
I see in logs
Dec 1 13:11:24 relayd[59724]: table ldap: 0 added, 1 deleted, 0 changed, 0
killed
# relayctl show sum|grep ldap
1 redirect ldap active
1 table ldap:1636 active (1 hosts)
1 host ldap1 100.00% up
2 host ldap2 disabled
# pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP (only)
So far, so good. However...
However, when I actually close the service on server ldap2 I see:
Dec 1 13:12:27 relayd[42873]: host ldap2, check script (766ms,script failed),
state up -> down, availability 98.29%
Dec 1 13:12:27 relayd[71859]: table ldap: 0 added, 0 deleted, 0 changed, 0
killed
Now, when I restart the server or the service on ldap2:
Dec 1 13:17:08 relayd[42873]: host ldap2, check script (987ms,script ok),
state down -> up, availability 98.28%
Dec 1 13:17:12 relayd[71859]: table ldap: 1 added, 0 deleted, 0 changed, 0
killed
# relayctl show sum|grep ldap2
2 host ldap2 disabled
Hosts is shown as disabled, but it's added the table.
# pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP
ldap2_IP
again:
# relayctl host dis ldap2
command succeeded.
# pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP
ldap2_IP
During this whole time while ldap2 is disabled I keep seeing in ldap2's logs
connects from the load balancer although it's disabled. Logs from the check
script.
When the check sees the service down->up, it re-enables the host although in
summary it's still stated as disabled.
Clients are also coming now apart from the check script.
If I re-enable the disabled host:
# relayctl host en ldap2
command succeeded
Dec 1 13:24:35 relayd[99810]: host ldap2, check script (796ms,script ok),
state unknown -> up, availability 100.00%
Dec 1 13:24:39 relayd[59724]: table ldap: 0 added, 0 deleted, 0 changed, 0
killed
I checked web csv but can't see any related change on relayd...
On August and 7.3 this didn't happen.
Giannis
Re: relayd checks and uses disabled hosts
On 01/12/2023 13:30, Kapetanakis Giannis wrote: > I checked web csv but can't see any related change on relayd... > > On August and 7.3 this didn't happen. Not relevant. I'm not on current, I run release. G
7.4 panic ip_output no HDR
Hi,
This is the 2nd panic I get on this machine after 7.4, both the same,
ip_output() from pflow_output_process()
ddb{0}> show panic
*cpu0: ip_output no HDR
ddb{0}> trace
db_enter() at db_enter+0x14
panic(820bea35) at panic+0xc3
ip_output(fd80b320ad00,0,fd8120670c48,0,0,fd8120670bd0,5718952b04ba
576d) at ip_output+0xa26
udp_output(fd8120670bd0,fd80b320ad00,fd80bd64a600,0) at udp_output+
0x3be
sosend(fd8120671720,fd80bd64a600,0,fd80b320ad00,0,0) at sosend+0x37
f
pflow_output_process(80875000) at pflow_output_process+0x67
taskq_thread(8002e380) at taskq_thread+0x100
end trace frame: 0x0, count: -7
I couldn't continue the debug because "machine ddbcpu 1" completely hanged the
machine.
It's strange because it's a backup router (bgpd/ospfd) and didn't have any
traffic at that moment.
Nothing on the logs at the time of panic.
On the last panic I managed to do a ps and got the * at softnet proc 3 if I
remember correct.
# ifconfig pflow
pflow0: flags=41 mtu 1448
index 11 priority 0 llprio 3
pflow: sender: xx.xx.xx.xx receiver: yy.yy.yy.yy: version: 10
groups: pflow
OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023
r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4234805248 (4038MB)
avail mem = 4086726656 (3897MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xbf6c8000 (92 entries)
bios0: vendor FUJITSU // Phoenix Technologies Ltd. version "6.00 Rev.
1.06.3031" date 12/14/2010
bios0: FUJITSU PRIMERGY RX200 S6
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP TCPA SLIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
SSDT SSDT SSDT EINJ HEST BERT SSDT ERST SPCR MCFG HPET APIC BOOT
acpi0: wakeup devices PE0_(S4) PE1_(S4) PE3_(S4) PE7_(S4) PE9_(S4) PE1A(S4)
USB1(S1) USB2(S1) USB3(S1) USB4(S1) USB5(S1) USB6(S1) USB7(S1) USB8(S1) COM1(S1)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-6
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 32 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.13 MHz, 06-2c-02, patch
001f
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 1
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 34 (application processor)
cpu1: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.14 MHz, 06-2c-02, patch
001f
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 1
cpu2 at mainbus0: apid 36 (application processor)
cpu2: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.18 MHz, 06-2c-02, patch
001f
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 1
cpu3 at mainbus0: apid 48 (application processor)
cpu3: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.22 MHz, 06-2c-02, patch
001f
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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 4-way I-cache, 256KB 64b/line
8-way L2 cache, 12MB 64b/line 16-way L3 cache
cpu3: smt 0, core 8, package 1
cpu4 at mainbus0: apid 50 (application processor)
cpu4: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.19 MHz, 06-2c-02, patch
001f
cpu4:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX
Re: AAAA entry for openbsd.org
If you're looking for a mirror to install/update ftp.cc.uoc.gr runs on both IPv4/IPv6 and is listed in official mirrors. http://ftp.cc.uoc.gr/mirrors/OpenBSD/ G On 23/10/2023 08:58, Armin Jenewein wrote: > No idea what you perceive here as a "rant", my apologies if that seemed > like one to you, that's not my intention. > > FWIW both ftplist1.openbsd.org and ftplist2.openbsd.org have no > entry, either. > > I don't see what I need to prove here. That's 3 hosts already that don't > have an DNS record, so if you're on an IPv6-only link, you can't > access these. I didn't check ALL the mirrors that the installer has in > the list, but the one popping up in my list as ftp.spline.de doesn't > have one, either, so that's just number four. > > With prices for IPv4 addresses are starting to increase, it surprises me > that this is still such a heated topic. Nobody asks about removing > IPv4-connectivity here. Nobody wants to break functionaly for v4-only > users. > > I did try installing OpenBSD in v6-only networks, yes. On an IPv6-only > host it doesn't even suggest a mirror to download from. > > My initial mail was about this one here, nevertheless: > > $ ping6 openbsd.org > ping6: no address associated with name > $ > > The fact that all the other hosts I mentioned are v4-only doesn't change > that situation in any way. > > ~ Armin > > > > > On 23-10-22 19:29:28, Philip Guenther wrote: >> On Sun, Oct 22, 2023 at 6:53 PM Armin Jenewein wrote: >> >>> Hi. >>> >>> On 23-10-22 15:47:45, Kastus Shchuka wrote: On Sun, Oct 22, 2023 at 10:29:08PM +0200, Armin Jenewein wrote: > Hi, > > as I'm almost 100% sure adding IPv6 connectivity to the openbsd.org > host > wouldn't introduce side-effects for IPv4 users: is there any reason > openbsd.org still has no entry at the end of 2023? Why do you need it? >>> Because it's extremely inconvenient to have manually type in the name of >>> a mirror that I know has an entry. The installer won't even be able >>> to download the mirror list because of the reason I mentioned. It tries >>> to talk to openbsd.org which obviously fails. >> >> See, this is why being clear about What Fine Problem You're Trying To Solve >> is important: AFAICT the installer tries to fetch the mirror list from >> ftplist1.openbsd.org and not from openbsd.org. >> >> Can you confirm that your _actual_ request is to have the installer be able >> to get the mirror list when on an IPv6-only host? >> >> (Please don't rant at people who try to help, particularly when doing >> exactly what you requested would NOT HAVE HELPED, unless you *want* people >> to drop you in their kill-file as "not worth trying to help".) >> >> >> Philip Guenther
Re: relayd ssl termination advice
On 08/10/2023 04:00, Courtney wrote: > Ultimately, I want to serve a handful of services on 80/443 that are > easily accessible internally and externally, and I don't want to have > unencrypted traffic between relayd and my server for the services that > are passing sessions and such. Then don't terminate the connection on relayd. Use redirect instead of a relay and terminate on the web server itself. It will also be a little faster since the router/relayd will only route/pass the packets to the appropriate backend server. For internal traffic you have to use appropriate DNS (local IP) and maybe a different certificate. G
Re: PF rate limiting options valid for UDP?
On 19/07/2023 13:31, Stuart Henderson wrote: > On 2023-07-19, Kapetanakis Giannis wrote: >> Maybe even better, can it run under relayd (redirect) on top of carp? > That's just rdr-to behind the scenes, no problem with that, though if > you want to do per IP rate limiting alongside load-balancing you might > want "mode source-hash" rather than the default round-robin or one of > the random options. > > (I wouldn't recommend sticky-address, because then you get into more > complex paths inside PF because it has to maintain source-tracking > information). I don't think source tracking is that important in this case scenario. relayd will only have one host, which will be the dnsdist listening on localhost (on each load balancer). dnsdist will have whatever it can support with stickiness/source-tracking. pf rdr-to could also be an option, but then you loose the carp demotion which relayd provides. thanks G
Re: PF rate limiting options valid for UDP?
On 18/07/2023 23:59, Stuart Henderson wrote: > PF's state-tracking options are only for TCP. (Blocking an IP > based on number of connections from easily spoofed UDP is a good > way to let third parties prevent your machine from communicating > with IPs that may well get in the way i.e. trigger a "self DoS"). > > You may be interested in looking into L7 methods of mitigating > problems from high rates of DNS queries - for example dnsdist > allows a lot of flexibility in this area. dnsdist looks interesting. Can it run on top of carp interfaces? Maybe even better, can it run under relayd (redirect) on top of carp? G
Re: Block network access completely for certain programs
On 04/07/2023 16:08, r...@danwin1210.de wrote: How do I block the network access completely for a certain program with a blacklist or whitelist, whitelist prefered, with OpenBSD's pf(4)? My pdf reader, music player, video player, vim and much more shouldnt have access to networking at all. I remember it being possible with the Windows firewall program to choose a certain program to be completely networking-less. Is this possible with OpenBSD too? I couldnt find anything in the man pages or in the FAQ regarding this issue. pf.conf(5) has option for user user user This rule only applies to packets of sockets owned by the specified user. For outgoing connections initiated from the firewall, this is the user that opened the connection. For incoming connections to the firewall itself, this is the user that listens on the destination port. ... G
Dell R350 PERC H355
Hi, I'm trying to install current on a Dell R350 with PERC H355 and does not detect the virtual disk (raid 1). Is it not supported yet? OpenBSD 7.3-current (RAMDISK_CD) #1203: Sun Jul 2 12:26:19 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 8278466560 (7894MB) avail mem = 8023552000 (7651MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7b3b9000 (46 entries) bios0: vendor Dell Inc. version "1.6.3" date 02/22/2023 bios0: Dell Inc. PowerEdge R350 acpi0 at bios0: ACPI 6.1 acpi0: tables DSDT FACP SSDT SSDT WD__ HPET APIC MCFG SSDT SSDT LPIT WSMT SSDT D BGP DBG2 SSDT TPM2 SSDT SPCR SSDT HEST BERT ERST EINJ PTDT DMAR FPDT acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) E-2356G CPU @ 3.20GHz, 3195.20 MHz, 06-a7-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX ,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPC NT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PE RF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,AVX512F,AVX 512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AV X512VBMI,UMIP,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOP T,XSAVEC,XGETBV1,XSAVES cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 12MB 64b/line 16-way L3 cache cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.1.2.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PC00) acpiprt1 at acpi0: bus -1 (PEG1) acpiprt2 at acpi0: bus -1 (PEG2) acpiprt3 at acpi0: bus 4 (RP01) acpiprt4 at acpi0: bus 6 (RP02) acpiprt5 at acpi0: bus -1 (RP03) acpiprt6 at acpi0: bus -1 (RP04) acpiprt7 at acpi0: bus -1 (RP05) acpiprt8 at acpi0: bus -1 (RP06) acpiprt9 at acpi0: bus -1 (RP07) acpiprt10 at acpi0: bus -1 (RP08) acpiprt11 at acpi0: bus -1 (RP09) acpiprt12 at acpi0: bus -1 (RP10) acpiprt13 at acpi0: bus -1 (RP11) acpiprt14 at acpi0: bus -1 (RP12) acpiprt15 at acpi0: bus -1 (RP13) acpiprt16 at acpi0: bus -1 (RP14) acpiprt17 at acpi0: bus -1 (RP15) acpiprt18 at acpi0: bus -1 (RP16) acpiprt19 at acpi0: bus 2 (RP17) acpiprt20 at acpi0: bus -1 (RP18) acpiprt21 at acpi0: bus -1 (RP19) acpiprt22 at acpi0: bus -1 (RP20) acpiprt23 at acpi0: bus -1 (RP21) acpiprt24 at acpi0: bus -1 (RP22) acpiprt25 at acpi0: bus 3 (RP23) acpiprt26 at acpi0: bus -1 (RP24) acpipci0 at acpi0 PC00: 0x 0x0011 0x0001 com1 at acpi0 COMA addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo com0 at acpi0 COMB addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo com0: console "IPI0001" at acpi0 not configured "INT34C6" at acpi0 not configured "PNP0C0E" at acpi0 not configured "ACPI0003" at acpi0 not configured "PNP0C0C" at acpi0 not configured "PNP0C33" at acpi0 not configured "MSFT0101" at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpicpu at acpi0 not configured acpipwrres at acpi0 not configured pci0 at mainbus0 bus 0 0:0:0: io address conflict 0xfffe/0x2 0:0:0: io address conflict 0xfffe/0x2 0:0:0: io address conflict 0xfffe/0x2 0:0:0: io address conflict 0xfffe/0x2 0:0:0: io address conflict 0xfffe/0x2 0:0:0: rom address conflict 0xf800/0x800 0:31:5: mem address conflict 0xfe01/0x1000 pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x4c53 rev 0x01 ppb0 at pci0 dev 6 function 0 vendor "Intel", unknown product 0x4c09 rev 0x01: msi pci1 at ppb0 bus 1 1:0:0: rom address conflict 0xfff0/0x10 vendor "Symbios Logic", unknown product 0x10e6 (class mass storage subclass RAID , rev 0x00) at pci1 dev 0 function 0 not configured xhci0 at pci0 dev 20 function 0 "Intel 500 Series xHCI" rev 0x11: msi, xHCI 1.20 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 500 Series Shared SRAM" rev 0x11 at pci0 dev 20 function 2 not configured "Intel 500 Series HECI" rev 0x11 at pci0 dev 22 function 0 not configured "Intel 500 Series HECI" rev 0x11 at pci0 dev 22 function 4 not configured ahci0 at pci0 dev 23 function 0 "Intel 500 Series AHCI" rev 0x11: msi, AHCI 1.3.1 ahci0: port 4: 1.5Gb/s ahci0: PHY offline on port 5 scsibus0 at ahci0: 32 targets cd0 at scsibus0 targ 4 lun 0: r
Re: pf state-policy floating to if-bound
On 15/06/2023 19:07, Peter Nicolai Mathias Hansteen wrote: >> On 15 Jun 2023, at 16:26, Kapetanakis Giannis >> wrote: >> After applying some keep state (if-bound) on major rules, I 've already >> found a problem. >> >> pfsync. >> >> It copies the interface. The interfaces are different on the backup firewall >> so the states will not match if I demote master. >> >> Anyway to overcome this? Maybe filtering with same group name that is the >> same on both firewalls? > Yes, I was going to suggest creating interface groups and referencing those > in your rules instead of interfaces. > > - P I believe that will only work for rule copying between the firewalls and not state copying with pfsync. State has an interface (or "all" for floating states) and that is copied between pfsync hosts. For example when filtering with egress group, pfsync copies the egress state's interface from primary firewall to backup (different interface names). It would be nice to add some kind of translation/mapping on the pfsync interface, to translate incoming remote states to local interface names. Don't know how difficult that would be. G
Re: pf state-policy floating to if-bound
On 15/06/2023 17:17, Kapetanakis Giannis wrote: > Hello, > > I'd like to make a change to my firewall/router from the default state-policy > floating to if-bound > > I believe the way my pf.conf is configured it will not do any harm but I'm > being cautious here and I'd like some info. > > The way I see it, I have two states for each packet traveling either > direction of the firewall. > One on the incoming interface and one on the outgoing interface for each > packet. > Each state is floating (pfctl -ss gives all) > > I filter always on the incoming interface, apply a tag and pass on the > outgoing interface everything that matches the tag. > One tag for packets coming from internet and a different tag for packets > coming from my internal network to the internet. > > I believe that if all my filtering is like above then changing the default > policy will work without any further changes in pf.conf > > I don't understand why floating is the default. > I mean, even with floating states, each state has a direction in/out, thus > the same state cannot be applied to multiple interfaces (incoming/outgoing) > and a different (floating) state is created on each interface. > > There must be a case I'm missing here. Maybe multipath routing? > > regards, > > Giannis After applying some keep state (if-bound) on major rules, I 've already found a problem. pfsync. It copies the interface. The interfaces are different on the backup firewall so the states will not match if I demote master. Anyway to overcome this? Maybe filtering with same group name that is the same on both firewalls? G
pf state-policy floating to if-bound
Hello, I'd like to make a change to my firewall/router from the default state-policy floating to if-bound I believe the way my pf.conf is configured it will not do any harm but I'm being cautious here and I'd like some info. The way I see it, I have two states for each packet traveling either direction of the firewall. One on the incoming interface and one on the outgoing interface for each packet. Each state is floating (pfctl -ss gives all) I filter always on the incoming interface, apply a tag and pass on the outgoing interface everything that matches the tag. One tag for packets coming from internet and a different tag for packets coming from my internal network to the internet. I believe that if all my filtering is like above then changing the default policy will work without any further changes in pf.conf I don't understand why floating is the default. I mean, even with floating states, each state has a direction in/out, thus the same state cannot be applied to multiple interfaces (incoming/outgoing) and a different (floating) state is created on each interface. There must be a case I'm missing here. Maybe multipath routing? regards, Giannis
Re: relayd filter
On 06/06/2023 16:49, Paul Pace wrote:
> On 6/5/23 3:15 PM, Nick Bouliane wrote:
>> Hi,
>>
>> in relayd.conf I'm trying to do :
>>
>> pass from 192.168.1.1 path "/something.html"
>>
>> If I individually specify the "from" or the "path", it works
>> but when I combine both, it doesn't work.
>
> Nowadays, when I come upon this I just use tags and move on.
>
> Something like this might work:
>
> match path "/something.html" tag something
> pass from 192.168.1.1 tagged something
>
>>
>> Am I missing something or if it's just not possible ?
>> Or is there another way to express this another way ?
>>
>> thank you,
>> Nick
Although this is probably a more elegant solution, relayd also supports
filtering.
I'm doing this in my http protocol {}
pass quick from _admin_ip_address
block quick path "/admin"
block quick path "/admin.html"
block quick path "/admin/"
G
Re: RSS or Atom syndication for security advisories?
I use https://undeadly.org/errata/errata.rss Seems to work for the last 2 years G On 23/05/2023 13:13, Stuart Henderson wrote: > On 2023/05/23 09:35, Xavier wrote: >> I did not say that. I did not see that you in particular, or anyone in this >> mailing list, make this work. >> As a user, I simply suggest creating an RSS channel for security advisories >> and *even* I offer myself to help. >> >> The intention behind was to improve OpenBSD web. Simply. > The number of people who work on errata, for obvious reasons, needs > to be a small set of people that we know+trust. Sometimes (though > fortunately not all that often) that work is very delicate and needs to > be done quickly but carefully. High stress situation already. > > Adding extra steps to the errata process, to merely provide the same > information which is _already provided_ but just not in the format you > prefer (in the case of pages on www.openbsd.org) and not on the website > you prefer (in the case of the rss feed on undeadly.org), can't be of > more than minor benefit to you, and no benefit to most people who > already receive that information via other methods, yet it adds extra > steps (= work) for every erratum that is produced. > >> Perhaps it's me but I perceived some kind or rudeness in some responses. > After being given a workable answer (the rss feed on undeadly), you didn't > like it and asked volunteers to do even more work than they already do, to > mostly benefit you. Which I think some will consider a bit rude itself. > >> Oh! Come on! Why don't we concentrate in teach reasons and not in "I don't >> want to move my position". Do you think this kind of answer would benefit >> the project? > There's no need to concentrate on tech reasons because it's not a technical > problem. >
Re: carp flapping
On 16/05/2023 00:11, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: Nick, spare yourself the pain and just designate one machine as the master. This is how we run all our proxy server pairs (nginx, squid, other stuff). For a pair fooa/foob, 'a' is the master, and gets advskew 100. The 'b' host gets 150. Make sure preemption is enabled. When it's upgrade time, upgrade the 'b' machine and reboot. If it looks stable, set its advskew to 50 and wait for it to pick up traffic. Now upgrade and reboot the 'a' host. When it looks happy, set 'b's advskew back to 150. This keeps everything in a known state. You are going to break connections no matter what -- even when you let the master float -- so you might as well do it under your own control. We schedule our updates for off-peak hours, and accept that the flip is going to interrupt traffic. You just have to live with it. We moved to this scheme on all our proxies and firewalls seven years ago and have never looked back. --lyndon Totally agree on this and on top of that add load balancers/routers in the mix which will run carp/relayd/pfsync/forwarding. With sticky sessions, all requests will redirect to the same backend server and you can avoid breaking service connections. These don't have to be big machines. G
Re: carp flapping
On 12/05/2023 14:43, Nick Holland wrote: > I had several other people suggest network problems. I'm not going to > say "impossible" or even "unlikely", but my understanding is that the > two machines are both plugged into the same switch, in the same rack. > > Several people pointed out I was using the default advskew of 1 second, > which means a small network glitch (or system load? maybe I'm all wrong > about this system never breaking a sweat, at least when it comes to > network traffic) would flip it, so I've increased it to 10 on both > machines (and apparently just induced a flip of my own. oops). By the > nature of this system, some people will be annoyed by any flip, so it > really doesn't matter if it was a 1 second outage or a 30 second outage, > I just want the system available again after an unhappy event (or > routine maintenance). > > Nick. Usually it's a network problem. The big delay of 3 days you had also suggests that. But on the other hand, I also had a similar problem in one of my load balancers (routing/fw/relayd), where the MASTER was becoming BACKUP for no obvious reason. I believed it was a network glitch, but couldn't trace it. The problem after all was that they where pushing the limit of max pf states and relayd checks where failing. Not obvious to spot at all. I believe default is 20K. pfctl -sm pfctl -si After increasing that limit with set limit states I've never had a glitch any more. G
Re: pfr_get_astats: corruption detected
Hi, I still see those messages in my logs. May 11 06:08:01 /bsd: pf: pfr_get_astats: corruption detected (7) What does it mean? Is there a problem with my pf tables? Thanks, G On 21/11/2022 18:47, Kapetanakis Giannis wrote: > Hi, > > Can someone explain messages of type > /bsd: pf: pfr_get_astats: corruption detected (2) > > in /var/log/messages? > > thanks, > > G > > >
Re: pflow(4) and ipv6 flows
On 21/02/2023 14:41, Florian Obser wrote: > On 2023-02-21 14:24 +02, Kapetanakis Giannis > wrote: >> Yes I'm using default netflow version 5. >> >> is IPFIX better in general or the only one that supports ipv6? > Yes, version 5 is not specified for IPv6 flows, only IPFIX can export > IPv6 flows. Thanks, activated and already see them G
Re: pflow(4) and ipv6 flows
Yes I'm using default netflow version 5. is IPFIX better in general or the only one that supports ipv6? thanks G On 21/02/2023 13:57, Florian Obser wrote: > Yes, > > wild guess, you are running with pflowproto 5. It probably works better > with pflowproto 10. > > On 2023-02-21 13:12 +02, Kapetanakis Giannis > wrote: >> Hi, >> >> Does pflow(4) support export of ipv6 flows? >> >> I see none recorded. >> >> Thanks, >> >> G >>
pflow(4) and ipv6 flows
Hi, Does pflow(4) support export of ipv6 flows? I see none recorded. Thanks, G
pfr_get_astats: corruption detected
Hi, Can someone explain messages of type /bsd: pf: pfr_get_astats: corruption detected (2) in /var/log/messages? thanks, G
Re: AMD EPYC
Thanks both Paul and Hrvoje for the quick replies :) Good news then, lets hope for a better performance. G
AMD EPYC
Hi, Looking for upgrading our firewall/router and thinking about switching from Xeon to EPYC (73F3 - 16C @ 3.5 GHz). Anyone running on EPYC? Any problems? Alternative would be something like dual Intel Xeon Gold 5315Y - 8C @ 3.20 thanks, Giannis
Re: pf rdr-to (localhost ntpd) not always works
The problem/limitation is probably from local port binding of the client:123 which is used for both connections. I see other clients that use high ports for ntp queries that create multiple states without any problem. all udp 127.0.0.1:123 (remote_ntp1:123) <- y.y.y.y:54401 SINGLE:MULTIPLE all udp 127.0.0.1:123 (remote_ntp2:123) <- y.y.y.y:52525 SINGLE:MULTIPLE :( G On 15/09/2022 11:12, Kapetanakis Giannis wrote: > Hi, > > I'm trying to enforce a local ntpd server (which is also our external > firewall/router) for all connections and I have a very strange problem. > Only one (dst) IP is allowed to create a state. After state expires a new dst > IP can be used. > > fw# pfctl -sr -R 154 > pass in log quick on $int_if inet proto udp from x.x.x.x to any port = 123 > rdr-to 127.0.0.1 > > client-x-x-x-x# ntpdate 1.2.3.4 > 15 Sep 10:34:15 ntpdate[620]: adjust time server 1.2.3.4 offset -0.96 sec > > On fw (ntpd server) I see: > > 10:34:09.366370 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:09.366460 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 > [tos 0x10] > 10:34:11.366247 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:11.366281 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 > [tos 0x10] > 10:34:13.366275 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:13.366324 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 > [tos 0x10] > > Sep 15 10:34:09.366383 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 1.2.3.4.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > > # pfctl -ss -vv -R 154 > > all udp 127.0.0.1:123 (1.2.3.4:123) <- x.x.x.x:123 MULTIPLE:MULTIPLE > age 00:00:19, expires in 00:00:47, 4:4 pkts, 304:304 bytes, rule 154 > id: 628ba534a943cb3c creatorid: 0001 > > Subsequent ntp queries to same IP 1.2.3.4 work fine. Same state is used. pkts > advance, expire time resets to 60 seconds > > However if I try a different dst IP from the same client it does not work > until state to 1.2.3.4 above expires. > > I see the incoming packet on the internal interface but I see no reply going > back to client (as before with 1.2.3.4). > > 10:34:26.812675 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:28.812571 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:30.812587 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > 10:34:32.812554 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 > prec -6 (DF) > > I also see the pf log (4 times now and not 1 as before) > Sep 15 10:34:26.812688 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > Sep 15 10:34:28.812583 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > Sep 15 10:34:30.812598 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > Sep 15 10:34:32.812566 rule 154/(match) pass in on int_if: x.x.x.x.123 > > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) > > No new state is created. pfctl -ss -R 154 only lists the one state of 1.2.3.4 > > After state expiration, a different IP can be used and works. > > Initial pf rule included keep state (max-src-states 10, source-track rule) > which also behaves the same. 10 src-IP connections are allowed and then no > more until one is expired. > However, again, if another destination IP is used I see no replies (bellow > the src limit of 10). > > system is 7.1 amd64 which syspatches. > > ntpd only lists servers, constraints and > listen on 127.0.0.1 > listen on ::1 > > ideas? > > G > > > >
Re: pf rdr-to (localhost ntpd) not always works
On 15/09/2022 15:06, Kapetanakis Giannis wrote: > The problem/limitation is probably from local port binding of the client:123 > which is used for both connections. > > I see other clients that use high ports for ntp queries that create multiple > states without any problem. > > all udp 127.0.0.1:123 (remote_ntp1:123) <- y.y.y.y:54401 SINGLE:MULTIPLE > all udp 127.0.0.1:123 (remote_ntp2:123) <- y.y.y.y:52525 SINGLE:MULTIPLE > > :( > > G Yes indeed. from info debug level I get. Sep 15 15:48:02 fw /bsd: pf: stack key attach failed on all: UDP in wire: (0) x.x.x.x:123 1.1.1.1:123 stack: (0) x.x.x.x:123 127.0.0.1:123 1:0 @154, existing: UDP in wire: (0) x.x.x.x:123 2.2.2.2:123 stack: (0) x.x.x.x:123 127.0.0.1:123 2:2 @154 Apparently src_ip:port <-> rdr_ip:port is used for state mapping and not src_ip_port <-> dst_ip:port G > > On 15/09/2022 11:12, Kapetanakis Giannis wrote: >> Hi, >> >> I'm trying to enforce a local ntpd server (which is also our external >> firewall/router) for all connections and I have a very strange problem. >> Only one (dst) IP is allowed to create a state. After state expires a new >> dst IP can be used. >> >> fw# pfctl -sr -R 154 >> pass in log quick on $int_if inet proto udp from x.x.x.x to any port = 123 >> rdr-to 127.0.0.1 >> >> client-x-x-x-x# ntpdate 1.2.3.4 >> 15 Sep 10:34:15 ntpdate[620]: adjust time server 1.2.3.4 offset -0.96 sec >> >> On fw (ntpd server) I see: >> >> 10:34:09.366370 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 >> prec -6 (DF) >> 10:34:09.366460 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 >> [tos 0x10] >> 10:34:11.366247 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 >> prec -6 (DF) >> 10:34:11.366281 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 >> [tos 0x10] >> 10:34:13.366275 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 >> prec -6 (DF) >> 10:34:13.366324 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 >> [tos 0x10] >> >> Sep 15 10:34:09.366383 rule 154/(match) pass in on int_if: x.x.x.x.123 > >> 1.2.3.4.123: v4 alarm client strat 0 poll 3 prec -6 (DF) >> >> # pfctl -ss -vv -R 154 >> >> all udp 127.0.0.1:123 (1.2.3.4:123) <- x.x.x.x:123 MULTIPLE:MULTIPLE >> age 00:00:19, expires in 00:00:47, 4:4 pkts, 304:304 bytes, rule 154 >> id: 628ba534a943cb3c creatorid: 0001 >> >> Subsequent ntp queries to same IP 1.2.3.4 work fine. Same state is used. >> pkts advance, expire time resets to 60 seconds >> >> However if I try a different dst IP from the same client it does not work >> until state to 1.2.3.4 above expires. >> >> I see the incoming packet on the internal interface but I see no reply going >> back to client (as before with 1.2.3.4). >> >> 10:34:26.812675 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 >> prec -6 (DF) >> 10:34:28.812571 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 >> prec -6 (DF) >> 10:34:30.812587 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 >> prec -6 (DF) >> 10:34:32.812554 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 >> prec -6 (DF) >> >> I also see the pf log (4 times now and not 1 as before) >> Sep 15 10:34:26.812688 rule 154/(match) pass in on int_if: x.x.x.x.123 > >> 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) >> Sep 15 10:34:28.812583 rule 154/(match) pass in on int_if: x.x.x.x.123 > >> 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) >> Sep 15 10:34:30.812598 rule 154/(match) pass in on int_if: x.x.x.x.123 > >> 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) >> Sep 15 10:34:32.812566 rule 154/(match) pass in on int_if: x.x.x.x.123 > >> 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) >> >> No new state is created. pfctl -ss -R 154 only lists the one state of 1.2.3.4 >> >> After state expiration, a different IP can be used and works. >> >> Initial pf rule included keep state (max-src-states 10, source-track rule) >> which also behaves the same. 10 src-IP connections are allowed and then no >> more until one is expired. >> However, again, if another destination IP is used I see no replies (bellow >> the src limit of 10). >> >> system is 7.1 amd64 which syspatches. >> >> ntpd only lists servers, constraints and >> listen on 127.0.0.1 >> listen on ::1 >> >> ideas? >> >> G >> >> >> >>
pf rdr-to (localhost ntpd) not always works
Hi, I'm trying to enforce a local ntpd server (which is also our external firewall/router) for all connections and I have a very strange problem. Only one (dst) IP is allowed to create a state. After state expires a new dst IP can be used. fw# pfctl -sr -R 154 pass in log quick on $int_if inet proto udp from x.x.x.x to any port = 123 rdr-to 127.0.0.1 client-x-x-x-x# ntpdate 1.2.3.4 15 Sep 10:34:15 ntpdate[620]: adjust time server 1.2.3.4 offset -0.96 sec On fw (ntpd server) I see: 10:34:09.366370 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 prec -6 (DF) 10:34:09.366460 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 [tos 0x10] 10:34:11.366247 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 prec -6 (DF) 10:34:11.366281 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 [tos 0x10] 10:34:13.366275 x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 prec -6 (DF) 10:34:13.366324 1.2.3.4.123 > x.x.x.x.123: v4 server strat 4 poll 3 prec -29 [tos 0x10] Sep 15 10:34:09.366383 rule 154/(match) pass in on int_if: x.x.x.x.123 > 1.2.3.4.123: v4 alarm client strat 0 poll 3 prec -6 (DF) # pfctl -ss -vv -R 154 all udp 127.0.0.1:123 (1.2.3.4:123) <- x.x.x.x:123 MULTIPLE:MULTIPLE age 00:00:19, expires in 00:00:47, 4:4 pkts, 304:304 bytes, rule 154 id: 628ba534a943cb3c creatorid: 0001 Subsequent ntp queries to same IP 1.2.3.4 work fine. Same state is used. pkts advance, expire time resets to 60 seconds However if I try a different dst IP from the same client it does not work until state to 1.2.3.4 above expires. I see the incoming packet on the internal interface but I see no reply going back to client (as before with 1.2.3.4). 10:34:26.812675 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) 10:34:28.812571 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) 10:34:30.812587 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) 10:34:32.812554 x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) I also see the pf log (4 times now and not 1 as before) Sep 15 10:34:26.812688 rule 154/(match) pass in on int_if: x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) Sep 15 10:34:28.812583 rule 154/(match) pass in on int_if: x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) Sep 15 10:34:30.812598 rule 154/(match) pass in on int_if: x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) Sep 15 10:34:32.812566 rule 154/(match) pass in on int_if: x.x.x.x.123 > 2.3.4.5.123: v4 alarm client strat 0 poll 3 prec -6 (DF) No new state is created. pfctl -ss -R 154 only lists the one state of 1.2.3.4 After state expiration, a different IP can be used and works. Initial pf rule included keep state (max-src-states 10, source-track rule) which also behaves the same. 10 src-IP connections are allowed and then no more until one is expired. However, again, if another destination IP is used I see no replies (bellow the src limit of 10). system is 7.1 amd64 which syspatches. ntpd only lists servers, constraints and listen on 127.0.0.1 listen on ::1 ideas? G
Re: Blocking ping scan
On 18/06/2022 12:15, Cristian Danila wrote: Good day! Does anyone know if OpenBSD(7.1) has the capability to be hidden against a pingscan(nmap -sn xxx.xxx.xxx.xxx)? In PF I have only 2 rules to block everything: block in quick all block out quick all This is a fresh OpenBSD7.1 with no other configuration in place. The only thing set is the default interface vic0 to allow dhcp By running a test with nmap -sn 192.168.121.131 I see this: Starting Nmap 7.92(https://nmap.org)at 2022-06-18 11:52 GTB Daylight Time Nmap scan report for 192.168.121.131 Host is up (0.00s latency). MAC Address: 00:0C:29:C3:D9:A7 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds On scanned host I see this by running tcpdump -i vic0 09:51:40.913770 arp who-has 192.168.121.131 tell 192.168.121.1 09:51:40.913795 arp reply 192.168.121.131 is-at 00:0c:29:c3:d9:a7 I am thinking(please correct me if I am wrong) that not all the traffic passes through pf hence this is why is not blocked. I would appreciate if someone could provide me a technical answer on this, even recommend me a book to read or docs regarding it. Kind regards, Claudiu Apparently you are on the same network, that's why the arp(4) reply. If you're not (and 192.168.121.1 is your gateway) then maybe want to add block drop or set block-policy drop your pf rule blocks icmp and rest of ip(4) traffic ping 192.168.121.131 to verify.
Re: dmesg - cpu, smt, core, package
On 09/02/2022 19:48, Mihai Popescu wrote: > $ dmesg | grep smt > cpu0: smt 0, core 0, package 0 > cpu1: smt 1, core 0, package 0 > cpu2: smt 0, core 1, package 0 > cpu3: smt 1, core 1, package 0 > > for > > AMD A8-5500B APU with Radeon(tm) HD Graphics, 3194.46 MHz, 15-10-01 > > What could be the "smt" thing? > multi threading # sysctl hw.smt G
Re: ttyflags hangs on Dell PowerEdge R200
Sorry to jump-in, but could this be similar to a problem I have since 6.7 ? https://marc.info/?l=openbsd-misc&m=159611309426907&w=2 tldr; Server does not finish boot until I connect to the server's java console on the iRMC (console redirection). G On 31/01/2022 16:51, Mark Kettenis wrote: >> Date: Mon, 31 Jan 2022 15:41:32 +0100 >> From: Jan Stary >> >> On Jan 31 14:47:41, mark.kette...@xs4all.nl wrote: Date: Mon, 31 Jan 2022 14:03:29 +0100 From: Jan Stary > On Jan 26 18:02:17, mark.kette...@xs4all.nl wrote: > > revision 1.406 > date: 2022/01/26 14:39:07; author: kettenis; state: Exp; lines: +2 -2; > commitid: zL3Ot2UVnkpDz6go; > An ACPI device needs to be both present and enabled for it to function. > So only attempt to attach hardware that has both bits enabled. This fixes > an issue where com(4) would attach for a disabled serial port leading to > misdetection of the hardware variant and a subsequent hang when /etc/rc > runs ttyflags -a. While this fixes the original problem on Dell PowerEdge it also seems to make /dev/console disappear on Beagle Bone Black (current/armv7) - last good dmesg and current dmesg below, the highlight of the diff being -com0 at omsysc7: ti16750, 64 byte fifo -com0: console +"serial" at omsysc7 not configured +init: can't open /dev/console: Device not configured Jan >>> Sorry, but no, the code I changed isn't even compiled on armv7. >> Ah, sorry for the confusion. >> >>> Not sure what's happening here. Are both kernels running with the >>> same U-Boot version? >> Yes, U-Boot SPL 2021.10 (Nov 01 2021 - 20:37:54 -0600) > Good. Did you try building a current kernel yourself? Sometimes > there are patches that need testing in the snapshots. In fact, the > Jan 24 may have had a version of Theo's fix for your ttyflags problem > in it ;). > OpenBSD 7.0-current (GENERIC) #0: Tue Jan 4 22:31:14 CET 2022 h...@bbb.stare.cz:/usr/src/sys/arch/armv7/compile/GENERIC real mem = 484184064 (461MB) avail mem = 463884288 (442MB) random: good seed from bootblocks mainbus0 at root: TI AM335x BeagleBone Black cpu0 at mainbus0 mpidr 0: ARM Cortex-A8 r3p2 cpu0: 32KB 64b/line 4-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 256KB 64b/line 8-way L2 cache omap0 at mainbus0 prcm0 at omap0 rev 0.2 dmtimer0 at omap0 rev 3.1 dmtimer1 at omap0 rev 3.1 omsysc0 at mainbus0: "target-module" omsysc1 at omsysc0: "target-module" "pmu" at omsysc1 not configured simplebus0 at mainbus0: "ocp" intc0 at simplebus0 rev 5.0 omsysc2 at simplebus0: "target-module" simplebus1 at simplebus0: "interconnect" simplebus2 at simplebus1: "segment" simplebus3 at simplebus1: "segment" omsysc3 at simplebus3: "target-module" "cpu" at omsysc3 not configured simplebus4 at simplebus1: "segment" omsysc4 at simplebus4: "target-module" simplebus5 at omsysc4: "prcm" omcm0 at simplebus5: "per-cm" omclock0 at omcm0: "l4ls-clkctrl" omclock1 at omcm0: "l3s-clkctrl" omclock2 at omcm0: "l3-clkctrl" omclock3 at omcm0: "l4hs-clkctrl" omclock4 at omcm0: "pruss-ocp-clkctrl" omclock5 at omcm0: "cpsw-125mhz-clkctrl" omclock6 at omcm0: "lcdc-clkctrl" omclock7 at omcm0: "clk-24mhz-clkctrl" omcm1 at simplebus5: "wkup-cm" omclock8 at omcm1: "l4-wkup-clkctrl" omclock9 at omcm1: "l3-aon-clkctrl" omclock10 at omcm1: "l4-wkup-aon-clkctrl" omcm2 at simplebus5: "mpu-cm" omclock11 at omcm2: "mpu-clkctrl" omcm3 at simplebus5: "l4-rtc-cm" omclock12 at omcm3: "l4-rtc-clkctrl" omcm4 at simplebus5: "gfx-l3-cm" omclock13 at omcm4: "gfx-l3-clkctrl" omcm5 at simplebus5: "l4-cefuse-cm" omclock14 at omcm5: "l4-cefuse-clkctrl" "prm" at simplebus5 not configured "prm" at simplebus5 not configured "prm" at simplebus5 not configured "prm" at simplebus5 not configured "prm" at simplebus5 not configured "prm" at simplebus5 not configured "prm" at simplebus5 not configured omsysc5 at simplebus4: "target-module" simplebus6 at omsysc5: "scm" syscon0 at simplebus6: "scm_conf" pinctrl0 at simplebus6 "control" at simplebus6 not configured "wkup_m3_ipc" at simplebus6 not configured "dma-router" at simplebus6 not configured omsysc6 at simplebus4: "target-module" omgpio0 at omsysc6: rev 0.1 gpio0 at omgpio0: 32 pins omsysc7 at simplebus4: "target-module" com0 at omsysc7: ti16750, 64 byte fifo com0: console omsysc8 at simplebus4: "target-module" tiiic0 at omsysc8 rev 0.11 iic0 at tiiic0 "ti,tps65217" at iic0 addr 0x24 not configured "atmel,24c256" at iic0 addr 0x50 not configured nxphdmi0 at iic0 addr 0x70: rev 0x0301 nxphdmi0: no display det
pflog to graylog
Hi, I want to push data from pflog0 device to my graylog server. Has anyone done something similar or maybe with elastic/GELF ? There is https://github.com/dennisoelkers/keil but seemd abandoned and I couldn't make it work. There is also packetbeat which is also ported to openbsd but it seems to gather/analyze specific protocols and not whole traffic. ideas? Giannis
Re: forum software recommend?
On 10/11/2021 14:58, Paul Wisehart wrote: Hi!, Does anyone recommend a forum software that works well with OpenBSD/httpd? I installed phpBB, and it seems fine, but I figured I'd ask here before forging ahead. Thanks!, -- Paul Wisehart You can also check SMF https://www.simplemachines.org/ Most of these are PHP/MySQL, so I don't see no reason why they shouldn't run on OpenBSD/httpd. G
Re: rc.firsttime after package daemons
On 03/11/2021 06:53, cho...@jtan.com wrote: > ... > > On the gripping hand, all it does is run fw_update and syspatch. This. Unless there is something more. Anyway, I followed Stuart's advice of adding a second DNS server in resolv.conf apart from 127.0.0.1 which was my usual practice for caching servers. I see no harm on this. Thanks for comments on unbound/nsd. I'm familiar and using those in another setup but it adds complexity when you want your caching servers to also have live copies (+live updates) of internal authoritative zones. You setup the zones twice (nsd and unbound stub-zone), which is not that bad, but you also have caching/negative caching on unbound until TTL or flush to see the updates/changes, which is more disturbing. G
rc.firsttime after package daemons
Hi, Just a notice for this. I have a system which is a DNS server it self and runs isc-bind, so the daemon is started from $pkg_scripts. rc.firsttime is run before pkg daemons are started so the system cannot (yet) resolve since it lists itself in /etc/resolv.conf If there is no other reason, maybe rc.firsttime could be moved after package daemons are started. best, Giannis
Re: blacklistd analogue
How about a distributed setup?
Has anyone thought of a way getting IPs from various servers (say linux
& fail2ban) to the central OpenBSD (pf) firewall?
Ideally with history in order to punish more the frequent abusers.
I had plans on looking to bgp to distribute the IPs around but maybe
there is already a better way doing this.
thanks and sorry for hijacking but I believe its quite relevant.
G
On 3/25/21 10:57 AM, Matthias Pressfreund wrote:
You could try this: https://github.com/mpfr/pftbld
It uses pf tables instead of anchors to achieve the same goal.
Handling sshd abusers may be accomplished by first using pf source-tracking
to catch them. For example:
-
table persist
block in quick from
pass in on egress proto tcp to egress port ssh keep state ( \
max-src-conn 50, max-src-conn-rate 5/180 \
overload flush global \
)
--
After that, abusers may be fed to pftbld by a cron-controlled script.
For example:
--
#!/bin/ksh
table='abusers_catch'
pftblctl='/usr/local/sbin/pftblctl'
sock='/var/run/pftbld-abuse.sock'
pfctl -t ${table} -T show | while read -r ip; do
[[ $(${pftblctl} -s ${sock} "${ip}") = 'ACK' ]] \
&& pfctl -q -t ${table} -T delete ${ip}
done
--
Handling httpd abusers is more simple and straightforward, as shown in the
pftbld documentation.
On 2021-03-24 19:33, jeanpierre wrote:
Does there exist an OpenBSD analogue for FreeBSD's blacklistd daemon?
For the sake of completeness: blacklistd is a daemon that, using pf
anchors, blocks connections from abusive hosts to parctiular services
(e.g. sshd) until they start behaving themselves again.
I find it very useful for timming down log files.
Regards,
Jean-Pierre
Re: relayd + pfsync
On 02/02/2021 05:18, Jordan Geoghegan wrote:
Hello,
I had a question about using relayd with pfsync.
I have a small gateway/load-balancer set up with relayd, carp and pfsync plus
BGPd for IP failover, and everything is working great. I was pleasantly
surprised at how easy it was to get pfsync tunnelled over wireguard. Things
failover perfectly, and I'm happy as a clam.
I however do have a question about some pfsync/relayd details that I'm not
fully clear on:
With all the plumbing being done with relayd and all the associated TCP/TLS/HTTP(s)
checks it's doing, it ends up setting up and tearing down a decent number of connections
on a recurring basis. I know in PF you can use the "no-sync" keyword to prevent
states created by certain rules from being synced across the wire, but I haven't found a
way to do this with rules/states generated by relayd.
It's probably largely irrelevant in the grand scheme of things, but I found it
slightly irritating having hundreds or thousands of state table entries
experiencing constant churn while being synced over the wire. Having the noise
from the relayd connectivity checks syncing back and forth makes using tcpdump
on a pfsync interface much less convenient. All these state table entries will
never be used should the machine fail-over, as all the connectivity checks are
initiated from the local IP address, rather that the CARP address.
So I guess what I'm trying to ask is: Is there a way to have relayd not sync
it's TCP/TLS/etc connectivity checks via pfsync?
I was hoping to get a sanity check here so I can confirm weather or not I'm
totally off base here.
I currently have "keep state (no-sync)" peppered throughout my config for rules I want
excluded from pfsync, as the pf config is quite simple. Maybe I'm missing something obvious, but is
there a "sync" option? ie the ability to manually specify exactly which rules/states you
want synced?
Would some sort of rule like "pass out on $int_if proto tcp to any user _relayd keep
state (no-sync)" do what I want, or would that also catch the traffic I'm trying to
load balance as well?
Any insight or advice would be much appreciated.
P.S Sorry for the wall of text
Regards,
Jordan
Hi,
As you said, you can use the no-sync.
Relayd checks don't create any pf rules. Only the listen creates rules
pfctl -sr -a'relayd/ldap'
pass in quick on rdomain 0 inet proto tcp from any to x.x.x.x port = 636
flags S/SA keep state (tcp.established 4200) tag RELAYD_ldap rdr-to
port 1636 least-states sticky-address
local checks from LB to hosts can have the no-sync.
I have these in my config
# checks from LB
pass out quick on $ldap_if proto tcp from ($ldap_if) to
($ldap_if:network) port {1389, 1636} keep state (no-sync)
Maybe you have another rule (out on $ldap_if) before, that allows the
traffic?
I handle incoming traffic (to LB) with pftag on relayd.conf and I
specifically allow them on out direction.
# client rules
pass out quick on $ldap_if tagged RELAYD_ldap keep state
(tcp.established 4200)
G
Re: ospf on wg(4)
On 30/01/2021 10:50, Bastien Durel wrote: Hello, IFAIK, wgaip is not routing, using wgaip 0.0.0.0/0 does not add a default route on interface. Regards, Cool. At least on linux it adds routes by default, which is not always desirable. Although reading the manual now, there is an option to disable this feature (Table = off) G
Re: ospf on wg(4)
On 29/01/2021 23:32, Bastien Durel wrote:
Le 29/01/2021 à 17:44, Olivier Cherrier a écrit :
Hi,
I'm trying to setup OSPF on a working Wireguard VPN using 6.8 amd64
machines. This is what I get:
# ospfd -dvvv
id = "172.26.1.1"
startup
kr_init: priority filter enabled
orig_rtr_lsa: area 0.0.0.0
orig_rtr_lsa: stub net, interface wg0
if_fsm: event UP resulted in action START and changing state for
interface wg0 from DOWN to P2P
send_packet: error sending packet to 224.0.0.5 on interface wg0: Network
is unreachable
send_hello: Network is unreachable
[...]
# ifconfig wg0
wg0: flags=80c3 mtu 1420
index 23 priority 0 llprio 3
wgport 33222
wgpubkey XXX
wgpeer YYY
wgpka 23 (sec)
wgendpoint A.B.C.D 31502
tx: 4317366604, rx: 382870060
last handshake: 47 seconds ago
wgaip 192.168.1.0/24
wgaip 172.26.1.3/32
wgpeer WWW
wgpka 23 (sec)
wgendpoint E.F.G.H 15776
tx: 609183380, rx: 1523684
last handshake: 1 seconds ago
wgaip 172.26.0.0/24
wgaip 172.26.1.2/32
groups: wg
inet 172.26.1.1 netmask 0xff00 broadcast 172.26.1.255
Is it possible to use a wg(4) interface for ospfd(8)?
Thank you,
Best.
Hello.
It is possible, I use it myself. You have to allow multicast address
on wg(4) interface(s):
225.0.0.5 for all OSPF routers
224.0.0.6 for all DR/BDR
(I use wgaip 0.0.0.0/0, so my config is not relavant for you)
Regards,
Sorry to jump in, but does this also add routes for 225.0.0.{5,6} via wg0?
If this is a case, this would be a problem for multiple interfaces.
Or maybe wg(4) handles multicast differently than normal IP
thanks
G
Re: CARP load balancing problems under KVM
On 12/01/2021 18:58, Carlos Lopez wrote: Thanks Gianni, but about what interface ? KVM bridges? In theory, MAC spoofing is avoided using this option: bridge.ageing-time: 300 On 12/1/21, 17:47, "owner-m...@openbsd.org on behalf of Kapetanakis Giannis" wrote: Check that you have mac spoofing filter disabled on that interface. For carp to work, I have it disabled on the virtual interface on the supervisor. I use ovirt so I do it on the network profile there. This is a libvirt filter option. Maybe it's applied by default on your setup. The idea is to disable this protection and allow mac spoofing. G
Re: CARP load balancing problems under KVM
Check that you have mac spoofing filter disabled on that interface. G On 12/01/2021 15:30, Carlos Lopez wrote: Hi David and misc@, Sorry to disturb with this.I have realized several tests this morning with two OpenBSD 6.8 carp'ed firewalls (fully patched) as kvm guests and result is the same: carp load balancing doesn't work. My host is a RedHat Enterprise Linux 8.3 with kernel .18.0-240.10.1.el8_3.x86_6 (fully patched also). I have tested all ip load balancing options under these OpenBSD virtual guests: ip, ip-unicast and ip-stealth. When I use only "ip" for load balancing in all carped interfaces, these appears as MASTER in both firewalls as you can see here: carp0: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0a description: Production Network index 12 priority 15 llprio 3 carp: carpdev vio0 advbase 1 balancing ip state MASTER vhid 10 advskew 0 state MASTER vhid 11 advskew 100 groups: carp status: master inet 172.22.55.30 netmask 0xffe0 broadcast 172.22.55.31 carp1: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0c description: Primary Public Network index 13 priority 15 llprio 3 carp: carpdev vio1 advbase 1 balancing ip state MASTER vhid 12 advskew 0 state MASTER vhid 13 advskew 100 groups: carp status: master inet 172.17.35.5 netmask 0xff00 broadcast 172.17.35.255 carp2: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0e description: Mgmt Network index 14 priority 15 llprio 3 carp: carpdev vio2 advbase 1 balancing ip state MASTER vhid 14 advskew 0 state MASTER vhid 15 advskew 100 groups: carp status: master inet 172.22.59.1 netmask 0xfff0 broadcast 172.22.59.15 carp3: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:10 description: DMZ Network index 15 priority 15 llprio 3 carp: carpdev vio3 advbase 1 balancing ip state MASTER vhid 16 advskew 0 state MASTER vhid 17 advskew 100 groups: carp status: master inet 172.22.54.1 netmask 0xfff8 broadcast 172.22.54.7 carp4: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:12 description: VPN Network index 16 priority 15 llprio 3 carp: carpdev vio4 advbase 1 balancing ip state MASTER vhid 18 advskew 0 state MASTER vhid 19 advskew 100 groups: carp status: master inet 172.22.56.1 netmask 0xfff8 broadcast 172.22.56.7 carp5: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:14 description: Encryption Network index 17 priority 15 llprio 3 carp: carpdev vio5 advbase 1 balancing ip state MASTER vhid 20 advskew 0 state MASTER vhid 21 advskew 100 groups: carp status: master inet 172.22.57.1 netmask 0xfff8 broadcast 172.22.57.7 carp6: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:16 description: IDPS Network index 18 priority 15 llprio 3 carp: carpdev vio6 advbase 1 balancing ip state MASTER vhid 22 advskew 0 state MASTER vhid 23 advskew 100 groups: carp status: master inet 172.22.60.1 netmask 0xfff0 broadcast 172.22.60.15 carp7: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:18 description: Windows Network index 19 priority 15 llprio 3 carp: carpdev vio8 advbase 1 balancing ip state MASTER vhid 24 advskew 0 state MASTER vhid 25 advskew 100 groups: carp status: master inet 172.22.61.1 netmask 0xfff8 broadcast 172.22.61.7 .. and all kvm guests behind these firewalls shows the following arp entries (172.22.55.30 is the carp'ed IP address. IP 172.22.55.28 is for fw01 and 172.22.55.29 is for fw02): root@stonehenge:~# ip neigh 172.22.55.14 dev eth0 lladdr ac:1f:6b:14:6a:f6 STALE 172.22.55.29 dev eth0 lladdr 00:50:56:a1:4d:c3 STALE 172.22.55.5 dev eth0 lladdr ac:1f:6b:14:6c:b0 STALE 172.22.55.30 dev eth0 INCOMPLETE 172.22.55.28 dev eth0 lladdr 00:50:56:6f:64:aa STALE 172.22.55.4 dev eth0 lladdr a0:ce:c8:0a:7e:f4 REACHABLE And after some seconds, arp entries appears as: root@stonehenge:~# ip neigh 172.22.55.14 dev eth0 lladdr ac:1f:6b:14:6a:f6 STALE 172.22.55.29 dev eth0 lladdr 00:50:56:a1:4d:c3 STALE 172.22.55.5 dev eth0 lladdr ac:1f:6b:14:6c:b0 STALE 172.22.55.30 dev eth0 FAILED 172.22.55.28 dev eth0 lladdr 00:50:56:6f:64:aa REACHABLE 172.22.55.4 dev eth0 lladdr a0:ce:c8:0a:7e:f4 DELAY In this case, no traffic flows and I can't see any packet using tcpdump When I use "ip-unicast" or "ip-stealth" options for CARP load balancing, CARP interfaces seems to be ok: carp0: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0a description: Production Network inde
disk boot delay and high cpu
Has anyone seen this before?
I'm experiencing disk stalls while doing sysupgrade.
OpenBSD 6.7 -> 6.8, which is a test VM running on KVM RHEL7/RHEL8.
VM storage is LVM on top of 10Gbps iSCSI with multipath.
Disk and network are on virtio.
Installation is fine (iso image stored locally on node).
But when doing sysupgrade I experience disk stalls.
Also qemu-kvm process has high cpu usage.
strace on qemu-kvm process on Linux node shows a hell lot of:
14:36:29 ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=13, events=POLLIN}, {fd=16,
events=POLLIN}, {fd=18, events=POLLIN}, {fd=29, events=POLLIN}, {fd=31,
events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=36,
events=POLLIN}], 12, {tv_sec=0, tv_nsec=996416}, NULL, 8) = 0 (Timeout)
<0.001011>
14:36:29 ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=7,
events=POLLIN}, {fd=8, events=POLLIN}, {fd=13, events=POLLIN}, {fd=16,
events=POLLIN}, {fd=18, events=POLLIN}, {fd=29, events=POLLIN}, {fd=31,
events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=36,
events=POLLIN}], 12, {tv_sec=0, tv_nsec=996427}, NULL, 8) = 0 (Timeout)
<0.001011>
If I logout from one of multipath the timeouts above stop, stalls stop and
upgrade continues.
If I don't logout, then upgrade will finish but it will take a lot ~ 10min.
I have a bugzilla ticket on redhat about this.
https://bugzilla.redhat.com/show_bug.cgi?id=1721395#c17
Rest of the infrastructure (what is not openbsd, is Linux) works fine.
I'm experiencing this for a long time (probably after sysupgrade was
introduced).
Manually upgrading, while system is running, does NOT stall.
G
ps. I have feeling that this might be related to kvm_intel preemption_timer
I've seen this before on this list, but it's not easy for me to test it right
now.
Re: compiling pmacct on obsd6.8
On 12/01/2021 10:25, Stuart Henderson wrote: > On 2021-01-12, Masato Asou wrote: >> Hi, >> >> From: Salvatore Cuzzilla >> Date: Mon, 11 Jan 2021 17:40:21 +0100 >> >>> I'm having some troubles with compiling the latest version of pmacct >>> (https://github.com/pmacct/pmacct) on obsd6.8 . >>> >>> I just wanted to know if someone was successful with it ... >> >> You can use /usr/ports/net/pmacct. > > That is not the latest version; OpenBSD's libpcap is too old for newer > pmacct which uses PCAP_NETMASK_UNKNOWN (added in 1.1.0, released 2010). pkg version runs fine for me on 6.8 # pkg_info pmacct Information for inst:pmacct-1.7.1 G
osp6d p2p send_ls_update
Hi, I've changed today my config from broadcast to p2p for both ipv4 and ipv6. In ospf6d I get this quite often: Dec 29 17:39:00 ospf6d[40695]: send_packet: error sending packet on interface vlanX: Network is unreachable Dec 29 17:39:00 ospf6d[40695]: send_ls_update: Network is unreachable debugging send_packet shows: Dec 29 18:12:57 ospf6d[65033]: send_packet: error sending packet on interface vlanX to ::: Network is unreachable Dec 29 18:12:57 ospf6d[65033]: send_ls_update: Network is unreachable The dst_address of send_packet is ::: This comes from send_ls_update system is current (20 dec). maybe something more is missing for P2P? G
Re: 6.8 openldap and SSL/TLS problem after upgrade
On 23/12/2020 03:53, Stuart Henderson wrote: On 2020-12-22, Kapetanakis Giannis wrote: Hi, After upgrading to 6.8-release I can no longer connect to my ldap server with openldap and SSL/TLS. I'm using a self signed root CA to sign LDAP server's certificate. /etc/openldap/ldap.conf has: TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT demand # /usr/local/bin/ldapsearch -d9 -x (openldap client) TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 20, subject: /CN=xxx, issuer: /CN=xxx TLS certificate verification: Error, unable to get local issuer certificate TLS certificate verification: depth: 1, err: 20, subject: /CN=xxx, issuer: /CN=xxx TLS certificate verification: Error, unable to get local issuer certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed (unable to get local issuer certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Even setting TLS_CACERT does not fix it, only making TLS_REQCERT never TLS_CACERTDIR has pem certificates and links with them with hashes ktrace does not show any reads on TLS_CACERTDIR bbbf0019.0@ -> My_ROOT_CA.asc My_ROOT_CA.asc@ -> My_ROOT_CA.pem Apparently this also breaks freeradius which seems logical. Thanks, G There were big changes in certificate validation in libressl a little before 6.8 and various problems have been found with them. I added a workaround for one issue in a -stable packages update to openldap, some are fixed in libressl in -current, and workarounds for some ports have been made by changing them to use openssl instead of libressl. Your best option is probably to run -current and report back if there are still problems and then hopefully 6.9 will be better. Yes, after upgrading to -current both problems where fixed (before pkg_add -u) thanks, G
Re: 6.8 openldap and SSL/TLS problem after upgrade
I'm replying in misc@ since it affects other people as well. For freeradius (freeradius-2.2.10p1) and ldap communication I had to also set require_cert = "allow" It didn't respect the setting of /etc/openldap/ldap.conf Maybe it's now linked against local ldap library and not openldap's ? G On 22/12/2020 16:59, Kostya Berger wrote: Wow, I seem to have the same problem with Freeradius. Fails to connect with the same error: unable to get local issuer certificate. And that with certificates that work FINE with exactly the same version of Freeradius in FreeBSD. And yes, no additional setting seem to help this. With kindest regards, Kostya Berger On Tuesday, 22 December 2020, 17:52:48 GMT+3, Kapetanakis Giannis wrote: Hi, After upgrading to 6.8-release I can no longer connect to my ldap server with openldap and SSL/TLS. I'm using a self signed root CA to sign LDAP server's certificate. /etc/openldap/ldap.conf has: TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT demand # /usr/local/bin/ldapsearch -d9 -x (openldap client) TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 20, subject: /CN=xxx, issuer: /CN=xxx TLS certificate verification: Error, unable to get local issuer certificate TLS certificate verification: depth: 1, err: 20, subject: /CN=xxx, issuer: /CN=xxx TLS certificate verification: Error, unable to get local issuer certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed (unable to get local issuer certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Even setting TLS_CACERT does not fix it, only making TLS_REQCERT never TLS_CACERTDIR has pem certificates and links with them with hashes ktrace does not show any reads on TLS_CACERTDIR bbbf0019.0@ -> My_ROOT_CA.asc My_ROOT_CA.asc@ -> My_ROOT_CA.pem Apparently this also breaks freeradius which seems logical. Thanks, G
6.8 openldap and SSL/TLS problem after upgrade
Hi, After upgrading to 6.8-release I can no longer connect to my ldap server with openldap and SSL/TLS. I'm using a self signed root CA to sign LDAP server's certificate. /etc/openldap/ldap.conf has: TLS_CACERTDIR /etc/openldap/cacerts TLS_REQCERT demand # /usr/local/bin/ldapsearch -d9 -x (openldap client) TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 20, subject: /CN=xxx, issuer: /CN=xxx TLS certificate verification: Error, unable to get local issuer certificate TLS certificate verification: depth: 1, err: 20, subject: /CN=xxx, issuer: /CN=xxx TLS certificate verification: Error, unable to get local issuer certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed (unable to get local issuer certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Even setting TLS_CACERT does not fix it, only making TLS_REQCERT never TLS_CACERTDIR has pem certificates and links with them with hashes ktrace does not show any reads on TLS_CACERTDIR bbbf0019.0@ -> My_ROOT_CA.asc My_ROOT_CA.asc@ -> My_ROOT_CA.pem Apparently this also breaks freeradius which seems logical. Thanks, G
Re: 6.7 upgrade problem
I've managed to track this a little bit further. Boot stop and waits until I connect to the server's java console on the iRMC. Upon connect, even with wrong username/password virtual keyboard is attached and boot continues. There seems to be some kind of infinite loop... I've checked various options on BIOS trying to match them with a same server that boots fine, but could not make it boot. Both servers have same iRMC firmware version. Server that does not boot has latest BIOS, where the one that boots has a previous one (both very old). With OpenBSD 6.6 I didn't had that problem. Here is the dmesg. I've commented inline when the boot stops. OpenBSD 6.7-current (GENERIC.MP) #369: Thu Jul 23 13:41:41 MDT 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4234805248 (4038MB) avail mem = 4091396096 (3901MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xbf6c8000 (92 entries) bios0: vendor FUJITSU // Phoenix Technologies Ltd. version "6.00 Rev. 1.10.3031" date 01/20/2012 bios0: FUJITSU PRIMERGY RX200 S6 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP TCPA SLIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT EINJ HEST BERT SSDT ERST SPCR MCFG HPET APIC BOOT acpi0: wakeup devices PE0_(S4) PE1_(S4) PE3_(S4) PE7_(S4) PE9_(S4) PE1A(S4) USB1(S1) USB2(S1) USB3(S1) USB4(S1) USB5(S1) USB6(S1) USB7(S1) USB8(S1) COM1(S1) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-9 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 32 (boot processor) cpu0: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.48 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 1 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 34 (application processor) cpu1: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 1 cpu2 at mainbus0: apid 36 (application processor) cpu2: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 1 cpu3 at mainbus0: apid 48 (application processor) cpu3: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 8, package 1 cpu4 at mainbus0: apid 50 (application processor) cpu4: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 cpu4: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 9, package 1 cpu5 at mainbus0: apid 52 (application processor) cpu5: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 cpu5: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu5: 256KB 64b/line 8-way L2 cache cpu5: smt 0, core 10, package 1 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 1 pa 0xfec8, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0:
Re: Fixed IP address for vmd dedicated VMs from dhcpd every boot/reboot
On 25/07/2020 11:28, Martin wrote: Hi, Sometimes dedicated VMs need fixed (the same) IP address assigned by dhcpd every run. I don't know how to achieve this by dhcpd configured. Every VM reboot it gets different IP. OpenBSD guests changes their IPs even without reboot, right in runtime. For instance I need to assign these IP addresses to VMs every run to dedicated VMs by dhcpd: OpenBSD obsd0.qcow2 10.0.1.12 OpenBSD obsd1.qcow2 10.0.1.13 OpenBSD obsd2.qcow2 10.0.1.14 Linux lin0.qcow2 10.0.1.22 Linux lin1.qcow2 10.0.1.23 It looks like MAC of guests changed every boot, so dhcpd assigned different IP address from the pool every boot/reboot. Please advice any way how to fix it. Thank you for answer in advance. Martin Not familiar at all with VMM but vm.conf(5) says: [locked] lladdr [etheraddr] Change the link layer address (MAC address) of the interface on the VM guest side. If not specified, a randomized address will be assigned by vmd(8). If the locked keyword is specified, vmd(8) will drop packets from the VM with altered source addresses. dhcpd.conf(5) also has examples on how to assign same IP per host MAC G
Re: relayd multiple listen on same redirect
On 04/07/2020 14:59, Brian Brombacher wrote:
On Jul 3, 2020, at 3:34 AM, Kapetanakis Giannis
wrote:
Hi,
My setup in relayd is like this:
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
redirect radacct {
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
I want to combine it in one redirect but the redirect forwards it to the first
port defined in listen for both radius and radacct ports.
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
Is there another way to do this or do I have to stick with two redirects?
thanks,
Giannis
Hi Giannis,
I have not tested your config or my advice for your config; however, my
assumptions are sticky-address is needed per udp port conversation for radius.
By contrast, if sticky was needed for the combination of both radius/radacct on
same backend host per source address or address/port, you cannot achieve that
reliably with least-states. I don’t know the radius protocols enough to know
the requirements.
Here’s my question after all that dribbling:
Have you tried using either of the following config options?
forward to destination
forward to nat
IIRC, in the past I had multiple TCP relay ports going to their specified ports
on the backend. I only needed to split things by address family (v4/6) for my
own purposes. I cannot remember if the directives above took port into
consideration. It might not be a far stretch to make that feasible with code
changes but I haven’t seen the relayd code paths in question so that’s a
complete guess (but I’m on my way to check ;). Also since I concentrated on
TCP relays, I don’t know how effective these directives would be for redirects.
My end config has separate relays per TCP service except passive FTP relaying.
Also, make sure your pf.conf has the right anchor. Only mentioning it because
your original email skips this detail. I doubt this would be missing if you
have a working setup already, so ignore if so.
Cheers,
Brian
Thanks for the answer Brian,
You 're probabaly right and least-states might not be the best choice.
My setup is a working one, but it only has one server (for now) in the
backend table so this hasn't come up so far.
I guess the best one would be
mode source-hash [key]
least-states [sticky-address]
The least-states option selects the address with the least active
states from a given address pool and considers given weights
associated with address(es). Weights can be specified between 1
and 65535. Addresses with higher weights are selected more often.
sticky-address can be specified to ensure that multiple connections
from the same source are mapped to the same redirection address.
Associations are destroyed as soon as there are no longer states
which refer to them; in order to make the mappings last beyond the
lifetime of the states, increase the global options with set
timeout src.track.
source-hash [key] [sticky-address]
The source-hash option uses a hash of the source address to
determine the redirection address, ensuring that the redirection
address is always the same for a given source. An optional key can
be specified after this keyword either in hex or as a string; by
default pfctl(8) randomly generates a key for source-hash every
time the ruleset is reloaded. sticky-address is as described
above.
G
relayd multiple listen on same redirect
Hi,
My setup in relayd is like this:
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
redirect radacct {
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
I want to combine it in one redirect but the redirect forwards it to the first
port defined in listen for both radius and radacct ports.
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
Is there another way to do this or do I have to stick with two redirects?
thanks,
Giannis
Re: Ynt: Disabling OpenBSD Login Prompt
On 10/06/2020 12:52, Valdrin MUJA wrote: > Sorry for lack of information, > > Firstly, my program is a kind of interactive shell which has own login > prompt. What I want to do is run my program on startup and do not use OpenBSD > login prompt. > > When I use "chsh", firstly OpenBSD Login Prompt appearing, after that my > program is running and my program's login prompt appearing. > > Lastly, I tried to update /etc/ttys and replace getty with my program to > disable OpenBSD login prompt and run my program. However, obviously this > didn't work. > > In short, I want to disable OpenBSD Login prompt and run my program. So login shell (chsh) has nothing to do with this. Shell is executed after login which is executed after getty. /etc/ttys needs to be changed. reboot after that. But why do you want to change the default getty login? If you just want to change what is displayed you can probably create a custom entry in /etc/gettytab. Also there is /etc/motd for custom messages after login, as another user said. Does your program handling terminal correctly? Does it handle login in a secure way? R u sure? G
Re: Disabling OpenBSD Login Prompt
On 10/06/2020 12:03, Valdrin MUJA wrote: > Hi Misc, > > I want to disable OpenBSD Login prompt at startup -and also after logging > out-. Because I want to run my external program instead of ksh. There is an > login prompt also in my program and I want to use it. > > I updated the /etc/ttys ; > > valdrin# cat /etc/ttys > # > # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ > # > # name getty typestatus comments > # > console "/usr/libexec/getty std.9600" vt220 off secure > ttyC0 "/usr/libexec/getty std.9600" vt220 on secure > ttyC1 "/usr/libexec/getty std.9600" vt220 on secure > ttyC2 "/usr/libexec/getty std.9600" vt220 on secure > ttyC3 "/usr/libexec/getty std.9600" vt220 on secure > ttyC4 "/usr/libexec/getty std.9600" vt220 off secure > ttyC5 "/usr/libexec/getty std.9600" vt220 on secure > ttyC6 "/usr/libexec/getty std.9600" vt220 off secure > ttyC7 "/usr/libexec/getty std.9600" vt220 off secure > ttyC8 "/usr/libexec/getty std.9600" vt220 off secure > ttyC9 "/usr/libexec/getty std.9600" vt220 off secure > ttyCa "/usr/libexec/getty std.9600" vt220 off secure > ttyCb "/usr/libexec/getty std.9600" vt220 off secure > tty00 "/root/myprogram" vt220on secure > tty01 "/usr/libexec/getty std.9600" unknown off > tty02 "/usr/libexec/getty std.9600" unknown off > tty03 "/usr/libexec/getty std.9600" unknown off > tty04 "/usr/libexec/getty std.9600" unknown off > tty05 "/usr/libexec/getty std.9600" unknown off > tty06 "/usr/libexec/getty std.9600" unknown off > tty07 "/usr/libexec/getty std.9600" unknown off > > I'm connected the device with com0 port so I updated the tty00 to run my > external program. However; system is stucking after date appears on startup. > > > starting network > reordering libraries: done. > starting early daemons: syslogd ntpd. > starting RPC daemons:. > savecore: no core dump > checking quotas: done. > clearing /tmp > kern.securelevel: 0 -> 1 > creating runtime link editor directory cache. > preserving editor files. > starting network daemons: sshd. > starting local daemons: cron. > Wed Jun 10 10:27:04 +03 2020 > > > Also, I tried "chsh" and "chpass" , but still OpenBSD login prompt appears.. > How can I overcome this issue? > > Thanks.. Since you're mixing login prompt (getty) with login shell (ksh) and since you don't provide info about "yourprogram" I believe that maybe you you've mixing things up? If you want to change a user's login shell, chsh(1) should be used. This specifies what shell is run for that user after login is successful. getty(8) is controlled by /etc/ttys - ttys(5) and has nothing to do with user login shell. read the man pages. G
Re: 6.7 upgrade problem
iide1: using apic 0 int 17 for native-PCI interrupt atapiscsi0 at pciide1 channel 1 drive 0 scsibus3 at atapiscsi0: 2 targets cd0 at scsibus3 targ 0 lun 0: removable cd0(pciide1:1:0): using PIO mode 4, Ultra-DMA mode 5 usb2 at uhci0: USB revision 1.0 uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci1: USB revision 1.0 uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb4 at uhci2: USB revision 1.0 uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb5 at uhci3: USB revision 1.0 uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb6 at uhci4: USB revision 1.0 uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb7 at uhci5: USB revision 1.0 uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pcppi0 at isa0 port 0x61 spkr0 at pcppi0 G On 09/06/2020 14:32, Kapetanakis Giannis wrote: > Hi, > > I'm trying to update a Fujitsu RX200 S6 server from 6.6->6.7 and I'm having > problems. > > via sysupgrade boot of upgrade kernel stops (no hung, no ddb) at > > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com0: console > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > pcppi0 at isa0 port 0x61 > > With manual upgrade process it stops later at > pchb24 at pci11 dev 6 function 3 vendor "Intel", unknown product 0x2db3 rev > 0x02 > > just before: > uhidev0 at uhub7 port 2 configuration 1 interface 0 "Dell Dell USB Keyboard" > rev 1.10/3.06 addr 2 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd0 at ukbd0: console keyboard, using wsdisplay0 > vscsi0 at root > scsibus4 at vscsi0: 256 targets > softraid0 at root > scsibus5 at softraid0: 256 targets > root on sd0a (190c023894b4.a) swap on sd0b dump on sd0b > > could it be the raid controller? > > I cannot even boot /obsd with 6.6 kernel (Bad system call) so i'm stack. > > I've tried disabling > > wskbd, ukbd, uhidev, pcppi, pckbc, usb without luck. > > Console is via ipmi but even if I turn it to my kvm i have the same problem. > > any ideas? > > Thanks, > > Giannis > > OpenBSD 6.6 (GENERIC.MP) #0: Thu Jun 4 16:25:00 MDT 2020 > > t...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 4234805248 (4038MB) > avail mem = 4093743104 (3904MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xbf6c8000 (92 entries) > bios0: vendor FUJITSU // Phoenix Technologies Ltd. version "6.00 Rev. > 1.06.3031" date 12/14/2010 > bios0: FUJITSU PRIMERGY RX200 S6 > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP TCPA SLIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT > SSDT SSDT SSDT SSDT EINJ HEST BERT SSDT ERST SPCR MCFG HPET APIC BOOT > acpi0: wakeup devices PE0_(S4) PE1_(S4) PE3_(S4) PE7_(S4) PE9_(S4) PE1A(S4) > USB1(S1) USB2(S1) USB3(S1) USB4(S1) USB5(S1) USB6(S1) USB7(S1) USB8(S1) > COM1(S1) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-9 > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 32 (boot processor) > cpu0: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.54 MHz, 06-2c-02 > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: smt 0, core 0, package 1 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 133MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 34 (application processor) > cpu1: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 1 > cpu2 at mainbus0: apid 36 (application processor) > cpu2: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-
6.7 upgrade problem
Hi, I'm trying to update a Fujitsu RX200 S6 server from 6.6->6.7 and I'm having problems. via sysupgrade boot of upgrade kernel stops (no hung, no ddb) at com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pcppi0 at isa0 port 0x61 With manual upgrade process it stops later at pchb24 at pci11 dev 6 function 3 vendor "Intel", unknown product 0x2db3 rev 0x02 just before: uhidev0 at uhub7 port 2 configuration 1 interface 0 "Dell Dell USB Keyboard" rev 1.10/3.06 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 variable keys, 6 key codes wskbd0 at ukbd0: console keyboard, using wsdisplay0 vscsi0 at root scsibus4 at vscsi0: 256 targets softraid0 at root scsibus5 at softraid0: 256 targets root on sd0a (190c023894b4.a) swap on sd0b dump on sd0b could it be the raid controller? I cannot even boot /obsd with 6.6 kernel (Bad system call) so i'm stack. I've tried disabling wskbd, ukbd, uhidev, pcppi, pckbc, usb without luck. Console is via ipmi but even if I turn it to my kvm i have the same problem. any ideas? Thanks, Giannis OpenBSD 6.6 (GENERIC.MP) #0: Thu Jun 4 16:25:00 MDT 2020 t...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4234805248 (4038MB) avail mem = 4093743104 (3904MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xbf6c8000 (92 entries) bios0: vendor FUJITSU // Phoenix Technologies Ltd. version "6.00 Rev. 1.06.3031" date 12/14/2010 bios0: FUJITSU PRIMERGY RX200 S6 acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP TCPA SLIT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT EINJ HEST BERT SSDT ERST SPCR MCFG HPET APIC BOOT acpi0: wakeup devices PE0_(S4) PE1_(S4) PE3_(S4) PE7_(S4) PE9_(S4) PE1A(S4) USB1(S1) USB2(S1) USB3(S1) USB4(S1) USB5(S1) USB6(S1) USB7(S1) USB8(S1) COM1(S1) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-9 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 32 (boot processor) cpu0: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.54 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 1 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 34 (application processor) cpu1: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 1 cpu2 at mainbus0: apid 36 (application processor) cpu2: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 1 cpu3 at mainbus0: apid 48 (application processor) cpu3: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 8, package 1 cpu4 at mainbus0: apid 50 (application processor) cpu4: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 cpu4: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,POPCNT,AES,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,MELTDOWN cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 9, package 1 cpu5 at mainbus0: apid 52 (application processor) cpu5: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz, 2800.11 MHz, 06-2c-02 cpu5: 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
Re: Article OpenBSD: Not Free Not Fuctional and Definetly Not Secure and BSD, the truth blog
On 28/05/2020 07:16, Quantum Robin wrote: Hi, While surfing on the Google to learn more about OpenBSD, I encountered this one: "OpenBSD: Not Free Not Fuctional and Definetly Not Secure ( https://aboutthebsds.wordpress.com/2013/01/25/20/) Is the author telling the truth? Or just yet another anti-BSD thing? why the fuck do you spam our mailboxes with some random shit you found on the internet, which is 7+ years ago? Do your research. G ps. shit, over the years this list is infecting my attitude.
Re: upgrade 6.6 -> 6.7
On 20/05/2020 11:23, Henrik Krysteli Semark wrote: > Did the same on my edge firewalls two days ago, with sysupgrade. > > It just works flawlessly! > +1 G
Re: 6.6 pflow IPFIX removed?
On 04/03/2020 18:35, Florian Obser wrote: > The ifconfig option parser is... special. > You must set flowdst as well as pflowproto. my bad. the problem was the src IP which was changed and the change wasn't reflected in the hostname.pflow0 sorry for the noise G
6.6 pflow IPFIX removed?
Hi, Is IPFIX removed from pflow in 6.6? # ifconfig pflow0 pflowproto 10 ifconfig: SIOCSETPFLOW: Can't assign requested address pflow(4) still mentions it. regards, Giannis
Re: route an IPv4 /32 to a different interface
On 15/12/2019 21:57, Denis Fondras wrote: Hi, I have this setup : em3: flags=8843 mtu 1500 lladdr index 4 priority 0 llprio 3 media: Ethernet autoselect (1000baseSX full-duplex) status: active inet6 fe80::aa9:b803:8a7a:ca72%em3 prefixlen 64 scopeid 0x4 inet 172.16.0.254 netmask 0xff00 broadcast 172.16.0.255 em4: flags=8843 mtu 1500 lladdr index 5 priority 0 llprio 3 media: Ethernet autoselect (1000baseSX full-duplex) status: active inet 172.16.0.249 netmask 0xfffc broadcast 172.16.0.251 inet6 fe80::29ae:98d:f238:fd68%em4 prefixlen 64 scopeid 0x5 I have a computer with IPv4 address 172.16.0.248 connected to em3. When I try to ping it, obviously it goes to em4. How can I route 172.16.0.248 through em3 ? I tried with : * route add 172.16.0.248/32 172.16.0.254 -iface em3 * route add 172.16.0.248/32 -llinfo -link -static -iface em3 but without luck. Thank you in advance, Denis You can do this with pf route-to G
Re: LDAP tls: handshake failure
On 23/10/2019 19:14, Predrag Punosevac wrote:
> Hi Misc,
>
> I just upgraded a LDAP server from 6.5 to 6.6 running authorization and
> authentication services for a 100 some member university research group.
> It appears TLS handshake is broken. This worked perfectly on 6.5 and
> earlier.
>
> titan# uname -a
> OpenBSD titan.int.autonlab.org 6.6 GENERIC.MP#372 amd64
>
> I am using LDAP daemon from the base
>
> titan# more /etc/ldapd.conf
> # $OpenBSD: ldapd.conf,v 1.1 2014/07/11 21:20:10 deraadt Exp $
>
> schema "/etc/ldap/core.schema"
> schema "/etc/ldap/inetorgperson.schema"
> schema "/etc/ldap/nis.schema"
>
> listen on lo0 tls certificate titan
> listen on em0 tls certificate titan
> listen on "/var/run/ldapi"
>
> namespace "dc=autonlab,dc=org" {
> rootdn "cn=admin,dc=autonlab,dc=org"
> rootpw "{SSHA}secret"
> index sn
> index givenName
> index cn
> index mail
> }
>
>
> Server certificate is regenerated and signed by my own certification of
> authority which is on the different machine. I used easy-rsa just like
> for one of my OpenBSD server.
>
>
> This is the configuration of openldap-client on the LDAP server itself
> which is used to modify database
>
> titan# pkg_info |grep openldap
> openldap-client-2.4.48 open-source LDAP software (client)
> openldap-server-2.4.48 open-source LDAP software (server)
>
> titan# more ldap.conf
> BASEdc=autonlab,dc=org
> URI ldap://titan.int.autonlab.org:389
>
> SIZELIMIT 12
> TIMELIMIT 15
> DEREF never
>
> SSL START_TLS
> TLS_REQCERT demand
>
> TLS_CACERT /etc/ldap/certs/ca.crt
> TLS_CERT/etc/ldap/certs/titan.crt
> TLS_CACERTDIR /etc/ldap/certs
> TLS_CIPHER_SUITE
> ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL
> TLS_PROTOCOL_MIN 3.3
>
> I didn't change DNS settings and I even have
>
> titan# more /etc/hosts
> 127.0.0.1 localhost
> ::1 localhost
> 192.168.6.1 titan.int.autonlab.org titan
>
>
> I would appreciate any clues.
>
> Cheers,
> Predrag Punosevac
>
>
>
ldapsearch -d9 might give some hint.
openssl s_client -connect titan.int.autonlab.org:389 -starttls ldap
might also give something.
G
relayd feature request
Hi, Today I found out that I was able to disable/enable hosts by name instead of id :) It would be nice if it worked when a host is mentioned in multiple redirects/tables (ie different ports): Id Type Name Avlblty Status 3 redirect mx-smtps active 3 table mx:465 active (2 hosts) 5 host mx1 100.00% up 6 host mx2 100.00% up 4 redirect mx-subm active 4 table mx:587 active (2 hosts) 7 host mx1 100.00% up 8 host mx2 100.00% up right now, relayctl host dis/en mx1, disables/enables it only in the first redirect. I've looked at the code but didn't find a clean way to make it happen... thanks in advance G
Re: ospf point to point network
On 23/06/2019 19:39, Stuart Henderson wrote: On 2019-06-22, Henry Bonath wrote: What about GRE(4) with a Cisco router on the other end? /etc/hostname.gre123: 1.1.1.1 1.1.1.2 netmask 255.255.255.252 up tunnel IP.OF.OB.SD IP.OF.I.OS Cisco IOS: ! interface Tunnel123 ip address 1.1.1.2 255.255.255.252 tunnel source GigabitEthernet0/0/1 tunnel destination IP.OF.OB.SD tunnel mode gre ! That's likely to work, at the expense of reduced MTU. But is it really worth it? The main problem with ethernet interfaces and ospfd was a bug with DR elections but that has been fixed for a while now. Yes, broadcast type network works fine. I was just hoping getting rid of the whole election thing and maybe a faster ospf sum-up. thanks all for all the input, G
Re: ospf point to point network
On 21/06/2019 20:30, Stuart Henderson wrote: On 2019-06-21, Kapetanakis Giannis wrote: Hi, Can I get an update if point to point network support has been added in ospfd? Thanks G On 19/12/2014 12:54, Kapetanakis Giannis wrote: On 18/12/14 22:38, Stuart Henderson wrote: On 2014-12-17, Kapetanakis Giannis wrote: Hi, I'd like to ask if point-to-point support has been added in ospfd. I've read this http://marc.info/?l=openbsd-misc&m=136580208222751&w=2 but I cant seem to find relevant entries in the source tree so probably is still out? regards, Giannis No, diff didn't work so it wasn't added. Thanks for the update. G Nothing changed in that respect. (For the benefit of the archives and readers unfamiliar with the situation, point to point works fine on a point-to-point interface, this is about ospfd pretending that an ethernet interface is "point to point"). That is likely something that would be added to release notes if it was added. Thanks for the reply Stuart. Is there any "hack" I can do with all those pseudo-interfaces available in OB to full ospfd and do p2p? For instance ifconfig(8) has ptp options for bridge. A fellow reader of misc@ proposed gif(4), but my other end is a cisco router. best, G
Re: ospf point to point network
Hi, Can I get an update if point to point network support has been added in ospfd? Thanks G On 19/12/2014 12:54, Kapetanakis Giannis wrote: > On 18/12/14 22:38, Stuart Henderson wrote: >> On 2014-12-17, Kapetanakis Giannis wrote: >>> Hi, >>> >>> I'd like to ask if point-to-point support has been added in ospfd. >>> >>> I've read this >>> http://marc.info/?l=openbsd-misc&m=136580208222751&w=2 >>> >>> but I cant seem to find relevant entries in the source tree so probably >>> is still out? >>> >>> regards, >>> >>> Giannis >>> >>> >> No, diff didn't work so it wasn't added. >> > > Thanks for the update. > > G >
Re: PF firewall for desktop
On 28/05/2019 11:12, Janne Johansson wrote: > Den sön 26 maj 2019 kl 10:03 skrev Walt : > >> I like having a firewall that would pretty much require someone physically >> entering the computer room in order to attack the firewall. With OpenBSD, >> your firewall can control your network traffic without having an IP address >> at all. >> One thing that you could try is to use the OpenBSD VM as the firewall, but >> don't assign any IP address to the firewall. The Win7 VM would have the >> actual IP address, but the OpenBSD VM would control the network. >> I am curious if there is any way to attack the firewall if it has no IP >> addresses. >> > If you build it like the emails before listed, you still have the attack > surface of the whole OS that runs VirtualBox, then the whole codebase of > Virtualbox on top of that before you reach your obsd ip-less > un-maintainable VM to "protect you" from evil packets. In advance it's been mentioned many times is this list that bridge-only (IP-less) firewall is not a recommended setup. Start with this: https://marc.info/?l=openbsd-misc&m=124056858519840&w=2 I'm sure you will find valuable info there like the post from Henning@ (pf dev): "yes. lots of idiots do it. bridging is stupid. don't. there are cases where you can't avoid it, but deliberately? about as clever as knowingly drinking methanol." First of all it's harder to detect problems, configuration errors. There might be performance issues as well since you're utilizing the bridge interface (not sure if it's still a case) IP/routing adds another layer of protection. The packets must pass the network layer 3 of the firewall. Layer 2 attacks are not easy to protect from or even to detect sometimes. Not having an IP on the firewall is no better than having an IP firewall with no open services or no open services on the external interface. G
Re: override pexp var in rc scripts
Fixed it by deleting /var/run/rc.d/pmacctd G On 13/03/2019 11:24, Kapetanakis Giannis wrote: > Hi, > > I'm trying to create a rc file for pmacctd. I've defined the pexp var but for > some reason it is not working. > I'm probably missing something not obvious to me. > > #!/bin/sh > # > > daemon="/usr/local/sbin/pmacctd" > > . /etc/rc.d/rc.subr > > pexp="pmacctd: Core Process.*" > > rc_reload=NO > > rc_cmd $1 > > pexp seems fine to me: > > # pgrep -xf "pmacctd: Core Process.*" > 9005 > > # ps -x|grep pmac > 9005 ?? Rs/11:19.15 pmacctd: Core Process [default] (pmacctd) > 16732 ?? R/3 1:29.26 pmacctd: Netflow Probe Plugin [default_nfprobe] > (pmacctd) > > # cat /var/run/rc.d/pmacctd > daemon_class=daemon > daemon_flags=-f /etc/pmacct/pmacctd.conf > daemon_rtable=0 > daemon_timeout=30 > daemon_user=root > pexp=/usr/local/sbin/pmacctd -f /etc/pmacct/pmacctd.conf > > thanks for any input, > > G > > >
override pexp var in rc scripts
Hi, I'm trying to create a rc file for pmacctd. I've defined the pexp var but for some reason it is not working. I'm probably missing something not obvious to me. #!/bin/sh # daemon="/usr/local/sbin/pmacctd" . /etc/rc.d/rc.subr pexp="pmacctd: Core Process.*" rc_reload=NO rc_cmd $1 pexp seems fine to me: # pgrep -xf "pmacctd: Core Process.*" 9005 # ps -x|grep pmac 9005 ?? Rs/11:19.15 pmacctd: Core Process [default] (pmacctd) 16732 ?? R/3 1:29.26 pmacctd: Netflow Probe Plugin [default_nfprobe] (pmacctd) # cat /var/run/rc.d/pmacctd daemon_class=daemon daemon_flags=-f /etc/pmacct/pmacctd.conf daemon_rtable=0 daemon_timeout=30 daemon_user=root pexp=/usr/local/sbin/pmacctd -f /etc/pmacct/pmacctd.conf thanks for any input, G
Re: Keeping track of MAC addresses
On 20/02/2019 23:38, Henry Bonath wrote: > Not sure if this is what you are looking for, but I like Netdisco for this. > It uses SNMP to query network routers, switches, and access points, > and dumps out their TCAM as well as ARP tables into a Database in > order to preserve a history of not only what MAC Address was mapped to > what IP Address, but also what switchport or Access Point it was > attached to. > > It uses an external PostgreSQL Database, and is written in Perl. > As far as I know, it is not available in any Packaged form for > OpenBSD, but I assume is probably manually installable. > > It's great for tracking down if a device drops off the network, and > being able to track down where it last was plugged in. NAV is also an option https://nav.uninett.no/ G
Re: boot problems, nvme?
On 31/01/2019 15:57, kasak wrote: > 31.01.2019 15:18, Kapetanakis Giannis пишет: >> Hi, >> >> I've just installed current as well 6.4 on a new pc and I have problems >> booting it. >> >> Although I can boot bsd.rd and install system fine I cannot boot the normal >> kernel. >> Boot hungs after >> wskbd0 at pckbd0: console keyboard, using wsdisplay1 >> >> In bsd.rd next line is >> softraid0 at root >> >> I couldn't transfer the dmesg from bsd.rd so I took pictures of it. >> Maybe someone can have a look? >> https://nefeli.cc.uoc.gr/index.php/s/ce6hAZzTWPcNOLu >> >> thanks >> >> G > > I can advice you to try to disable pcppi driver. > > boot -c > > disable pcppi > > quit > > What motherboard you own? Thanks that worked. hw.vendor=Gigabyte Technology Co., Ltd. hw.product=Z370 HD3P is this a bug? G
boot problems, nvme?
Hi, I've just installed current as well 6.4 on a new pc and I have problems booting it. Although I can boot bsd.rd and install system fine I cannot boot the normal kernel. Boot hungs after wskbd0 at pckbd0: console keyboard, using wsdisplay1 In bsd.rd next line is softraid0 at root I couldn't transfer the dmesg from bsd.rd so I took pictures of it. Maybe someone can have a look? https://nefeli.cc.uoc.gr/index.php/s/ce6hAZzTWPcNOLu thanks G
Re: syspatch, relink and kernel version/date
On 20/12/2018 18:58, lists+m...@ggp2.com wrote:
> I can't confirm, but I think I noticed this on a box that was using the
> MP kernel even though it was an SP machine.
You are right. It is a single cpu machine running MP kernel.
So is this patched or not?
G
> On Thu, Dec 20, 2018 at 12:14:14PM +0200, Kapetanakis Giannis wrote:
>> Hi,
>>
>> I'm a bit confused about syspatch and kernel updates. One of machines after
>> latest syspatch (009) and after reboot it lists old kernel date.
>>
>> This happens only on this machine. I've seen it happen before, not sure if
>> it was on the same one or some other box.
>>
>> machine1:
>> # syspatch -l
>> 001_xserver
>> 002_syspatch
>> 003_portsmash
>> 004_lockf
>> 005_perl
>> 006_uipc
>> 007_smtpd
>> 008_qcow2
>> 009_recvwait
>>
>> # uname -prsv
>> OpenBSD 6.4 GENERIC.MP#364 amd64
>>
>> # sysctl kern.version
>> kern.version=OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018
>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>
>> machine2:
>> # syspatch -l
>> 001_xserver
>> 002_syspatch
>> 003_portsmash
>> 004_lockf
>> 005_perl
>> 006_uipc
>> 007_smtpd
>> 008_qcow2
>> 009_recvwait
>>
>> # uname -prsv
>> OpenBSD 6.4 GENERIC.MP#2 amd64
>>
>> # sysctl kern.version
>> kern.version=OpenBSD 6.4 (GENERIC.MP) #2: Tue Dec 18 13:17:16 CET 2018
>>
>> r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>>
>> on machine1 relink.log seems fine:
>> # cat /usr/share/relink/kernel/GENERIC.MP/relink.log
>> (SHA256) /bsd: OK
>> LD="ld" sh makegap.sh 0x
>> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
>> ${OBJS}
>> textdatabss dec hex
>> 104959482796320 671744 13964012d512ec
>> mv newbsd newbsd.gdb
>> ctfstrip -S -o newbsd newbsd.gdb
>> mv -f newbsd bsd
>> umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h
>> /var/db/kernel.SHA256 /bsd
>>
>> Kernel has been relinked and is active on next reboot.
>>
>> SHA256 (/bsd) =
>> 8b216c359324a4a938bd35c2c97416b62ffec8c8b955f8b86d65ddf9dc0d71b1
>>
>> Also /bsd has newer date so it seems updated.
>> # ls -ld /bsd
>> -rwx-- 1 root wheel 15461926 Dec 19 10:04 /bsd*
>>
>> # ls -ld /usr/share/relink/kernel/GENERIC.MP/relink.log
>> -rw-r--r-- 1 root wheel 486 Dec 19 10:04
>> /usr/share/relink/kernel/GENERIC.MP/relink.log
>>
>> can someone explain this?
>>
>> thanks
>>
>> G
>>
>
syspatch, relink and kernel version/date
Hi,
I'm a bit confused about syspatch and kernel updates. One of machines after
latest syspatch (009) and after reboot it lists old kernel date.
This happens only on this machine. I've seen it happen before, not sure if it
was on the same one or some other box.
machine1:
# syspatch -l
001_xserver
002_syspatch
003_portsmash
004_lockf
005_perl
006_uipc
007_smtpd
008_qcow2
009_recvwait
# uname -prsv
OpenBSD 6.4 GENERIC.MP#364 amd64
# sysctl kern.version
kern.version=OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
machine2:
# syspatch -l
001_xserver
002_syspatch
003_portsmash
004_lockf
005_perl
006_uipc
007_smtpd
008_qcow2
009_recvwait
# uname -prsv
OpenBSD 6.4 GENERIC.MP#2 amd64
# sysctl kern.version
kern.version=OpenBSD 6.4 (GENERIC.MP) #2: Tue Dec 18 13:17:16 CET 2018
r...@syspatch-64-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
on machine1 relink.log seems fine:
# cat /usr/share/relink/kernel/GENERIC.MP/relink.log
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0x
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
104959482796320 671744 13964012d512ec
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
mv -f newbsd bsd
umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h /var/db/kernel.SHA256
/bsd
Kernel has been relinked and is active on next reboot.
SHA256 (/bsd) = 8b216c359324a4a938bd35c2c97416b62ffec8c8b955f8b86d65ddf9dc0d71b1
Also /bsd has newer date so it seems updated.
# ls -ld /bsd
-rwx-- 1 root wheel 15461926 Dec 19 10:04 /bsd*
# ls -ld /usr/share/relink/kernel/GENERIC.MP/relink.log
-rw-r--r-- 1 root wheel 486 Dec 19 10:04
/usr/share/relink/kernel/GENERIC.MP/relink.log
can someone explain this?
thanks
G
Re: bind and error sending response: would block
On 19/11/2018 12:30, Stuart Henderson wrote: > On 2018-11-16, Kapetanakis Giannis wrote: >> Hi, >> >> after upgrading one of my bind (cache resolver) machines to 6.4 (release) >> I'm getting these errors quite often: >> >> Nov 16 15:55:14 server named[30616]: client: warning: client @0x6591da02440 >> xxx.xxx.xxx.xxx#39702 (a1928.d.akamai.net): error sending response: would >> block >> >> https://kb.isc.org/docs/aa-00717 >> it's either EWOULDBLOCK or EAGAIN errors. >> >> I've tried playing with -U and -n settings. >> Setting -n 1 (one cpu/core) solves the problem >> >> Ideally I would set it to -n 8 -U 8 >> >> any ideas? > > > Maybe try raising sysctl net.inet.udp.sendspace? > I've increased it to 41600 (same as recv), 131072, 1048576 without any change. Default is 9216 G
bind and error sending response: would block
Hi, after upgrading one of my bind (cache resolver) machines to 6.4 (release) I'm getting these errors quite often: Nov 16 15:55:14 server named[30616]: client: warning: client @0x6591da02440 xxx.xxx.xxx.xxx#39702 (a1928.d.akamai.net): error sending response: would block https://kb.isc.org/docs/aa-00717 it's either EWOULDBLOCK or EAGAIN errors. I've tried playing with -U and -n settings. Setting -n 1 (one cpu/core) solves the problem Ideally I would set it to -n 8 -U 8 any ideas? system is: isc-bind-9.11.4pl2 6.4 GENERIC.MP#364 amd64 hw.machine=amd64 hw.model=Intel(R) Xeon(R) CPU E5405 @ 2.00GHz hw.ncpu=8 hw.cpuspeed=1995 hw.vendor=Dell Inc. hw.product=PowerEdge 1950 hw.physmem=4273274880 hw.usermem=4273262592 hw.ncpufound=8 hw.smt=0 hw.ncpuonline=8 # netstat -m 57 mbufs in use: 42 mbufs allocated to data 11 mbufs allocated to packet headers 4 mbufs allocated to socket names and addresses 35/192 mbuf 2048 byte clusters in use (current/peak) 0/45 mbuf 2112 byte clusters in use (current/peak) 0/64 mbuf 4096 byte clusters in use (current/peak) 0/56 mbuf 8192 byte clusters in use (current/peak) 0/42 mbuf 9216 byte clusters in use (current/peak) 0/50 mbuf 12288 byte clusters in use (current/peak) 0/56 mbuf 16384 byte clusters in use (current/peak) 0/48 mbuf 65536 byte clusters in use (current/peak) 6016/6296/524288 Kbytes allocated to network (current/peak/max) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines # netstat -s udp: 2939445 datagrams received 0 with incomplete header 0 with bad data length field 0 with bad checksum 2251 with no checksum 620 input packets software-checksummed 1995 output packets software-checksummed 1327 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to missing IPsec protection 0 dropped due to full socket buffers 2938118 delivered 2964353 datagrams output 2133126 missed PCB cache thanks, G
Re: relayd and radius
On 19/10/18 21:01, Shawn Southern wrote:
> So apparently this works... I was expecting relayd to listen on those ports,
> but I'm guessing that since it hooks through pf, that's not necessary.
>
> -Original Message-
> From: owner-m...@openbsd.org On Behalf Of Shawn
> Southern
> Sent: October 19, 2018 1:00 PM
> To: misc@openbsd.org
> Subject: relayd and radius
>
> We have a lot of devices that use RADIUS, but they do not allow us to specify
> a 2nd RADIUS server. Since we use OpenBSD w/ CARP as our router/firewall, we
> want to use relayd to provide some redundancy for the RADIUS servers.
>
> There are two internal subnets - 10.10.10.0/24, which has our servers, and
> 10.10.11.0/24 that has the devices using RADIUS to authenticate clients.
> 10.10.10.1 and 10.10.11.1 are both carp interfaces.
>
> When starting relayd, nothing appears to be listening on the RADIUS ports.
> Is this even possible with relayd? Is my configuration just horribly wrong?
>
> relayd.conf:
> radius1 = "10.10.10.5"
> radius2 = "10.10.10.6"
> radius_listen = "10.10.11.1"
>
> table { $radius1 }
> table { $radius2 }
>
> redirect radius {
> listen on $radius_listen udp port 1812:1813
> forward to check icmp
> forward to check icmp
> }
>
> Thanks in advance for any help!
>
Yes, relayd adds rdr-to rules in pf. No port listening.
You should check your configuration
I believe it should be
table { $radius1, $radius2 }
and then on redirect: forward to check icmp
G
