Bind address for wireguard

2023-08-29 Thread Samuel Jayden
Hello misc@,

Is it possible to bind source address on wireguard as the source address of
the connection?
Thanks.

P.S. In fact this is a feature request. It's not too suitable for work
arounds.
Yeah, someone can say "use vrf", "use route command for the destination ip
address of the wireguard's remote endpoint".
But when I use workarounds like that  I have always had other, also bigger
issues.
So simply found out that binding source address will be a life saver.


Parallel PF

2023-10-24 Thread Samuel Jayden
Hello dear OpenBSD team,

I'm sure that something like parallel IP forwarding and increasing the
number of softnet kernel tasks to 4 is definitely being considered on the
PF side too, but I would like to express my concern about timing. Do you
have any schedule for this?

I think one of the common prayers of all OpenBSD users is that PF will
speed up. Thank you for reading and my best regards.

--
Sam


Re: Parallel PF

2023-10-24 Thread Samuel Jayden
I shared a naive user experience. I didn't mean to be rude. Anyway, thank
you for reading and responding.

On Tue, Oct 24, 2023 at 5:46 PM Irreverent Monk  wrote:

> The standard response is - show your code.  If you sit down and think
> about it, isn't it rude to go to a project to tell them that they must
> prioritize what they are doing for what you want...?
>
> On Tue, Oct 24, 2023 at 6:40 AM Samuel Jayden 
> wrote:
>
>> Hello dear OpenBSD team,
>>
>> I'm sure that something like parallel IP forwarding and increasing the
>> number of softnet kernel tasks to 4 is definitely being considered on the
>> PF side too, but I would like to express my concern about timing. Do you
>> have any schedule for this?
>>
>> I think one of the common prayers of all OpenBSD users is that PF will
>> speed up. Thank you for reading and my best regards.
>>
>> --
>> Sam
>>
>


Re: Parallel PF

2023-10-25 Thread Samuel Jayden
Hello Valdrin,

I am also aware that attaching PF to more than one CPU will not be enough,
and I think I have been misunderstood; I do not reproach about this. Just a
curiosity on my part.

As far as I learned from users who wrote me private messages, OpenBSD does
not have a public RoadMap. Of course, I respect this. I was just asking if
maybe a developer would come along and at least satisfy the curiosity of us
users, even if he didn't give a date. I apologize again for being
misunderstood. I never meant to be rude. As a user, I still don't think
wishing multiple PF tasks is a bad thing. On the contrary, I think user
experience will be given importance.

On the other hand, I will upgrade my OpenBSD 7.3 firewall running in a
VMware environment to 7.4. By the way, I will use ix(4) instead of vmx,
thanks to SR-IOV technology, and I am sure I will get a performance
increase.

I would like to thank the OpenBSD team for developing this beautiful
operating system.

On Wed, Oct 25, 2023 at 5:18 PM Valdrin MUJA 
wrote:

> Hello Sam,
>
> I don't have the answer to this question, but I can make a few comments on
> my own behalf. Maybe it can give you an idea.
> As far as I observed, it is not PF's turn yet. I guess what needs to be
> done regarding cloned interfaces such as tun and the ethernet layer will be
> done first. In fact, as far as I follow, there are some issues in the
> UDP_input section.
> Of course, I'm sure a lot will change when PF becomes mp-safe, but I
> believe there is still time for that.
> PF's performance can reach up to 10Gbps with the right CPU selection. Do
> you have traffic that exceeds this? Maybe if you can provide specific
> information there will be a chance for someone to help.
> ------
> *From:* owner-m...@openbsd.org  on behalf of
> Samuel Jayden 
> *Sent:* Tuesday, October 24, 2023 17:54
> *To:* Irreverent Monk 
> *Cc:* misc@openbsd.org 
> *Subject:* Re: Parallel PF
>
> I shared a naive user experience. I didn't mean to be rude. Anyway, thank
> you for reading and responding.
>
> On Tue, Oct 24, 2023 at 5:46 PM Irreverent Monk 
> wrote:
>
> > The standard response is - show your code.  If you sit down and think
> > about it, isn't it rude to go to a project to tell them that they must
> > prioritize what they are doing for what you want...?
> >
> > On Tue, Oct 24, 2023 at 6:40 AM Samuel Jayden <
> samueljaydan1...@gmail.com>
> > wrote:
> >
> >> Hello dear OpenBSD team,
> >>
> >> I'm sure that something like parallel IP forwarding and increasing
> the
> >> number of softnet kernel tasks to 4 is definitely being considered on
> the
> >> PF side too, but I would like to express my concern about timing. Do you
> >> have any schedule for this?
> >>
> >> I think one of the common prayers of all OpenBSD users is that PF will
> >> speed up. Thank you for reading and my best regards.
> >>
> >> --
> >> Sam
> >>
> >
>


Sierra Wireless LTE-A does not recognized as Umb Interface

2023-11-13 Thread Samuel Jayden
Hello Dear misc,

Model Full Name: Sierra Wireless, Incorporated Sierra Wireless EM7455
Qualcomm\M-. Snapdragon? X7 LTE-A

I have an OpenBSD system, and I want to use the Sierra Wireless modem as
the Umb interface. I changed the LTE mode to MBIM, but OpenBSD does not
recognize it as an Umb Interface.

I changed the MBIM mode using the command 'cu -l /dev/cuaU2 -s 9600,'
connecting and executing AT commands. After switching to MBIM mode, I am
unable to access it using OpenBSD's cu commands. However, I successfully
connected and confirmed that the MBIM mode change was done successfully
using cu on a Linux system(ubuntu). It’s fully operational under Linux.
When attempting to connect to cuaU2 after the MBIM mode change, I encounter
the following errors:
OpenBSD# cu -l /dev/cuaU0 -s 9600
cu: open("/dev/cuaU0"): Input/output error
OpenBSD# cu -l /dev/cuaU1 -s 9600
cu: open("/dev/cuaU1"): Input/output error
OpenBSD# cu -l /dev/cuaU2 -s 9600
cu: open("/dev/cuaU2"): Device not configured
OpenBSD# cu -l /dev/cuaU3 -s 9600
cu: open("/dev/cuaU3"): Device not configured
OpenBSD#

Is there a way to solve this problem, or does OpenBSD not support Sierra
Wireless modem?

The driver's dmesg and usbdevs output are as follows:

*dmesg:*
umsm0 at uhub1 port 3 configuration 1 interface 0 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
ucom0 at umsm0
umsm1 at uhub1 port 3 configuration 1 interface 3 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
ucom1 at umsm1
umsm2 at uhub1 port 3 configuration 1 interface 12 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
umsm2: missing endpoint
umsm3 at uhub1 port 3 configuration 1 interface 13 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
2.10/0.06 addr 6
umsm3: missing endpoint

*usbdevs:*
addr 06: 1199:9071 Sierra Wireless, Incorporated, Sierra Wireless EM7455
Qualcomm\M-. Snapdragon? X7 LTE-A
 high speed, power 500 mA, config 1, rev 0.06, iSerial
LF93858930021032
 driver: umsm0
 driver: umsm1
 driver: umsm2
 driver: umsm3

Thank you in advance for your help.


umb0: open error: FAILURE

2023-11-13 Thread Samuel Jayden
Hello misc,

After experiencing mbim attach (from umsm) issue[*] with EM7455, I
purchased another LTE module with a different   (SIM8262E-M2) chipset. This
time switching to mbim mode was no problem.
However, this time it remains as "SIM not initialized". But when you
install Linux on the same device, it can successfully obtain an IP address
and access the internet.

I tested this on both OpenBSD 7.3 and 7.4.
Here is some output that might be useful:

# usbdevs
addr 03: 1e0e:9003 SIMCOM, SDXLEMUR-LITE-MTP _SN:C7FD1685
super speed, power 224 mA, config 1, rev 5.04, iSerial 0123456789ABCDEF
driver: umb0

# ifconfig umb0
umb0: flags=8815 mtu 1500
index 7 priority 6 llprio 3
roaming disabled registration unknown
state down cell-class none
SIM not initialized PIN required
APN internet
status: down

dmesg after debug flag :
umb0: state change timeout
umb0: open error: FAILURE

dmesg is attached

How can I solve this? Thanks.

[*] https://marc.info/?l=openbsd-misc&m=169988135425184&w=2
OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8412323840 (8022MB)
avail mem = 8137629696 (7760MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x78a4 (73 entries)
bios0: vendor American Megatrends International, LLC. version "5.19" date 
07/31/2023
bios0: Default string Default string
efi0 at bios0: UEFI 2.7
efi0: American Megatrends rev 0x50013
acpi0 at bios0: ACPI 6.2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP MCFG SSDT FIDT OEM1 HPET APIC PRAM RSCI SSDT SSDT NHLT 
SSDT SSDT PSDS LPIT SSDT FPDT DMAR SSDT TPM2 WSMT
acpi0: wakeup devices RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) 
RP04(S0) PXSX(S0) RP05(S0) PXSX(S0) RP06(S0) PXSX(S0) RP07(S0) PXSX(S0) 
XHCI(S0) XDCI(S0) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xc000, bus 0-255
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,FB_CLEAR,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
12-way L2 cache, 4MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) J6412 @ 2.00GHz, 1995.68 MHz, 06-96-01, patch 0017
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCN

Re: umb0: open error: FAILURE

2023-11-13 Thread Samuel Jayden
Hello Stefan(s),

Thanks for your replies.
In my setup PIN is disabled.Also I've just tried entering { ifconfig umb0
down;ifconfig umb0 apn internet;ifconfig umb0 pin "";ifconfig umb0 up } But
nothing comes up.
It is still at the same stage.

