Re: [7.3/i386] pf-badhost - Illegal instruction (core dumped)
I realize he shared it here, but this an OpenBSD mailing list. I strongly suggest you contact the author, don't just "hope" he regularly monitors this list. I've contacted him before at his email address and he was very prompt in reply. 73 diana KI5PGJ On May 30, 2023 8:05:04 AM MDT, Radek wrote: >Hello and sorry for the late reply, > >> Did you contact the individual who provides pf-bafhost script? He has >> always responded to me when I contacted him. >No, I didn't. Jordan shared his scripts here, I hope he reads misc@. >
NFS mounted but shows nothing even df -h has it
Hello, I have OpenBSD 7.2 installed and NFS service running on Cubieboard2, one Linux client and one MacOS client, everything works fine for the last 6 months. Yesterday as usual I mounted NFS share and showed mounting successfully even command `df -h` got it, but `ls /Users/jazzi/nfs` showed nothing. Tried on both Linux and MacOS. OpenBSD is 24*7 running and I didn't do anything to change the system, maybe it's too hot so I shut it down for the whole night and power on the next day but it didn't work. +++ Here is how I mount it on MacOS: > sudo mount -t nfs -o > resvport,async,nolocks,locallocks,soft,wsize=32768,rsize=32768 > 192.168.31.231:/mnt/hdd /Users/jazzi/nfs +++ Here is the settings on OpenBSD NFS server: # $ cat /etc/exports # For Macbook Air /mnt/hdd -alldirs -mapall=root 192.168.31.76 # For Linux desktop /mnt/hdd -alldirs -mapall=root 192.168.31.77 Any help will be appreciated, thank you. -- jazzi Best Regard,
Re: Route based IPsec
> On 27 May 2023, at 21:40, Stuart Henderson wrote: > > On 2023-05-27, Valdrin MUJA wrote: >>Does OpenBSD have routed based IPsec support? > > Not yet. while you wait, it might be possible to configure a gif tunnel protected by ipsec transport mode. dlg
OT: Thank you for a second to none documentation in OpenBSD!!!
Hi, I just wanted to take a moment to give you guys thanks big time! I guess I have been spoiled for the last 2+ decades using OpenBSD and always find what I need in the man pages and rarely needed to search the web for additional info. Even for a noob trying OpenBSD I realize how easy it is and how much the docs provide what's needed and even the FAQ are very useful and get get anyone form nothing to a full system quickly just by some right to the point reading! Now how this come may be as a surprise, well in all fairness I have been trying on/off to test NixOS, sure I have to also come clean and say the last time I touch Linux was more then 20 years ago. So things changes and when I discover OpenBSD, I never looked back. I run my businesses with it and it always been loyal to me big time! Where people say, well it not as fast then Linux, or what not, I say, I don't care I put more systems in place and it does the job. It's easier for me that way and it just work! But now that I am really trying to give a fair shut to NixOS, not a bad system sure, but the DOCS SUCK!!! Try to find something gin the man page on the local system well good luck. Try to find how to configure things the way you want good luck. Sure there is docs, don't get me wrong, but it is useful for the one that really don't need them! May be it's just me and I will admit, I have VERY HIGH expectation from docs as that's what I am used too and I just realize that I have been spoiled big time and for this I really needed to say it and thanks needed to be given. Many many thanks for the great work done not only on the system, but the docs as well! Like the say is, you never know what you had until you loose it! Docs in OpenBSD is incredibly well done. And as it's been said in the project, if there is mistake in the docs, it's consider a bug, then if I apply that to NixOS, it is so full of bugs that it is sad... Sure after I get use to it and play with it for a year may be I will fell comfortable again, but the point here is that, docs in OpenBSD doesn't need for you to invest years and spend weeks full time to get to a point that is good. Sure I am not so young anymore so I guess I don't learn as fast as i used to, but man the system is so clean and docs are so good, that trying something new makes it painful! Thank you guys! You did such a wonderful work over the years, you may not realise how different and beautiful it is or may be you know it. I just wanted to take the time to thank you all! Specially Nick, as when I started he was the one in change of the FAQ on the site and he started a work that was second to none and made me fall in love with OpenBSD then. Please just don't stop. way to many times there is winning on misc@, but know that many may be silent, but we do appreciate your work and gift to the community big time. I always loved it and new it was great here, but never realize how much better it was until I had to actually try to do the same on other systems. I have been spoiled to the point that at my age now trying something else makes me sick! Thank you a million times! Best regards, Daniel
Using pf route-to to Route Network Traffic a tun interface and Replying from it
Hi Folks,
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
pass out log quick on $tun_if reply-to (em0 (em0))
--
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?
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 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 1857621092 ecr 0,sackOK,eol], length 0
00:00:00.251641 rule 6/0(match): pass out on em0: 192.168.1.128.52572 >
17.248.173.70.443: Flags [S], seq 445446, win 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 2056755864 ecr 0,sackOK,eol], length 0
00:00:00.257416 rule 6/0(match): pass out on em0: 192.168.1.128.52573 >
17.248.172.208.443: Flags [S], seq 1732485582, win 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 1481034375 ecr 0,sackOK,eol], length 0
00:00:00.251107 rule 6/0(match): pass out on em0: 192.168.1.128.52574 >
17.248.172.172.443: Flags [S], seq 3829285313, win 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 2878347929 ecr 0,sackOK,eol], length 0
00:00:00.013117 rule 6/0(match): pass out on em0: 192.168.1.128.52558 >
23.53.168.52.443: Flags [S], seq 4080379298, win 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 2646123787 ecr 0,sackOK,eol], length 0
00:00:00.37 rule 6/0(match): pass out on em0: 192.168.1.128.52557 >
23.53.168.52.443: Flags [S], seq 357265796, win 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 4150893962 ecr 0,sackOK,eol], length 0
00:00:02.208051 rule 6/0(match): pass out on em0: 192.168.1.128.52567 >
17.248.173.13.443: Flags [S], seq 3186783538, win 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 119993039 ecr 0,sackOK,eol], length 0
00:00:00.077884 rule 4/0(match): pass in on em0: 192.168.1.1 > 224.0.0.1:
igmp query v2
00:00:00.175705 rule 6/0(match): pass out on em0: 192.168.1.128.52568 >
17.248.172.177.443: Flags [S], seq 1856508746, win 65535, options [mss
1460,nop,wscale 6,nop,nop,TS val 2360328967 ecr 0,sackOK,eol], length 0
00:00:00.255099 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
Re: [7.3/i386] pf-badhost - Illegal instruction (core dumped)
On 2023-05-30, Radek wrote:
> Hello and sorry for the late reply,
>
>> Did you contact the individual who provides pf-bafhost script? He has
>> always responded to me when I contacted him.
> No, I didn't. Jordan shared his scripts here, I hope he reads misc@.
>
>> what program dumped core?
> Some parts of [1]. How can I determine which lines do it?
pf-badhost is a fairly large ksh script which calls a bunch of various
other programs depending on what's present (3 different awks, 4
different file fetching tools, 3 search tools, etc).
It isn't likely to be the script itself which is SIGILLing but one of those
other programs.
What is the name of the core dump file?
>> dmesg?
> cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class)
> 500 MHz, 05-0a-02
> cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
so no SSE, etc.
Re: support of thinkpad arm
BESSOT Jean-Michel writes: > Hello > > I wish to know if the last thinkpad arm will be supported by openbsd > before buying one. > > here the computer: > https://www.lenovo.com/fr/fr/p/laptops/thinkpad/thinkpadx/thinkpad--x13s-(13-inch-snapdragon)/len101t0019 > > what do you know about this ? > A few of us have them, including myself. It's fine if you're looking to hack on arm64 stuff but probably not a great daily driver as we currently lack support for wifi and accelerated graphics. You'd really need to follow -current. If this isn't want you're looking for in a system I would not recommend it currently. -dv
Re: [7.3/i386] pf-badhost - Illegal instruction (core dumped)
Hello and sorry for the late reply,
> Did you contact the individual who provides pf-bafhost script? He has always
> responded to me when I contacted him.
No, I didn't. Jordan shared his scripts here, I hope he reads misc@.
> what program dumped core?
Some parts of [1]. How can I determine which lines do it?
> dmesg?
OpenBSD 7.3 (GENERIC) #0: Wed May 24 13:42:36 CEST 2023
r...@test73.my.domain:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 536363008 (511MB)
avail mem = 509431808 (485MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 20/80/26, BIOS32 rev. 0 @ 0xfac40
pcibios0 at bios0: rev 2.0 @ 0xf/0x1
pcibios0: pcibios_get_intr_routing - function not supported
pcibios0: PCI IRQ Routing information unavailable.
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc8000/0xa800
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
0:20:0: io address conflict 0x6100/0x100
0:20:0: io address conflict 0x6200/0x200
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 6 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
00:00:24:cb:4f:c8
ukphy0 at vr0 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr1 at pci0 dev 7 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 5, address
00:00:24:cb:4f:c9
ukphy1 at vr1 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr2 at pci0 dev 8 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 9, address
00:00:24:cb:4f:ca
ukphy2 at vr2 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
vr3 at pci0 dev 9 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 12, address
00:00:24:cb:4f:cb
ukphy3 at vr3 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 0x004063,
model 0x0034
glxpcib0 at pci0 dev 20 function 0 "AMD CS5536 ISA" rev 0x03: rev 3, 32-bit
3579545Hz timer, watchdog, gpio, i2c
gpio0 at glxpcib0: 32 pins
iic0 at glxpcib0
pciide0 at pci0 dev 20 function 2 "AMD CS5536 IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 1-sector PIO, LBA48, 7629MB, 15625216 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 21 function 0 "AMD CS5536 USB" rev 0x02: irq 15, version 1.0,
legacy support
ehci0 at pci0 dev 21 function 1 "AMD CS5536 USB" rev 0x02: irq 15
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00
addr 1
isa0 at glxpcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbc0: unable to establish interrupt for irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
nsclpcsio0 at isa0 port 0x2e/2: NSC PC87366 rev 9: GPIO VLM TMS
gpio1 at nsclpcsio0: 29 pins
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "AMD OHCI root hub" rev 1.00/1.00
addr 1
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on wd0a (660c82c04771c00d.a) swap on wd0b dump on wd0b
On Thu, 25 May 2023 18:17:49 - (UTC)
Stuart Henderson wrote:
> On 2023-05-25, Radek wrote:
> > Hello,
> > I am getting the following error message when I try to run pf-badhost
> > script [1] at fresh install 7.3/i386. Have I missed something?
> >
> > 1. https://www.geoghegan.ca/pub/pf-badhost/latest/install/openbsd.txt
> >
> > test73# doas -u _pfbadhost pf-badhost -O openbsd
> > doas (r...@test73.my.domain) password:
> > Illegal instruction
> > Illegal instruction
> > Illegal instruction
> > Illegal instruction
> > Illegal instruction
> > Illegal instruction
> > Illegal instruction (core dumped)
> > Illegal instruction (core dumped)
> > Illegal instruction (core dumped)
> > Illegal instruction (core dumped)
> >
> > No blocklist changes...
> > Illegal instruction (core dumped)
>
> dmesg?
>
> what program dumped core?
>
>
Radek
Re: High Interrupt After 7.3 Upgrade
Samuel Jayden [samueljaydan1...@gmail.com] wrote: > Hi again, > > Just for the record: > I've downgraded to OpenBSD 7.2 (reinstalled) and everything is working like > a charm again. > I don't know what is wrong with 7.3 but ipi interrupt rate is too much and > somehow OpenBSD performance is too bad.. > Thanks for reading. > Sounds like you are using 'systat' to measure interrupts. This is a bug in systat was was fixed in 7.3. Here is Scott Cheloha's message from that fix: "systat(1): vmstat: measure elapsed time with clock_gettime(2) instead of ticks The vmstat view in systat(1) should not use statclock() ticks to count elapsed time. First, ticks are low resolution. Second, the statclock is sometimes randomized, so each tick is not necessarily of equal length. Third, we're counting ticks from every CPU on the system, so every rate in the view is divided by the number of CPUs. For example, on an amd64 system with 8 CPUs you currently see: 200 clock ... when the true clock interrupt rate on that system is 1600. Instead, measure elapsed time with clock_gettime(2). Use CLOCK_UPTIME here so we exclude time when the system is suspended. With this change we no longer need "stathz" or "hertz". We can also get rid of the anachronistic secondary clock failure test. Prompted by dlg@ and jmatthew@. deraadt@ says this has been in snaps since 2022-11-21; no complaints. Link: https://marc.info/?l=openbsd-tech=166898960831136=2 ok dlg@ deraadt@"
Re: support of thinkpad arm
> Hello > > I wish to know if the last thinkpad arm will be supported by openbsd > before buying one. > > here the computer: > https://www.lenovo.com/fr/fr/p/laptops/thinkpad/thinkpadx/thinkpad--x13s-(13-inch-snapdragon)/len101t0019 The commit history contains quite a lot of things related to X13s, https://marc.info/?l=openbsd-cvs=2=1=x13s=b so it is being worked on. Can't say usability at this point, but I think one can say there is interest in that box. The 7.2 release notes had: Added support for Lenovo ThinkPad x13s and other machines using the Qualcomm Snapdragon 8cx Gen 3 (SC8280XP) SoC. -- May the most significant bit of your life be positive.
support of thinkpad arm
Hello I wish to know if the last thinkpad arm will be supported by openbsd before buying one. here the computer: https://www.lenovo.com/fr/fr/p/laptops/thinkpad/thinkpadx/thinkpad--x13s-(13-inch-snapdragon)/len101t0019 what do you know about this ? bye
Re: sysctl ddb.trigger
Paul de Weerd: > Indeed, `sysctl kern.securelevel=-1` allows entering DDB with `sysctl > ddb.trigger=1`. (Yes, I am logged in over serial, and that works > well). That was not clear from the ddb manpage, nor from the > securelevel manpage It's in sysctl(2): DBCTL_TRIGGER (ddb.trigger) When DBCTL_CONSOLE is set, writing to DBCTL_TRIGGER causes the system to enter ddb(4). When running with a securelevel(7) greater than 0, the process writing to this variable must be running on the console in order to enter ddb(4). > --- ddb.4 22 Dec 2022 19:53:22 - 1.105 > +++ ddb.4 30 May 2023 06:34:19 - > @@ -46,7 +46,9 @@ is invoked upon a kernel panic when the > is set to 1. > It may be invoked from the console when the sysctl > .Va ddb.console > -is set to 1, using any of the following methods: > +is set to 1 and > +.Va kern.securelevel > +is set to 0 or -1, using any of the following methods: But your problem appears to be that you are invoking it not from the console. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: RSS or Atom syndication for security advisories?
I use https://undeadly.org/errata/errata.rss Seems to work for the last 2 years G On 23/05/2023 13:13, Stuart Henderson wrote: > On 2023/05/23 09:35, Xavier wrote: >> I did not say that. I did not see that you in particular, or anyone in this >> mailing list, make this work. >> As a user, I simply suggest creating an RSS channel for security advisories >> and *even* I offer myself to help. >> >> The intention behind was to improve OpenBSD web. Simply. > The number of people who work on errata, for obvious reasons, needs > to be a small set of people that we know+trust. Sometimes (though > fortunately not all that often) that work is very delicate and needs to > be done quickly but carefully. High stress situation already. > > Adding extra steps to the errata process, to merely provide the same > information which is _already provided_ but just not in the format you > prefer (in the case of pages on www.openbsd.org) and not on the website > you prefer (in the case of the rss feed on undeadly.org), can't be of > more than minor benefit to you, and no benefit to most people who > already receive that information via other methods, yet it adds extra > steps (= work) for every erratum that is produced. > >> Perhaps it's me but I perceived some kind or rudeness in some responses. > After being given a workable answer (the rss feed on undeadly), you didn't > like it and asked volunteers to do even more work than they already do, to > mostly benefit you. Which I think some will consider a bit rude itself. > >> Oh! Come on! Why don't we concentrate in teach reasons and not in "I don't >> want to move my position". Do you think this kind of answer would benefit >> the project? > There's no need to concentrate on tech reasons because it's not a technical > problem. >
Re: sysctl ddb.trigger
Thank you, Stuart, Sebastien and Aaron (and others, off-list).
Indeed, `sysctl kern.securelevel=-1` allows entering DDB with `sysctl
ddb.trigger=1`. (Yes, I am logged in over serial, and that works
well). That was not clear from the ddb manpage, nor from the
securelevel manpage (admittedly, I didn't read that until after the
replies to my mail, since I didn't think securelevel played into
this).
I suggest the below diffs to document this requirement.
Paul
PS: sending BREAK over uplcom still doesn't work, but if I'm reading
Stuart correctly, I think this is because my serial getty runs on
tty00, not on console:
[weerd@pom] $ grep -e console -e tty00 /etc/ttys
console "/usr/libexec/getty std.9600" vt220 off secure
tty00 "/usr/libexec/getty std.115200" vt220on secure
On this machine, I often switch between `set tty pc0` and `set tty
com0` for debugging purposes, but I always want a getty running on the
serial port.
Index: ddb.4
===
RCS file: /cvs/src/share/man/man4/ddb.4,v
retrieving revision 1.105
diff -u -p -r1.105 ddb.4
--- ddb.4 22 Dec 2022 19:53:22 - 1.105
+++ ddb.4 30 May 2023 06:34:19 -
@@ -46,7 +46,9 @@ is invoked upon a kernel panic when the
is set to 1.
It may be invoked from the console when the sysctl
.Va ddb.console
-is set to 1, using any of the following methods:
+is set to 1 and
+.Va kern.securelevel
+is set to 0 or -1, using any of the following methods:
.Bl -dash -offset 3n
.It
Using the key sequence
Index: securelevel.7
===
RCS file: /cvs/src/share/man/man7/securelevel.7,v
retrieving revision 1.31
diff -u -p -r1.31 securelevel.7
--- securelevel.7 21 Aug 2019 20:44:09 - 1.31
+++ securelevel.7 30 May 2023 06:36:30 -
@@ -73,6 +73,7 @@ raw disk devices of mounted file systems
system immutable and append-only file flags may not be removed
.It
the
+.Va ddb.trigger ,
.Va fs.posix.setuid ,
.Va hw.allowpowerdown ,
.Va kern.allowkmem ,
On Mon, May 29, 2023 at 07:56:51AM -, Stuart Henderson wrote:
| On 2023-05-29, Sebastien Marie wrote:
| > On Mon, May 29, 2023 at 02:41:00PM +1000, Aaron Mason wrote:
| >> On Mon, May 29, 2023 at 4:08 AM Paul de Weerd wrote:
| >> >
| >> > (for the record, BREAK doesn't work either to enter ddb, I
| >> > guessed it was due to the USB-to-serial dongle I'm using (uplcom(4)
| >> > lacking support for sending a proper BREAK .. but this may be the same
| >> > issue?)
|
| fwiw BREAK does usually work in uplcom. It's uark that is known not to work.
| (but since a BREAK is just holding the line at 0 for longer than a normal
| character transmission time, if the console port speed is fairly high,
| it's easy to send something that will be interpreted as break by setting
| a low speed on the transmitting port and sending a char with enough 0 bits
| in it).
|
| > From the code, to use ddb.trigger (aka DBCTL_TRIGGER), you need:
| >
| > - kern.securelevel < 1 (on a running system, kern.securelevel = -1)
| > OR
| > - something related to the console (I suppose "having the tty of the
current
| > process being the same than the console")
| >
| > If you are connected to serial, but your console is on VGA, it might be
related.
|
| If that's the case, 1) it would also prevent BREAK on the serial port
| from working, and 2) it probably wouldn't help to be able to trigger
| ddb anyway, because ddb output will go to the system console, not the
| console where ddb.trigger=1 was used.
|
| > So you might need to set kern.securelevel to lower value ("sysctl
kern.securelevel=-1"
| > in /etc/rc.securelevel), or make your console on serial (with "set tty
com0" on
| > bootloader).
|
| If 'set tty comX' isn't already used, the answer is almost certainly to
| set that.
|
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
