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/
Re: Sony VAIO SVE15118FGB Keyboard and WiFi Issues
Hello Stefan,
On Mon, May 29, 2023 at 09:07:09PM +0200, Stefan Sperling wrote:
> On Mon, May 29, 2023 at 10:13:30PM +1200, Avon Robertson wrote:
> > $ fgrep -e AR9485 *
> > ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP20x16284
> > ar9003reg.h:#define AR9485_PHY_CH0_XTAL 0x16290
> > ar9003reg.h:/* Bits for AR9485_PHY_65NM_CH0_TOP2. */
> > ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_M 0xf000
> > ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_S 12
> > ar9003reg.h:/* Bits for AR9485_PHY_CH0_XTAL. */
> > ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_M 0x7f00
> > ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_S 24
> > ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_M 0x00fe
> > ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_S 17
> > ar9380.c: * Routines for AR9380 and AR9485 chipsets.
> > ar9380.c: reg = AR_READ(sc, AR9485_PHY_65NM_CH0_TOP2);
> > ar9380.c: reg = RW(reg, AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL,
> > ar9380.c: AR_WRITE(sc, AR9485_PHY_65NM_CH0_TOP2, reg);
> > ar9380.c: reg = AR_READ(sc, AR9485_PHY_CH0_XTAL);
> > ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPINDAC,
> > ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPOUTDAC,
> > ar9380.c: AR_WRITE(sc, AR9485_PHY_CH0_XTAL, reg);
> > ar9380reg.h: * AR9485 1.1 programming.
> > ar9380reg.h: * AR9485 1.1 Tx gains.
> > ar9380reg.h: * AR9485 1.1 Rx gains.
> > athn.c: return ("AR9485");
> >
> > Am I missing something w.r.t. enabling the athn interface OR is the
> > Atheros AR9485 chip really unsupported? The dmesg output identifies it
> > as having a rom address conflict and as having an unconfigured function
> > 0.
>
> The ar9380.c parts of this driver are intentionally disabled because they
> do not work. I would be happy to review and test patches that improve
> this sad situation.
Thank you for the information. I will look further into the issue in a
few days when time permits, and try to gain some understanding of the
driver code.
--
Regards,
aer
Multi path routing with BGPD
Hello,
I try to setup multipath routing environment with OpenBSD's bgpd.
As I understand from man page the keyword is add-path.
Here is my environmental report:
1. In my lab I simulate two wan links for each device.
2. Each device also has a LAN network to announce.
3. In the middle of these two devices there is another OpenBSD acting as
Router.
Device 1 :
WAN1 : 192.168.10.2/24
WAN2: 10.1.1.2/24
LAN : 172.16.1.1/24
GRE1 : 172.31.1.1 -> 172.31.1.2 netmask /24 (over wan1)
GRE2 : 172.31.2.1 -> 172.31.2.2 netmask /24 (over wan2)
Device 2 :
WAN1 : 192.168.20.2/24
WAN2: 10.1.2.2/24
LAN : 172.16.2.1/24
GRE1 : 172.31.1.2 -> 172.31.1.1 netmask /24 (over wan1)
GRE2 : 172.31.2.2 -> 172.31.2.1 netmask /24 (over wan2)
Router :
192.168.10.1/24
192.168.20.1/24
10.1.1.1/24
10.1.2.1/24
-
Here bgpd.conf file contents :
Device1# cat /etc/bgpd.conf
AS 100
network 172.16.1.0/24
neighbor 172.31.1.2 {
remote-as 100
log updates
announce IPv4 unicast
announce add-path recv yes
announce add-path send best
}
neighbor 172.31.2.2 {
remote-as 100
log updates
announce IPv4 unicast
announce add-path recv yes
announce add-path send best
}
allow quick from { ibgp }
allow quick to { ibgp }
Device2# cat /etc/bgpd.conf
AS 100
network 172.16.2.0/24
neighbor 172.31.1.1 {
remote-as 100
log updates
announce IPv4 unicast
announce add-path recv yes
announce add-path send best
}
neighbor 172.31.2.1 {
remote-as 100
log updates
announce IPv4 unicast
announce add-path recv yes
announce add-path send best
}
allow quick from { ibgp }
allow quick to { ibgp }
Here bgpctl show outputs:
#bgp connection is OK
Device1# bgpctl show
Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd
172.31.1.2100 9 9 0 00:02:34 1
172.31.2.2100 9 9 0 00:02:34 1
# we can see rib tables are ready
Device1# bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
AI*>N 172.16.1.0/240.0.0.0 100 0 i
I*> N 172.16.2.0/24172.31.1.2100 0 i
I*m N 172.16.2.0/24172.31.2.2100 0 i
Device2# bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete
flags ovs destination gateway lpref med aspath origin
I*> N 172.16.1.0/24172.31.1.1100 0 i
I*m N 172.16.1.0/24172.31.2.1100 0 i
AI*>N 172.16.2.0/240.0.0.0 100 0 i
But there is only one path in FIB table:
Device1# bgpctl show fib | grep B
flags: B = BGP, C = Connected, S = Static
N = BGP Nexthop reachable via this route
B 48 172.16.2.0/24172.31.1.2
Device2# bgpctl show fib | grep B
flags: B = BGP, C = Connected, S = Static
N = BGP Nexthop reachable via this route
B 48 172.16.1.0/24172.31.1.1
Also my sysctl.conf is ok (net.inet.ip.multipath=1)
I just wanna add multpath routes for my networks as dynamic.
It's ok with static routing(*) but I would like to achieve it as dynamically
with bgpd.
What is wrong with my configuration? Can you please help me.
Thanks.
(*)
Device1# route add 172.16.2.0/24 172.31.1.2 -mpath
add net 172.16.2.0/24: gateway 172.31.1.2
Device1# route add 172.16.2.0/24 172.31.2.2 -mpath
add net 172.16.2.0/24: gateway 172.31.2.2
Device1# netstat -rnf inet | grep 172.16.2
172.16.2/24172.31.1.2 UGSP 00 - 8 gre1
172.16.2/24172.31.2.2 UGSP 00 - 8 gre2
Device2# route add 172.16.1.0/24 172.31.1.1 -mpath
add net 172.16.1.0/24: gateway 172.31.1.1
Device2# route add 172.16.1.0/24 172.31.2.1 -mpath
add net 172.16.1.0/24: gateway 172.31.2.1
Device2# netstat -rnf inet | grep 172.16.1
172.16.1/24172.31.1.1 UGSP 00 - 8 gre1
172.16.1/24172.31.2.1 UGSP 00 - 8 gre2
Re: Sony VAIO SVE15118FGB Keyboard and WiFi Issues
On Mon, May 29, 2023 at 10:13:30PM +1200, Avon Robertson wrote:
> $ fgrep -e AR9485 *
> ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2 0x16284
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL 0x16290
> ar9003reg.h:/* Bits for AR9485_PHY_65NM_CH0_TOP2. */
> ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_M 0xf000
> ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_S 12
> ar9003reg.h:/* Bits for AR9485_PHY_CH0_XTAL. */
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_M0x7f00
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_S24
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_M 0x00fe
> ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_S 17
> ar9380.c: * Routines for AR9380 and AR9485 chipsets.
> ar9380.c: reg = AR_READ(sc, AR9485_PHY_65NM_CH0_TOP2);
> ar9380.c: reg = RW(reg, AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL,
> ar9380.c: AR_WRITE(sc, AR9485_PHY_65NM_CH0_TOP2, reg);
> ar9380.c: reg = AR_READ(sc, AR9485_PHY_CH0_XTAL);
> ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPINDAC,
> ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPOUTDAC,
> ar9380.c: AR_WRITE(sc, AR9485_PHY_CH0_XTAL, reg);
> ar9380reg.h: * AR9485 1.1 programming.
> ar9380reg.h: * AR9485 1.1 Tx gains.
> ar9380reg.h: * AR9485 1.1 Rx gains.
> athn.c: return ("AR9485");
>
> Am I missing something w.r.t. enabling the athn interface OR is the
> Atheros AR9485 chip really unsupported? The dmesg output identifies it
> as having a rom address conflict and as having an unconfigured function
> 0.
The ar9380.c parts of this driver are intentionally disabled because they
do not work. I would be happy to review and test patches that improve
this sad situation.
Sony VAIO SVE15118FGB Keyboard and WiFi Issues
My aim is to configure this surplus laptop as a router firewall for my
daughter's home network.
The laptop previously had Windows 8 installed and it's keyboard worked
without apparent error under Windows 8, as did it's Atheros AR9485 WiFi.
OpenBSD Issue 1: Laptop Keyboard
When an attempt was made (after a cold boot) to install OpenBSD using an
install73.iso, heaps of gibberish was written to the screen. The
onboard keyboard proved to be unusable as well, because many keys did
not behave correctly. I suspected that a non US keyboard layout was
configured.
With an external keyboard connected to a USB-2 port, after much trial
and error; a 'Systemrescue 10' CD was booted, and with more trial and
error it's 'dd' binary was used to zero the entire 750GB spinning
fixed disk. With some difficulty, OpenBSD was then installed from an
install73.iso CD.
Post install and after some basic configuration of the root and sole
user accounts, /usr/sbin/sysupgrade -s was invoked. This succeeded but
during bootup many lines of this set of characters, '^[[7~' (without the
quotes), were interspersed with the boot messages.
The onboard keyboard fails to accept/display many key presses. This
makes it impossible(?) to login unless an external keyboard is used.
After the external keyboard typed the next command it was disconnected
and 'Enter' was hit on the laptop keyboard.
$ wsconsctl
keyboard.type=pc-xt
...
keyboard.encoding=us
...
A table of some example key presses is shown next.
Key Output Key Output Key Output Key Output
ESC ^[ ` ` 1 blank Shift-r blank
2 2 3 blank 4 4 Shift-s blank
5 blank 6 6 7 blank Shift-t blank
8 blank 9 blank 0 0 ; ;
z z Shift-z blank c blank Shift-; blank
i i j j k blank q q
OpenBSD Issue 2: Unable to Configure /etc/hostname.athn
According to athn(4) the laptop's AR9485 chip is not supported. But:
$ pwd
/sys/dev/ic
$ fgrep -e AR9485 *
ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP20x16284
ar9003reg.h:#define AR9485_PHY_CH0_XTAL 0x16290
ar9003reg.h:/* Bits for AR9485_PHY_65NM_CH0_TOP2. */
ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_M 0xf000
ar9003reg.h:#define AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL_S 12
ar9003reg.h:/* Bits for AR9485_PHY_CH0_XTAL. */
ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_M 0x7f00
ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPINDAC_S 24
ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_M 0x00fe
ar9003reg.h:#define AR9485_PHY_CH0_XTAL_CAPOUTDAC_S 17
ar9380.c: * Routines for AR9380 and AR9485 chipsets.
ar9380.c: reg = AR_READ(sc, AR9485_PHY_65NM_CH0_TOP2);
ar9380.c: reg = RW(reg, AR9485_PHY_65NM_CH0_TOP2_XPABIASLVL,
ar9380.c: AR_WRITE(sc, AR9485_PHY_65NM_CH0_TOP2, reg);
ar9380.c: reg = AR_READ(sc, AR9485_PHY_CH0_XTAL);
ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPINDAC,
ar9380.c: reg = RW(reg, AR9485_PHY_CH0_XTAL_CAPOUTDAC,
ar9380.c: AR_WRITE(sc, AR9485_PHY_CH0_XTAL, reg);
ar9380reg.h: * AR9485 1.1 programming.
ar9380reg.h: * AR9485 1.1 Tx gains.
ar9380reg.h: * AR9485 1.1 Rx gains.
athn.c: return ("AR9485");
Am I missing something w.r.t. enabling the athn interface OR is the
Atheros AR9485 chip really unsupported? The dmesg output identifies it
as having a rom address conflict and as having an unconfigured function
0.
Thank you for any information and or advice that you have to resolve
either or both the above issues.
Regards Avon.
PS
To prevent a TLDR scenario, only a dmesg obtained post the sysupgrade
is inlined below. The dmesg that was saved after a reboot post the
initial install can be posted to the list if it would be of use.
My searches of the marc.info bugs@openbsd and misc@openbsd failed to
find anything that was relevant.
OpenBSD 7.3-current (GENERIC.MP) #1202: Fri May 26 09:25:17 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8542482432 (8146MB)
avail mem = 8263929856 (7881MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6da0 (18 entries)
bios0: vendor Insyde Corp. version "R0210E6" date 05/11/2012
bios0: Sony Corporation SVE15118FGB
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI ASF! HPET APIC MCFG SLIC WDAT SSDT BOOT ASPT SSDT
SSDT SSDT
acpi0: wakeup devices P0P1(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S0)
RP01(S0) PXSX(S4) RP02(S0) PXSX(S4) RP03(S3) PXSX(S4) RP04(S4) PXSX(S4)
RP05(S4) PXSX(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) Core(TM) i7-3612QM CPU
Re: sysctl ddb.trigger
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.