Even if I set the wrong PIN it gives the same message. I think it really
can not initialize the SIM.The question is why? How to troubleshoot?



On Mon, Nov 13, 2023 at 11:07 PM Stefan Sperling  wrote:

> On Mon, Nov 13, 2023 at 10:03:01PM +0300, Samuel Jayden wrote:
> > Hello misc,
> >
> > After experiencing mbim attach (from umsm) issue[*] with EM7455, I
> > purchased another LTE module with a different   (SIM8262E-M2) chipset.
> This
> > time switching to mbim mode was no problem.
> > However, this time it remains as "SIM not initialized". But when you
> > install Linux on the same device, it can successfully obtain an IP
> address
> > and access the internet.
>
> This is the important bit in your logs:
>
> > SIM not initialized PIN required
>  ^^
>
> Try setting the SIM card's PIN with 'ifconfig umb0 pin '.
>
> On my laptop I have this in /etc/hostname.umb0 (with the correct
> pin instead of  and the correct APN):
>
> pin 
> apn myapn
> roaming
> down
>
> With this in place running 'ifconfig umb0 up' is enough to get link.
>


Re: umb0: open error: FAILURE

2023-11-14 Thread Samuel Jayden
openbsd# cat /etc/hostname.umb0
pin ""
apn internet
up

openbsd# sh -x /etc/netstart umb0
+ set +o sh
+ id -u
+ let 0 != 0
+ . /etc/rc.d/rc.subr
+ FUNCS_ONLY=1
+ _rc_actions=start stop restart reload check configtest
+ readonly _rc_actions
+ [ -n 1 ]
+ return
+ _rc_parse_conf
+ PRINT_ONLY=false
+ V4_AUTOCONF=false
+ V6_AUTOCONF=false
+ IP6KERNEL=false
+ getopts :n opt
+ shift 0
+ ifconfig lo0 inet6
+ > /dev/null
+ 2>&1
+ IP6KERNEL=true
+ true
+ false
+ sysctl -q net.inet6.ip6.soiikey=0c075149b0a265a8596ef640b7c91b9b
+ let 1 > 0
+ vifscreate umb0
+ ifstart umb0
+ defaultroute
+ return


umb0: flags=8811 mtu 1500
index 7 priority 6 llprio 3
roaming disabled registration unknown
state down cell-class none
SIM not initialized PIN required
APN internet
status: down

Nothing changed. I've also rebooted...

On Mon, Nov 13, 2023 at 11:46 PM Samuel Jayden 
wrote:

> Hello Stefan(s),
>
> Thanks for your replies.
> In my setup PIN is disabled.Also I've just tried entering { ifconfig umb0
> down;ifconfig umb0 apn internet;ifconfig umb0 pin "";ifconfig umb0 up } But
> nothing comes up.
> It is still at the same stage.
>
> Even if I set the wrong PIN it gives the same message. I think it really
> can not initialize the SIM.The question is why? How to troubleshoot?
>
>
>
> On Mon, Nov 13, 2023 at 11:07 PM Stefan Sperling  wrote:
>
>> On Mon, Nov 13, 2023 at 10:03:01PM +0300, Samuel Jayden wrote:
>> > Hello misc,
>> >
>> > After experiencing mbim attach (from umsm) issue[*] with EM7455, I
>> > purchased another LTE module with a different   (SIM8262E-M2) chipset.
>> This
>> > time switching to mbim mode was no problem.
>> > However, this time it remains as "SIM not initialized". But when you
>> > install Linux on the same device, it can successfully obtain an IP
>> address
>> > and access the internet.
>>
>> This is the important bit in your logs:
>>
>> > SIM not initialized PIN required
>>  ^^
>>
>> Try setting the SIM card's PIN with 'ifconfig umb0 pin '.
>>
>> On my laptop I have this in /etc/hostname.umb0 (with the correct
>> pin instead of  and the correct APN):
>>
>> pin 
>> apn myapn
>> roaming
>> down
>>
>> With this in place running 'ifconfig umb0 up' is enough to get link.
>>
>


Re: umb0: open error: FAILURE

2023-11-14 Thread Samuel Jayden
Hi David,

I am absolutely sure that PIN status is turned off. And yes, it doesn't ask
for a PIN on the phone either.
When you install Linux on the same device, it gets an IP address on the
wwan0 interface and can access the internet.


On Tue, Nov 14, 2023 at 12:42 PM David Coppa  wrote:

> On Tue, Nov 14, 2023 at 10:10 AM Samuel Jayden
>  wrote:
>
> > Nothing changed. I've also rebooted...
>
> Just to be sure... If you put this sim card into a mobile phone, is it
> asking for a PIN or not?
>
> Ciao,
> David
>


Re: umb0: open error: FAILURE

2023-11-14 Thread Samuel Jayden
Hello Stefan,

I bought another line from another GSM operator. I entered its APN
information and the result is the same. You can be sure that I made these
checks.
In fact, in my first message, I wrote that I debugged ifconfig umb0 and
sent the output.

dmesg after debug flag :
umb0: state change timeout
umb0: open error: FAILURE

Nov 14 11:04:57 openbsd /bsd: umb0: state change timeout
Nov 14 11:04:57 openbsd /bsd: umb0: open error: FAILURE
^C

Can it be some kind of bug? What should I do to debug this?
Please let me know.


On Tue, Nov 14, 2023 at 12:58 PM Stefan Sperling  wrote:

> On Mon, Nov 13, 2023 at 11:46:14PM +0300, Samuel Jayden wrote:
> > Hello Stefan(s),
> >
> > Thanks for your replies.
> > In my setup PIN is disabled.Also I've just tried entering { ifconfig umb0
> > down;ifconfig umb0 apn internet;ifconfig umb0 pin "";ifconfig umb0 up }
> But
> > nothing comes up.
> > It is still at the same stage.
>
> Checking the code, the "PIN required" state is a default state which
> gets upgraded by a specific status message received from the device.
> So perhaps this message from ifconfig is misleading, and the device
> never tells us what the actual SIM state is.
>
> Are you sure the APN "internet" is correct?
> If not then please check with your ISP, they should be able to
> tell you the APN to use.
>
> There is also the 'ifconfig umb0 debug' command which will show debug
> output from umb in dmesg and /var/log/messages once the interface starts
> operating. Perhaps that will provide hints about the connection failure.
>


Re: umb0: open error: FAILURE

2023-11-14 Thread Samuel Jayden
Hi Stuart,


I will try to upgrade the SIMCOM LTE module's firmware. Maybe it can
solve the problem.
Also I've got a related question:
How can I connect to (mbim-mode) lte modem's AT interface.
As I realized, I can not connect to an LTE device which has switched to
mbim-mode under OpenBSD.
Before mbim-mode I was able to connect to it via cu -l /dev/cuaU2

Thanks.

On Tue, Nov 14, 2023 at 1:57 PM Stuart Henderson 
wrote:

> On 2023-11-13, Samuel Jayden  wrote:
> > # ifconfig umb0
> > umb0: flags=8815 mtu 1500
> > index 7 priority 6 llprio 3
> > roaming disabled registration unknown
> > state down cell-class none
> > SIM not initialized PIN required
>
> This "PIN required" can be a red herring - iirc you see the same if the
> device needs an "fcc unlock" command before it will start operating.
> I believe this would be dependent on the device firmware.
>
> In general I would recommend using a readymade "LTE router" if possible.
> My track record with 3G/LTE devices on OpenBSD is getting about 20% of the
> devices that I've tried to actually work...
>
> --
> Please keep replies on the mailing list.
>
>


DDB Crash Report About if_ether.c and arpinit() Gelen Kutusu

2024-01-26 Thread Samuel Jayden
Hello Misc,

My OpenBSD 7.4 crash with this error messages;

panic: kernel diagnostic assertion "ifp != NULL" failed: file
"/usr/src/sys/net/inet/if_ether.c", line 758

Stopped at db_enter+0x14: popq %rbp
   TID  PID UID   PRFLAGS   PFLAGS   CPUCOMMAND
 399412   7311877   0x112 0   10dhcpleased
 360364   39155   115   0x112 0   11slaacd
 155433   90182 00x14000  0x2002softnet0
 162438   45442 00x14000  0x2004systq
* 37835   96688 00x14000 0x42000softclock
db_enter() at db_enter+0x14
panic(820a8599) at panic+0xc3
__assert(821232bc,8209baea,2f6,820712c0) at
__assert+0x29
arpinit() at arpinit
arptimer(825a38e8) at arptimer+0x5f
softclock_thread(800021c1fd48) at softclock_thread+0x12b
end trace frame: 0x0, count: 9
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}>

Dmesg output of my device is in the attachment.

