relayd DSR carp failover
Hi,
I'm evaluating DSR with route to redirection on relayd on two carped boxes (kvm
VMs) with current.
Don't jump on me... The project is for a high volume download (http/ftp/rsync)
server (mostly mirror/isos, including OpenBSD) and it would be nice if the
streams are not get passed back through the load balancers.
The whole setup has another set of PF real boxes in front which is working fine.
I'm having problem when I do the failover from active LB to backup LB.
pfsync is working fine. I see the sloppy state syncing to backup LB.
wget/browser download from http is able to recover but with a hiccup
2017-05-25 11:33:28 (17.2 MB/s) - Read error at byte 31600632/2023751680
(Connection reset by peer). Retrying.
rsync fails completely after the failover to backup LB.
of course this is not the case with forward instead of route to where LB/router
sees all the traffic.
I guess this might be normal since the LB does not see the whole connection,
but maybe there is a way to make it work.
my setup is like this:
relayd (on rdomain9):
redirect ftp-www {
listen on $ftp_addr port http interface $ftp_if
pftag RELAYD_ftp-www
sticky-address
route to mode source-hash ftp check http "/foo.html" digest
9f50f9f6a6d05ebefd6e97b7444e51cc3aa3b8f7 interface vio1
}
pf:
pass quick on vio0 proto carp all keep state (no-sync)
pass quick on vio1 proto carp all keep state (no-sync)
pass quick on vio0 proto pfsync all keep state (no-sync)
anchor "relayd/*" all {
anchor "ftp-rsync" all {
pass in quick on vio1 on rdomain 9 inet proto tcp from any to $vip port =
873 flags any keep state (sloppy, tcp.established 600) tag RELAYD_ftp-rsync
route-to @vio1 source-hash 0xebfa1f07ddc8dc1f881b943a0a106721
sticky-address
}
anchor "ftp-www" all {
pass in quick on vio1 on rdomain 9 inet proto tcp from any to $vip port =
80 flags any keep state (sloppy, tcp.established 600) tag RELAYD_ftp-www
route-to @vio1 source-hash 0xebfa1f07ddc8dc1f881b943a0a106721
sticky-address
}
}
block drop all
pass out quick on vio0 from (vio0) to any flags S/SA keep state (no-sync)
pass out quick on vio1 from (vio1) to any flags S/SA keep state (no-sync)
match in all scrub (no-df random-id) #with or without
pass in quick from to any flags S/SA
block drop in log quick all
block drop out log quick all
suggestions?
thanks
Giannis
ps. I've read a couple of threads about this on the list, but I couldn't find a
positive answer.
ps2. tcpdump on pflog gives me wrong rules numbers when the relayd anchor is in
place, but this is another story
2017/06/29 - vlan(4)/svlan(4) ifconfig(8) changes
Following current on vlan change from vlan to vnetid, this is in quite some time now right? I see this https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_vlan.c?rev=1.161&content-type=text/x-cvsweb-markup which is Fri Apr 15 04:29:59 2016 Apparently the old configuration vlan N vlandev still works. Is the removal going to happen any time soon or after 6.2 ? regards, Giannis
Kernel relink failed
Hi, I've got this today after applying Jul 2 snapshot sha256: cannot open /var/db/kernel.SHA256: No such file or directory sha256: /bsd does not exist in /var/db/kernel.SHA256 upgrade was "without the install kernel" https://www.openbsd.org/faq/upgrade61.html#NoInstKern G
Re: Kernel relink failed
On 03/07/17 12:45, Paul de Weerd wrote: > On Mon, Jul 03, 2017 at 11:52:09AM +0300, Kapetanakis Giannis wrote: > | Hi, > | > | I've got this today after applying Jul 2 snapshot > | > | sha256: cannot open /var/db/kernel.SHA256: No such file or directory > | sha256: /bsd does not exist in /var/db/kernel.SHA256 > | > | upgrade was "without the install kernel" > | https://www.openbsd.org/faq/upgrade61.html#NoInstKern > > That is for moving from 6.0 to 6.1, for 6.1 to current snapshots, you > should add a step `sha256 /bsd > /var/db/kernel.SHA256` and reboot > (twice!). See this ( http://marc.info/?t=14980725022&r=1&w=2 ) > thread for some more details. > > Paul 'WEiRD' de Weerd I'm using the upgrade 6.0->6.1 just for the kernel info and untar (copy paste) Then I use -current info. Could you please add something about it in -current https://www.openbsd.org/faq/current.html So it should be something like this? #part1 put new kernels extract new .tgz #part2 sha256 -h /var/db/kernel.SHA256 /bsd cd /usr/share/compile/GENERIC.MP (replace kernel version here) make newbsd make newinstall reboot (once) I did #part2 after the upgrade ? G
dhcrelay broken after Apr 5
Hi, Just upgraded a set of my firewalls that also do dhcrelay to -current. The program stopped working ok. Some dhcp requests where being forwarded some not. tcpdump was showing the request on internal interface but I couldn't see the request being forwarded on the external interface. For some vlans the relay was working for some not. I've located the problem to this commit: http://marc.info/?l=openbsd-cvs&m=149140326301074&w=2 Reverting back to: bpf.c,v 1.17 packet.c,v 1.13 dhcpd.h,v 1.22 2017/04/04 everything was ok again. My setup is (trunk - on one firewall) - Vlans - carp - dhcrelay 28 vlans, 28 carps, 18 dhcrelay, 30 bpf devices regards, Giannis
Re: dhcrelay broken after Apr 5
On 04/07/17 19:09, Reyk Floeter wrote:
> First of all, please send a proper bug reports to bugs@, not misc.
> "It used to work but now it doesn't" is not very helpful.
>
> Could you share your actual configuration or, even better, provide a
> simplified way to reproduce your problem? rzalamena, me, and some
> other people have tested different setups but you seem to have an
> interestingly complex configuration.
>
> The new code has more validation, so it might be that it rightfully or
> wrongfully rejects packets that have been accepted before.
>
> Could you try again with the attached diff? It doesn't change
> behavior but it adds some chatty logging when a packet is rejected.
> Maybe it helps to find the issue.
>
> Reyk
Hi and thanks for the answer.
I would have send a better report if I could debug it.
-d does not produce any messages.
Also I'm not sure how to reproduce it. It just happened after the upgrade
and it happens in a random way... Not all users and not on all vlans.
I will try the patch and send a report to @bugs
G
> Index: usr.sbin/dhcrelay/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay/bpf.c,v
> retrieving revision 1.19
> diff -u -p -u -p -r1.19 bpf.c
> --- usr.sbin/dhcrelay/bpf.c 19 Apr 2017 05:36:12 - 1.19
> +++ usr.sbin/dhcrelay/bpf.c 4 Jul 2017 16:01:29 -
> @@ -349,11 +349,17 @@ send_packet(struct interface_info *inter
>
> /* Assemble the headers... */
> if ((bufp = assemble_hw_header(buf, sizeof(buf), 0, pc,
> - interface->hw_address.htype)) == -1)
> + interface->hw_address.htype)) == -1) {
> + log_warnx("%s:%d: assemble_hw_header failed, len %zu",
> + __func__, __LINE__, len);
> goto done;
> + }
> if ((bufp = assemble_udp_ip_header(buf, sizeof(buf), bufp, pc,
> - (unsigned char *)raw, len)) == -1)
> + (unsigned char *)raw, len)) == -1) {
> + log_warnx("%s:%d: assemble_udp_ip_header failed,"
> + " offset %zd len %zu", __func__, __LINE__, bufp, len);
> goto done;
> + }
>
> /* Fire it off */
> iov[0].iov_base = (char *)buf;
> @@ -447,6 +453,9 @@ receive_packet(struct interface_info *in
>* skip this packet.
>*/
> if (offset < 0) {
> + log_warnx("%s:%d: decode_hw_header failed,"
> + " len %zu", __func__, __LINE__,
> + interface->rbuf_len);
> interface->rbuf_offset += hdr.bh_caplen;
> continue;
> }
> @@ -457,6 +466,9 @@ receive_packet(struct interface_info *in
>
> /* If the IP or UDP checksum was bad, skip the packet... */
> if (offset < 0) {
> + log_warnx("%s:%d: decode_udp_ip_header failed,"
> + " offset %zd len %zu", __func__, __LINE__,
> + offset, interface->rbuf_len);
> interface->rbuf_offset += hdr.bh_caplen;
> continue;
> }
> @@ -470,6 +482,10 @@ receive_packet(struct interface_info *in
>* life, though).
>*/
> if (hdr.bh_caplen > len) {
> + log_warnx("%s:%d: XXX shouldn't happen in real life,"
> + " caplen %u > len %zu", __func__, __LINE__,
> + hdr.bh_caplen, len);
> +
> interface->rbuf_offset += hdr.bh_caplen;
> continue;
> }
> Index: usr.sbin/dhcrelay/packet.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay/packet.c,v
> retrieving revision 1.14
> diff -u -p -u -p -r1.14 packet.c
> --- usr.sbin/dhcrelay/packet.c5 Apr 2017 14:40:56 - 1.14
> +++ usr.sbin/dhcrelay/packet.c4 Jul 2017 16:01:29 -
> @@ -104,8 +104,12 @@ assemble_hw_header(unsigned char *buf, s
>
> switch (intfhtype) {
> case HTYPE_ETHER:
> - if (buflen < offset + ETHER_HDR_LEN)
> + if (buflen < offset + ETHER_HDR_LEN) {
> + log_warnx("%s:%d: short ether hdr buflen %zu < %zu",
> + __func__, __LINE__,
> + buflen, offset + ETHER_HDR_LEN);
> return (-1);
> + }
>
> /* Use the supplied address or let the kernel fill it. */
> memcpy(eh.ether_shost, pc->pc_smac, ETHER_ADDR_LEN);
> @@ -117,6 +121,8 @@ assemble_hw_header(unsigned char *buf, s
> offset += ETHER_HDR_LEN;
> break;
> default:
> + log_warnx("%s:%d: invalid htype %u", __func__, __LINE__,
> + intfhtype);
> return (-1);
> }
>
> @@ -130,8 +136,12 @@ assemble_udp_ip_header(unsigned char *bu
Re: dhcrelay broken after Apr 5
On 04/07/17 19:09, Reyk Floeter wrote: > Could you try again with the attached diff? It doesn't change > behavior but it adds some chatty logging when a packet is rejected. > Maybe it helps to find the issue. > > Reyk I've send the bug report as detailed as I could. In a few words, applying your diff gave me these: Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header failed, len 364 Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header failed, len 364 G
Re: dhcrelay broken after Apr 5
On 05/07/17 12:45, Reyk Floeter wrote: > >> On 05.07.2017, at 11:41, Kapetanakis Giannis >> wrote: >> >> On 04/07/17 19:09, Reyk Floeter wrote: >>> Could you try again with the attached diff? It doesn't change >>> behavior but it adds some chatty logging when a packet is rejected. >>> Maybe it helps to find the issue. >>> >>> Reyk >> >> I've send the bug report as detailed as I could. >> > > Thanks, now it is a good bug report and I think it helps to find the issue > with carp+dhcrelay. > > You had a typo in the email subject ;-) > >> In a few words, applying your diff gave me these: >> Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >> Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header >> failed, len 364 >> Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >> Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header >> failed, len 364 >> > > Reyk > oops :)) sorry for that, do you want me to send it again with the correct subject so it's archived ok? G
Re: Separate VLAN from untagged traffic.
On 07/07/17 15:35, Per-Olov Sjöholm wrote: > Hi > > I have config like this on an internal interface since 5 year back in time > that together with my VLAN enabled Cisco and Zyxel switches route traffic > around in my network. I run OpenBSD 6.0 AMD64 at the moment. > > cat /etc/hostname.em0 > —snip-- > up > ### VLAN > !ifconfig vlan2 inet 192.168.0.1 netmask 255.255.255.0 broadcast > 192.168.0.255 vlan 2 vlandev $if description "IP on FW to the LAN" > !ifconfig vlan3 inet 192.168.1.1 netmask 255.255.255.0 broadcast > 192.168.1.255 vlan 3 vlandev $if description "IP on FW to the DMZ1" > !ifconfig vlan4 inet 192.168.2.1 netmask 255.255.255.0 broadcast > 192.168.2.255 vlan 4 vlandev $if description "IP on FW to the DMZ2" > !ifconfig vlan1003 inet 192.168.42.1 netmask 255.255.255.0 broadcast > 192.168.42.255 vlan 1003 vlandev $if description "IP on FW to the GUEST" > ### ROUTES etc > #!route add 192.168.200.0/22 193.12.234.141 > !route add 172.31.128.0/23 192.168.1.25 > ### IPv6 > !ifconfig vlan2 inet6 alias 2001:470:dc5d:1::1 prefixlen 64 > !ifconfig vlan3 inet6 alias 2001:470:dc5d:2::1 prefixlen 64 > !ifconfig vlan4 inet6 alias 2001:470:dc5d:3::1 prefixlen 64 > —snip-- > > On the internet interface (em3) I have only an static IP. Today there is no > VLAN here. Just a plain internet connection and no VLAN tags from the ISP. > > > Now… > The provider allows me to skip the media hub they supplied in favour for me > taking care of the TV input myself. I have a mentally problem to take > internet directly into my switch and separate the VLAN there which I know > how to easily do. But one mistake in the conf and, well… > > So, in the near future the ISP will add a VLAN tag for TV in parallell to the > untagged internet traffic coming in to em3. > > > QUESTION: > How would I continue with the config I have and expand it to take the tagged > TV VLAN 845 they soon will add incoming to my em3 and bridge that VLAN tagged > TV traffic out on let say em2. The docs aren't that clear to me. The TV > traffic VLAN has no IP I can set. I just want to filter the TV VLAN out > incoming on em3 and send it to em2. How would I add a VLAN interface to a > parent em* interface and se no IP on it? After that I assume I can just > create a bridge between that VLAN interface and em2. Or is this a bad idea? > > > Thanks in advance. First of all, fix your setup to create vlan interfaces the proper way, ie /etc/hostname.vlanX much more clean setup. Do you have a switch right now connected to em3 which can do 802.1Q tagging? If yes, then use that for switching. There is not point passing the TV traffic through the OBSD. If not then use your OBSD box. more details depend on the configuration from your provider. I mean if the TV should get an IP address and if it expects tagged/untagged traffic. G
Re: WireGuard will make OpenIKED obsolete?
On 14/07/17 02:50, if...@airmail.cc wrote: > Hi, > I have recently read about WireGuard Protocol and it seems really > interesting. Here's a description (from wireguard.io): It's interesting indeed. In advance in their roadmap they say: "Eventually we'll work with OpenBSD to produce a component for their kernel ..." https://www.wireguard.io/roadmap/ G
Re: Read sysctl from file
On 20/07/17 18:48, Consus wrote: On 07:08 Thu 20 Jul, Kai Wetlesen wrote: Because it's a nice way to apply configuration changes made to /etc/sysctl.conf without restarting the whole server? Systemctl doesn't offer hot reload unless the controlled daemon offers the capability in the first place. The only thing systemd does is hits the controlling process on the head with a known conf-reload signal or (gasp) a DBus control statement. Both of these can be done just as well with an rc script, and without restarting the service. What systemd has to do with anything? We are talking about sysctl(8) and sysctl.conf(5). Guys, it's easy to emulate sysctl -p with a simple 4 line (maybe less) script. In advance, /etc/rc already does that. G
Re: Open /dev/mem file failed when running as a root priviledge
On 12/09/17 03:58, Nan Xiao wrote: > Hi all, > > Greetings from me! > > I want to run dmidecode (https://github.com/mirror/dmidecode) on OpenBSD > 6.1, but executing it will report following errors: I also need the output of dmidecode and I do the following in by boxes: /etc/rc.securelevel: if [[ -x /usr/local/sbin/dmidecode ]]; then /usr/local/sbin/dmidecode > /var/run/dmidecode.boot fi It runs the script at an early stage, before the change of kern.securelevel so access to /dev/mem is allowed. G
ping -R causes panic
I got this panic today after ping -R I don't run pfsync # ping -R www.google.com panic: kernel diagnostic assertion "m0->m_flags & M_PKTHDR" failed: file "/usr/src/sys/kern/uipc_mbuf.c", line 1344splassert: pfsync_update_state: want 1 have 256 pStopped at db_enter+0x5: popq%rbp TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *299140 12380 510x33 02 ping 422116 15532 0 0x14000 0x2001 softnet db_enter() at db_enter+0x5 panic() at panic+0x128 __assert(81020a74,80002692f4a0,0,1) at __assert+0x24 m_dup_pkt(ff010c77caf8,1,ff00baab064b) at m_dup_pkt+0x225 ip_pcbopts(1,ff00baab0600) at ip_pcbopts+0x138 sosetopt(ff010947b018,800026798d68,80002692f5f0,ff00baab0600) a t sosetopt+0xd0 sys_setsockopt(80002692f680,690,800026798d68) at sys_setsockopt+0x13d syscall() at syscall+0x270 --- syscall (number 105) --- end of kernel end trace frame: 0x7f7bf230, count: 7 0xc362b93239a: OpenBSD 6.2-beta (GENERIC.MP) #86: Sun Sep 10 10:07:51 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4273274880 (4075MB) avail mem = 4136747008 (3945MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcfb9c000 (67 entries) bios0: vendor Dell Inc. version "2.7.0" date 10/30/2010 bios0: Dell Inc. PowerEdge 1950 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET MCFG WD__ SLIC ERST HEST BERT EINJ TCPA acpi0: wakeup devices PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.26 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu0: 6MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 332MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.01 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.01 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu2: 6MB 64b/line 16-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz, 1995.01 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR cpu3: 6MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins , remapped to apid 4 acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (PEX2) acpiprt2 at acpi0: bus 5 (UPST) acpiprt3 at acpi0: bus 6 (DWN1) acpiprt4 at acpi0: bus 8 (DWN2) acpiprt5 at acpi0: bus 1 (PEX3) acpiprt6 at acpi0: bus -1 (PE2P) acpiprt7 at acpi0: bus 10 (PEX4) acpiprt8 at acpi0: bus -1 (PE2P) acpiprt9 at acpi0: bus 12 (PEX6) acpiprt10 at acpi0: bus 2 (SBEX) acpiprt11 at acpi0: bus 14 (COMP) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicpu2 at acpi0: C1(@1 halt!) acpicpu3 at acpi0: C1(@1 halt!) "PNP0C33" at acpi0 not configured "PNP0700" at acpi0 not configured "IPI0001" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 5000X Host" rev 0x12 ppb0 at pci0 dev 2 function 0 "Intel 5000 PCIE" rev 0x12 pci1 at ppb0 bus 4 ppb1 at pci1 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01 pci2 at ppb1 bus 5 ppb2 at pci2 dev 0 function 0 "Intel 6321ESB PCIE" rev 0x01 pci3 at ppb2 bus 6 ppb3 at pci3 dev 0 function 0 "ServerWorks PCIE-PCIX" rev 0xc3 pci4 at ppb3 bus 7 bnx0 at pci4 dev 0 function 0 "Broadcom BCM5708" rev 0x12: apic 4 int 16 ppb4 at pci2 dev 1 function 0 "Intel 6321ESB PCIE" rev 0x01 pci5 at ppb4 bus 8 ppb5 at pci1 dev 0 function 3 "Intel 6321ESB PCIE-PCIX" rev 0x01 pci6 at ppb5 bus 9 ppb6 at pci0 dev 3 function 0 "Intel 5000 PCIE" rev 0x12 pci7 at ppb6 bus 1 mpi0 at pci7 dev 0 function 0 "Symbios Logic SAS1068E" rev 0x08: msi mpi0: SAS6IR, firmware 0.25.47.0 scsibus1 a
Re: ping -R causes panic
On 20/09/17 19:25, Visa Hankala wrote: On Wed, Sep 20, 2017 at 02:26:56PM +0300, Kapetanakis Giannis wrote: I got this panic today after ping -R I don't run pfsync # ping -R www.google.com panic: kernel diagnostic assertion "m0->m_flags & M_PKTHDR" failed: file "/usr/src/sys/kern/uipc_mbuf.c", line 1344splassert: pfsync_update_state: want 1 have 256 pStopped at db_enter+0x5: popq%rbp TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *299140 12380 510x33 02 ping 422116 15532 0 0x14000 0x2001 softnet db_enter() at db_enter+0x5 panic() at panic+0x128 __assert(81020a74,80002692f4a0,0,1) at __assert+0x24 m_dup_pkt(ff010c77caf8,1,ff00baab064b) at m_dup_pkt+0x225 ip_pcbopts(1,ff00baab0600) at ip_pcbopts+0x138 sosetopt(ff010947b018,800026798d68,80002692f5f0,ff00baab0600) a t sosetopt+0xd0 sys_setsockopt(80002692f680,690,800026798d68) at sys_setsockopt+0x13d syscall() at syscall+0x270 --- syscall (number 105) --- end of kernel end trace frame: 0x7f7bf230, count: 7 Thank you for reporting this. A fix for the bug has been committed. Thanks for the quick fix :) tested and no more panic G
WPA2 and KRACK
As it seems, WPA2 should be considered broken [1] https://www.krackattacks.com/ [2] https://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt according to [1] OpenBSD has silently released a patch G
Re: WPA2 and KRACK
On 17/10/17 13:27, Christoph R. Murauer wrote: > See https://marc.info/?l=openbsd-misc&m=150814941311682&w=2 > > Use the search box for the mailing list - saves you time. thanks, didn't follow that. G
Re: Dell PowerEdge R430/R440 support
On 25/04/18 13:22, Jan Vlach wrote: > Hello misc, > > has anybody Dell PowerEdge R430 or E440 running with OpenBSD? Is the > hardware supported? > > I can't really get the exact chipsets from vendor to cross check with > drivers in OpenBSD and I can't find dmesg or mention anywhere. (Checked > dmesgd.nycbug.org, archives and google generally) > > I would like to have OpenBSD softraid RAID1 with 3 SSD drives, but I'm > not sure what controllers are supported. > > > Vendor states these storage controllers for R440: > PERC H330, H730p, H740p, HBA330, Software RAID (SWRAID) S140 > > R430: > HBA330/H330/H730/H730P > > The chipset is should be C620 for R440 and C610 for R430. > > I have no idea what the chip for ethernet is. > > Any hints, please, what should/would work? I intend to share dmesg to dmesg@ > and nycbug's dmesgd. > > Thank you, > Jan I have an R430, not in production yet but running fine with 6.3 hw.product=PowerEdge R430 PERC H730 Integrated RAID Controller, 1GB Cache dmesg: OpenBSD 6.3-current (GENERIC.MP) #210: Wed Apr 18 20:04:07 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17065086976 (16274MB) avail mem = 16539983872 (15773MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7af09000 (61 entries) bios0: vendor Dell Inc. version "2.6.0" date 10/31/2017 bios0: Dell Inc. PowerEdge R430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP MCEJ WD__ SLIC HPET APIC MCFG MSCT SLIT SRAT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ acpi0: wakeup devices PCI0(S4) BR1A(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) BR3D(S4) XHC_(S0) RP01(S4) RP02(S4) RP03(S4) RP04(S4) RP05(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz, 2897.02 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: cannot disable silicon debug cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz, 2896.65 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: cannot disable silicon debug cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz, 2896.65 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: cannot disable silicon debug cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz, 2896.65 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: cannot disable silicon debug cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 8 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz, 2896.65 MHz 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
Re: Syspatches 006 and 007 missing on ftp2.eu.openbsd.org
On 09/05/18 13:36, Stuart Henderson wrote: > On 2018/05/09 12:06, Jan Vlach wrote: >> Hello Mirrors discuss list, >> >> it seems that ftp2.eu.openbsd.org is missing syspatches 6 and 7 in >> https://ftp2.eu.openbsd.org/pub/OpenBSD/syspatch/6.3/amd64 >> >> Latest snapshot in /pub/OpenBSD/snapshots/amd64 is from 2018-05-04 >> versus 2018-05-09 on ftp.eu (for example) >> >> Is the sync broken or just slow? Could the responsible sysadm check it, >> please? >> >> Thank you, >> Jan >> > > The fanout server for all L2 mirrors seems to be down at the moment > (at least from the mirror I'm able to check from, and phessler reported > this to the maintainer yesterday as well), at this point your best bet > is probably to fetch patches from whichever mirror you can find that has > them. > You can use: https://ftp.cc.uoc.gr/pub/OpenBSD/syspatch/6.3/amd64/ G
Re: OpenBSD logo on my private hompage. It is allowed?
On 08/06/18 02:51, justina colmena wrote: > On June 7, 2018 3:27:30 PM AKDT, Johannes Krottmayer wrote: > " ... it is our intent that anyone be able to use these images to represent > OpenBSD in a positive light -- but do not make profit from them " > > The no-profit clause is new. Sounds like I'd better dump OpenBSD entirely if > I want to make a profit at any sort of business or keep any of my private > information private or retain any of MY intellectual property for my own use. > There's a giant hole in my pocket that needs to be sewn up. Not sure where to > go. The lawyers are coming out like alligators from the Florida swamps. This > is as bad as SCO and groklaw. > > OpenBSD is for non-profit use only. Thank you for bringing that to my > attention. It's disturbing how many trolls gather in this list. GTFO G
Re: "Halted" firewall - is it a good idea as feature? or just a fun story
On 07/06/18 20:04, Kollar Arpad wrote: > Hello, > > http://www.drdobbs.com/halted-firewalls/199101324 > > What do you think of it? :) any similar feature in OpenBSD? :D you might be interested in securelevel(7) G
ospfd network look
Hi,
I'm trying to evaluate a new setup with 4 routers. This test setup is on VMs
with Jun/7 snapshot.
|--- R2 ---
R1 |--- R4
|--- R3 ---
See here for better view: https://imgur.com/a/ddyEQPb
R2, R3, R4 are on a shared network and do ospf
R2, R3 have a static default route to R1 (-priority 50).
In final setup it will be with bgp/ibgp but I left it out for simplicity.
If R2,R3 connect with R1 on different interfaces (not shared) then I have a
network loop of R2->R3 and R3->R2
If I put R1,R2,R3 on the same network I have no loop.
info is a bit long but I hope someone has a look.
R2# netstat -nr|grep default
default10.200.0.3 UG 0 1409 -32 vio1
default10.100.2.0 UGS03 -50 vio2
R3# netstat -nr|grep default
default10.200.0.2 UG 0 1406 -32 vio1
default10.100.3.0 UGS04 -50 vio3
R4# netstat -nr |grep default
default10.200.0.2 UG 04 -32 vio1
With bgp/ibgp I again have a loop R2,R3 sending to each other
R2# netstat -nr | grep default
default10.200.0.3 UG 00 -32 vio1
default10.100.2.0 UG 01 -48 vio2
R2# bgpctl show ip bgp
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
*>0.0.0.0/010.100.2.0 130 0 64530 i
AI*> 10.200.0.0/160.0.0.0100 0 i
R3# netstat -nr | grep default
default10.200.0.2 UG 0 127 -32 vio1
default10.200.0.2 UG 00 -48 vio1
R3# bgpctl show ip bgp
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I*> 0.0.0.0/010.100.2.0 130 0 64530 i
* 0.0.0.0/010.100.3.0 100 0 64530 i
I*> 10.200.0.0/1610.200.0.2 100 0 i
AI* 10.200.0.0/160.0.0.0100 0 i
R2 ospfd.conf:
router-id 10.200.0.2
metric 1
redistribute default set { metric 1 type 1 }
area 0.0.0.0 {
interface vio1 { router-priority 2 }
interface vio2 { passive }
}
R3 ospfd.conf:
router-id 10.200.0.3
metric 1
redistribute default set { metric 100 type 1 }
area 0.0.0.0 {
interface vio1 { router-priority 3 }
interface vio3 { passive }
}
# ospfctl show database external
Type-5 AS External Link States
LS age: 908
Options: -|-|-|-|-|-|-|-
LS Type: AS External
Link State ID: 0.0.0.0 (External Network Number)
Advertising Router: 10.200.0.2
LS Seq Number: 0x8001
Checksum: 0x18f6
Length: 36
Network Mask: 0.0.0.0
Metric type: 1
Metric: 1
Forwarding Address: 10.100.2.0
External Route Tag: 0
LS age: 908
Options: -|-|-|-|-|-|-|-
LS Type: AS External
Link State ID: 0.0.0.0 (External Network Number)
Advertising Router: 10.200.0.3
LS Seq Number: 0x8001
Checksum: 0x01a8
Length: 36
Network Mask: 0.0.0.0
Metric type: 1
Metric: 100
Forwarding Address: 10.100.3.0
External Route Tag: 0
# ospfctl show database router
Router Link States (Area 0.0.0.0)
LS age: 254
Options: -|-|-|-|-|-|E|-
LS Type: Router
Link State ID: 10.200.0.2
Advertising Router: 10.200.0.2
LS Seq Number: 0x8002
Checksum: 0xc8b1
Length: 48
Flags: *|*|*|*|*|-|E|-
Number of Links: 2
Link connected to: Stub Network
Link ID (Network ID): 10.100.2.0
Link Data (Network Mask): 255.255.255.254
Metric: 1
Link connected to: Transit Network
Link ID (Designated Router address): 10.200.0.4
Link Data (Router Interface address): 10.200.0.2
Metric: 1
LS age: 254
Options: -|-|-|-|-|-|E|-
LS Type: Router
Link State ID: 10.200.0.3
Advertising Router: 10.200.0.3
LS Seq Number: 0x8002
Checksum: 0xdb9a
Length: 48
Flags: *|*|*|*|*|-|E|-
Number of Links: 2
Link connected to: Stub Network
Link ID (Network ID): 10.100.3.0
Link Data (Network Mask): 255.255.255.254
Metric: 1
Link connected to: Transit Network
Link ID (Designated Router address): 10.200.0.4
Link Data (Router Interface address): 10.200.0.3
Metric: 1
LS age: 253
Options: -|-|-|-|-|-|E|-
LS Type: Router
Link State ID: 10.200.0.4
Advertising Router: 10.200.0.4
LS Seq Number: 0x8002
Checksum: 0xc333
Length: 36
Flags: *|*|*|*|*|-|-|-
Number of Links: 1
Link connected to: Transit Network
Link ID (Designated Router address): 10.200.0.4
Link Data (Router Interface address): 10.200.0.4
Metric: 1
Re: OpenBSD in qemu freezes randomly
On 19/06/18 19:47, Stuart Henderson wrote: On 2018-06-19, Leo Unglaub wrote: i have searched the list archive and found some similar reports but none of them found a solution for the problem. (at least not the threads i have found) I run some OpenBSD 6.3 instances in a virtual environment. The host is some unknown Linux distribution with qemu on it. After the data center updated there kernels and also qemu my virtual OpenBSD instances startet to freeze randomly but almost always during login. They freeze up so hard that i cannot drop into a debugger or get any output whatsoever. There is not even a core dump, nothing. Just for testing purposes i installed a 6.2 as well and did syspatch on it just to see if the error happens there as well and it does. I have added a dmesg on the bottom of the email. I talked to the people at the datacenter and they confirmed that they did a Linux kernel update at the same time as the problems started. They send me a link to this bug report here from Arch. They say they don't use Arch, but the problem described here is exactly what i experienced as well: https://bugs.archlinux.org/task/55231 They should try setting this on the host: kvm-intel.preemption_timer=0 It seems that this patch on linux kernel fixes the problem. https://patchwork.kernel.org/patch/10411125/ G
Re: OpenBSD in qemu freezes randomly
On 20/06/18 17:03, Leo Unglaub wrote: Hey, thank you very much for the link. I have forwarded it to the support staff at the datacenter. I hope they apply it very quickly. I let you know if this fixes the problem. Thanks and greetings Leo On 06/19/18 21:21, Kapetanakis Giannis wrote: They should try setting this on the host: kvm-intel.preemption_timer=0 It seems that this patch on linux kernel fixes the problem. https://patchwork.kernel.org/patch/10411125/ G no problem. Also have a look here: https://bugzilla.redhat.com/show_bug.cgi?id=1584775 G
ospfd feature request
Thanks for the latest changes on ospfd/ospf6d especially for 'depend on' for v6 While you're there can you please also see if you can add the following change. I've tried to make a diff but failed. bgpd provides fib-priority to set the routing priority which is useful. Would you please add it also for ospfd/ospf6d instead of the hardcoded RTP_OSPF 32? thanks in advance G
Re: DHCP on several VLANs
On 13/09/18 16:25, Allan Streib wrote: > I need to set up DHCP for several VLANs. The server has 1 physical > interface (bnx1) available for this. > > My naive thought is I create the vlans with bnx1 as the "parent", e.g. > > /etc/hostname.vlan101: > inet 172.16.101.253 255.255.255.0 NONE parent bnx1 vnetid 101 > > /etc/hostname.vlan102: > inet 172.16.102.253 255.255.255.0 NONE parent bnx1 vnetid 102 > > /etc/hostname.vlan103: > inet 172.16.102.253 255.255.255.0 NONE parent bnx1 vnetid 103 > > bnx1 is connected to switch port with all three VLANs tagged. > > Then, rcctl set dhcpd flags vlan101 vlan102 vlan103 > > Is there a better approach? > > Allan This, or use dhcrelay (dhcp helper address on VLAN gateways) 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
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: 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
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: 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.
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: 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-
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: 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
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: 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
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: 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:
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: 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
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
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: 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
Re: Captive portal with OpenBSD as a hostap
On 05/10/15 14:35, David Coppa wrote: On Mon, Oct 5, 2015 at 1:18 PM, C.L. Martinez wrote: Hi all, I have installed an openbsd vm to works as a hostap for tablets and smartphones (android and iOS). All it is working ok: pf, hostapd and dhcpd server. All tablets and smartphones that I have tested works ok, connects and surfs Internet. But now I am thinking to use some type of auth (user/pass using a SSL/TLS channel) instead to use wpa/wpa2 keys. Sometime ago exists this project: Chillispot (http://www.chillispot.org/) but it seems discontinued. Someone knows any type of project/software to accomplish?? I would like to keep simple as much as I can. Thanks. You could try CoovaChilli. https://github.com/sevan/coova-chilli/ http://coova.github.io/ Ciao David Another option you could look is authpf(8) which is in base. Not web based captive portal, but similar setup with ssh. G
Re: Captive portal with OpenBSD as a hostap
On 05/10/15 16:26, laudarch wrote: I made a custom implementation and a diff to authpf, will share that later just in case anyone wants it. I hope this helps you, it pretty simple http://bastienceriani.fr/?p=70 That's nice, but how do you log-out inactive users/IPs? There is no such option in pf a) expire after a certain amount of time and/or b) expire after a certain amount of inactivity pfsense (sorry) uses pf for all it's firewalling and ipf for tracking down users coming from it's captive portal. G
Re: Captive portal with OpenBSD as a hostap
On 06/10/15 01:04, Abel Abraham Camarillo Ojeda wrote: That's nice, but how do you log-out inactive users/IPs? There is no such option in pf a) expire after a certain amount of time and/or pfctl -t loggedusers -T expire 3600 # expire after one hour, regardless of activity you're right on this. I'm also using it for bruteforcers but I've forgot. My main concern is inactive users. G
Re: Captive portal with OpenBSD as a hostap
On 08/10/15 23:17, Predrag Punosevac wrote: Somebody will correct me if I am wrong but the way that Authpf works (I have configured it in the past) is to load a new set of PF rules after successful ssh login. My understanding is that by default the traffic remains unencrypted unless we use more PF magic to force HTTP traffic (HTTPS should be encrypted itself) through some kind VPN over SSH. That way this chapter of the Book of PF was always such a mystery to me. http://home.nuug.no/~peter/pf/en/vegard.authpf.html authpf indeed loads rules per user, and also adds the user's IP in authpf_users table. This is done to allow further traffic to be routed through the ssh gateway (from authenticated users). It does not encrypt traffic. Usually you're doing this on the same LAN (client/server). The http redirect on the book is mostly a redirect to an informations page (and maybe ssh download location). as my understanding is that wpa2 will encrypt entire traffic (I am not discussing how securely). Installing ssh clients on various tablets/smart phones is non-trivial thing for uneducated user. Since I don't want to disturb bad spirits and bring back old flame wars fought over web interface for AuthPF I would like to suggest something else. Namely OpenBSD includes npppd and IPSec and setting and L2TP over IPsec VPN is a breeze as I found out by setting it up. http://marc.info/?l=openbsd-misc&m=142791463307903&w=2 In my experience most Android/Kindel/Smart phone devices have a client for L2TP via IPSec and it is very easy to use it. What I am trying to say is that one could set an "unprotected" WiFi network allowing only L2TP/IPSec authentication. Once a device is authenticated PF rules would allow HTTP, HTTPS and what not through L2TP/IPSec VPN tunnel. The devices will have Internet connection. Whole traffic will be inside an encrypted tunnel and no special software will be required on Android/Smart phone devices. Best, Predrag Have in mind that the traffic is encrypted only from client to the vpn server and not up to the final destination. VPN is usually used to get in the network from remote locations or remotely use local network resources to get out. Nevertheless it's an option :) Another option would be 802.1x but the OP asked for a captive portal and we're getting off topic... regards, G
pf table counters
Hi, Is there a problem with table counters and NAT? I don't have any counters at all. I have a table which has counters enabled # pfctl -sT -v|grep nat_users --a-r-C nat_users I also have pf rules that reference this table. @100 pass out quick on vlan123 inet proto tcp from port > 1023 to ! port > 1023 flags S/SA nat-to xx.xx.xx.xx/29 source-hash 0xkey I also have states created from this rule #pfctl -ss -vv|grep "rule 100" age 04:00:49, expires in 23:59:43, 1150:1431 pkts, 163312:103039 bytes, rule 100 age 04:00:35, expires in 23:53:03, 60:35 pkts, 3266:1980 bytes, rule 100 age 00:06:10, expires in 00:10:00, 15:1 pkts, 4544:60 bytes, rule 100 ... However I don't have counters on the table's entries. # pfctl -t nat_users -vTshow yy.yy.yy.1 Cleared: Thu Sep 24 14:13:08 2015 yy.yy.yy.2 Cleared: Thu Sep 24 14:13:08 2015 If I create another table and a normal pf rule (no nat) then I have counters... as soon as there is traffic matching the rule. second question: when is the cleared time I see above updated apart from the initial input of the ip in the table? thanks Giannis
Re: serious watchdog timeout issues with em driver
On 20/11/15 15:12, Martin Pieuchot wrote:
I just committed a revert to 1.305 keeping the API changes needed for
the driver to build.
This should bring your stability back, please let us know if that's not
the case.
I'm sorry for your troubles.
Hi,
I've upgraded yesterday to Dec 6 snapshot and today I got my first
em0: watchdog timeout -- resetting
regards,
G
OpenBSD 5.8-current (GENERIC.MP) #1468: Sun Dec 6 11:27:59 MST 2015
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0:
FPU,V86,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,CNXT-ID,xTPR,PERF
real mem = 2146910208 (2047MB)
avail mem = 2093232128 (1996MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 04/13/04, BIOS32 rev. 0 @ 0xfb7f0, SMBIOS rev. 2.3 @
0xf0800 (42 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00 PG" date 04/13/2004
bios0: Supermicro P4SCE
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC
acpi0: wakeup devices HUB0(S5) UAR1(S5) UAR2(S5) USB0(S1) USB1(S1) USB2(S1)
USB3(S1) USBE(S1) MODM(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu1:
FPU,V86,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,CNXT-ID,xTPR,PERF
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (HUB0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
bios0: ROM list: 0xc/0x8000 0xc8000/0x8000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82875P Host" rev 0x02
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 16
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801EB/ER USB" rev 0x02: apic 2 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb0 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2
pci1 at ppb0 bus 1
vga1 at pci1 dev 9 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci1 dev 10 function 0 "Intel 82541EI" rev 0x00: apic 2 int 22, address
00:30:48:72:28:58
em1 at pci1 dev 11 function 0 "Intel 82541EI" rev 0x00: apic 2 int 23, address
00:30:48:72:28:59
ichpcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA, channel
0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
pciide0: channel 1 disabled (no drives)
pciide1 at pci0 dev 31 function 2 "Intel 82801EB SATA" rev 0x02: DMA, channel 0
configured to native-PCI, channel 1 configured to native-PCI
pciide1: using apic 2 int 18 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 78533MB, 160836480 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 6
ichiic0 at pci0 dev 31 function 3 "Intel 82801EB/ER SMBus" rev 0x02: apic 2 int
17
iic0 at ichiic0
spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC3200CL3.0
spdmem1 at iic0 addr 0x51: 512MB DDR SDRAM non-parity PC3200CL3.0
spdmem2 at iic0 addr 0x52: 512MB DDR SDRAM non-parity PC3200CL3.0
spdmem3 at iic0 addr 0x53: 512MB DDR SDRAM non-parity PC3200CL3.0
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at ichpcib0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627HF rev 0x17
lm1 at wbsio0 port 0x290/8: W83627HF
npx0 at isa0 port 0xf0/16: reported by CPUID; using exceptio
Re: serious watchdog timeout issues with em driver
On 08/12/15 19:39, Chris Cappuccio wrote: Kapetanakis Giannis [bil...@edu.physics.uoc.gr] wrote: On 20/11/15 15:12, Martin Pieuchot wrote: I just committed a revert to 1.305 keeping the API changes needed for the driver to build. This should bring your stability back, please let us know if that's not the case. I'm sorry for your troubles. Hi, I've upgraded yesterday to Dec 6 snapshot and today I got my first em0: watchdog timeout -- resetting em0 at pci1 dev 10 function 0 "Intel 82541EI" rev 0x00: apic 2 int 22, address 00:30:48:72:28:58 em1 at pci1 dev 11 function 0 "Intel 82541EI" rev 0x00: apic 2 int 23, address 00:30:48:72:28:59 Can you try to pinpoint when it started? You mean what type of traffic caused it? Don't know. The server is a ~ busy internal-only recursive DNS server (bind). Other than that I was playing in it's shell when the event occurred, nothing special. If you mean time since boot, it was after ~ 22hours Dec 7 15:53:20 /bsd: OpenBSD 5.8-current (GENERIC.MP) #1468: Sun Dec 6 11:27:59 MST 2015 Dec 8 16:06:59 /bsd: em0: watchdog timeout -- resetting Dec 8 16:07:00 named[10537]: client: warning: client xx.xx.xx.xx#30399 (mail.expressionclones.com): error sending response: host unreachable Dec 8 16:07:00 named[10537]: client: warning: client yy.yy.yy.yy#52263 (85.151.91.139.sa-accredit.habeas.com): error sending response: host unreachable The event happened only once and it's network recovered after a few seconds. no reboot. G
Re: serious watchdog timeout issues with em driver
On 08/12/15 21:47, Kapetanakis Giannis wrote: The event happened only once and it's network recovered after a few seconds. no reboot. G Well that didn't last long. Today I found the server hanged at ddb after a new watchdog timeout on em0. Keyboard was not working so I could not get all the info. I wrote on paper: uvm_fault(0xd0ba3660, 0xefffe000, 0, 1) -> d kernel: page fault trap, code=0 Stopped at bpf_m_xhalt+0x6f: movzwl 0(%esi),%eax G
Re: kerberos
On 09/12/15 15:13, Friedrich Locke wrote: What is/are the alternative(ies) for kerberos on openbsd ? (Since is was removed from the distribution). Thanks. Don't know if you can compile it, but the commit-remove msg is all time classic :) http://marc.info/?l=openbsd-cvs&m=139816103911227&w=2 G
Re: serious watchdog timeout issues with em driver
On 09/12/15 10:42, Kapetanakis Giannis wrote: On 08/12/15 21:47, Kapetanakis Giannis wrote: The event happened only once and it's network recovered after a few seconds. no reboot. G Well that didn't last long. Today I found the server hanged at ddb after a new watchdog timeout on em0. Keyboard was not working so I could not get all the info. I wrote on paper: uvm_fault(0xd0ba3660, 0xefffe000, 0, 1) -> d kernel: page fault trap, code=0 Stopped at bpf_m_xhalt+0x6f: movzwl 0(%esi),%eax G Hi, Has something changed from Dec 6 snapshot to Dec 9 current that fixed this? I've seen that the driver has not been updated. I've compiled new current kernel on Dec 9 and system does NOT have any problem since then. No watchdog timeout and no crash. Problem solved? Any link to the commit that solved it? thanks Giannis
Re: OpenBSD help
On 15/12/15 18:07, Alessandro Baggi wrote: Hi list, I've a firewall on an apu1D running OpenBSD. Today during a simple management, I've noticed that the system is up since 1 day and 23 hours. Running "cat authlog" I see that the last two logged session are: Dec 2 at 12 and today. Running "last" I see: myuser (current session) (still logged in) reboot ~Sun Dec 13 18:06 In my configuration I don't give access from wan and dmz. Access is only from LAN ssh key based (key is on a usbdrive) and from console and the console machine is off since installation. Reading other logfile (messages.X.gz, daemon.X.gz...) I can't find nothing useful. I don't think that there is an automatic (magic) reboot and I've no configured personal script or other. Maybe Hacked? Someone can help me to find what happened? Thanks in advance. from last(1) The pseudo-user ``reboot'' logs in at reboots of the system; thus last reboot will give an indication of mean time between reboot. G
Re: serious watchdog timeout issues with em driver
Hi,
Problem is still here with Dec 16 snapshot.
Dec 17 13:08:20 server /bsd: OpenBSD 5.8-current (GENERIC.MP) #1494: Wed
Dec 16 12:13:03 MST 2015
Dec 17 13:08:20 server /bsd:
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
Dec 17 13:08:20 server /bsd: cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz
("GenuineIntel" 686-class) 3 GHz
Dec 17 13:08:20 server /bsd: em0 at pci1 dev 10 function 0 "Intel
82541EI" rev 0x00: apic 2 int 22, address 00:30:48:72:28:58
Dec 17 13:08:20 server /bsd: em1 at pci1 dev 11 function 0 "Intel
82541EI" rev 0x00: apic 2 int 23, address 00:30:48:72:28:59
Dec 20 16:53:18 server /bsd: em0: watchdog timeout -- resetting
Dec 21 01:54:12 server /bsd: em0: watchdog timeout -- resetting
G
states by rule
Hi, Is there a quick way to find the exact states or state number created by a specific rule(s) without parsing the whole state table (pfctl -ss -vv)? I've tried loading the rules I'm concerned about in a separate anchor but that didn't work pfctl -a foo -ss thanks G
Re: states by rule
On 11/01/16 13:27, Stuart Henderson wrote: On 2016-01-11, Kapetanakis Giannis wrote: Hi, Is there a quick way to find the exact states or state number created by a specific rule(s) without parsing the whole state table (pfctl -ss -vv)? I've tried loading the rules I'm concerned about in a separate anchor but that didn't work pfctl -a foo -ss thanks G pfctl -ss -R 3 Thanks Stuart, that was exactly what I was looking for :) didn't notice that on man page. G
igmp option 148 (RA)
Hi,
I'm constantly seeing this on my pf router.
rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query
[tos 0xc0] [ttl 1]
Rule 61 is:
@61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep
state (no-sync)
tcpdump on $ext_if shows:
$ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32,
optlen=4 IPOPT-148{4})
I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
Is this normal? Why does it think it's bad?
Ext gateway is cisco (no under my control) which apparently is sending
this option.
G
Re: igmp option 148 (RA)
On 21/01/16 12:40, Stefan Sperling wrote:
On Thu, Jan 21, 2016 at 12:27:06PM +0200, Kapetanakis Giannis wrote:
Hi,
I'm constantly seeing this on my pf router.
rule 61/(ip-option) pass in on $ext_if: $ext_gw > 224.0.0.1: igmp query [tos
0xc0] [ttl 1]
Rule 61 is:
@61 pass quick inet proto igmp from $ext_if:network to 224.0.0.1 keep state
(no-sync)
tcpdump on $ext_if shows:
$ext_gw > 224.0.0.1: igmp query [tos 0xc0] [ttl 1] (id 59056, len 32,
optlen=4 IPOPT-148{4})
I guess pf has a problem with ip-option 148 which is router alert (rfc2113)
Is this normal? Why does it think it's bad?
Ext gateway is cisco (no under my control) which apparently is sending this
option.
G
Multicast traffic is black-holed by default.
You may want to set multicast_host=Yes in /etc/rc.conf.local.
See the MULTICAST ROUTING section in the netstart(8) man page.
I 've tried multicast=YES and manually removing the -reject rule
as in /etc/netstart (route -qn delete 224.0.0.0/4)
but nothing changed
multicast_host seems deprecated. I can't find any entry for this in
/etc/rc /etc/rc.conf or /etc/netstart
Anyway I don't think this is the problem since the reject route probably
has nothing to do with pf deciding it's a bad ip option.
thanx for reply
G
Re: igmp option 148 (RA)
On 21/01/16 13:15, Stuart Henderson wrote: See pf.conf(5) "allow-opts". thanx Stuart :) that did the trick G
Re: vlan on trunk member not permitted
On 10/02/16 09:45, Marc Peters wrote: Hi list, for my laptop, i created a trunk(4) interface with em0 and iwn0 as members. IPv6 is provided on a separate vlan for now. Without trunking the interfaces, the vlan interface comes up and everything's working fine: ~ $ sudo /bin/sh /etc/netstart vlan6 ifconfig: SIOCSETVLAN: Protocol not supported ifconfig: SIOCIFAFATTACH: Invalid argument ifconfig: SIOCSIFXFLAGS: Invalid argument iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: Maybe iwn0 does not support vlan? I don't see anything relative on it's product brief sheet. http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/centrino-advanced-n-6205-brief.pdf Did you try to start vlan 6 on iwn0 (instead of em0) and see if it works. If both interfaces support vlan then vlan on top of trunk should not be a problem. I've used that configuration for both failover and lacp setups. good luck, G
dhcrelay: send_packet: No buffer space available
Hi, I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: Feb 8 21:00:04 dhcrelay: send_packet: No buffer space available Feb 9 16:47:02 dhcrelay: send_packet: No buffer space available Feb 9 18:43:50 dhcrelay: send_packet: No buffer space available Feb 10 10:00:14 dhcrelay: send_packet: No buffer space available Feb 10 12:34:02 dhcrelay: send_packet: No buffer space available Feb 10 18:05:02 dhcrelay: send_packet: No buffer space available Feb 10 20:19:02 dhcrelay: send_packet: No buffer space available Feb 10 23:10:05 dhcrelay: send_packet: No buffer space available Feb 11 23:30:09 dhcrelay: send_packet: No buffer space available Feb 12 11:48:52 dhcrelay: send_packet: No buffer space available Before I start pushing buttons I shouldn't, any recommendations? Thanks, G # netstat -m 460 mbufs in use: 450 mbufs allocated to data 5 mbufs allocated to packet headers 5 mbufs allocated to socket names and addresses 447/1968/6144 mbuf 2048 byte clusters in use (current/peak/max) 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) 0/14/6146 mbuf 9216 byte clusters in use (current/peak/max) 0/10/6150 mbuf 12288 byte clusters in use (current/peak/max) 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) 2184 Kbytes allocated to network (46% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines # vmstat -m Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 8868 256755361280 91 32 1760 11845863660 640 27 64 2484 12287496442 320 2545 128 4357 591116059 160112 256 5541821820217 80 1254 512 708 36 803977 40423 1024 171149 716381 20 497401 2048 129 5 218715 10 0 4096 2100 5 348328 5 2028 8192 210 2 4679 5 0 163847 0 12 5 0 32768 41 0 42 5 0 655361 03321986 5 0 2621441 0 1 5 0 5242881 0 1 5 0 Memory usage type by bucket size Size Type(s) 16 devbuf, pcb, rtable, ifaddr, UFS mount, dirhash, ACPI, ip_moptions, exec, VM swap, UVM amap, UVM aobj, USB, USB device, temp 32 devbuf, pcb, rtable, ifaddr, sem, dirhash, ACPI, in_multi, exec, UVM amap, USB, USB device, temp 64 devbuf, rtable, ifaddr, sysctl, vnodes, dirhash, ACPI, proc, in_multi, ether_multi, VM swap, UVM amap, USB, NDP, temp 128 devbuf, pcb, rtable, ifaddr, UFS mount, sem, dirhash, ACPI, NFS srvsock, ip_moptions, in_multi, pfkey data, UVM amap, USB, USB device, temp 256 devbuf, rtable, ifaddr, sysctl, ioctlops, iov, vnodes, shm, VM map, dirhash, ACPI, exec, UVM amap, USB, USB device 512 devbuf, ifaddr, ioctlops, iov, UFS mount, dirhash, ACPI, file desc, ttys, newblk, UVM amap, temp 1024 devbuf, pcb, ifaddr, sysctl, ioctlops, iov, mount, shm, proc, ttys, exec, UVM amap, crypto data, temp 2048 devbuf, ifaddr, ioctlops, iov, UFS mount, ACPI, VM swap, UVM amap, UVM aobj, temp 4096 devbuf, ifaddr, ioctlops, proc, ttys, UVM amap, memdesc, temp 8192 devbuf, ttys, pagedep, UVM amap, USB, temp 16384 devbuf, NFS daemon, MSDOSFS mount, temp 32768 devbuf, UFS quota, UFS mount, ISOFS mount, inodedep 65536 devbuf, temp 262144 VM swap 524288 VM swap Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 4695 10221K 10222K 78644K754610 0 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 pcb6515K 16K 78644K134960 0 16,32,128,1024 rtable 111537K 52K 78644K 5613250 0 16,32,64,128,256 ifaddr 31642K 42K 78644K 3500 0 16,32,64,128,256,512,1024,2048,4096 sysctl 3 2K 2K 78644K30 0 64,256,1024 ioctlops 0 0K 4K 78644K418010 0 256,512,1024,2048,4096 iov 0 0K 2K 78644K 1420 0 256,512,1024,2048 mount 3 3K 3K 78644K30 0 1024 vnodes 127780K 81K 78644K 99580 0 6
Re: dhcrelay: send_packet: No buffer space available
On 12/02/16 18:56, Stuart Henderson wrote: On 2016-02-12, Kapetanakis Giannis wrote: Hi, I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: What version were you running before? To establish whether it's a dhcrelay problem or something to do with carp can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? The previous version was from July 2015 so it was far away from now. I guess it will not work with current kernel and pledge(2), tame(2) changes correct? G
Re: dhcrelay: send_packet: No buffer space available
On 12/02/16 18:56, Stuart Henderson wrote: On 2016-02-12, Kapetanakis Giannis wrote: Hi, I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: What version were you running before? To establish whether it's a dhcrelay problem or something to do with carp can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? I went back to 2016/02/01 and 2016/01/12 (packet.c) and I have the same problem so it doesn't seem like a dhcrelay problem. I changed it to print the interfaces Feb 17 18:04:28 dhcrelay: send_packet: No buffer space available on carp63 Feb 18 09:16:35 dhcrelay: send_packet: No buffer space available on carp32 Feb 18 09:27:45 dhcrelay: send_packet: No buffer space available on carp32 but there is no network/routing problem. Setup is trunk (lacp) - vlans - carps - dhcrelay for internal trunk (lacp) / nat for external ospf in (passive on carps) / out on ext trunk. Any way to debug this further? thanks, Giannis
Re: dhcrelay: send_packet: No buffer space available
On 18/02/16 13:22, Peter Hessler wrote: On 2016 Feb 18 (Thu) at 12:25:07 +0200 (+0200), Kapetanakis Giannis wrote: :On 12/02/16 18:56, Stuart Henderson wrote: :>On 2016-02-12, Kapetanakis Giannis wrote: :>>Hi, :>> :>>I have a carped firewall which is using dhcrelay to forward dhcp :>>requests to another carped dhcp server. :>>After upgrade to Feb 4 snapshot I'm seeing these in my logs: :>What version were you running before? :> :>To establish whether it's a dhcrelay problem or something to do with carp :>can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? :> : :I went back to 2016/02/01 and 2016/01/12 (packet.c) and I have the same :problem :so it doesn't seem like a dhcrelay problem. : :I changed it to print the interfaces :Feb 17 18:04:28 dhcrelay: send_packet: No buffer space available on carp63 :Feb 18 09:16:35 dhcrelay: send_packet: No buffer space available on carp32 :Feb 18 09:27:45 dhcrelay: send_packet: No buffer space available on carp32 :but there is no network/routing problem. : :Setup is trunk (lacp) - vlans - carps - dhcrelay for internal :trunk (lacp) / nat for external : :ospf in (passive on carps) / out on ext trunk. : :Any way to debug this further? : :thanks, : :Giannis : How many bpf devices do you have? You may need to create more. I have 20 bpf devices, 27 vlan interfaces, 27 carp interfaces, 17 dhcrelay processes. wasn't there a message when bpf devides were short? Anyway I pushed it to 30 bpf devices and see how it goes. G
Re: dhcrelay: send_packet: No buffer space available
On 18/02/16 15:52, Kapetanakis Giannis wrote: On 18/02/16 13:22, Peter Hessler wrote: How many bpf devices do you have? You may need to create more. I have 20 bpf devices, 27 vlan interfaces, 27 carp interfaces, 17 dhcrelay processes. wasn't there a message when bpf devides were short? Anyway I pushed it to 30 bpf devices and see how it goes. G Unfortunately that wasn't the problem... Feb 19 09:10:42 dhcrelay: send_packet: No buffer space available carp48 # fstat|grep bpf|wc -l 19 any more ideas? thanks G
Re: dhcrelay: send_packet: No buffer space available
On 20/02/16 13:52, Stuart Henderson wrote:
Are the carp interfaces "up" (i.e. master) when you see these messages?
Yes always.
On both firewalls I have net.inet.carp.log=3 and I haven't logged any
carp up/down - MASTER/BACKUP transition messages.
On the other hand, on backup firewall I just noticed relevant? messages
but on different times and no other sign that it became the MASTER.
Feb 9 12:58:54 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 9 16:41:58 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 11 10:16:37 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 11 18:32:21 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 15 10:31:01 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 16 12:06:10 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 17 16:45:06 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 18 09:19:11 backup_fw2 dhcrelay: send_packet: Network is unreachable
So it looks it's related to carp because the backup fw shouldn't have
relay the dhcp requests from clients but for some unknown reason it did...
How can I make the warning() to print carp/interface status?
I did the following to print interface name:
diff -u -p -r1.10 bpf.c
--- bpf.c 7 Feb 2016 00:49:28 - 1.10
+++ bpf.c 20 Feb 2016 12:53:02 -
@@ -299,7 +299,7 @@ send_packet(struct interface_info *inter
result = writev(interface->wfdesc, iov, 2);
done:
if (result == -1)
- warning("send_packet: %m");
+ warning("send_packet: %m on %s", interface->name);
return (result);
}
Thanks!
G
Re: Is there an option switch to lower minimum DH strength in SSH client?
On 03/11/17 15:27, Jacob Leifman wrote: >> KexAlgorithms +diffie-hellman-group1-sha1 >> Ciphers +aes128-cbc >> >> Regards >> > > Hi, > > Not quite, I have the converse problem -- using the modern ssh client and > being unable to connect to an older embedded ssh server. But your solution > indicates that in the ssh server implementation the explicit compatibility > mode actually works. I find the incongruity between server and client > approaches to backwards compatibility rather odd, since it is generally > much easier to upgrade or replace a client application (end-user software) > than the server application, especially embedded server as in my case. > > -Jacob. The reverse is done on your .ssh/config host old-server Hostname 10.0.0.1 KexAlgorithms diffie-hellman-group-exchange-sha1 Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc choose what works for you ssh -v is a friend here to see where it complains. G
Re: bug tracking system for OpenBSD
On 22/12/17 17:36, Stuart Henderson wrote: > The important part is the data itself. > ... > IMHO if anything is going to happen with this it's going to come > from someone who just gets on and does it. Maybe someone who just > throws a spreadsheet or something together to keep track of > tech@/bugs@ mails. I'd be very surprised if a useful system > comes from someone who is looking at it as a technical exercise > of setting up the system. I agree with you that the important is the data itself and not the system chosen for the work. Such a movement can start from zero ground without migrating data from @bugs or @tech. But to be fair with the OP it all depends on dev's (mainly) willingness to track/respond/close tickets. I say devs because these are the people who commit fixes of bugs and so they should monitor/update this system as well. It's extra work for them instead of developing... and I understand that. I don't see a reason @tech should be forwarded to this ticket system. @bugs can be eventually closed or somehow migrated to this system (new mails and not existing ones). Personally I would like to see such a system in OB. G
Re: bug tracking system for OpenBSD
On 23/12/17 12:24, Stuart Henderson wrote: Forwarded? No way! Same for bugs@ as tech@. It needs manual work to triage, identify what is a bug, follow up with the reporter to make sure the report is accurate and has enough information to be useful. Same whatever the entry point is. If reporters can add bugs to it directly, they need to go into a triage queue and *not* appear in the main system until that's done. The idea of a bug tracking system is to spread the work and help people remember things. It should *reduce* work done by devs because they no longer have to drag even the most basic information out of a reporter and figure out whether it's a bug or user error or a support request in disguise. If it means *extra* work for devs, it's not going to work. I still don't agree with you about maintaining both @tech/@bugs in correlation with a web interface (bugtracking). Not a gain, just extra trouble. What happens in other places is that if a mail comes that looks like a possible ticket (not resolvable by mail), someone replies and says "please open bug report in https://..."; so we can track it. However you 're right with the last paragraph above and it's something I haven't thought before. More people might get involved and eventually this might get some work out of the devs. G
i7 vs Xeon forwarding performance
Hi, Has anyone tested newer i7 vs Xeon E5 performance comparison on forwarding? All tests I've seen (mainly by Hrvoje Popovski) are on Xeon cpus. I know that things are a moving target with UNLOCKing taking place but it would be interesting to share any results if there are available. regards, G
Re: Bitmask for 224.0.0.0 in Martians PF table entry
On 10/01/18 20:55, Aham Brahmasmi wrote: > Hi, > > What is the correct bitmask for the 224.0.0.0 Martian table entry in > pf.conf? > > There are two bitmasks in two links on this page - > http://www.team-cymru.org/bogon-reference-http.html. /3 in the The Text > Bogon List, Aggregated and /4 in IPv4 Fullbogons. /3 is also present in > https://www.openbsd.org/faq/pf/example1.html. > > I think it should be /3, but I am still learning pf. > > Thanks. > > Regards, > ab > See here: https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml 224/4 is the multicast allocation (224-239) 240/4 is for future use (240-255) 224/3 is both of the above if you don't use multicast then 224/3 should be ok, otherwise 240/4 G ps. for multicast specific see https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
nat-to (least-states / round-robin) problem
Hi, I've discovered something that looks like a bug in nat translation with least-states or round-robin Instead of using the nat-pool is uses wrong IPs # pfctl -sr -R0 pass out log quick on vlan123 inet from xx.xx.xx.xx to 188.113.88.193 flags S/SA tagged from_internal nat-to xx.xx.yy.24/29 least-states Jan 23 10:59:06.602884 rule 0/(match) pass out on vlan123: 0.0.0.0.62722 > 188.113.88.193.80: S 3243156923:3243156923(0) win 29200 (DF) Jan 23 10:59:21.836380 rule 0/(match) pass out on vlan123: 0.0.0.1.57696 > 188.113.88.193.80: S 1280038032:1280038032(0) win 29200 (DF) See the 0.0.0.0 address? That's the first packet. The second packet (2nd wget) uses the next IP, 0.0.0.1 etc. The same problem is with round-robin 10:54:24.750786 0.0.0.2.50332 > 188.113.88.193.80: S 1923288633:1923288633(0) win 29200 (DF) 10:54:28.078831 0.0.0.3.50350 > 188.113.88.193.80: S 925801869:925801869(0) win 29200 (DF) If I use random or source-hash I have no problem. Maybe this is fixed in current but I though I should report. # head -1 /var/run/dmesg.boot OpenBSD 6.2-beta (GENERIC.MP) #104: Mon Sep 18 23:31:27 MDT 2017 I'll try an upgrade later today... G
Re: nat-to (least-states / round-robin) problem
On 23/01/18 11:08, Kapetanakis Giannis wrote: > Hi, > > I've discovered something that looks like a bug in nat translation with > least-states or round-robin > > Instead of using the nat-pool is uses wrong IPs > > # pfctl -sr -R0 > pass out log quick on vlan123 inet from xx.xx.xx.xx to 188.113.88.193 flags > S/SA tagged from_internal nat-to xx.xx.yy.24/29 least-states > > Jan 23 10:59:06.602884 rule 0/(match) pass out on vlan123: 0.0.0.0.62722 > > 188.113.88.193.80: S 3243156923:3243156923(0) win 29200 1460,sackOK,timestamp 3169583207 0,nop,wscale 9> (DF) > Jan 23 10:59:21.836380 rule 0/(match) pass out on vlan123: 0.0.0.1.57696 > > 188.113.88.193.80: S 1280038032:1280038032(0) win 29200 1460,sackOK,timestamp 3169598441 0,nop,wscale 9> (DF) > > See the 0.0.0.0 address? That's the first packet. The second packet (2nd > wget) uses the next IP, 0.0.0.1 etc. > > The same problem is with round-robin > 10:54:24.750786 0.0.0.2.50332 > 188.113.88.193.80: S 1923288633:1923288633(0) > win 29200 (DF) > 10:54:28.078831 0.0.0.3.50350 > 188.113.88.193.80: S 925801869:925801869(0) > win 29200 (DF) > > If I use random or source-hash I have no problem. > > Maybe this is fixed in current but I though I should report. > # head -1 /var/run/dmesg.boot > OpenBSD 6.2-beta (GENERIC.MP) #104: Mon Sep 18 23:31:27 MDT 2017 > > I'll try an upgrade later today... > > G > same problem with latest snapshot: OpenBSD 6.2-current (GENERIC.MP) #382: Sun Jan 21 14:13:38 MST 2018 G
Re: nat-to (least-states / round-robin) problem
On 23/01/18 11:54, Kapetanakis Giannis wrote: > On 23/01/18 11:08, Kapetanakis Giannis wrote: >> Hi, >> >> I've discovered something that looks like a bug in nat translation with >> least-states or round-robin >> >> Instead of using the nat-pool is uses wrong IPs >> >> # pfctl -sr -R0 >> pass out log quick on vlan123 inet from xx.xx.xx.xx to 188.113.88.193 flags >> S/SA tagged from_internal nat-to xx.xx.yy.24/29 least-states >> >> Jan 23 10:59:06.602884 rule 0/(match) pass out on vlan123: 0.0.0.0.62722 > >> 188.113.88.193.80: S 3243156923:3243156923(0) win 29200 > 1460,sackOK,timestamp 3169583207 0,nop,wscale 9> (DF) >> Jan 23 10:59:21.836380 rule 0/(match) pass out on vlan123: 0.0.0.1.57696 > >> 188.113.88.193.80: S 1280038032:1280038032(0) win 29200 > 1460,sackOK,timestamp 3169598441 0,nop,wscale 9> (DF) >> >> See the 0.0.0.0 address? That's the first packet. The second packet (2nd >> wget) uses the next IP, 0.0.0.1 etc. >> >> The same problem is with round-robin >> 10:54:24.750786 0.0.0.2.50332 > 188.113.88.193.80: S >> 1923288633:1923288633(0) win 29200 > 0,nop,wscale 9> (DF) >> 10:54:28.078831 0.0.0.3.50350 > 188.113.88.193.80: S 925801869:925801869(0) >> win 29200 (DF) >> >> If I use random or source-hash I have no problem. >> >> Maybe this is fixed in current but I though I should report. >> # head -1 /var/run/dmesg.boot >> OpenBSD 6.2-beta (GENERIC.MP) #104: Mon Sep 18 23:31:27 MDT 2017 >> >> I'll try an upgrade later today... >> >> G >> > same problem with latest snapshot: > OpenBSD 6.2-current (GENERIC.MP) #382: Sun Jan 21 14:13:38 MST 2018 > > G > Hi, any luck with the above? thanks, G
Re: OpenBSD and IPMI
On 09/03/18 15:11, Denis wrote: > By reading this article > blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair > raised. > > How to OpenBSD security withstands against IPMI holed solution from top > hardware vendors? > > Best ways to prevent potential risks for OpenBSD over IPMI? > > Thanks The OS has nothing to do with a onboard-device running it's own firmware and having direct access to network. Look for how you can secure/disable lom/drac/bmc whatever itself or the network that is given access to. G
relayd clients on same network with servers
Hi, I'm designing a new setup with relayd and multiple pools. I'm using redirects with forward. The problem I have is that all the real server as in the same VLAN. In advance the servers in one pool need to access the servers in another pool, through the load balancer, thus having a problem with replies not passing through the LB (ie IMAP server accessing LDAP servers) I've thought of different solutions for this and I've come up to the following. I need a second opinion: 1) Use different VLAN per pool of servers 2) 1 VLAN, with 1 bridge and multiple subnets on vether devices 3) Source NAT to hide client IP 4) Use a relay as a proxy (instead of redirect on the $int_if) 5) Use DSR (route-to) with sloppy states Solution 1 seems the best to me but it has overhead of adding/managing the vlans everywhere. Solution 2 seems to work but I'm not quite sure about it 3 and 4 hide the client IP so I want to avoid it 5 also want to avoid, has problems with failover, don't like the half states So 2 seems ok, I have basic separation of pools and I guess since I control all the servers the jumping from one subnet to another is not a serious security problem. appreciate any opinions on this Giannis ps. whole setup with carp-pfsync
Re: relayd clients on same network with servers
On 19/03/18 13:51, Mischa wrote: > Hi Giannis, > > From my experience dealing with a lot of load balancers in my time, and also > working for different vendors, the easiest is to use source-nat. > This is just configuration on the relayd itself without making "major" > changes in the rest of the network or servers. Which you would need to do to > when choosing different VLANs or DSR. > > Your concern about source-net and hiding the client IP is valid, but easily > fixed with Client-IP header in http, if http is the protocol, otherwise you > will loose the client IP. ;) > One more thing to remember with source-nat is the maximum amount of > concurrent connections you can handle in a single IP, if that is below 64k > you are fine, otherwise you will have to create a pool of IPs to source-nat > from. > > In my opinion DSR is only relevant for services like FTP and NNTP, where you > have a lot more traffic going out than coming in, so you don't have to put > that burden through the single load balancer interface. > > If you have the ability to change the VLANs that of course the cleanest of > all the option and source-nat the dirtiest, but it's also the simplest. :) > > Good luck! > > Mischa Thanks for the reply Mischa, Well since most of traffic is not http based I cannot use the headers for client IP :-/ This will also be a problem with firewalling on the real servers as well. So that probably leaves out SNAT and relay proxy. I also agree that DSR is not needed. Yes, multiple VLANs is the cleanest solution. My concern is mainly with 1 VLAN and multiple subnets which does the trick of returning the traffic through the LB as well as keeping the setup simple. Another solution would also be some kind of private vlans with openvswitch thanks, Giannis
Re: OpenBSD vs Linux KVM Guest Performance and Stability
On 16/04/18 18:40, Claudio Jeker wrote: really depends on the KVM/linux version Don't forget to set "options kvm-intel preemption_timer=0" for modprobe on newer linux kernels. After that it seems to work nicely. This module option (according to lists) is about timing issues with kvm and obsd. Does it affect performance as well? which kernel? G
Re: OpenBSD vs Linux KVM Guest Performance and Stability
On 17/04/18 10:28, Daniel Santos wrote: > On 2018-04-16 23:00, Claudio Jeker wrote: >> On Mon, Apr 16, 2018 at 11:10:46PM +0300, Kapetanakis Giannis wrote: >>> On 16/04/18 18:40, Claudio Jeker wrote: >>> > >>> >>really depends on the KVM/linux version >>> >> >>> >Don't forget to set "options kvm-intel preemption_timer=0" for modprobe on >>> >newer linux kernels. After that it seems to work nicely. >>> > >>> >>> This module option (according to lists) is about timing issues with kvm and >>> obsd. >>> Does it affect performance as well? >> >> It affects stability (sometimes VM hang because the clock interrupts don't >> work correctly) which is a big performace killer. Also for me stat clock >> was not running so there was no way to know what CPU load the VM has. >> >>> which kernel? >> >> I see it for sure on a 4.14 kernel. Guess more affected. > > For me the kernels: > > Host: 3.2.0-4-amd64 Debian Wheezy 7.11 (and no I don't want to upgrade this, > it's running production vms over 300 days). > > Modules: > > kvm_intel 122046 78 > kvm 291951 1 kvm_intel > > I don't use any kvm module options on the Linux host. My host also runs bunch > of other VMs (linuxes with different kernels, freeBSD, windows 7). That is why I've asked the kernel version from Claudio. I also use Centos7 with kernel 3.10.0-693.21.1.el7.x86_64 on supervisor machines and I don't experience any timing issues or hungs as reported on those threads. Not using any custom modprobe options either. Stability is fine and performance is as it is. G
Re: carp ssh setup
On 17/04/18 02:06, jungle Boogie wrote: > Hi All, > > I have a very simple carp setup - basically I want ssh access if the > master goes offline. > In theory, this are functioning correctly. In practice, it seems the > backup is taking over way too often - the backup takes over way too > often, even when I'm ssh'd to the master device. > > master: > inet 192.168.0.99 255.255.255.0 192.168.0.255 vhid 1 carpdev dwxe0 > state master advskew 1 pass pass > > backup: > inet 192.168.0.99 255.255.255.0 192.168.0.255 vhid 1 carpdev dwxe0 > state backup advskew 10 pass pass Do you have IP addresses on the physical interfaces dwxe0? Use netmask 255.255.255.255 on carp devices. and then use the IP address off the physical interface (dwxe0) to access each firewall. ifconfig -A would be useful for more help G
upgrade 6.2 snapshots to 6.3 release
Hi, since more and more of my servers have been migrated to OpenBSD :) and I'm getting a bit lazy, I want to upgrade some of my 6.2 snapshots to 6.3 release and use syspatch for upgrading them in the future. What was the date of code lock/freeze so I can safely put 6.3 on top? Thanks, G
Re: upgrade 6.2 snapshots to 6.3 release
On 19/04/18 13:54, Sebastian Benoit wrote: > Kapetanakis Giannis(bil...@edu.physics.uoc.gr) on 2018.04.19 13:37:24 +0300: >> Hi, >> >> since more and more of my servers have been migrated to OpenBSD :) and I'm >> getting a bit lazy, I want to upgrade some of my 6.2 snapshots to 6.3 >> release and use syspatch for upgrading them in the future. > > sad to hear that you dont want to test snapshots in the future ;) I will, i will :) but not on every machine I have. It's adding a lot of work. I will keep the most important machines manually updated with snapshots as I also want the latest features ;) >> What was the date of code lock/freeze so I can safely put 6.3 on top? > > You should be able to update any system that claims its 6.2-current to > 6.3. > > All instructions on http://www.openbsd.org/faq/upgrade63.html should work, > even when starting from a 6.2-current snapshot. > > There is no specific data before or after that would not work, including for > versions claiming to be 6.3-beta and 6.3 up until "OpenBSD 6.3 (GENERIC.MP) > #107: Sat Mar 24 14:21:59 MDT 2018" which is the final released 6.3. > > /Benno So I can even update OpenBSD 6.3 (GENERIC.MP) #62: Wed Mar 14 ? Eventually 6.3 is the 23-24 Mar snapshot? thanks, G
Re: upgrade 6.2 snapshots to 6.3 release
On 19/04/18 23:46, Sebastian Benoit wrote: > Correct. And between Mar 14 and Mar 24, there is i believe nothing (like rm > commands etc) in the upgrade63.html that you need to do, just do the update > and run sysmerge and syspatch and pkg_add -u. Thanks for the answers. Last question: What's the story with the packages? I see all of them with Mar 28 date. I guess they are never updated, even for security update of some package? 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.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
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
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: 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
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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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
