Re: pf queue on packets with state
Hi Stuart, thank you for your clear reply
On 2021-02-02 22:41:49, Stuart Henderson wrote:
> Whichever rule creates state for the packets that you want to send
> to a queue should have the queue assignment. The queue name is attached
> to the PF state; when the packet is transmitted outbound it will use
> the queue of that name on that interface.
Yup, that was is. Instead of doing
match out on $i_lan all set queue q_lte_in_http set prio 0
I did it "the opoosite" way
match in on $i_lan all set queue q_lte_in_http set prio 0
Also in my real rules I've changed "from port $p_http" to "to port $p_http",
and it started to match queues as expected. Thank you!
I did read something around these lines on the openbsd forum, that queues
are tied to input state, but I was just trying to do "pass in $i_lan".
It never occured to me to try do 'set queue' during 'in' part. I've read
about queueing in pf.conf(5) and nothing there hints this also.
> You don't want queue names dealing with in/out/interface. Just the type
> of traffic / queue policy / whatever. For example "user1", "user2", ..
> or "http", "dns", .. or "high/med/low" or something.
>
Yes, I am indeed queueing by service dns/ssh/games, but my firewall has
multiple WAN interfaces with different speed so I also must specify this.
In examples I wanted to keep things to bare minimum so people do not have
to waste time thinking what mess I have in my pf.conf :D
> I find it easier to make the match rule setting the queue quite wide,
> then do anything more complex (IP/port restrictions etc) in pass/block
> rules.
> You should use some variant of "block" covering all traffic as your
> first rule ("block" / "block log" etc) so that packets are not allowed
> to pass unless they create state. This makes it easier to figure out
> the queues, and prevents state tracking getting messed up with TCP (the
> TCP state must be created from a SYN packet not an intermediate packet
> otherwise it doesn't know what the window-scaling value is, which will
> cause longer lasting or fast connections to get dropped incorrectly).
That's what I think too, I use pf in "block by default" and have rules
to block everything at top. And I intend to queue packets by service port
or IP.
> > Is there any way to limit ingress on some ips/ports? I'd like to limit
> > greedy apps like youtube or netflix from taking all the bandwidth.
>
> Good luck finding the relevant IPs for these ;) You might like to play
> with "burst" and see if you can do something that way. (e.g. standard
> bandwidth is slower, but allow a fast initial burst). But you'll probably
> need to do that with separate queues per IP and it gets to be a pain.
I found some sites with ip ranges for netflix and youtube, they are quite
broad, but it's better than crippled network.
Thank you again for clarification and explaining this to me.
--
.-.---.-.--.
| Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source |
| +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter |
| https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`--^--^-^--'
signature.asc
Description: PGP signature
Re: pf queue on packets with state
On 2021-02-02, michal.lyszc...@bofc.pl wrote:
> --syjteu3hgkkj7xpe
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
>
> Hi, I'm trying to setup queues on my LTE interface. This machine is firewall
> machine with two interfaces: wan and lan. Egress traffic is queueing without
> a problem. Rules like
>
> match out on $i_wan proto {tcp udp} to any port $p_dns set queue
> q_lte_out_dns set prio 6
>
> work as intended and I can see that rules are being matched in systat queue
> and rules.
>
> Problem is with ingress packets. Yes, I know people say it makes no sense to
> do it, but I belive it can work for TCP traffic. The slower program is
> receiving data, the slower it will ACK, the slower server will be sending
> data, and there should be more space for other packets.
>
> Anyway, it does not seem to work for me. I try the most basic rules:
>
> queue q_lte_in_root on $i_lan bandwidth 20M max 20M qlimit 50
>
> This works as intended, speedtests do indeed show my speed is more or less
> 20Mbit. Now I add 2 more queues, default and for http
>
> queue q_lte_in_std parent q_lte_in_root bandwidth 512K default qlimit 50
> queue q_lte_in_http parent q_lte_in_root bandwidth 512K qlimit 50
>
> And I create match rule:
>
> match out on $i_lan all set queue q_lte_in_http set prio 0
There is a knack to this that pretty much everybody doing queue config
takes a while to figure out - the queue name with "in" is a giveaway
that you didn't find it yet.
Whichever rule creates state for the packets that you want to send
to a queue should have the queue assignment. The queue name is attached
to the PF state; when the packet is transmitted outbound it will use
the queue of that name on that interface.
You don't want queue names dealing with in/out/interface. Just the type
of traffic / queue policy / whatever. For example "user1", "user2", ..
or "http", "dns", .. or "high/med/low" or something.
Simplest match rules are like
match from 192.0.2.1 queue user1
match to 192.0.2.1 queue user1
or
match proto tcp to port 80 queue http
(plus the pass rule to allow it)
I find it easier to make the match rule setting the queue quite wide,
then do anything more complex (IP/port restrictions etc) in pass/block
rules.
> And this rule is matched only by a handful of packets. systat queue
> shows that majority of packets go through q_lte_in_std, and only some
> of the packets go through q_lte_in_http. systat rules also shows only
> some of the packets are being matched by that rule.
>
>
> I don't know, it looks like only packets without state match "match"
> rule and are being queued properly? I know filtering will be skipped
You should use some variant of "block" covering all traffic as your
first rule ("block" / "block log" etc) so that packets are not allowed
to pass unless they create state. This makes it easier to figure out
the queues, and prevents state tracking getting messed up with TCP (the
TCP state must be created from a SYN packet not an intermediate packet
otherwise it doesn't know what the window-scaling value is, which will
cause longer lasting or fast connections to get dropped incorrectly).
> for packets that have state but queueing is not skipped. So why can't
> I queue packets ingressing on LTE that are being egressed on LAN
> interface?
>
> Is there any way to limit ingress on some ips/ports? I'd like to limit
> greedy apps like youtube or netflix from taking all the bandwidth.
Good luck finding the relevant IPs for these ;) You might like to play
with "burst" and see if you can do something that way. (e.g. standard
bandwidth is slower, but allow a fast initial burst). But you'll probably
need to do that with separate queues per IP and it gets to be a pain.
> I read pf.conf man and searched the whole net but I couldn't find
> answer to my question. I think I could make it work if I made pf
> stateless by default? Performance is not an issue here, machine
> can take it, but I couldn't find a way to do stateless by default.
stateful is the way to go, it just needs the queue assigned in the right
place.
> Any ideas? Maybe I didn't read something carefully enough?
>
>
rsync over ssh, slow speed (700 kB/s) on x230
Hi, on my x230 the rsync over ssh speed is extremly slow - about 700 kB/s over wireless. I don't see a performance issue on the source and target systems. When I reboot to Linux the speed is acceptable - about 12 mB/s over wireless. The compression an ciphers parameters don't have impact to the speed. Interesting is that under OpenBSD in debug mode the lines get printed slowly. 692.05kB/s0:17:16 debug2: channel 0: rcvd adjust 32768 Under Linux the debug lines scroll really fast over the screen debug2: channel 0: rcvd adjust 114688 Do you have any ideas how I can solve the problem? ulimit, openfiles limit etc. don't show any problems. Thanks and best regards, Sven
Re: Bootloader on USB stick fails with "root device not found"
On Tue, Feb 02, 2021 at 07:04:38AM +, tetrahe...@danwin1210.me wrote: > Looking thru the manpages, I don't see any provision for adding AND / OR > logic to keys (e.g require both passphrase AND keydisk to boot, require > passphrase OR keydisk, etc) the way Linux cryptsetup provides, at least, > OR-logic across multiple keyslots. > > (Having multiple keyslots on an encrypted volume has saved me a few times!) > > Is there anything like this in OpenBSD? It is possible to add multiple key disk slices (type RAID) to the same disklabel. This way, a single USB stick could unlock multiple volumes. The idea of protecting key disks with a passphrase (two-factor auth) has been raised before. It has not been implemented yet, simply because nobody has done the work. A search of the mailing list archives should yield some prior discussion. I would also make use of this feature if it was available. I'd be happy to review and test relevant patches.
Re: auto-boot
Le mercredi 27 janvier 2021 à 08:20 -0700, Diana Eichert a écrit : > On Tue, Jan 26, 2021 at 5:30 AM Stuart Longland > wrote: > > > > On 25/1/21 11:40 pm, Bastien Durel wrote: > > > Hello, > > > > > > Short-circuit pins 3-5 using my DB9 cable as Mihai Popescu > > > said[1] > > > worked. > > > Alas, this setup prevent to plug-in the cable on the other side > > > ^^ > > > > > > But this confirm there is an hardware problem. > > The issue is the input RCV line is floating which causes spurious > characters, a > properly designed circuit should not have this issue. > > You really should insert a high ohm valu resistor in the path between > RCV and GND, > this would allow you to build a serial cable that still functions. > Hello again, I bought a pair of these : https://corrin.geekwu.org/owncloud/index.php/s/3Bci6SRDjR9gPgs and tried to put a 1kΩ resistor between pins 3 and 5, then reboot; but the router hanged again. I tried with pins 1-3 to make sure it was not a male/female numbering problem, but with no more success :( Worse : it did not boot with a wire between ports 3-5 (nor 1-5) Is there some other wiring to do to get the plug working ? (I tried to make it work before I plug actual cable, but maybe it's not possible ?) Thanks, PS: is 1kΩ enough ? I don't know if it's actually "high value" -- Bastien
pf queue on packets with state
Hi, I'm trying to setup queues on my LTE interface. This machine is firewall
machine with two interfaces: wan and lan. Egress traffic is queueing without
a problem. Rules like
match out on $i_wan proto {tcp udp} to any port $p_dns set queue
q_lte_out_dns set prio 6
work as intended and I can see that rules are being matched in systat queue
and rules.
Problem is with ingress packets. Yes, I know people say it makes no sense to
do it, but I belive it can work for TCP traffic. The slower program is
receiving data, the slower it will ACK, the slower server will be sending
data, and there should be more space for other packets.
Anyway, it does not seem to work for me. I try the most basic rules:
queue q_lte_in_root on $i_lan bandwidth 20M max 20M qlimit 50
This works as intended, speedtests do indeed show my speed is more or less
20Mbit. Now I add 2 more queues, default and for http
queue q_lte_in_std parent q_lte_in_root bandwidth 512K default qlimit 50
queue q_lte_in_http parent q_lte_in_root bandwidth 512K qlimit 50
And I create match rule:
match out on $i_lan all set queue q_lte_in_http set prio 0
And this rule is matched only by a handful of packets. systat queue
shows that majority of packets go through q_lte_in_std, and only some
of the packets go through q_lte_in_http. systat rules also shows only
some of the packets are being matched by that rule.
I don't know, it looks like only packets without state match "match"
rule and are being queued properly? I know filtering will be skipped
for packets that have state but queueing is not skipped. So why can't
I queue packets ingressing on LTE that are being egressed on LAN
interface?
Is there any way to limit ingress on some ips/ports? I'd like to limit
greedy apps like youtube or netflix from taking all the bandwidth.
I read pf.conf man and searched the whole net but I couldn't find
answer to my question. I think I could make it work if I made pf
stateless by default? Performance is not an issue here, machine
can take it, but I couldn't find a way to do stateless by default.
Any ideas? Maybe I didn't read something carefully enough?
--
.-.---.-.--.
| Michal Lyszczek | Embedded C, Linux | Company Address | .-. open source |
| +48 727 564 419 | Software Engineer | Leszczynskiego 4/29 | oo| supporter |
| https://bofc.pl `.--: 50-078 Wroclaw, Pol | /`'\ & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer |
`--^--^-^--'
signature.asc
Description: PGP signature
Re: Keyboard on raspberry pi rpi3b not working
I have a similar situation with a Logitech G series keyboard. From reading man pages for usb, usbhid, wscons, ect. I'm able to get the keyboard input using usbhidctl(8) and if I leave this program running I I'm able to use my external keyboard. Does anyone know how to have the keyboard automatically work? bash-5.0 # usbhidctl -f /dev/uhid5 -v -r Report descriptor: Collection page=Consumer usage=Consumer_Control Input size=1 count=1 page=Consumer usage=Scan_Next_Track, logical range 0..1 Input size=1 count=1 page=Consumer usage=Scan_Previous_Track, logical range 0..1 Input size=1 count=1 page=Consumer usage=Stop, logical range 0..1 Input size=1 count=1 page=Consumer usage=Play/Pause, logical range 0..1 Input size=1 count=1 page=Consumer usage=Mute, logical range 0..1 Input size=1 count=1 page=Consumer usage=Volume_Increment, logical range 0..1 Input size=1 count=1 page=Consumer usage=Volume_Decrement, logical range 0..1 Input size=1 count=1 Const page=0x usage=0x, logical range 0..1 End collection Total input size 1 bytes Total output size 0 bytes Total feature size 0 bytes bash-5.0 # usbhidctl -f /dev/uhid5 -a -v usbhidctl: USB_GET_REPORT (probably not supported by device): Input/output error bash-5.0 # usbhidctl -f /dev/uhid5 -l Consumer_Control.Scan_Next_Track=0 Consumer_Control.Scan_Previous_Track=0 Consumer_Control.Stop=0 Consumer_Control.Play/Pause=0 Consumer_Control.Mute=0 Consumer_Control.Volume_Increment=0 Consumer_Control.Volume_Decrement=0 Hello world, from USB external keyboard! bash-5.0 # #keyboard now works in a new terminal Here's my relevant dmesg output: uhub9 at uhub8 port 2 configuration 1 interface 0 "GenesysLogic USB2.0 Hub" rev 2.00/22.16 addr 3 uhub9: device problem, disabling port 2 uhidev0 at uhub9 port 1 configuration 1 interface 0 "Logitech Gaming Mouse G402" rev 2.00/90.02 addr 4 uhidev0: iclass 3/1 ums0 at uhidev0: 16 buttons, Z and W dir wsmouse1 at ums0 mux 0 uhidev1 at uhub9 port 1 configuration 1 interface 1 "Logitech Gaming Mouse G402" rev 2.00/90.02 addr 4 uhidev1: iclass 3/0, 17 report ids ukbd0 at uhidev1 reportid 1: 8 variable keys, 6 key codes wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 uhid2 at uhidev1 reportid 16: input=6, output=6, feature=0 uhid3 at uhidev1 reportid 17: input=19, output=19, feature=0 On Sun, Jun 21, 2020 at 03:34:44PM -0700, openbsdtai123 wrote: Dear Theo, Hello, I would like that my keyboard G213 works, but unfortunately, it doesnt. Please find my dmesg. I am looking forward to reading you. Best regards Openbsd user OpenBSD 6.7 (GENERIC.MP) #602: Thu May 7 13:45:48 MDT 2020 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 958754816 (914MB) avail mem = 899207168 (857MB) mainbus0 at root: Raspberry Pi 3 Model B Rev 1.2 cpu0 at mainbus0 mpidr 0: ARM Cortex-A53 r0p4 cpu0: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu0: 512KB 64b/line 16-way L2 cache efi0 at mainbus0: UEFI 2.8 efi0: Das U-Boot rev 0x20200100 apm0 at mainbus0 simplefb0 at mainbus0: 1824x984, 32bpp wsdisplay0 at simplefb0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) "system" at mainbus0 not configured "axi" at mainbus0 not configured simplebus0 at mainbus0: "soc" bcmdmac0 at simplebus0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10 bcmclock0 at simplebus0 bcmmbox0 at simplebus0 bcmgpio0 at simplebus0 bcmaux0 at simplebus0 bcmintc0 at simplebus0 bcmdog0 at simplebus0 bcmrng0 at simplebus0 pluart0 at simplebus0: console bcmsdhost0 at simplebus0: 250 MHz base clock sdmmc0 at bcmsdhost0: 4-bit, sd high-speed, mmc high-speed, dma "dsi" at simplebus0 not configured dwctwo0 at simplebus0 bcmtemp0 at simplebus0 "local_intc" at simplebus0 not configured sdhc0 at simplebus0 sdhc0: SDHC 3.0, 200 MHz base clock sdmmc1 at sdhc0: 4-bit, sd high-speed, mmc high-speed simplebus1 at simplebus0: "firmware" "expgpio" at simplebus1 not configured "power" at simplebus0 not configured "mailbox" at simplebus0 not configured "gpiomem" at simplebus0 not configured "fb" at simplebus0 not configured "vcsm" at simplebus0 not configured "virtgpio" at simplebus0 not configured simplebus2 at mainbus0: "clocks" "clock" at simplebus2 not configured "clock" at simplebus2 not configured "phy" at mainbus0 not configured "arm-pmu" at mainbus0 not configured agtimer0 at mainbus0: tick rate 19200 KHz "leds" at mainbus0 not configured "fixedregulator_3v3" at mainbus0 not configured "fixedregulator_5v0" at mainbus0 not configured cpu1 at mainbus0 mpidr 1: ARM Cortex-A53 r0p4 cpu1: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu1: 512KB 64b/line 16-way L2 cache cpu2 at mainbus0 mpidr 2: ARM Cortex-A53 r0p4 cpu2: 32KB 64b/line 2-way L1 VIPT I-cache, 32KB 64b/line 4-way L1 D-cache cpu2: 512KB 64b/line 16-way L2 cache cpu3 at mainbus0 mpidr 3: ARM Cortex-A53 r0p4
Unknown process modifying routing table
Hi all, My routing table is being modified by an unknown process. I have system accounting enabled and I'm monitoring route changes but the PID of the process reported by `route monitor` is always 0 for these unknown changes. I've seen my default route (VPN) being deleted and new routes being added for specific IPs. I'm out of ideas how to find out what process is modifying my routing table. Here are the logs: bash-5.0# route -n show Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface default10.0.0.1 UGS 15 635 - 8 pair1 224/4 127.0.0.1 URS00 32768 8 lo0 10.0.0/24 10.0.0.2 UCn10 - 4 pair1 10.0.0.1 xx:xx:xx:xx:xx:xx UHLch 20 76 - 3 pair1 10.0.0.2 xx:xx:xx:xx:xx:xx UHLl 0 251 - 1 pair1 10.0.0.255 10.0.0.2 UHb00 - 1 pair1 10.2.0.1 10.0.0.1 UGHD 1 599 - L 8 pair1 13.35.193.117 10.0.0.1 UGHD 1 616 - L 8 pair1 13.224.227.64 10.0.0.1 UGHD 1 611 - L 8 pair1 52.48.109.111 10.0.0.1 UGHD 1 614 - L 8 pair1 52.84.91.7 10.0.0.1 UGHD 1 574 - L 8 pair1 99.84.5.23010.0.0.1 UGHD 1 620 - L 8 pair1 104.16.9.251 10.0.0.1 UGHD 0 289 1350 8 pair1 104.16.241.18 10.0.0.1 UGHD 1 610 - L 8 pair1 104.18.26.20 10.0.0.1 UGHD 1 609 - L 8 pair1 104.21.22.28 10.0.0.1 UGHD 1 617 - L 8 pair1 108.177.120.13610.0.0.1 UGHD 1 625 - L 8 pair1 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 8 7322 32768 1 lo0 140.82.121.3 10.0.0.1 UGHD 1 636 - L 8 pair1 142.250.186.12910.0.0.1 UGHD 1 604 - L 8 pair1 157.230.120.63 10.0.0.1 UGHD 1 596 - L 8 pair1 172.67.203.118 10.0.0.1 UGHD 1 607 - L 8 pair1 172.217.169.86 10.0.0.1 UGHD 1 632 - L 8 pair1 185.199.111.15410.0.0.1 UGHD 2 633 - L 8 pair1 216.58.206.132 10.0.0.1 UGHD 1 624 - L 8 pair1 216.58.212.227 10.0.0.1 UGHD 1 629 - L 8 pair1 Internet6: DestinationGatewayFlags Refs Use Mtu Prio Iface ::/96 ::1UGRS 0 0 32768 8 lo0 ::1::1UHhl 10 32 32768 1 lo0 :::0.0.0.0/96 ::1UGRS 0 0 32768 8 lo0 2002::/24 ::1UGRS 0 0 32768 8 lo0 2002:7f00::/24 ::1UGRS 0 0 32768 8 lo0 2002:e000::/20 ::1UGRS 0 0 32768 8 lo0 2002:ff00::/24 ::1UGRS 0 0 32768 8 lo0 fe80::/10 ::1UGRS 0 0 32768 8 lo0 fec0::/10 ::1UGRS 0 0 32768 8 lo0 fe80::1%lo0fe80::1%lo0UHl0 0 32768 1 lo0 ff01::/16 ::1UGRS 5 5 32768 8 lo0 ff01::%lo0/32 fe80::1%lo0Um 0 1 32768 4 lo0 ff02::/16 ::1UGRS 5 5 32768 8 lo0 ff02::%lo0/32 fe80::1%lo0Um 0 1 32768 4 lo0 The routes for 216.58.212.227, 216.58.206.132, 185.199.111.154, 172.217.169.86, 172.67.203.118, 157.230.120.63, 142.250.186.129, 140.82.121.3, 108.177.120.136, 104.21.22.28, 104.18.26.20, 104.16.241.18, 104.16.9.251, 99.84.5.230, 52.48.109.111, 52.84.5.230, 13.224.227.64, 13.35.193.117 are completely unknown and not added by myself. bash-5.0# route monitor got message of size 176 on Tue Jan 26 13:13:16 2021 RTM_DELETE: Delete Route: len 176, priority 8, table 0, if# 8, name pair1, pid: 0, seq 0, errno 0 flags: fmask: use:0 mtu:0expire:0 locks: inits: sockaddrs: 172.67.203.118 10.0.0.1 xx:xx:xx:xx:xx:xx 10.0.0.2 got message of size 176 on Tue Jan 26 13:13:16 2021 RTM_DELETE:
Re: rdsetroot and gzip'd bsd.rd
On Mon, Feb 01, 2021 at 08:30:17PM -0500, Daniel Jakots wrote:
> On Mon, 01 Feb 2021 18:18:43 -0700, "Theo de Raadt"
> wrote:
>
> > Should rdsetroot be able to edit gzip'd files? I am not sure about
> > that.
>
> Yeah, I don't think so either. gzip(1) can be easily used to uncompress
> it beforehand.
>
> But the result is still that rdsetroot on -current is not able to
> extract a bsd.rd even when given an uncompressed bsd.rd (i.e. a "ELF
> 64-bit LSB executable, x86-64, version 1" bsd.rd).
>
I looked at what it is done for amd64/ramdisk_cd
bsd.rd target is made from bsd (kernel) + mr.fs (rdboot filesystem) with
rdsetroot(8)
bsd.gz target is made from bsd.rd with strip(1) + gzip(1).
with current method, it is bsd.gz which is installed in RELEASEDIR as
bsd.rd file.
the problem is rdsetroot(8) doesn't support extracting the mr.fs part
from image when the image is stripped: it expects to find
"rd_root_size" and "rd_root_image" symbols to locate the size and the
offset of the mr.fs part inside the image.
It is possible to use strip with -K rd_root_size -K rd_root_image
option to preserve these specifics symbols (and make rdsetroot -x to
work again). I tested it successfully on i386.
diff a6394f126ec0ed0606e8aac07a82ab1a4c4f2988 /home/semarie/repos/openbsd/src
blob - 77fdc3e10fc525e725a40528b728c06976eefc06
file + distrib/i386/ramdisk_cd/Makefile
--- distrib/i386/ramdisk_cd/Makefile
+++ distrib/i386/ramdisk_cd/Makefile
@@ -56,8 +56,8 @@ MRMAKEFSARGS= -o disklabel=${MRDISKTYPE},minfree=0,den
bsd.gz: bsd.rd
cp bsd.rd bsd.strip
- strip bsd.strip
- strip -R .comment -R .SUNW_ctf bsd.strip
+ strip -K rd_root_size -K rd_root_image bsd.strip
+ strip -K rd_root_size -K rd_root_image -R .comment -R .SUNW_ctf
bsd.strip
gzip -9cn bsd.strip > bsd.gz
bsd.rd: mr.fs bsd
Please note that the second strip call need -K option too, else the
symtab is removed. I am a bit surprised by this behaviour.
I am unsure I will be able to provide a patch for all
architectures. Please comment if the direction is right or not.
Thanks.
--
Sebastien Marie
OpenMPI 4.0.5 segfault with mpi_file_open() [ OpenBSD 6.8 release & current ]
Hello everyone,
I'm all new to the OpenBSD world and decided to go full OpenBSD on my
thinkpad (T480). Yesterday, I installed devel/openmpi from packages
but it is not
working as expected (I'm surely doing something wrong as my tests are
extremely basic and are working on a linux live image).
Those are the steps I did after installing OpenBSD 6.8 - AMD64
(RELEASE or CURRENT) with default disk layout:
$> pkg_add gcc g95 openmpi gdb
$> mpirun --version
mpirun (Open MPI) 4.0.5
$> mpicc --version
egcc (GCC) 8.4.0
## Program I'm trying to run: mpitest.c ##
/* MPI test creating file */
#include
#include
#include
int main(int argc, char *argv[])
{
MPI_File fh;
int rank, sze;
MPI_Init(NULL,NULL);
MPI_Comm_rank(MPI_COMM_WORLD, );
MPI_Comm_size(MPI_COMM_WORLD, );
printf("This is process %d / %d\n", rank+1, sze);
if(MPI_File_open(MPI_COMM_WORLD, "test.txt",
MPI_MODE_CREATE|MPI_MODE_WRONLY,
MPI_INFO_NULL, ))
{
printf("Unable to create file \"test.txt\" ...");
fflush(stdout);
}
else
{
MPI_File_close();
}
MPI_Finalize();
return 0;
}
## RUN PROGRAM:
According to /usr/local/share/doc/pkg-readmes/openmpi:
$> export OMPI_MCA_btl=self,tcp,vader
$> export OMPI_MCA_mpi_yield_when_idle=1
$> export PMIX_MCA_gds=hash
$> mpicc -o mpitest mpitest.c
$> mpirun -np 1 -H localhost:1 ./mpitest
This is process 1/1
[test:31721] *** Process received signal ***
[test:31721] Signal: Segmentation fault (11)
[test:31721] Signal code: Address not mapped (1)
[test:31721] Failing at address: 0x130
-
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job hase beed aborted.
-
-
mpirun noticed that process rank 0 with PID 0 on node test exited on
signal 11 (Segmentation fault)
## END RUN PROGRAM
## RESULT OF GDB BACKTRACE ##
$> egdb ./mpitest
(...)
(gdb) run
Starting program: /home/test/mpitest
[New process 47898]
This is process 1/1
[New thread 123113]
[New thread 580170]
Thread 1 received signal SIGSEGV, Segmentation fault.
0x00a58bd673c3 in mca_common_ompio_file_close() from
/usr/local/lib/libmca_common_ompio.so.2.0
(gdb) backtrace
#0 0x00a58bd673c3 in mca_common_ompio_file_close () from
/usr/local/lib/libmca_common_ompio.so.2.0
#1 0x00a5ba9f15dc in mca_io_ompio_file_close () from
/usr/local/lib/openmpi/mca_io_ompio.so
#2 0x00a5268c572c in file_destructor () from
/usr/local/lib/libmpi.so.5.0
#3 0x00a5268c5cb9 in ompi_file_open () from
/usr/local/lib/libmpi.so.5.0
#4 0x00a5268ef055 in PMPI_File_open () from
/usr/local/lib/libmpi.so.5.0
#5 0x00a2c7864e5c in main ()
## END GDB RESULT ##
## FORTRAN TEST
I tried the same example using fortran (Fortran program not shown):
$> mpifort --version
GNU Fortran (GCC) 8.4.0
$> mpifort -o fmpitest fmpitest.f90
$> mpirun -np 1 -H localhost:1 ./fmpitest
fmpitest:/usr/local/lib/libmpi.so.5.0: ./fmpitest : WARNING:
symbol(mpi_fortran_statuses_ignore_) size mismatch,
relink your program
fmpitest:/usr/local/lib/libmpi.so.5.0: ./fmpitest : WARNING:
symbol(mpi_fortran_status_ignore_) size mismatch,
relink your program
Program received signal SIGSEGV: Segmentation fault -
invalid memory reference
(...)
## END OF FORTRAN TEST
## QUESTIONS
** Could anyone tell me what I'm doing wrong as those codes are compiling
fine on linux liveUSB ?
** Are those warnings from openmpi-fortran safe to ignore?
Thank you very much!
Martin
$> uname -a
OpenBSD test.localhost 6.8 GENERIC.MP#98 amd64
PS: These errors appear in OpenBSD 6.8 Release OR Current
(1 snapshot per day tested for the last 5 days) on my thinkpad.
Re: umount at boot possible?
Thanks for the prompt reply. I will do what you suggested and report back. > Sent: Tuesday, February 02, 2021 at 2:38 PM > From: "Paul de Weerd" > To: "misc nick" > Cc: "misc" > Subject: Re: umount at boot possible? > > On Tue, Feb 02, 2021 at 01:30:28PM +0100, misc nick wrote: > | Hello > | > | I have a separate disk that i was mounting as a nfs partition. That disk > crashed (it was very old). Now that OpenBSD 6.7/i386 release system cannot > boot because it can't mount the disk. > | Is it possible to umount the partition or somehow skip mounting it at boot > time and continue booting from the disk that contains the OS? > > Before loading the OpenBSD kernel, at the bootloader type `boot -s`. > This boots the system in single user mode. Now you can manually mount > the root filesystem (`mount -u -w /`), and you can then fix your > /etc/fstab to exclude the broken disk. > > Note that in single user mode, many userland tools are not available > if /usr is on a separate partition (which is a sane default). You'll > have to fix /etc/fstab with tools like cat and ed, or mount /usr. > > Once things are fixed, unmount everything that you manually mounted, > and remount the root filesystem read-only again (`mount -u -r /`). > Then exit the single user shell, the system should continue booting > from there. > > Cheers, > > Paul 'WEiRD' de Weerd > > -- > >[<++>-]<+++.>+++[<-->-]<.>+++[<+ > +++>-]<.>++[<>-]<+.--.[-] > http://www.weirdnet.nl/ >
Re: umount at boot possible?
On Tue, Feb 02, 2021 at 01:30:28PM +0100, misc nick wrote: | Hello | | I have a separate disk that i was mounting as a nfs partition. That disk crashed (it was very old). Now that OpenBSD 6.7/i386 release system cannot boot because it can't mount the disk. | Is it possible to umount the partition or somehow skip mounting it at boot time and continue booting from the disk that contains the OS? Before loading the OpenBSD kernel, at the bootloader type `boot -s`. This boots the system in single user mode. Now you can manually mount the root filesystem (`mount -u -w /`), and you can then fix your /etc/fstab to exclude the broken disk. Note that in single user mode, many userland tools are not available if /usr is on a separate partition (which is a sane default). You'll have to fix /etc/fstab with tools like cat and ed, or mount /usr. Once things are fixed, unmount everything that you manually mounted, and remount the root filesystem read-only again (`mount -u -r /`). Then exit the single user shell, the system should continue booting from there. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
umount at boot possible?
Hello I have a separate disk that i was mounting as a nfs partition. That disk crashed (it was very old). Now that OpenBSD 6.7/i386 release system cannot boot because it can't mount the disk. Is it possible to umount the partition or somehow skip mounting it at boot time and continue booting from the disk that contains the OS? Thanks in advance
Re: Bootloader on USB stick fails with "root device not found"
On Sun, Jan 31, 2021 at 12:06:37PM +0100, Stefan Sperling wrote: On Sun, Jan 31, 2021 at 11:47:04AM +0100, Stefan Sperling wrote: In general, crypto softraid volumes don't auto-assemble. I forgot that softraid volumes that use a key disk instead of a passphrase will auto-assemble. Have you already tried that? A disklabel slice on the USB key could act as a key disk for the encrypted volume on the internal disk. Thanks, that's a very interesting idea, I will try that and let you know. Looking thru the manpages, I don't see any provision for adding AND / OR logic to keys (e.g require both passphrase AND keydisk to boot, require passphrase OR keydisk, etc) the way Linux cryptsetup provides, at least, OR-logic across multiple keyslots. (Having multiple keyslots on an encrypted volume has saved me a few times!) Is there anything like this in OpenBSD?
Re: bgpd not including MED attribute on updates
Hello Claudio,
Thank you for the clarification. Your suggestion works splendidly.
On Thu, Jan 28, 2021 at 3:12 PM Claudio Jeker
wrote:
> On Thu, Jan 28, 2021 at 02:51:33PM +0100, open...@kene.nu wrote:
> > In my case MED is changed with + on every eBGP hop. I use it to
> > calculate the total MED over several hops to decide the best path from a
> > latency point of view.
> >
> > My intention with listing the advertised prefix from R1 was to show that
> > there is a MED present. As per the tcpdump I did, the MED attribute is
> not
> > included in the BGP update packets. This I have confirmed is the case for
> > all prefixes on R1 that has an iBGP nexthop. Any prefixes that in R1 has
> an
> > eBGP nexthop advertises MED as expected.
> >
> > The "bgpd -vn" for R1:
> >
> > AS 64660
> > router-id 172.30.37.1
> > socket "/var/run/bgpd.sock.0"
> > holdtime 9
> > rde med compare always
> > nexthop qualify via bgp
> >
> > prefix-set "internal" {
> >
> > }
> >
> > rde rib Adj-RIB-In no evaluate
> > rde rib Loc-RIB rtable 0 fib-update yes
> >
> > neighbor 172.30.1.54 {
> > descr "R2"
> > remote-as 64840
> > enforce neighbor-as yes
> > enforce local-as yes
> > announce IPv4 unicast
> > }
> >
> > group "rr" {
> > neighbor 172.30.37.25 {
> > descr "rr1"
> > remote-as 64660
> > local-address 172.30.37.1
> > enforce neighbor-as no
> > enforce local-as yes
> > announce IPv4 unicast
> > }
> > neighbor 172.30.37.39 {
> > descr "rr2"
> > remote-as 64660
> > local-address 172.30.37.1
> > enforce neighbor-as no
> > enforce local-as yes
> > announce IPv4 unicast
> > }
> > }
> >
> > deny from any
> > deny to any
> > allow to ebgp prefix-set "internal"
> > allow to ibgp prefix-set "internal"
> > allow from ebgp prefix-set "internal"
> > allow from group "rr" prefix-set "internal"
> > match to ibgp set { nexthop self }
> > match from 172.30.1.54 set { metric +23 }
>
> Any route learned via rr1 or rr2 will not pass the MED on to R2 because
> the system does not touch the MED and therefor bgpd considers the received
> MED from rr1 and rr2 to have originated from outside and so it is excluded
> from UPDATES to EBGP peers.
>
> You should add a 'maych from ibgp set med +0' rule which makes MED learned
> via IBGP to be considered to be sent out.
>
> > On Thu, Jan 28, 2021 at 2:01 PM Claudio Jeker
> > wrote:
> >
> > > On Thu, Jan 28, 2021 at 12:41:29PM +0100, open...@kene.nu wrote:
> > > > Hello,
> > > >
> > > > I am experiencing this on 6.8, fully syspatched.
> > > >
> > > > root@R1():~ # uname -a
> > > > OpenBSD R1 6.8 GENERIC.MP#4 amd64
> > > >
> > > > The problem is that R1 sends updates with MED set to 0 even though I
> > > expect
> > > > it not to be. Upon reviewing a tcpdump pcap taken at R2, the MED
> > > attribute
> > > > is not even included in said update sent from R1.
> > > >
> > > > This only applies to some, not all updates, in my case it seems to
> affect
> > > > routes where R1 has an ospf discovered nexthop. (172.30.37.2)
> > > >
> > > > root@R1():~ # route -n get 172.30.37.2 | grep priority
> > > >priority: 32 (ospf)
> > > >
> > > > root@R1():~ # route -n get 172.30.1.110 | grep priority
> > > >priority: 8 (static)
> > > >
> > > > root@R1():~ # bgpctl sh ip bgp neigh R2 out | egrep
> "172.30.194.[1234]"
> > > > * N 172.30.194.1/32 172.30.1.110 100 210 64750 i
> > > > * N 172.30.194.2/32 172.30.37.2 100 251 64750 i
> > > > * N 172.30.194.3/32 172.30.1.110 100 210 64750 i
> > > > * N 172.30.194.4/32 172.30.1.110 100 210 64750 i
> > > >
> > > > root@R2():~ $ bgpctl sh ip bgp neigh R1 in | egrep
> "172.30.194.[1234]"
> > > > * N 172.30.194.1/32 172.30.1.55100 210 64660
> 64750
> > > i
> > > > * N 172.30.194.2/32 172.30.1.55100 0 64660
> 64750
> > > i
> > > > * N 172.30.194.3/32 172.30.1.55100 210 64660
> 64750
> > > i
> > > > * N 172.30.194.4/32 172.30.1.55100 210 64660
> 64750
> > > i
> > >
> > > Please remember that MED is not really a transitive attribute. It only
> > > hops into an AS but not accross it. So a MED recv from an EBGP session
> is
> > > not forwarded. If the MED is changed (e.g. set med +1 -- maybe set med
> +0
> > > works as well, don't remember) then the MED will be passed on.
> > > From the output the session between R1 and R2 is EBGP so it very much
> > > depends on your filter rules. If the MED was changed by the ruleset it
> > > will be sent if not it will be filtered.
> > >
> > > With the limited information it is not really possible to know. Note,
> the
> > > adj-rib-out output on R1 shows the prefix before the attribute is
> stripped.
> > > Also the ASPATH prepend happens then.
> > >
> > > --
> > > :wq Claudio
> > >
>
> --
> :wq Claudio
>