Thank you in advance for your interest.
Mini, 4.27> naa.6d0946600a3aa2002d1bbe5515c8a45b
sd0: 1830784MB, 512 bytes/sector, 3749445632 sectors
scsibus2 at mfii0: 256 targets
ppb1 at pci2 dev 2 function 0 "Intel Xeon-D PCIE" rev 0x01: msi
pci4 at ppb1 bus 3
3:0:0: rom address conflict 0xfff8/0x8
3:0:1: rom address conflict 0xfff8/0x8
ix0 at pci4 dev 0 function 0 "Intel 82599" rev 0x01, msix, 16 queues, address 
90:e2:ba:ea:73:2c
ix1 at pci4 dev 0 function 1 "Intel 82599" rev 0x01, msix, 16 queues, address 
90:e2:ba:ea:73:2d
ppb2 at pci2 dev 3 function 0 "Intel Xeon-D PCIE" rev 0x01
pci5 at ppb2 bus 1
em0 at pci5 dev 0 function 0 "Intel I350" rev 0x01: msi, address 
24:6e:96:71:8d:b0
em1 at pci5 dev 0 function 1 "Intel I350" rev 0x01: msi, address 
24:6e:96:71:8d:b1
em2 at pci5 dev 0 function 2 "Intel I350" rev 0x01: msi, address 
24:6e:96:71:8d:b2
em3 at pci5 dev 0 function 3 "Intel I350" rev 0x01: msi, address 
24:6e:96:71:8d:b3
ppb3 at pci2 dev 3 function 2 "Intel Xeon-D PCIE" rev 0x01
pci6 at ppb3 bus 4
"Intel Xeon-D Address Map" rev 0x01 at pci2 dev 5 function 0 not configured
"Intel Xeon-D Hot Plug" rev 0x01 at pci2 dev 5 function 1 not configured
"Intel Xeon-D RAS" rev 0x01 at pci2 dev 5 function 2 not configured
"Intel Xeon-D I/O APIC" rev 0x01 at pci2 dev 5 function 4 not configured
"Intel C610 MS SPSR" rev 0x05 at pci2 dev 17 function 0 not configured
ahci0 at pci2 dev 17 function 4 "Intel C610 AHCI" rev 0x05: msi, AHCI 1.3
scsibus3 at ahci0: 32 targets
"Intel C610 MEI" rev 0x05 at pci2 dev 22 function 0 not configured
"Intel C610 MEI" rev 0x05 at pci2 dev 22 function 1 not configured
ehci0 at pci2 dev 26 function 0 "Intel C610 USB" rev 0x05: apic 8 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb4 at pci2 dev 28 function 0 "Intel C610 PCIE" rev 0xd5
pci7 at ppb4 bus 5
ppb5 at pci2 dev 28 function 7 "Intel C610 PCIE" rev 0xd5: msi
pci8 at ppb5 bus 6
ppb6 at pci8 dev 0 function 0 "Renesas SH7758 PCIE Switch" rev 0x00
pci9 at ppb6 bus 7
ppb7 at pci9 dev 0 function 0 "Renesas SH7758 PCIE Switch" rev 0x00
pci10 at ppb7 bus 8
ppb8 at pci10 dev 0 function 0 "Renesas SH7758 PCIE-PCI" rev 0x00
pci11 at ppb8 bus 9
vga1 at pci11 dev 0 function 0 "Matrox MGA G200eR" rev 0x01
wsdisplay at vga1 not configured
ehci1 at pci2 dev 29 function 0 "Intel C610 USB" rev 0x05: apic 8 int 18
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
pcib0 at pci2 dev 31 function 0 "Intel C610 LPC" rev 0x05
ahci1 at pci2 dev 31 function 2 "Intel C610 AHCI" rev 0x05: msi, AHCI 1.3
scsibus4 at ahci1: 32 targets
isa0 at pcib0
isadma0 at isa0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
pci12 at mainbus0 bus 128
ppb9 at pci12 dev 2 function 0 "Intel Xeon-D PCIE" rev 0x01: msi
pci13 at ppb9 bus 129
ix2 at pci13 dev 0 function 0 "Intel 82599" rev 0x01, msix, 16 queues, address 
a0:36:9f:ec:e1:7c
ix3 at pci13 dev 0 function 1 "Intel 82599" rev 0x01, msix, 16 queues, address 
a0:36:9f:ec:e1:7e
"Intel Xeon-D Address Map" rev 0x01 at pci12 dev 5 function 0 not configured
"Intel Xeon-D Hot Plug" rev 0x01 at pci12 dev 5 function 1 not configured
"Intel Xeon-D RAS" rev 0x01 at pci12 dev 5 function 2 not configured
"Intel Xeon-D I/O APIC" rev 0x01 at pci12 dev 5 function 4 not configured
vmm0 at mainbus0: VMX/EPT
efifb0 at mainbus0: 1280x1024, 32bpp
wsdisplay0 at efifb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhub2 at uhub0 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 
2.00/0.05 addr 2
uhub3 at uhub2 port 6 configuration 1 interface 0 "no manufacturer Gadget USB 
HUB" rev 2.00/0.00 addr 3
uhub4 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev 
2.00/0.05 addr 2
vscsi0 at root
scsibus5 at vscsi0: 256 

Re: DDB Crash Report About if_ether.c and arpinit() Gelen Kutusu

2024-01-30 Thread Samuel Jayden
Hello again,

My device continues to crash almost every single day.
Unfortunately, due to the system freeze, I'm unable to generate a crash
report. These crashes typically result in the following errors:

kernel : protection fault trap, code=0
Stopped at arptimer+0x45: movq 0x10(%r15),%rdi
ddb{0}>

Is there a solution to this issue? What steps should I take?
Thanks.


On Sat, Jan 27, 2024 at 10:51 AM Samuel Jayden 
wrote:

> Hello Misc,
>
> My OpenBSD 7.4 crash with this error messages;
>
> panic: kernel diagnostic assertion "ifp != NULL" failed: file
> "/usr/src/sys/net/inet/if_ether.c", line 758
>
> Stopped at db_enter+0x14: popq %rbp
>TID  PID UID   PRFLAGS   PFLAGS   CPUCOMMAND
>  399412   7311877   0x112 0   10dhcpleased
>  360364   39155   115   0x112 0   11slaacd
>  155433   90182 00x14000  0x2002softnet0
>  162438   45442 00x14000  0x2004systq
> * 37835   96688 00x14000 0x42000softclock
> db_enter() at db_enter+0x14
> panic(820a8599) at panic+0xc3
> __assert(821232bc,8209baea,2f6,820712c0) at
> __assert+0x29
> arpinit() at arpinit
> arptimer(825a38e8) at arptimer+0x5f
> softclock_thread(800021c1fd48) at softclock_thread+0x12b
> end trace frame: 0x0, count: 9
> https://www.openbsd.org/ddb.html describes the minimum info required in
> bug reports. Insufficient info makes it difficult to find and fix bugs.
> ddb{0}>
>
> Dmesg output of my device is in the attachment.
>
> Thank you in advance for your interest.
>


Re: DDB Crash Report About if_ether.c and arpinit() Gelen Kutusu

2024-01-31 Thread Samuel Jayden
Hello Valdrin,

Thanks, I'll check it out and write here soon.

On Wed, Jan 31, 2024 at 12:40 PM Valdrin MUJA 
wrote:

> Hello Samuel,
>
> I think you should give a chance to this commit:
>
>
> https://github.com/openbsd/src/commit/73fb5aae645f3bc12746fd705a937dfc9f9abc01
>
> I hope it works for you.
>
> --
> Valdrin
> --
> *From:* owner-m...@openbsd.org  on behalf of
> Samuel Jayden 
> *Sent:* Wednesday, January 31, 2024 10:29
> *To:* misc@openbsd.org 
> *Subject:* Re: DDB Crash Report About if_ether.c and arpinit() Gelen
> Kutusu
>
> Hello again,
>
> My device continues to crash almost every single day.
> Unfortunately, due to the system freeze, I'm unable to generate a crash
> report. These crashes typically result in the following errors:
>
> kernel : protection fault trap, code=0
> Stopped at arptimer+0x45: movq 0x10(%r15),%rdi
> ddb{0}>
>
> Is there a solution to this issue? What steps should I take?
> Thanks.
>
>
> On Sat, Jan 27, 2024 at 10:51 AM Samuel Jayden  >
> wrote:
>
> > Hello Misc,
> >
> > My OpenBSD 7.4 crash with this error messages;
> >
> > panic: kernel diagnostic assertion "ifp != NULL" failed: file
> > "/usr/src/sys/net/inet/if_ether.c", line 758
> >
> > Stopped at db_enter+0x14: popq %rbp
> >TID  PID UID   PRFLAGS   PFLAGS   CPUCOMMAND
> >  399412   7311877   0x112 0   10dhcpleased
> >  360364   39155   115   0x112 0   11slaacd
> >  155433   90182 00x14000  0x2002softnet0
> >  162438   45442 00x14000  0x2004systq
> > * 37835   96688 00x14000 0x42000softclock
> > db_enter() at db_enter+0x14
> > panic(820a8599) at panic+0xc3
> > __assert(821232bc,8209baea,2f6,820712c0) at
> > __assert+0x29
> > arpinit() at arpinit
> > arptimer(825a38e8) at arptimer+0x5f
> > softclock_thread(800021c1fd48) at softclock_thread+0x12b
> > end trace frame: 0x0, count: 9
> > https://www.openbsd.org/ddb.html describes the minimum info required in
> > bug reports. Insufficient info makes it difficult to find and fix bugs.
> > ddb{0}>
> >
> > Dmesg output of my device is in the attachment.
> >
> > Thank you in advance for your interest.
> >
>


Re: DDB Crash Report About if_ether.c and arpinit() Gelen Kutusu

2024-02-13 Thread Samuel Jayden
Hello again,

The patch you suggested definitely worked; OpenBSD no longer crashes. Thank
you very much.

On Wed, Jan 31, 2024 at 2:40 PM Samuel Jayden 
wrote:

