relayd filter
Hi, in relayd.conf I'm trying to do : pass from 192.168.1.1 path "/something.html" If I individually specify the "from" or the "path", it works but when I combine both, it doesn't work. Am I missing something or if it's just not possible ? Or is there another way to express this another way ? thank you, Nick
VisionFive 2 status
Hi, I tried to boot VisionFive 2 RISC-V SBC board [1] with a current OpenBSD snapshot and I got it to boot from a SD card after replacing the Linux root partition on the image provided by the vendor with an OpenBSD partition. I guess it's still early days and that could be why I couldn't find previous messages or info on the web with dmesg output since is not super-interesting yet. Anyway, you can boot bsd.rd but the installer will not be able to advance after the step where the install disk is selected since no storage devices are found (no USB devices are detected yet and I don't have a M2 SSD disk handy to test (to-do)). See below dmesg output (I'll try to repeat this later with OpenBSD preinstalled on the SD card to see if I can get further in the boot process with this board): 8< disks: sd0* >> OpenBSD/riscv64 BOOTRISCV64 1.5 boot> cannot open sd0a:/etc/random.seed: No such file or directory booting sd0a:/bsd: 5513256+1352760+212848+701688 [362973+122+503952+360008]=0xa0b160 clk u5_dw_i2c_clk_core already disabled clk u5_dw_i2c_clk_apb already disabled bootargs: all mapped type 0x0 pa 0x4000 va 0x4000 pages 0x80 attr 0x8 type 0x7 pa 0x4008 va 0x4008 pages 0x180 attr 0x8 type 0x2 pa 0x4020 va 0x4020 pages 0x4000 attr 0x8 type 0x7 pa 0x4420 va 0x4420 pages 0x3cf2 attr 0x8 type 0x9 pa 0x47ef2000 va 0x47ef2000 pages 0x1c attr 0x8 type 0x7 pa 0x47f0e000 va 0x47f0e000 pages 0xb66d1 attr 0x8 type 0x2 pa 0xfe5df000 va 0xfe5df000 pages 0xb attr 0x8 type 0x4 pa 0xfe5ea000 va 0xfe5ea000 pages 0x1 attr 0x8 type 0x7 pa 0xfe5eb000 va 0xfe5eb000 pages 0x1 attr 0x8 type 0x2 pa 0xfe5ec000 va attr 0x8 type 0x1 pa 0xfe6ec000 va 0xfe6ec000 pages 0x26 attr 0x8 type 0x4 pa 0xfe712000 va 0xfe712000 pages 0x8 attr 0x8 type 0x6 pa 0xfe71a000 va 0xfe71a000 pages 0x1 attr 0x8008 type 0x4 pa 0xfe71b000 va 0xfe71b000 pages 0x3 attr1e000 va 0xfe71e000 pages 0x3 attr 0x8008 type 0x4 pa 0xfe721000 va 0xfe721000 pages 0x1 attr 0x8 type 0x6 pa 0xfe722000 va 0xfe722000 pages 0x4 attr 0x8008 type 0x4 pa 0xfe726000 va 0xfe726000 pages 0xe attr 0x8 type 0x2 pa 0xfe734000 va 0xfe734000 pages 0x1811 attr 0x8 type 0x5 pa 0xfff45000 va 0xfff45000 pages 0x1 attr 0x8008 type 0x2 pa 0xfff46000 va 0xfff46000 pages 0xba attr 0x8 type 0x4 pa 0x1 va 0x1 pages 0x14 attr 0x8 [ using 1228024 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2023 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 7.3-current (GENERIC) #337: Mon Jun 5 01:57:41 MDT 2023 dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC real mem = 4294967296 (4096MB) avail mem = 8183058432 (7803MB) SBI: OpenSBI v1.2, SBI Specification Version 1.0 random: boothowto does not indicate good seed mainbus0 at root: StarFive VisionFive V2 cpu0 at mainbus0: SiFive U7 imp 4210427 rv64imafdcbsux intc0 at cpu0 cpu0: 32KB 64b/line 64-way L1 I-cache, 32KB 64b/line 64-way L1 D-cache cpu0: 2048KB 64b/line 2048-way L2 cache "osc" at mainbus0 not configured "gmac1_rmii_refin" at mainbus0 not configured "gmac1_rgmii_rxin" at mainbus0 not configured "i2stx_bclk_ext" at mainbus0 not configured "i2stx_lrck_ext" at mainbus0 not configured "i2srx_bclk_ext" at mainbus0 not configured "i2srx_lrck_ext" at mainbus0 not configured "tdm_ext" at mainbus0 not configured "mclk_ext" at mainbus0 not configured "jtag_tck_inner" at mainbus0 not configured "bist_apb" at mainbus0 not configured "stg_apb" at mainbus0 not configured "gmac0_rmii_refin" at mainbus0 not configured "gmac0_rgmii_rxin" at mainbus0 not configured "clk_rtc" at mainbus0 not configured "hdmitx0_pixelclk" at mainbus0 not configured "mipitx_dphy_rxesc" at mainbus0 not configured "mipitx_dphy_txbytehs" at mainbus0 not configured simplebus0 at mainbus0: "soc" syscon0 at simplebus0: "aon_syscon" syscon1 at simplebus0: "stg_syscon" syscon2 at simplebus0: "sys_syscon" plic0 at simplebus0 syscon3 at simplebus0: "dssctrl" "pmu" at simplebus0 not configured "cache-controller" at simplebus0 not configured "clint" at simplebus0 not configured "clock-controller" at simplebus0 not configured "spi" at simplebus0 not configured "otp" at simplebus0 not configured "usbdrd" at simplebus0 not configured "rtc" at simplebus0 not configured "pmu" at simplebus0 not configured com0 at simplebus0: dw16550 com0: console "gpio" at simplebus0 not configured "i2c5" at simplebus0 not configured dwmmc0 at simplebus0: can't establish interrupt dwmmc1 at simplebus0: can't establish interrupt "reset-controller" at simplebus0 not configured "ethernet" at simplebus0 not configured "ethernet" at simplebus0 not configured "snd-card" at simplebus0 not configured "dmc" at simplebus0 not configured gpiorestart0 at mainbus0 "firmware" at mainbus0 not configured
Re: core dumps from latest wireguard-tools
Tried this: pkg_delete wireguard-tools pkg_delete -a(which removes bash-5.2.15) then pkg_add wireguard-tools (which also reinstalls bash-5.2.15) And it resolved the issue on all 3 systems.
groups update
0 C Japan P Niigata F 4 times a year O Echigo BSD Users Group M inqu...@ebug.jp U https://www.ebug.jp N *BSD
Re: core dumps from latest wireguard-tools
Have you tried rebuilding it? On 2023/06/05 09:47, Sonic wrote: > What I find odd is that it dumps core on 3 of the 5 systems but works > fine on the other two. All systems are x64 at OpenBSD 7.3-current > (GENERIC.MP) #1216 with wireguard-tools-1.0.20210914p1v0. > > On Mon, Jun 5, 2023 at 8:51 AM Stuart Henderson > wrote: > > > > On 2023-06-05, Sonic wrote: > > > After upgrading several systems to the latest snapshot this evening > > > most of them are causing core dumps when running wg: > > > > > > # wg > > > Segmentation fault (core dumped) > > > > > > This is with: > > > wireguard-tools-1.0.20210914p1v0 > > > > wireguard-tools had a port REVISION bump, because of an ABI change > > between the kernel and userland relating to wg interfaces. > > > > But it was bumped very soon after the kernel change was committed, > > so there is a good chance that the package build was done on a > > machine which didn't have the new kernel headers, but the ports > > tree was updated to a version after the bump. > > > > Please try rebuilding from /usr/ports/net/wireguard-tools. > > > > If that now works then we need to bump the REVISION again. > > > >
Re: core dumps from latest wireguard-tools
What I find odd is that it dumps core on 3 of the 5 systems but works fine on the other two. All systems are x64 at OpenBSD 7.3-current (GENERIC.MP) #1216 with wireguard-tools-1.0.20210914p1v0. On Mon, Jun 5, 2023 at 8:51 AM Stuart Henderson wrote: > > On 2023-06-05, Sonic wrote: > > After upgrading several systems to the latest snapshot this evening > > most of them are causing core dumps when running wg: > > > > # wg > > Segmentation fault (core dumped) > > > > This is with: > > wireguard-tools-1.0.20210914p1v0 > > wireguard-tools had a port REVISION bump, because of an ABI change > between the kernel and userland relating to wg interfaces. > > But it was bumped very soon after the kernel change was committed, > so there is a good chance that the package build was done on a > machine which didn't have the new kernel headers, but the ports > tree was updated to a version after the bump. > > Please try rebuilding from /usr/ports/net/wireguard-tools. > > If that now works then we need to bump the REVISION again. > >
Re: core dumps from latest wireguard-tools
On 2023-06-05, Sonic wrote: > After upgrading several systems to the latest snapshot this evening > most of them are causing core dumps when running wg: > > # wg > Segmentation fault (core dumped) > > This is with: > wireguard-tools-1.0.20210914p1v0 wireguard-tools had a port REVISION bump, because of an ABI change between the kernel and userland relating to wg interfaces. But it was bumped very soon after the kernel change was committed, so there is a good chance that the package build was done on a machine which didn't have the new kernel headers, but the ports tree was updated to a version after the bump. Please try rebuilding from /usr/ports/net/wireguard-tools. If that now works then we need to bump the REVISION again.
Re: SOLVED [7.3/i386] pf-badhost - Illegal instruction (core dumped)
On 2023-06-05, Radek wrote: > RipGrep caused my issue. When I replaced ripgrep with ggrep the script > started to work fine. Can you try a new ripgrep binary built with a different target-cpu type for me please? The default for the rust compiler is to use SSE instructions which aren't present on your Alix. Either build from ports with the MODCARGO_RUSTFLAGS line changed to this: MODCARGO_RUSTFLAGS =-C debuginfo=0 -C target-cpu=i586 or try the binary at https://junkpile.org/rg If this helps then it might be a good idea to change the default in lang/rust/patches/patch-compiler_rustc_target_src_spec_i686_unknown_openbsd_rs so that other rust programs are compiled that way (currently it uses "pentiumpro" which I understand disables SSE2 but not SSE).
Re: program compiled with clang from base runs 4 times slower than compiled with gcc-11.2.0p6 from ports
On 2023-06-05, Kastus Shchuka wrote: > Next I tried -fno-fixup-gadgets, and that made a radical difference: Not entirely a surprise, we have seen this a few times now. Usually it is fine, but has quite bad effects on some programs, however it is quite a nice mitigation (big reduction in the number of available ROP gadgets in compiled code).
Re: Using pf route-to to Route Network Traffic a tun interface and Replying from it
On Tue, May 30, 2023 at 06:07:32PM +0300, Nick Andersen wrote:
> Hi Folks,
hi.
>
> I am writing to seek assistance regarding an issue I am experiencing in
> trying to route my Personal Computer's network traffic to a TUN interface.
> My objective is to modify some of its content and subsequently return the
> traffic back.
>
> So far, I have successfully created a TUN interface using the following
> configuration:
>
> andersen@pc% ifconfig tun8 inet 172.16.122.1/32 172.16.122.2 up
> andersen@pc% ifconfig tun8
> tun8: flags=8051 mtu 1500
> inet 172.16.122.1 --> 172.16.122.2 netmask 0x
>
>
> Subsequently, I have also inspected the primary Ethernet interface, em0, as
> follows:
>
>
> andersen@pc % ifconfig em0
> em0: flags=8863 mtu 1500
> options=6463
> ether xx:xx:xx:xx:xx:xx
> inet 192.168.1.128 netmask 0xff00 broadcast 192.168.1.255
> nd6 options=201
> media: autoselect
> status: active
>
>
>
> And I've updated pf.conf;
>
> set skip on { lo0 tun8 }
>
> ext_if="em0"
> tun_if="tun8"
>
> # allow dns
> pass in log quick on $ext_if inet proto { tcp udp } from any to any port 53
> pass out log quick on $ext_if inet proto { tcp udp } from any to any port
> 53
>
> pass in log quick on $ext_if
> pass out log quick on $ext_if route-to (tun8 (tun8)) no state
the syntax and semantics for route-to changed before 6.9. are you
running a stable release (ie, 7.2 or preferably 7.3)?
the pf.conf syntax changed so that instead of routing to an interface
with an optional IP address, you route-to a destination IP address. the
semantic change is that route-to relies on states. so you probably want
pass out log quick on $ext_if route-to 172.16.122.2
because pfctl will resolve interface names to ips, you can also use
this:
pass out log quick on $ext_if route-to tun8:peer
> pass out log quick on $tun_if reply-to (em0 (em0))
you have "set skip on tun8" above, which means this rule won't run.
however, you have a problem where you don't want to route-to to
happen to the packets that are being reinjected by your program. i think
the least worst way to do that in this situation is to use the
following:
pass out log quick on $ext_if received-on $tun_if
pass out log quick on $ext_if route-to $tun_if:peer
if you want your program to handle packets in both directions on a
connection, you could have rules like this:
pass out log quick on $ext_if reply-to $tun_if:peer received-on $tun_if
pass out log quick on $ext_if route-to $tun_if:peer
you wont be able to tell the direction of the packets apart if they
all go through the one tun interface though. if you route-to tun8
and reply-to another interface (eg, tun9), then you will be able
to differentiate them based on which tun interface you read them
from.
divert(4) sockets might also work for you depending on what you're
doing. if you're just monitoring packets then there's also dup-to
and bpf/tcpdump.
> --
>
> I implemented a small C program that reads packets from /dev/tun8 and
> writes them back to the same device. During the writing phase, I have
> attempted to add a 4-byte TUN header (with AF_INET byte). The issue arises
> when I enable pf, as my connectivity ceases to function. I suspect that the
> problem may be linked to the reply-to rule. I can accurately read all
> network packets, but my network connectivity is disrupted when I activate
> pf.
>
> Are there any thoughts about what I'm doing wrong?
id leave pf enabled and just change rules.
>
> Thanks!
>
> Here is a sample from pflog;
>
> andersen@pc% sudo tcpdump -nettti pflog0
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>
> listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 246
> bytes
>
> 00:00:00.00 rule 6/0(match): pass out on em0: 192.168.1.128.52553 >
> 17.248.173.70.443: Flags [S], seq 1289016582, win 65535, options [mss
> 1460,nop,wscale 6,nop,nop,TS val 1617830816 ecr 0,sackOK,eol], length 0
>
> 00:00:00.005332 rule 6/0(match): pass out on em0: 192.168.1.128.52569 >
> 17.248.172.107.443: Flags [S], seq 1886843796, win 65535, options [mss
> 1460,nop,wscale 6,nop,nop,TS val 386220006 ecr 0,sackOK,eol], length 0
>
> 00:00:00.178005 rule 6/0(match): pass out on em0: 192.168.1.128.52554 >
> 17.248.172.208.443: Flags [S], seq 3787270145, win 65535, options [mss
> 1460,nop,wscale 6,nop,nop,TS val 1898437799 ecr 0,sackOK,eol], length 0
>
> 00:00:00.079092 rule 6/0(match): pass out on em0: 192.168.1.128.52570 >
> 17.248.173.83.443: Flags [S], seq 606598735, win 65535, options [mss
> 1460,nop,wscale 6,nop,nop,TS val 2940552698 ecr 0,sackOK,eol], length 0
>
> 00:00:00.174093 rule 6/0(match): pass out on em0: 192.168.1.128.52555 >
> 17.248.172.172.443: Flags [S], seq 1449413825, win 65535, options [mss
> 1460,nop,wscale 6,nop,nop,TS val 212268682 ecr 0,sackOK,eol], length 0
>
> 00:00:00.079048 rule 6/0(match): pass out on em0: 192.168.1.128.52571 >
> 17.248.172.135.443: Flags [S], seq 1322915507, win
Re: [7.3/i386] pf-badhost - Illegal instruction (core dumped)
Just realized that if I edit the subject it will create a new thread in marc.info. So.. closing the thread, the solution is here: https://marc.info/?l=openbsd-misc=168594789107213=2 Sorry for the mess. On Sat, 3 Jun 2023 17:37:08 -0500 Andrew Daugherity wrote: > Unfortunately it looks like sh -x does not trace into functions, and > it is something inside "main" which is crashing: > > > > set -x or something. > > Sorry, I should have started with that. > > > > test73# doas -u _pfbadhost pf-badhost -O openbsd > > [ ... ] > > + command -v typeset > > + > /dev/null > > + 2>&1 > > + main -O openbsd > > Illegal instruction > > [ ... ] > > Illegal instruction (core dumped) > > > > No blocklist changes... > > Illegal instruction (core dumped) > > Both sh and ksh seem to behave that way, but bash will trace inside > functions. Try calling the script with 'bash -x' and hopefully you > can pinpoint which binary called by main() is crashing. > > -Andrew > Radek