> Hello Valdrin,
>
> Thanks, I'll check it out and write here soon.
>
> On Wed, Jan 31, 2024 at 12:40 PM Valdrin MUJA 
> wrote:
>
>> Hello Samuel,
>>
>> I think you should give a chance to this commit:
>>
>>
>> https://github.com/openbsd/src/commit/73fb5aae645f3bc12746fd705a937dfc9f9abc01
>>
>> I hope it works for you.
>>
>> --
>> Valdrin
>> --
>> *From:* owner-m...@openbsd.org  on behalf of
>> Samuel Jayden 
>> *Sent:* Wednesday, January 31, 2024 10:29
>> *To:* misc@openbsd.org 
>> *Subject:* Re: DDB Crash Report About if_ether.c and arpinit() Gelen
>> Kutusu
>>
>> Hello again,
>>
>> My device continues to crash almost every single day.
>> Unfortunately, due to the system freeze, I'm unable to generate a crash
>> report. These crashes typically result in the following errors:
>>
>> kernel : protection fault trap, code=0
>> Stopped at arptimer+0x45: movq 0x10(%r15),%rdi
>> ddb{0}>
>>
>> Is there a solution to this issue? What steps should I take?
>> Thanks.
>>
>>
>> On Sat, Jan 27, 2024 at 10:51 AM Samuel Jayden <
>> samueljaydan1...@gmail.com>
>> wrote:
>>
>> > Hello Misc,
>> >
>> > My OpenBSD 7.4 crash with this error messages;
>> >
>> > panic: kernel diagnostic assertion "ifp != NULL" failed: file
>> > "/usr/src/sys/net/inet/if_ether.c", line 758
>> >
>> > Stopped at db_enter+0x14: popq %rbp
>> >TID  PID UID   PRFLAGS   PFLAGS   CPUCOMMAND
>> >  399412   7311877   0x112 0   10dhcpleased
>> >  360364   39155   115   0x112 0   11slaacd
>> >  155433   90182 00x14000  0x2002softnet0
>> >  162438   45442 00x14000  0x2004systq
>> > * 37835   96688 00x14000 0x42000softclock
>> > db_enter() at db_enter+0x14
>> > panic(820a8599) at panic+0xc3
>> > __assert(821232bc,8209baea,2f6,820712c0) at
>> > __assert+0x29
>> > arpinit() at arpinit
>> > arptimer(825a38e8) at arptimer+0x5f
>> > softclock_thread(800021c1fd48) at softclock_thread+0x12b
>> > end trace frame: 0x0, count: 9
>> > https://www.openbsd.org/ddb.html describes the minimum info required in
>> > bug reports. Insufficient info makes it difficult to find and fix bugs.
>> > ddb{0}>
>> >
>> > Dmesg output of my device is in the attachment.
>> >
>> > Thank you in advance for your interest.
>> >
>>
>


CARP and VRRP compliance

2024-02-13 Thread Samuel Jayden
Hello OpenBSD,

I am reaching out to seek guidance on creating redundancy between a Cisco
Router and OpenBSD. After conducting extensive research on the subject, I
find myself in need of clarification on a specific point.

My intention is to employ the use of the CARP protocol in OpenBSD and VRRP
on the Cisco Router. However, I am uncertain about the compatibility
between OpenBSD's CARP and Cisco's VRRP protocols.

If any of you have practical experience or insights into using these two
protocols simultaneously within the same broadcast domain, I would greatly
appreciate hearing about your experiences.

Thank you in advance for your time and assistance.

Best regards
Sam


Re: CARP and VRRP compliance

2024-02-13 Thread Samuel Jayden
Hello Marcus,

Thank you for your response.

>From the information provided in the link, it appears that CARP and VRRP
protocols aren't inherently interoperable.
While Cisco may have attempted to address this by introducing a command
like "disable-loop-detection carp" in its Nexus 1000V virtual router
product, this solution unfortunately doesn't extend to standard router
hardware, rendering it ineffective in many scenarios.

Also I've another question:
Is it feasible to achieve CARP and VRRP interoperability through a
user-space application?
I am curious if there are any existing solutions or approaches that
leverage user-space applications to bridge the interoperability gap between
CARP and VRRP.
If anyone has insights or experiences in this area, I would greatly
appreciate hearing about them.

Thank you for considering my inquiries.

Best regards
Sam

On Tue, Feb 13, 2024 at 8:26 PM Marcus MERIGHI  wrote:

> Hello Samuel,
>
> samueljaydan1...@gmail.com (Samuel Jayden), 2024.02.13 (Tue) 17:35 (CET):
> > I am reaching out to seek guidance on creating redundancy between a Cisco
> > Router and OpenBSD. After conducting extensive research on the subject, I
> > find myself in need of clarification on a specific point.
>
> This has some background info for you:
>
> https://mwl.io/archives/1866
>
> Marcus
>


Re: CARP and VRRP compliance

2024-02-15 Thread Samuel Jayden
Greetings,

I have now attained a deeper understanding of the topic at hand; thank you
for your insights. It appears that my requirements necessitate
communication between a Cisco router and VRRP, rather than CARP. Upon
reviewing the open-source projects you've recommended, here are my findings:

The vrrpd project seems quite distant from being readily compilable. It
exhibits a classic Linux developer's perspective, showing no inclination
towards ensuring compatibility with operating systems outside the Linux
realm.

I am still engaged with frr-vrrpd, yet, to my dismay, I haven't managed to
compile it thus far.

With freevrrpd, I am tantalizingly closer to a resolution. By crafting
minor patches, I've successfully compiled it, albeit necessitating the
deactivation of netgraph code.

Upon conducting a VRRP test between OpenBSD + freevrrpd and a Cisco Router,
I observed that both devices persisted in identifying themselves as the
master. Monitoring the relevant interface with tcpdump allowed me to
perceive packets emanating from the Cisco Router; however, there was a
conspicuous absence of VRRP packets from the OpenBSD system. It seems
plausible that disabling the netgraph code contributed to this predicament.

Should there exist an equivalent to netgraph within OpenBSD, I am eager to
explore that avenue.

Thanks.
Sam


On Wed, Feb 14, 2024 at 2:06 PM Stuart Henderson 
wrote:

> On 2024-02-13, Samuel Jayden  wrote:
> > From the information provided in the link, it appears that CARP and VRRP
> > protocols aren't inherently interoperable.
>
> They are different protocols - they *had* to be different because VRRP
> was subject to patents. And if carp was changed now, it wouldn't be
> interoperable with existing carp installations.
>
> > While Cisco may have attempted to address this by introducing a command
> > like "disable-loop-detection carp" in its Nexus 1000V virtual router
> > product, this solution unfortunately doesn't extend to standard router
> > hardware, rendering it ineffective in many scenarios.
>
> That's not about interop beteeen carp and vrrp speakers, it's about
> using carp (or vrrp or hsrp or similar) on a port attached to the
> 'virtual switch'. See 'Information About Redundant Routing Protocols' on
>
> https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_5_1/layer_2_switching/configuration/guide/n1000v_l2/n1000v_l2_7redundantroutingprot.html
>
> > Is it feasible to achieve CARP and VRRP interoperability through a
> > user-space application?
>
> No. They are different protocols. For what you want to do, running VRRP
> on the OpenBSD box might make some sense though. There are various
> existing userland implementations of VRRP that might be able to run
> on OpenBSD, probably with some work to port them - e.g. freevrrpd,
> frr-vrrpd, vrrpd. Nothing already in the ports tree (if someone wanted
> to try I'd suggest starting by looking at freevrrpd).
>
> --
> Please keep replies on the mailing list.
>
>


Re: CARP and VRRP compliance

2024-02-15 Thread Samuel Jayden
Hello Theo,

It's disheartening to see the disparity in treatment between entities like
OpenBSD and larger corporations within these governance structures.
However, your resolve in the face of such challenges is commendable. The
creation of CARP, under the circumstances you described, not only serves as
a practical solution but also as a principled stand against the
monopolization of technology standards. This unwavering commitment is the
reason OpenBSD is so deeply respected and cherished.

Thank you for your perseverance and for setting an example of integrity in
the technology community.
This is why we love OpenBSD so much.

Kind regards
Sam

On Wed, Feb 14, 2024 at 7:26 PM Theo de Raadt  wrote:

> Stuart Henderson  wrote:
>
> > On 2024-02-13, Samuel Jayden  wrote:
> > > From the information provided in the link, it appears that CARP and
> VRRP
> > > protocols aren't inherently interoperable.
> >
> > They are different protocols - they *had* to be different because VRRP
> > was subject to patents. And if carp was changed now, it wouldn't be
> > interoperable with existing carp installations.
> >
> > > While Cisco may have attempted to address this by introducing a command
> > > like "disable-loop-detection carp" in its Nexus 1000V virtual router
> > > product, this solution unfortunately doesn't extend to standard router
> > > hardware, rendering it ineffective in many scenarios.
> >
> > That's not about interop beteeen carp and vrrp speakers, it's about
> > using carp (or vrrp or hsrp or similar) on a port attached to the
> > 'virtual switch'. See 'Information About Redundant Routing Protocols' on
> >
> https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_5_1/layer_2_switching/configuration/guide/n1000v_l2/n1000v_l2_7redundantroutingprot.html
> >
> > > Is it feasible to achieve CARP and VRRP interoperability through a
> > > user-space application?
> >
> > No. They are different protocols. For what you want to do, running VRRP
> > on the OpenBSD box might make some sense though. There are various
> > existing userland implementations of VRRP that might be able to run
> > on OpenBSD, probably with some work to port them - e.g. freevrrpd,
> > frr-vrrpd, vrrpd. Nothing already in the ports tree (if someone wanted
> > to try I'd suggest starting by looking at freevrrpd).
>
> This was my experience:
>
> VRRP was the first patent-encumbered protocol squeezed through the IETF
> process.
>
> The backers of that change in process were employees and laywers at a few
> major companies, but also tightly integrated into the IETF approval
> process.
>
> When we objected to the VRRP situation, they circled the wagons, not just
> to defend the VRRP patent, but to protect a future of patent's being OK in
> IETF processes.
>
> In response, OpenBSD carefully developed a similar mechanism called CARP,
> and the acronymn actually expands to "Cisco Asshole Redundancy Protocol",
> because the main traitors inside IETF were Cisco employees.
>
> Then we asked IETF for numbers to make this a unique protocol.  Unlike
> a recent threads where Tatu asked IETF for port 22 and they just gave it
> to him, the various number authorities inside IETF demanded that we follow
> the most stringent procedures for CARP.  Even to this day, IETF provides
> the various prototol numbers to some large corporate industry members
> without
> forcing them down those stringent procedures.
>
> As a result, we simply squatted on the VRRP numbers.  We gave them plenty
> of warning we would be doing this.  Over the following years, we heard some
> real anger IETF decision makers internally, but none of them re-visited our
> request for seperate numbers.  We never got numbers.  So CARP will stay
> where it is.
>
> One major bug was in VRRP on some HP product was found in the first year.
> CARP packets were incorrectly parsed as VRRP packets.  I don't remember
> the details, but I think it rebooted that HP device, probably a switch.
>
> Oh well.
>
>


When IPSec destination 0.0.0.0/0, I cannot ping directly connected Interfaces

2024-03-12 Thread Samuel Jayden
Dear Misc,

I have an OpenBSD device with two interfaces: vport10 with an IP address of
192.168.83.1/24 and vport20 with an IP address of 192.168.85.1/24. I have
configured IPSec to route all traffic from these two vport interfaces to
another point through an IPSec tunnel using the destination network
0.0.0.0/0.

Due to IPSec operating before kernel routing, I cannot even ping the
directly connected interfaces' IP addresses.

I've attempted to implement route-based PF rules to solve the issue, but
unfortunately, the problem persists.
I'm looking for a solution that allows for the local traffic between these
two interfaces to bypass the IPSec tunnel, ensuring they can communicate
with each other while keeping the IPSec destination network as 0.0.0.0/0.

Here's my IPSec configuration:

ike active esp tunnel from { 192.168.83.0/24 192.168.85.0/24 } to {
0.0.0.0/0 } \
peer A.B.C.D \
main auth hmac-md5 enc 3des group modp1024 lifetime 86400 \
quick auth hmac-md5 enc 3des group none lifetime 43200 \
psk "verysecret"

Thanks in advance.


veb Interface Max Cache Size Restrict

2023-04-18 Thread Samuel Jayden
Hello,
I have one veb interface in OpenBSD 7.2 and 5 ethernet ports are paired
with this veb. As I understand from the ifconfig output, 4096 mac address
cache values can be kept in this veb interface .

ifconfig veb10
veb10: flags=8843
index 12 llprio 3
groups: veb
em3 flags=3
port 4 ifpriority 0 ifcost 0
em0 flags=3
port 1 ifpriority 0 ifcost 0
em1 flags=3
port 2 ifpriority 0 ifcost 0
ix3 flags=3
port 8 ifpriority 0 ifcost 0
ix2 flags=3
port 7 ifpriority 0 ifcost 0
Addresses (max cache: 4096, timeout: 240):
2c:f0:5d:73:f8:c4 em1 0 flags=0<>


When I tried to extend this limit value with the command "ifconfig veb10
maxaddr 4097", I got the following error message:
"ifconfig: veb10: Invalid argument"
The maximum value I can give without this error message is 4096. Isn't this
value a bit narrow?

I have tested that the mac addresses of the connected devices are not
recorded in the veb interface after exceeding the limit.

I want to switch from Cisco device to OpenBSD in a place where there are
more than 8 thousand MAC addresses, but I need to exceed this max cache
size value.
How can I increase this max cache size value 8192 or higher value?

Thank you in advance for your interest.


Re: veb Interface Max Cache Size Restrict

2023-04-19 Thread Samuel Jayden
Sincerely thank you David for your answer,
I hope you may consider committing it to src and I kindly say that it would
be perfect if this max cache size limit value was tied to a sysctl
parameter.

David Gwynne , 19 Nis 2023 Çar, 02:30 tarihinde şunu
yazdı:

> On Tue, Apr 18, 2023 at 07:51:08PM +0000, Samuel Jayden wrote:
> > Hello,
> > I have one veb interface in OpenBSD 7.2 and 5 ethernet ports are paired
> > with this veb. As I understand from the ifconfig output, 4096 mac address
> > cache values can be kept in this veb interface .
> >
> > ifconfig veb10
> > veb10: flags=8843
> > index 12 llprio 3
> > groups: veb
> > em3 flags=3
> > port 4 ifpriority 0 ifcost 0
> > em0 flags=3
> > port 1 ifpriority 0 ifcost 0
> > em1 flags=3
> > port 2 ifpriority 0 ifcost 0
> > ix3 flags=3
> > port 8 ifpriority 0 ifcost 0
> > ix2 flags=3
> > port 7 ifpriority 0 ifcost 0
> > Addresses (max cache: 4096, timeout: 240):
> > 2c:f0:5d:73:f8:c4 em1 0 flags=0<>
> > 
> >
> > When I tried to extend this limit value with the command "ifconfig veb10
> > maxaddr 4097", I got the following error message:
> > "ifconfig: veb10: Invalid argument"
> > The maximum value I can give without this error message is 4096. Isn't
> this
> > value a bit narrow?
>
> maybe. it seemed pretty high when i made it up.
>
> > I have tested that the mac addresses of the connected devices are not
> > recorded in the veb interface after exceeding the limit.
> >
> > I want to switch from Cisco device to OpenBSD in a place where there are
> > more than 8 thousand MAC addresses, but I need to exceed this max cache
> > size value.
> > How can I increase this max cache size value 8192 or higher value?
>
> you change 4096 to a bigger number in the code.
>
> Index: if_etherbridge.c
> ===
> RCS file: /cvs/src/sys/net/if_etherbridge.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 if_etherbridge.c
> --- if_etherbridge.c5 Jul 2021 04:17:41 -   1.7
> +++ if_etherbridge.c19 Apr 2023 02:25:54 -
> @@ -675,7 +676,7 @@ int
>  etherbridge_set_max(struct etherbridge *eb, struct ifbrparam *bparam)
>  {
> if (bparam->ifbrp_csize < 1 ||
> -   bparam->ifbrp_csize > 4096) /* XXX */
> +   bparam->ifbrp_csize > 16384) /* XXX */
> return (EINVAL);
>
> /* commit */
>


Re: veb Interface Max Cache Size Restrict

2023-04-20 Thread Samuel Jayden
Yeah. Thanks. It worked.

deich...@placebonol.com , 19 Nis 2023 Çar, 17:17
tarihinde şunu yazdı:

> OpenBSD tries to limit the amount of knob tuning, people tend to shoot
> themselves in the foot when they start playing with knobs.
>
> However you can always compile your own kernel with the information
> provided.
>
> On April 19, 2023 2:12:00 AM MDT, Samuel Jayden <
> samueljaydan1...@gmail.com> wrote:
> >Sincerely thank you David for your answer,
> >I hope you may consider committing it to src and I kindly say that it
> would
> >be perfect if this max cache size limit value was tied to a sysctl
> >parameter.
> >
> >David Gwynne , 19 Nis 2023 Çar, 02:30 tarihinde şunu
> >yazdı:
> >
> >> On Tue, Apr 18, 2023 at 07:51:08PM +, Samuel Jayden wrote:
> >> > Hello,
> >> > I have one veb interface in OpenBSD 7.2 and 5 ethernet ports are
> paired
> >> > with this veb. As I understand from the ifconfig output, 4096 mac
> address
> >> > cache values can be kept in this veb interface .
> >> >
> >> > ifconfig veb10
> >> > veb10: flags=8843
> >> > index 12 llprio 3
> >> > groups: veb
> >> > em3 flags=3
> >> > port 4 ifpriority 0 ifcost 0
> >> > em0 flags=3
> >> > port 1 ifpriority 0 ifcost 0
> >> > em1 flags=3
> >> > port 2 ifpriority 0 ifcost 0
> >> > ix3 flags=3
> >> > port 8 ifpriority 0 ifcost 0
> >> > ix2 flags=3
> >> > port 7 ifpriority 0 ifcost 0
> >> > Addresses (max cache: 4096, timeout: 240):
> >> > 2c:f0:5d:73:f8:c4 em1 0 flags=0<>
> >> > 
> >> >
> >> > When I tried to extend this limit value with the command "ifconfig
> veb10
> >> > maxaddr 4097", I got the following error message:
> >> > "ifconfig: veb10: Invalid argument"
> >> > The maximum value I can give without this error message is 4096. Isn't
> >> this
> >> > value a bit narrow?
> >>
> >> maybe. it seemed pretty high when i made it up.
> >>
> >> > I have tested that the mac addresses of the connected devices are not
> >> > recorded in the veb interface after exceeding the limit.
> >> >
> >> > I want to switch from Cisco device to OpenBSD in a place where there
> are
> >> > more than 8 thousand MAC addresses, but I need to exceed this max
> cache
> >> > size value.
> >> > How can I increase this max cache size value 8192 or higher value?
> >>
> >> you change 4096 to a bigger number in the code.
> >>
> >> Index: if_etherbridge.c
> >> ===
> >> RCS file: /cvs/src/sys/net/if_etherbridge.c,v
> >> retrieving revision 1.7
> >> diff -u -p -r1.7 if_etherbridge.c
> >> --- if_etherbridge.c5 Jul 2021 04:17:41 -   1.7
> >> +++ if_etherbridge.c19 Apr 2023 02:25:54 -
> >> @@ -675,7 +676,7 @@ int
> >>  etherbridge_set_max(struct etherbridge *eb, struct ifbrparam *bparam)
> >>  {
> >> if (bparam->ifbrp_csize < 1 ||
> >> -   bparam->ifbrp_csize > 4096) /* XXX */
> >> +   bparam->ifbrp_csize > 16384) /* XXX */
> >> return (EINVAL);
> >>
> >> /* commit */
> >>
>


High Interrupt After 7.3 Upgrade

2023-05-02 Thread Samuel Jayden
Hello misc,


My firewall just slowed down after upgrading from 7.2 to 7.3.

When I look at some values on the system I’ve realized there are high
interrupts on it.


Total Interrupts are over 40.000

em1 is over 4000

em2 is over 3000

Clock is nearly 2000

ipi over 30.000


But there are no Ierrs, Oerrs or Colls on those interfaces.


You can find some hardware information and my question is where to start
for debugging?

Why IPI is so heavy?

Can it be related via this notice from 73.html

‘’Added support for per-CPU counters to evcount(9)
. Useful for counting events that are
prone to occur simultaneously across multiple CPUs, like clock interrupts
and IPIs.’’

Thanks.



# sysctl hw.model

hw.model=Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz

# sysctl hw.ncpuonline



hw.ncpuonline=8


# uptime



 9:08PM  up 13 mins, 1 user, load averages: 2.06, 1.98, 1.38


OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023

dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

real mem = 34237882368 (32651MB)

avail mem = 33180819456 (31643MB)

random: good seed from bootblocks

mpath0 at root

scsibus0 at mpath0: 256 targets

mainbus0 at root

bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7bd0 (101 entries)

bios0: vendor American Megatrends Inc. version "AHBA" date 10/03/2018

bios0: Lanner Inc. NCA4010D

efi0 at bios0: UEFI 2.4

efi0: American Megatrends rev 0x5000b

acpi0 at bios0: ACPI 5.0

acpi0: sleep states S0 S5

acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG UEFI DBG2 HPET MSCT SLIT
SRAT WDDT SSDT SSDT SSDT PRAD DMAR

acpi0: wakeup devices XHCI(S0) EHC1(S0) EHC2(S0) RP01(S0) RP02(S0) RP03(S0)
RP04(S0) RP05(S0) RP06(S0) RP07(S0) RP08(S0) BR1A(S0) BR1B(S0) BR2A(S0)
BR2B(S0) BR2C(S0) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits

acpimadt0 at acpi0 addr 0xfee0: PC-AT compat

cpu0 at mainbus0: apid 0 (boot processor)

cpu0: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz, 1995.41 MHz, 06-56-03

cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 12MB 64b/line 12-way L3 cache

cpu0: smt 0, core 0, package 0

mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges

cpu0: apic clock running at 99MHz

cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE

cpu1 at mainbus0: apid 2 (application processor)

cpu1: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz, 1995.45 MHz, 06-56-03

cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 12MB 64b/line 12-way L3 cache

cpu1: smt 0, core 1, package 0

cpu2 at mainbus0: apid 4 (application processor)

cpu2: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz, 1995.49 MHz, 06-56-03

cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 12MB 64b/line 12-way L3 cache

cpu2: smt 0, core 2, package 0

cpu3 at mainbus0: apid 6 (application processor)

cpu3: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz, 1995.58 MHz, 06-56-03

cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN

cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 12MB 64b/line 12

Re: High Interrupt After 7.3 Upgrade

2023-05-04 Thread Samuel Jayden
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.


On Tue, May 2, 2023 at 9:24 PM Samuel Jayden 
wrote:

> Hello misc,
>
>
> My firewall just slowed down after upgrading from 7.2 to 7.3.
>
> When I look at some values on the system I’ve realized there are high
> interrupts on it.
>
>
> Total Interrupts are over 40.000
>
> em1 is over 4000
>
> em2 is over 3000
>
> Clock is nearly 2000
>
> ipi over 30.000
>
>
> But there are no Ierrs, Oerrs or Colls on those interfaces.
>
>
> You can find some hardware information and my question is where to start
> for debugging?
>
> Why IPI is so heavy?
>
> Can it be related via this notice from 73.html
>
> ‘’Added support for per-CPU counters to evcount(9)
> <https://man.openbsd.org/evcount.9>. Useful for counting events that are
> prone to occur simultaneously across multiple CPUs, like clock interrupts
> and IPIs.’’
>
> Thanks.
>
>
>
> # sysctl hw.model
>
> hw.model=Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz
>
> # sysctl hw.ncpuonline
>
>
>
> hw.ncpuonline=8
>
>
> # uptime
>
>
>
>  9:08PM  up 13 mins, 1 user, load averages: 2.06, 1.98, 1.38
>
>
> OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023
>
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> real mem = 34237882368 (32651MB)
>
> avail mem = 33180819456 (31643MB)
>
> random: good seed from bootblocks
>
> mpath0 at root
>
> scsibus0 at mpath0: 256 targets
>
> mainbus0 at root
>
> bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7bd0 (101 entries)
>
> bios0: vendor American Megatrends Inc. version "AHBA" date 10/03/2018
>
> bios0: Lanner Inc. NCA4010D
>
> efi0 at bios0: UEFI 2.4
>
> efi0: American Megatrends rev 0x5000b
>
> acpi0 at bios0: ACPI 5.0
>
> acpi0: sleep states S0 S5
>
> acpi0: tables DSDT FACP APIC FPDT FIDT TCPA MCFG UEFI DBG2 HPET MSCT SLIT
> SRAT WDDT SSDT SSDT SSDT PRAD DMAR
>
> acpi0: wakeup devices XHCI(S0) EHC1(S0) EHC2(S0) RP01(S0) RP02(S0)
> RP03(S0) RP04(S0) RP05(S0) RP06(S0) RP07(S0) RP08(S0) BR1A(S0) BR1B(S0)
> BR2A(S0) BR2B(S0) BR2C(S0) [...]
>
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>
> cpu0 at mainbus0: apid 0 (boot processor)
>
> cpu0: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz, 1995.41 MHz, 06-56-03
>
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>
> cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
> 64b/line 8-way L2 cache, 12MB 64b/line 12-way L3 cache
>
> cpu0: smt 0, core 0, package 0
>
> mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
>
> cpu0: apic clock running at 99MHz
>
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE
>
> cpu1 at mainbus0: apid 2 (application processor)
>
> cpu1: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz, 1995.45 MHz, 06-56-03
>
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>
> cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
> 64b/line 8-way L2 cache, 12MB 64b/line 12-way L3 cache
>
> cpu1: smt 0, core 1, package 0
>
> cpu2 at mainbus0: apid 4 (application processor)
>
> cpu2: Intel(R) Xeon(R) CPU D-1548 @ 2.00GHz, 1995.49 MHz, 06-56-03
>
> cpu2:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED

Re: High Interrupt After 7.3 Upgrade

2023-06-01 Thread Samuel Jayden
Hi Boyd,

I noted the uptime values when I received notifications like "Internet is
slow", "Intranet is too slow" from users. In all of them, the load average
was 5 and above.
This is what I mean with the firewall just slowed down.

Also there were more error messages like these:
pmap_unwire: wiring for pmap 0xfd8e8c2f8bd8 va 0xc000a44000 didn't
change!
In Fact I live with pmap_unwire messages but that time those messages were
increased so much.

That's nearly all I have at the moment. Thanks.




On Thu, Jun 1, 2023 at 8:39 PM Boyd Stephens 
wrote:

> On 5/2/23 13:24, Samuel Jayden wrote:
> >
> > My firewall just slowed down after upgrading from 7.2 to 7.3.
>
> Hello Samuel,
>
> When you mention that your "firewall just slowed down" specifically what
> metric and/or anecdotal data are/were you using to determine this
> particular status of its operation(s)?
>
> Secondly what type of network load is present when you experience these
> issues?
>
> 
> Boyd Stephens
> I85Cyber.org
>


Multi-Queue for tun/wg/vxlan?

2024-09-12 Thread Samuel Jayden
Hello OpenBSD Misc,

I have observed that network interfaces such as ix, ixl, vmx, and others
support multi-queue functionality. Initially, I thought multi-queue support
was exclusive to physical interfaces. However, upon noticing this feature
in the vmx interface, I realized that even virtual/cloned interfaces could
possess multi-queue support.

That said, based on my observations through kstat, I see that this support
has not yet been activated in OpenBSD for virtual interfaces like tun, wg,
or vxlan, which are critical in today's networking landscape.

In this context, I wonder if this is technically infeasible, or if it's
simply not on the roadmap yet. I believe I wouldn't be mistaken in saying
that this feature would likely attract interest beyond just myself.

Thank you and best regards.


Re: SIM Card Detection Issue on Dual-SIM LTE Module

2024-10-28 Thread Samuel Jayden
Hello Barbaros,

Have you checked if this hardware is functioning without issues? It might
be worth installing Linux to see if you can establish a GSM connection
there.

Additionally, disabling umsm in the kernel could be another potential
solution. I think it’s worth a try. Here’s what you’ll need to do:
config -e -f /bsd
disable umsm
quit
reboot

I hope this works for you.

On Mon, Oct 28, 2024 at 3:33 AM Barbaros Bilek 
wrote:

> Hi misc,
>
> I'm encountering an issue with a Quectel EM120R-GL LTE module with dual
> SIM slots on OpenBSD. The system (ifconfig umb0) consistently displays the
> error "SIM not inserted, PIN required," despite attempts to set the APN,
> reboot, and bring the interface up. I’m 100% certain that the PIN is
> disabled.
>
> Here are some key command outputs and troubleshooting steps: (// are my
> comments)
>
>- AT+QSIMSTAT? → +QSIMSTAT: 0,0 // (SIM not detected)
>- AT+CPIN? → +CME ERROR: 10 // (SIM not ready)
>- AT+CIMI → +CME ERROR: // 3 (operation not allowed)
>- AT+QSIMDET=1,1 → OK // (SIM detection enabled)
>- AT+QSIMSEL=1 or AT+QSIMSEL=2 → ERROR // (cannot switch SIM slot)
>
> I also tried the following configurations with reboots after each change,
> but neither resolved the issue:
>
>- AT+QSIMDET=0,0 followed by reboot
>- AT+QSIMDET=1,0 followed by reboot
>- The AT+QSIMDET=0,0 command disables SIM detection for both slots,
>meaning the module will not check for the presence of a SIM card in either
>slot. Conversely, the AT+QSIMDET=1,0 command enables detection for the
>first SIM slot while disabling it for the second, allowing the module to
>check only the first slot for a SIM card. Neither configuration, however,
>successfully resolves the issue.
>
> In each case, AT+QSIMSTAT? consistently returns +QSIMSTAT: 0,0; showing
> that the SIM is not detected. It appears that OpenBSD cannot detect or
> manage SIM slots in this MBIM mode, and the umb driver might not fully
> support dual-SIM functionality in this context.
>
> Has anyone else encountered a similar issue or found a workaround for
> managing dual-SIM LTE modules on OpenBSD?
> Thanks in advance for any insights!
>
> P.S. Some useful command outputs:
> openbsd76# usbdevs -a 3 -vv
> addr 03: 2c7c:0620 Quectel, EM120R-GL
>   super speed, power 224 mA, config 1, rev 4.09, iSerial
> e40fc2ef
>   driver: umsm0
>   driver: umsm1
>   driver: umsm2
>   driver: umsm3
>
> It would be beneficial to add the Quectel EM120R-GL to the man umb(4)
> page. Especially if we can resolve this dual SIM issue. I’m also prepared
> to provide any additional outputs you need and to perform further actions
> as required.
>
> Also dmesg is attached via this email.
> Thanks in advance.
>
> --
> Barbaros
>
>


Re: NVMe Disk Not Recognized - OpenBSD 7.6 Installation Problem

2025-02-21 Thread Samuel Jayden
Hello Anders,

I've already tried several other brands of NVMe disks, but nothing has
changed.

In fact, since OpenBSD detects fewer network interfaces than the hardware
actually has, I believe this is a more general issue rather than something
specifically related to the NVMe disk.

I just want to reiterate: How can I assist the OpenBSD team in finding a
permanent solution?

Thank you and best regards.

On Fri, Feb 21, 2025 at 4:23 AM Anders Andersson  wrote:

> On Thu, Feb 20, 2025 at 2:07 PM Claudio Jeker 
> wrote:
> >
> > On Thu, Feb 20, 2025 at 03:59:06PM +0300, Samuel Jayden wrote:
> > > Hi again,
> > >
> > > I've replaced the NVMe disk; however, the issue persists without any
> > > noticeable improvement or change in behavior. I would greatly
> appreciate
> > > any guidance or suggestions on how to troubleshoot or resolve this
> problem.
> > > Any help would be highly valued.
> >
> > Remove some of those ixl or igc cards. You ran out of interrupts because
> > the 8 ixl and 4 igc eat them all. You may be able to disable them via
> boot
> > -c as well.
> >
> > --
> > :wq Claudio
> >
>
> Cute, running out of interrupts like it's 1988! Too bad the NVMe disks
> don't have DIP-switches. :)
>
>


Re: NVMe Disk Not Recognized - OpenBSD 7.6 Installation Problem

2025-02-20 Thread Samuel Jayden
Hi again,

I've replaced the NVMe disk; however, the issue persists without any
noticeable improvement or change in behavior. I would greatly appreciate
any guidance or suggestions on how to troubleshoot or resolve this problem.
Any help would be highly valued.

On Wed, Feb 19, 2025 at 6:43 PM Samuel Jayden 
wrote:

> Dear OpenBSD Misc Team,
>
> I am encountering an issue while trying to install OpenBSD 7.6. The
> installation process does not detect my NVMe disk.
>
> During boot, I ran machine diskinfo and confirmed that the system
> recognizes the NVMe disk:
>
> boot> machine diskinfo
> DiskBlkSiz  IoAlign SizeFlags   Checksum
> hd0 512 0   14GB0x4 0x63b8911f  Removable
> hd1 512 4   931GB   0x0 0x0
>
>
> During the installation shell, I checked the dmesg output and observed
> the following logs:
>
> # dmesg | grep nvme
> nvme0 at pci11 dev 0 function 0 vendor "Silicon Motion", unknown product
> 0x2263 rev 0x03: failed to allocate interrupt slot for PIC msix pin
> -2146762752
>
> The NVMe disk itself does not appear to have any hardware issues. I can
> see it listed in the BIOS without any problems.
>
> I have attached the dmesg.txt file for further information.
>
> Could you please advise on any steps I should take to successfully install
> OpenBSD 7.6 with this NVMe disk?
>
> Best regards,
>


Re: NVMe Disk Not Recognized - OpenBSD 7.6 Installation Problem

2025-02-20 Thread Samuel Jayden
Hello Claudio,

Thanks for your help.

I followed your advice and completely disabled ixl, which allowed me to
install and boot OpenBSD 7.6.
However, since there is no configuration option like disable ixl4, all
interfaces were disabled.
This hardware actually has 8 multi-gig igc RJ45 interfaces and 8 10G SFP+ ixl
fiber interfaces.
As a temporary workaround, it would be sufficient if I could get 4 copper
ports and 4 fiber ports working.
I will check whether I can partially disable the interfaces from the
device's BIOS.

In the meantime, what should be done for a permanent solution?
If there are any outputs I can share to assist, please let me know.

On Thu, Feb 20, 2025 at 4:02 PM Claudio Jeker 
wrote:

> On Thu, Feb 20, 2025 at 03:59:06PM +0300, Samuel Jayden wrote:
> > Hi again,
> >
> > I've replaced the NVMe disk; however, the issue persists without any
> > noticeable improvement or change in behavior. I would greatly appreciate
> > any guidance or suggestions on how to troubleshoot or resolve this
> problem.
> > Any help would be highly valued.
>
> Remove some of those ixl or igc cards. You ran out of interrupts because
> the 8 ixl and 4 igc eat them all. You may be able to disable them via boot
> -c as well.
>
> > On Wed, Feb 19, 2025 at 6:43 PM Samuel Jayden <
> samueljaydan1...@gmail.com>
> > wrote:
> >
> > > Dear OpenBSD Misc Team,
> > >
> > > I am encountering an issue while trying to install OpenBSD 7.6. The
> > > installation process does not detect my NVMe disk.
> > >
> > > During boot, I ran machine diskinfo and confirmed that the system
> > > recognizes the NVMe disk:
> > >
> > > boot> machine diskinfo
> > > DiskBlkSiz  IoAlign SizeFlags   Checksum
> > > hd0 512 0   14GB0x4 0x63b8911f  Removable
> > > hd1 512 4   931GB   0x0 0x0
> > >
> > >
> > > During the installation shell, I checked the dmesg output and observed
> > > the following logs:
> > >
> > > # dmesg | grep nvme
> > > nvme0 at pci11 dev 0 function 0 vendor "Silicon Motion", unknown
> product
> > > 0x2263 rev 0x03: failed to allocate interrupt slot for PIC msix pin
> > > -2146762752
> > >
> > > The NVMe disk itself does not appear to have any hardware issues. I can
> > > see it listed in the BIOS without any problems.
> > >
> > > I have attached the dmesg.txt file for further information.
> > >
> > > Could you please advise on any steps I should take to successfully
> install
> > > OpenBSD 7.6 with this NVMe disk?
> > >
> > > Best regards,
> > >
>
> --
> :wq Claudio
>


NVMe Disk Not Recognized - OpenBSD 7.6 Installation Problem

2025-02-19 Thread Samuel Jayden
Dear OpenBSD Misc Team,

I am encountering an issue while trying to install OpenBSD 7.6. The
installation process does not detect my NVMe disk.

During boot, I ran machine diskinfo and confirmed that the system
recognizes the NVMe disk:

boot> machine diskinfo
DiskBlkSiz  IoAlign SizeFlags   Checksum
hd0 512 0   14GB0x4 0x63b8911f  Removable
hd1 512 4   931GB   0x0 0x0


During the installation shell, I checked the dmesg output and observed the
following logs:

# dmesg | grep nvme
nvme0 at pci11 dev 0 function 0 vendor "Silicon Motion", unknown product
0x2263 rev 0x03: failed to allocate interrupt slot for PIC msix pin
-2146762752

The NVMe disk itself does not appear to have any hardware issues. I can see
it listed in the BIOS without any problems.

I have attached the dmesg.txt file for further information.

Could you please advise on any steps I should take to successfully install
OpenBSD 7.6 with this NVMe disk?

Best regards,
OpenBSD 7.6-current (RAMDISK_CD) #502: Tue Jan 21 10:52:50 MST 2025
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 34100400128 (32520MB)
avail mem = 33060233216 (31528MB)
random: good seed from bootblocks
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x75bf4000 (105 entries)
bios0: vendor American Megatrends International, LLC. version "5.27" date 
03/02/2024
bios0: Default string Default string
acpi0 at bios0: ACPI 6.4
acpi0: tables DSDT FACP FIDT SSDT SSDT SSDT SSDT HPET APIC MCFG SSDT UEFI NHLT 
LPIT SSDT SSDT SSDT DBGP DBG2 SSDT DMAR FPDT SSDT SSDT SSDT SSDT TPM2 PHAT WSMT
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 12th Gen Intel(R) Core(TM) i7-12700K, 3592.29 MHz, 06-97-02, patch 
0026
cpu0: cpuid 1 
edx=bfebfbff
 
ecx=77fafbff
cpu0: cpuid 6 eax=dfcff5 ecx=409
cpu0: cpuid 7.0 
ebx=239c27eb
 ecx=98c027ac 
edx=fc1cc410
cpu0: cpuid a vers=5, gp=6, gpwidth=48, ff=3, ffwidth=48
cpu0: cpuid d.1 eax=f
cpu0: cpuid 8001 edx=2c100800 
ecx=121
cpu0: cpuid 8007 edx=100
cpu0: msr 
10a=88fd6b
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 
10-way L2 cache, 25MB 64b/line 10-way L3 cache
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PC00)
acpiprt1 at acpi0: bus 1 (PEG1)
acpiprt2 at acpi0: bus -1 (PEG0)
acpiprt3 at acpi0: bus -1 (RP09)
acpiprt4 at acpi0: bus -1 (RP10)
acpiprt5 at acpi0: bus -1 (RP11)
acpiprt6 at acpi0: bus -1 (RP12)
acpiprt7 at acpi0: bus -1 (RP13)
acpiprt8 at acpi0: bus -1 (RP14)
acpiprt9 at acpi0: bus 11 (RP15)
acpiprt10 at acpi0: bus -1 (RP16)
acpiprt11 at acpi0: bus 3 (RP01)
acpiprt12 at acpi0: bus 4 (RP02)
acpiprt13 at acpi0: bus 5 (RP03)
acpiprt14 at acpi0: bus 6 (RP04)
acpiprt15 at acpi0: bus 7 (RP05)
acpiprt16 at acpi0: bus 8 (RP06)
acpiprt17 at acpi0: bus 9 (RP07)
acpiprt18 at acpi0: bus 10 (RP08)
acpiprt19 at acpi0: bus -1 (RP17)
acpiprt20 at acpi0: bus -1 (RP18)
acpiprt21 at acpi0: bus -1 (RP19)
acpiprt22 at acpi0: bus -1 (RP20)
acpiprt23 at acpi0: bus -1 (RP21)
acpiprt24 at acpi0: bus -1 (RP22)
acpiprt25 at acpi0: bus -1 (RP23)
acpiprt26 at acpi0: bus -1 (RP24)
acpiprt27 at acpi0: bus 2 (RP25)
acpiprt28 at acpi0: bus -1 (RP26)
acpiprt29 at acpi0: bus -1 (RP27)
acpiprt30 at acpi0: bus -1 (RP28)
acpiec0 at acpi0: not present
acpipci0 at acpi0 PC00: 0x0010 0x0011 0x
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
"ACPI000E" at acpi0 not configured
"PNP0C0E" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"INT33A1" at acpi0 not configured
"PNP0C0C" at acpi0 not configured
"MSFT0101" at acpi0 not configured
"MSFT8000" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpipwrres at acpi0 not configured
acpitz at acpi0 not configured
acpipwrres at acpi0 no

Debugging "SIM Not Inserted PIN Required" issue

2025-03-06 Thread Samuel Jayden
Hello OpenBSD,


I am experiencing a peculiar issue with a device in which I use a Sierra
Wireless EM7455(*) LTE module that I have converted to MBIM mode. I have
also disabled umsm by entering config -e -f /bsd.

Most of the time, the umb status on my device appears as *"SIM not inserted
PIN required,"* even though a SIM card is physically inserted. The only
scenario in which I achieve success is after rebooting the device. However,
rebooting is not a guaranteed solution—sometimes, it takes 4-5 consecutive
reboots before umb0 becomes functional.

How can I debug this issue?

For further context, I have also swapped out the LTE module with another
unit, yet I observe the same behavior across 5-6 different devices of the
same make and model.

*P.S.* The device has a single LTE module but dual SIM slots.

(*)
addr 03: 1199:9071 Sierra Wireless, Incorporated, Sierra Wireless EM7455
Qualcomm Snapdragon X7 LTE-A super speed, power 126 mA, config 1, rev 0.06,
iSerial LF10770712011033 driver: umb0 driver: ugen0

Also dmesg is attached via this email.

Thanks in advance.
OpenBSD 7.6 (GENERIC.MP) #338: Mon Sep 30 08:55:35 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8527794176 (8132MB)
avail mem = 8246099968 (7864MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f204000 (50 entries)
bios0: vendor American Megatrends Inc. version "FNCA1515B0VS16T001" date 
08/26/2019
bios0: Lanner Electronics Inc. NCA-1515B
efi0 at bios0: UEFI 2.6
efi0: American Megatrends rev 0x5000d
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP FPDT FIDT TCPA MCFG WDAT APIC BDAT HPET UEFI SSDT DMAR 
SPCR WSMT
acpi0: wakeup devices XHC1(S4) PEX0(S0) PEX4(S0) PEX5(S0) PEX6(S0) LAN0(S0) 
LAN1(S0) LAN2(S0) LAN3(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 4 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.01 MHz, 06-5f-01, patch 
003e
cpu0: cpuid 1 
edx=bfebfbff
 
ecx=47f8ebbf
cpu0: cpuid 6 eax=55 ecx=9
cpu0: cpuid 7.0 
ebx=2294e283 
edx=ac000400
cpu0: cpuid a vers=4, gp=4, gpwidth=48, ff=3, ffwidth=48
cpu0: cpuid d.1 eax=f
cpu0: cpuid 8001 edx=2c100800 ecx=101
cpu0: cpuid 8007 edx=100
cpu0: msr 
10a=14000c69
cpu0: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 
16-way L2 cache
cpu0: smt 0, core 2, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 25MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2, IBE
cpu1 at mainbus0: apid 12 (application processor)
cpu1: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.03 MHz, 06-5f-01, patch 
003e
cpu1: smt 0, core 6, package 0
cpu2 at mainbus0: apid 16 (application processor)
cpu2: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.02 MHz, 06-5f-01, patch 
003e
cpu2: smt 0, core 8, package 0
cpu3 at mainbus0: apid 24 (application processor)
cpu3: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz, 2200.02 MHz, 06-5f-01, patch 
003e
cpu3: smt 0, core 12, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (PEX0)
acpiprt2 at acpi0: bus 10 (PEX4)
acpiprt3 at acpi0: bus 4 (PEX5)
acpiprt4 at acpi0: bus 5 (PEX6)
acpiprt5 at acpi0: bus 6 (VRP0)
acpiprt6 at acpi0: bus 8 (VRP1)
acpiprt7 at acpi0: bus 1 (VRP2)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
"PNP0003" at acpi0 not configured
acpicmos0 at acpi0
com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 3: ns16550a, 16 byte fifo
"PNP0C33" at acpi0 not configured
tpm0 at acpi0 TPM_ 1.2 (TIS) addr 0xfed4/0x5000, WEC WPCT200 rev 0x4
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
acpitz0 at acpi0: critical temperature is 91 degC
cpu0: using VERW MDS workaround
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel C3000 Host" rev 0x11
pchb1 at pci0 dev 4 function 0 "Intel C3000 GLREG" rev 0x11
"Intel C3000 RCEC" rev 0x11 at pci0 dev 5 function 0 not configured
ppb0 at pci0 dev 6 function 0 "Intel C3000 PCIE" rev 0x11
pci1 at ppb0 bus 1
"Intel C3000 QAT" rev 0x11 at pci1 dev 0 function 0 not configured
ppb1 at pci0 dev 9 function 0 "Intel C3000 PCIE" rev 0x11
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel I350 Fiber" rev 0x01: msi, address 
00:90:0b:9e:d7:d5
em1 at pci2 dev 0 function 1 "Intel I350 Fiber" rev 0x01: msi, address 
00:90:0b:9e:d7:d6
em2 at pci2 dev 0 function 2 "Intel I350" rev 0x01: msi, address 
00:90:0b:9e:d7:d7
em3 at pci2 dev 0 function 3 "Intel I350" rev 0x01: msi, address 
00:90:0b:9e:d7:d8
ppb2 at pci0 dev 14 function 0 "Intel C3000 PCIE" rev 0x11
pci3 at ppb2 bus 10
ppb3 at pci0 dev 15 

Re: Debugging "SIM Not Inserted PIN Required" issue

2025-03-07 Thread Samuel Jayden
Hello again,

Has anyone encountered a similar issue or have any insights on potential
debugging approaches? Any guidance would be greatly appreciated.

Looking forward to your thoughts.

Best regards,
Sam

On Thu, Mar 6, 2025 at 1:28 PM Samuel Jayden 
wrote:

> Hello OpenBSD,
>
>
> I am experiencing a peculiar issue with a device in which I use a Sierra
> Wireless EM7455(*) LTE module that I have converted to MBIM mode. I have
> also disabled umsm by entering config -e -f /bsd.
>
> Most of the time, the umb status on my device appears as *"SIM not
> inserted PIN required,"* even though a SIM card is physically inserted.
> The only scenario in which I achieve success is after rebooting the device.
> However, rebooting is not a guaranteed solution—sometimes, it takes 4-5
> consecutive reboots before umb0 becomes functional.
>
> How can I debug this issue?
>
> For further context, I have also swapped out the LTE module with another
> unit, yet I observe the same behavior across 5-6 different devices of the
> same make and model.
>
> *P.S.* The device has a single LTE module but dual SIM slots.
>
> (*)
> addr 03: 1199:9071 Sierra Wireless, Incorporated, Sierra Wireless EM7455
> Qualcomm Snapdragon X7 LTE-A super speed, power 126 mA, config 1, rev 0.06
> , iSerial LF10770712011033 driver: umb0 driver: ugen0
>
> Also dmesg is attached via this email.
>
> Thanks in advance.
>
>