Re: DHCP server ignoring PF rules?

2022-12-17 Thread Barbaros Bilek
Hello Cristian,

If you put your physical interface into veb(4) and set link1 flag you can
filter dhcp packets.
For more please read man veb
Have a nice weekend.

--
Best Regards
Barbaros



On Sat, Dec 17, 2022 at 4:40 PM Cristian Danila  wrote:

> Thanks for the provided info, now it makes sense about what is happening.
> Any idea about a possible way to control these packets?
> Still investigating but I had still not found yet a way to do it.
>
> Thank you.
>
> On Sat, Dec 17, 2022 at 3:11 PM David Gwynne  wrote:
> >
> > dhcpd reads packets off the wire using BPF, which happens as packets
> come off the network interface, but before the IP stack where pf runs.
> >
> > > On 17 Dec 2022, at 22:40, Cristian Danila  wrote:
> > >
> > > Good day!
> > > I finished setup an DHCP server and for some reason it seems DHCP
> > > server is ignoring PF filter.
> > > In short, in PF I have active only one rule:
> > > block drop quick all
> > >
> > > Double checked PF and it is enabled
> > > So using a windows machine to test DHCP server:
> > > 1) ifconfig /release
> > > 2) ifconfig /renew
> > >
> > > somehow dhcpd still serves the windows(only when is enabled) and
> > > ignores PF rule.
> > > Could you please help me in telling if dhcpd has some intended logic
> > > to ignore PF or what might
> > > cause this unexpected behavior?
> > >
> > > Kind Regards!
> > >
> >
>
>


Re: Multicast Routing issues with OpenBSD

2022-11-10 Thread Barbaros Bilek
Hi Tarkan,

I've already tried all of them but it is not working.
Also note that PIM support was removed from OpenBSD; so it's an option. [*]

[*] https://www.mail-archive.com/tech@openbsd.org/msg43264.html


On Wed, Nov 9, 2022 at 3:37 PM Tarkan Erimer - BSD 
wrote:

>
>
> On 9.11.2022 12.39 PM, Barbaros Bilek wrote:
> > Hi again,
> >
> > I've added this route :
> > ''route add 239.0.1.2/32 172.16.1.1''
> > But nothing changed.
> > Is OpenBSD capable of multicast routing? Am I doing a wrong
> configuration?
> > Any thoughts?
> > Thanks in advance.
> >
> > On Tue, Nov 8, 2022 at 6:28 PM Barbaros Bilek 
> > wrote:
> >
> >> Hi Folks,
> >>
> >> I try to do multicast routing with OpenBSD 7.2
> >> Here is my setup:
> >>
> >> # Default GW to internet
> >> echo 'inet autoconf' > /etc/hostname.em0
> >> # Get 10.10.12.81/24 from dhcp-server with gw 10.10.12.1
> >>
> >> # Multicast Server  Interface (transmit packets)
> >> echo 'inet 172.16.1.1 255.255.255.0 NONE' > /etc/hostname.em1
> >> # Multicast Client interface (receive packets)
> >> echo 'inet 172.16.55.1 255.255.255.0 NONE' > /etc/hostname.em2
> >> # Forward ip & multicast
> >> echo 'sysctl net.inet.ip.forwarding=1' > /etc/sysctl.conf
> >> echo 'sysctl net.inet.ip.mforwarding=1' >> /etc/sysctl.conf
> >> # Enable Multicast on OpenBSD
> >> rcctl enable multicast
> >> # Disable PF
> >> rcctl disable pf
> >>
> >> # Mrouted Configuration
> >> multicast_test# cat /etc/mrouted.conf
> >> name STD 239.0.0.0/16
> >> pruning on
> >> phyint 172.16.1.1 threshold 16
> >> boundary STD
> >> altnet 172.16.0.0/16
> >> phyint 172.16.55.1 threshold 16
> >> boundary STD
> >> altnet 172.16.0.0/16
> >> phyint 10.10.12.81 disable
> >> # Enable mrouted on startUp
> >> rcctl enable mrouted
> >> # Reboot system
> >> reboot
> >>
> >> For testing purposes I use this application : Singlewire Software IC
> Test
> >> Multicast (It uses )
> >> I'm sure about my testing environment. Because when I use a Brocade ICX
> L3
> >> switch with router pim configuration everything is ok. But with OpenBSD
> >> multicast routing fails:
> >>
> >> Here some logs :
> >>
> >> multicast_test# mrinfo
> >>
> >> 127.0.0.1 (localhost) [version 3.8,prune,genid,mtrace]:
> >>
> >>10.10.12.81 -> 0.0.0.0 (local) [1/1/disabled]
> >>
> >>172.16.1.1 -> 0.0.0.0 (local) [1/16/querier/leaf]
> >>
> >>172.16.55.1 -> 0.0.0.0 (local) [1/16/querier/leaf]
> >>
> >>
> >> multicast_test# netstat -g
> >>
> >>
> >> Virtual Interface Table
> >>
> >>   Vif  Thresh  Local-AddressRemote-Address   Pkt_in  Pkt_out
> >>
> >> 1  16  172.16.1.1   4580
> >>
> >> 2  16  172.16.55.100
> >>
> >>
> >> Multicast Forwarding Cache
> >>
> >>   Hash  Origin   Mcastgroup   Traffic  In-Vif
> >> Out-Vifs/Forw-ttl
> >>
> >>  0  172.16.1.1   239.0.1.2   458B   1
> >>
> >>
> >> Total no. of entries in cache: 1
> >>
> >>
> >> IPv6 Multicast Interface Table is empty
> >>
> >> IPv6 Multicast Routing Table is empty
> >>
> >>
> >> Output when I run mrouted at debug mode :
> >>
> >>
> >> multicast_test# mrouted -d
> >>
> >>
> >>
> >>
> >> mrouted: debug level invalid
> >>
> >> debug level 2
> >>
> >> 18:06:55.405 mrouted version 3.8
> >>
> >> 18:06:55.407 Getting vifs from kernel interfaces
> >>
> >> 18:06:55.408 installing em0 (10.10.12.81 on subnet 10.10.12/24) as vif
> #0
> >> - rate=0
> >>
> >> 18:06:55.408 installing em1 (172.16.1.1 on subnet 172.16.1/24) as vif
> #1 -
> >> rate=0
> >>
> >> 18:06:55.408 installing em2 (172.16.55.1 on subnet 172.16.55/24) as vif
> #2
> >> - rate=0
> >>
> >> 18:06:55.408 Getting vifs from /etc/mrouted.conf
> >>
> >> 18:06:55.408 Installing vifs in mrouted...
> >>
> >> 18:06:55.408 vif #1, phyint 172.16.1.1
> >>
> >> 18:06:55.409 vif #2, ph

Re: Multicast Routing issues with OpenBSD

2022-11-09 Thread Barbaros Bilek
Hi again,

I've added this route :
''route add 239.0.1.2/32 172.16.1.1''
But nothing changed.
Is OpenBSD capable of multicast routing? Am I doing a wrong configuration?
Any thoughts?
Thanks in advance.

On Tue, Nov 8, 2022 at 6:28 PM Barbaros Bilek 
wrote:

> Hi Folks,
>
> I try to do multicast routing with OpenBSD 7.2
> Here is my setup:
>
> # Default GW to internet
> echo 'inet autoconf' > /etc/hostname.em0
> # Get 10.10.12.81/24 from dhcp-server with gw 10.10.12.1
>
> # Multicast Server  Interface (transmit packets)
> echo 'inet 172.16.1.1 255.255.255.0 NONE' > /etc/hostname.em1
> # Multicast Client interface (receive packets)
> echo 'inet 172.16.55.1 255.255.255.0 NONE' > /etc/hostname.em2
> # Forward ip & multicast
> echo 'sysctl net.inet.ip.forwarding=1' > /etc/sysctl.conf
> echo 'sysctl net.inet.ip.mforwarding=1' >> /etc/sysctl.conf
> # Enable Multicast on OpenBSD
> rcctl enable multicast
> # Disable PF
> rcctl disable pf
>
> # Mrouted Configuration
> multicast_test# cat /etc/mrouted.conf
> name STD 239.0.0.0/16
> pruning on
> phyint 172.16.1.1 threshold 16
> boundary STD
> altnet 172.16.0.0/16
> phyint 172.16.55.1 threshold 16
> boundary STD
> altnet 172.16.0.0/16
> phyint 10.10.12.81 disable
> # Enable mrouted on startUp
> rcctl enable mrouted
> # Reboot system
> reboot
>
> For testing purposes I use this application : Singlewire Software IC Test
> Multicast (It uses )
> I'm sure about my testing environment. Because when I use a Brocade ICX L3
> switch with router pim configuration everything is ok. But with OpenBSD
> multicast routing fails:
>
> Here some logs :
>
> multicast_test# mrinfo
>
> 127.0.0.1 (localhost) [version 3.8,prune,genid,mtrace]:
>
>   10.10.12.81 -> 0.0.0.0 (local) [1/1/disabled]
>
>   172.16.1.1 -> 0.0.0.0 (local) [1/16/querier/leaf]
>
>   172.16.55.1 -> 0.0.0.0 (local) [1/16/querier/leaf]
>
>
> multicast_test# netstat -g
>
>
> Virtual Interface Table
>
>  Vif  Thresh  Local-AddressRemote-Address   Pkt_in  Pkt_out
>
>1  16  172.16.1.1   4580
>
>2  16  172.16.55.100
>
>
> Multicast Forwarding Cache
>
>  Hash  Origin   Mcastgroup   Traffic  In-Vif
> Out-Vifs/Forw-ttl
>
> 0  172.16.1.1   239.0.1.2   458B   1
>
>
> Total no. of entries in cache: 1
>
>
> IPv6 Multicast Interface Table is empty
>
> IPv6 Multicast Routing Table is empty
>
>
> Output when I run mrouted at debug mode :
>
>
> multicast_test# mrouted -d
>
>
>
>
> mrouted: debug level invalid
>
> debug level 2
>
> 18:06:55.405 mrouted version 3.8
>
> 18:06:55.407 Getting vifs from kernel interfaces
>
> 18:06:55.408 installing em0 (10.10.12.81 on subnet 10.10.12/24) as vif #0
> - rate=0
>
> 18:06:55.408 installing em1 (172.16.1.1 on subnet 172.16.1/24) as vif #1 -
> rate=0
>
> 18:06:55.408 installing em2 (172.16.55.1 on subnet 172.16.55/24) as vif #2
> - rate=0
>
> 18:06:55.408 Getting vifs from /etc/mrouted.conf
>
> 18:06:55.408 Installing vifs in mrouted...
>
> 18:06:55.408 vif #1, phyint 172.16.1.1
>
> 18:06:55.409 vif #2, phyint 172.16.55.1
>
> pruning on
>
> 18:06:55.410 Installing vifs in kernel...
>
> 18:06:55.410 vif #1, phyint 172.16.1.1
>
> 18:06:55.410 vif #2, phyint 172.16.55.1
>
> vifs_with_neighbors = 0
>
>
> Virtual Interface Table
>
> Vif  Name  Local-Address   M  Thr  Rate
> Flags
>
>  0em0  10.10.12.81 subnet: 10.10.12/24 1   1  0
> disabled
>
> 18:06:55.411 warning - SIOCGETVIFCNT fails
>
>
>  1em1  172.16.1.1  subnet: 172.16.1/24 1  16  0
> querier
>
> alternate subnets: 172.16/16
>
>boundaries: 239.0/16
>
> 18:06:55.411 warning - SIOCGETVIFCNT fails
>
>
>  2em2  172.16.55.1 subnet: 172.16.55/241  16  0
> querier
>
> alternate subnets: 172.16/16
>
>boundaries: 239.0/16
>
> 18:06:55.411 warning - SIOCGETVIFCNT fails
>
>
>
> Multicast Routing Table (3 entries)
>
>  Origin-Subnet  From-GatewayMetric Tmr In-Vif  Out-Vifs
>
>  172.16.55/24  1 0   21*
>
>  172.16.1/24   1 0   12*
>
>  172.16/16 1 0   12*
>
>
> 18:07:15.583 update 0 starting at 3 of 3
>
> 18:07:16.593 update 0 starting at 3 of 3
>
> 18:07:17.602 update 0 starting at 3 of 3
>
> 18:07:18.612 upda

Multicast Routing issues with OpenBSD

2022-11-08 Thread Barbaros Bilek
Hi Folks,

I try to do multicast routing with OpenBSD 7.2
Here is my setup:

# Default GW to internet
echo 'inet autoconf' > /etc/hostname.em0
# Get 10.10.12.81/24 from dhcp-server with gw 10.10.12.1

# Multicast Server  Interface (transmit packets)
echo 'inet 172.16.1.1 255.255.255.0 NONE' > /etc/hostname.em1
# Multicast Client interface (receive packets)
echo 'inet 172.16.55.1 255.255.255.0 NONE' > /etc/hostname.em2
# Forward ip & multicast
echo 'sysctl net.inet.ip.forwarding=1' > /etc/sysctl.conf
echo 'sysctl net.inet.ip.mforwarding=1' >> /etc/sysctl.conf
# Enable Multicast on OpenBSD
rcctl enable multicast
# Disable PF
rcctl disable pf

# Mrouted Configuration
multicast_test# cat /etc/mrouted.conf
name STD 239.0.0.0/16
pruning on
phyint 172.16.1.1 threshold 16
boundary STD
altnet 172.16.0.0/16
phyint 172.16.55.1 threshold 16
boundary STD
altnet 172.16.0.0/16
phyint 10.10.12.81 disable
# Enable mrouted on startUp
rcctl enable mrouted
# Reboot system
reboot

For testing purposes I use this application : Singlewire Software IC Test
Multicast (It uses )
I'm sure about my testing environment. Because when I use a Brocade ICX L3
switch with router pim configuration everything is ok. But with OpenBSD
multicast routing fails:

Here some logs :

multicast_test# mrinfo

127.0.0.1 (localhost) [version 3.8,prune,genid,mtrace]:

  10.10.12.81 -> 0.0.0.0 (local) [1/1/disabled]

  172.16.1.1 -> 0.0.0.0 (local) [1/16/querier/leaf]

  172.16.55.1 -> 0.0.0.0 (local) [1/16/querier/leaf]


multicast_test# netstat -g


Virtual Interface Table

 Vif  Thresh  Local-AddressRemote-Address   Pkt_in  Pkt_out

   1  16  172.16.1.1   4580

   2  16  172.16.55.100


Multicast Forwarding Cache

 Hash  Origin   Mcastgroup   Traffic  In-Vif  Out-Vifs/Forw-ttl

0  172.16.1.1   239.0.1.2   458B   1


Total no. of entries in cache: 1


IPv6 Multicast Interface Table is empty

IPv6 Multicast Routing Table is empty


Output when I run mrouted at debug mode :


multicast_test# mrouted -d




mrouted: debug level invalid

debug level 2

18:06:55.405 mrouted version 3.8

18:06:55.407 Getting vifs from kernel interfaces

18:06:55.408 installing em0 (10.10.12.81 on subnet 10.10.12/24) as vif #0 -
rate=0

18:06:55.408 installing em1 (172.16.1.1 on subnet 172.16.1/24) as vif #1 -
rate=0

18:06:55.408 installing em2 (172.16.55.1 on subnet 172.16.55/24) as vif #2
- rate=0

18:06:55.408 Getting vifs from /etc/mrouted.conf

18:06:55.408 Installing vifs in mrouted...

18:06:55.408 vif #1, phyint 172.16.1.1

18:06:55.409 vif #2, phyint 172.16.55.1

pruning on

18:06:55.410 Installing vifs in kernel...

18:06:55.410 vif #1, phyint 172.16.1.1

18:06:55.410 vif #2, phyint 172.16.55.1

vifs_with_neighbors = 0


Virtual Interface Table

Vif  Name  Local-Address   M  Thr  Rate   Flags

 0em0  10.10.12.81 subnet: 10.10.12/24 1   1  0
disabled

18:06:55.411 warning - SIOCGETVIFCNT fails


 1em1  172.16.1.1  subnet: 172.16.1/24 1  16  0
querier

alternate subnets: 172.16/16

   boundaries: 239.0/16

18:06:55.411 warning - SIOCGETVIFCNT fails


 2em2  172.16.55.1 subnet: 172.16.55/241  16  0
querier

alternate subnets: 172.16/16

   boundaries: 239.0/16

18:06:55.411 warning - SIOCGETVIFCNT fails



Multicast Routing Table (3 entries)

 Origin-Subnet  From-GatewayMetric Tmr In-Vif  Out-Vifs

 172.16.55/24  1 0   21*

 172.16.1/24   1 0   12*

 172.16/16 1 0   12*


18:07:15.583 update 0 starting at 3 of 3

18:07:16.593 update 0 starting at 3 of 3

18:07:17.602 update 0 starting at 3 of 3

18:07:18.612 update 0 starting at 3 of 3


When i watch packets on em1 i can see multicast packets are arriving:
(constantly
increasing...)

multicast_test# tcpdump -nettti em1 host 239.0.1.2

tcpdump: listening on em1, link-type EN10MB

Nov 08 18:19:33.344608 2c:f0:5d:73:f8:c4 01:00:5e:00:01:02 0800 73:
172.16.1.2.50665 > 239.0.1.2.20480: udp 31

Nov 08 18:19:34.358455 2c:f0:5d:73:f8:c4 01:00:5e:00:01:02 0800 73:
172.16.1.2.50665 > 239.0.1.2.20480: udp 31


But at the receiver side (em2) there are no multicast packets transmitted
by em1
After a while i saw only one packet as igmp nreport with TTL 1

multicast_test# tcpdump -nettti em2 host 239.0.1.2

tcpdump: listening on em2, link-type EN10MB

Nov 08 18:21:12.994258 2c:f0:5d:73:f8:c3 01:00:5e:00:01:02 0800 60:
172.16.55.2 > 239.0.1.2: igmp nreport 239.0.1.2 [ttl 1]


I've even tried some igmp/mcast proxies but could not figure out how to
become a multicast router with my best OS, OpenBSD.

I can not understand what I am doing wrong.
Thanks and regards.


Re: Howto convert Sierra Wireless EM7455 from umsm to umb

2022-11-06 Thread Barbaros Bilek
Hi again,

But I could not figure out how to connect this card's serial ports.
I've tried the cu command but what is the exact serial port for that card?
How can I find it?

On Sun, Nov 6, 2022 at 4:23 PM Marcus MERIGHI  wrote:

> Hello Barbaros,
>
> barbarosb...@gmail.com (Barbaros Bilek), 2022.11.06 (Sun) 13:49 (CET):
> > Thanks for your reply.
> > I've tried disabling umsm but it didn't work.
> > Now OpenBSD recognize it as ugen0
> > ugen0 at uhub0 port 7 "Sierra Wireless, Incorporated Sierra Wireless
> EM7455
> > Qualcomm\M-. Snapdragon? X7 LTE-A" rev 3.00/0.06 addr 2
>
> sorry about that, but worth a try.
>
> > Also, I think the link you posted above is wrong.
>
> I have no idea how that happend. The subject was
>
> List SIMCom SIM8262E-M2 as supported for umb(4)
> (Kevin Lo )
>
> https://marc.info/?l=openbsd-tech=166523975919835
>
> If I got it right this time. It's a non-standard AT command to be sent
> via one of the serial ports of the card.
>
> Marcus
>
> > It talks about something different ("patch for embedded controller
> > detection") and I couldn't relate with this issue.
> > Regards.
> >
> > P.S. dmesg attached, also i can supply more. Thanks for reading.
> >
> >
> > On Sun, Nov 6, 2022 at 1:45 PM Marcus MERIGHI 
> wrote:
> >
> > > barbarosb...@gmail.com (Barbaros Bilek), 2022.11.05 (Sat) 23:22 (CET):
> > > > I have Sierra Wireless EM7455 on my OpenBSD 7.2 router device.
> > > > OpenBSD detects this card like this:
> > > [...]
> > > > Is it possible to convert this card into MBIM mode to get an umb
> device?
> > > > Thanks.
> > >
> > > The man page of umb(4) lists this device, so it should work.
> > > You could try disabling umsm(4) with config(8) and see if this
> > > makes it attach as umb(4)
> > > Maybe you need a magical command like the one mentioned here:
> > >
> > > https://marc.info/?l=openbsd-tech=166523592618229
> > >
> > > Marcus
> > >
>
> > OpenBSD 7.2 (GENERIC.MP) #0: Wed Oct 26 12:01:47 MDT 2022
> > r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
> GENERIC.MP
> > real mem = 4244283392 (4047MB)
> > avail mem = 4098240512 (3908MB)
> > random: good seed from bootblocks
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f31 (47 entries)
> > bios0: vendor American Megatrends Inc. version "R1.00" date 01/31/2019
> > bios0: Caswell CAN-0261
> > acpi0 at bios0: ACPI 6.1
> > acpi0: sleep states S0 S4 S5
> > acpi0: tables DSDT FACP FPDT FIDT TCPA MCFG WDAT APIC BDAT HPET UEFI
> SSDT DMAR SPCR HEST BERT ERST EINJ WSMT
> > acpi0: wakeup devices PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4)
> PEX5(S4) PEX6(S4) PEX7(S4) XHC1(S4) LAN0(S4) LAN1(S4) LAN2(S4) LAN3(S4)
> > 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 12 (boot processor)
> > cpu0: Intel(R) Atom(TM) CPU C3338 @ 1.50GHz, 1500.01 MHz, 06-5f-01
> > 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,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > 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 6, 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 24 (application processor)
> > cpu1: Intel(R) Atom(TM) CPU C3338 @ 1.50GHz, 1500.02 MHz, 06-5f-01
> > 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,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
> > cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 2MB
> 64b/line 16-way L2 cache
> > 

Re: Howto convert Sierra Wireless EM7455 from umsm to umb

2022-11-06 Thread Barbaros Bilek
Hi Marcus,

Thanks for your reply.
I've tried disabling umsm but it didn't work.
Now OpenBSD recognize it as ugen0
ugen0 at uhub0 port 7 "Sierra Wireless, Incorporated Sierra Wireless EM7455
Qualcomm\M-. Snapdragon? X7 LTE-A" rev 3.00/0.06 addr 2

Also, I think the link you posted above is wrong.
It talks about something different ("patch for embedded controller
detection") and I couldn't relate with this issue.
Regards.

P.S. dmesg attached, also i can supply more. Thanks for reading.


On Sun, Nov 6, 2022 at 1:45 PM Marcus MERIGHI  wrote:

> barbarosb...@gmail.com (Barbaros Bilek), 2022.11.05 (Sat) 23:22 (CET):
> > I have Sierra Wireless EM7455 on my OpenBSD 7.2 router device.
> > OpenBSD detects this card like this:
> [...]
> > Is it possible to convert this card into MBIM mode to get an umb device?
> > Thanks.
>
> The man page of umb(4) lists this device, so it should work.
> You could try disabling umsm(4) with config(8) and see if this
> makes it attach as umb(4)
> Maybe you need a magical command like the one mentioned here:
>
> https://marc.info/?l=openbsd-tech=166523592618229
>
> Marcus
>
OpenBSD 7.2 (GENERIC.MP) #0: Wed Oct 26 12:01:47 MDT 2022

r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4244283392 (4047MB)
avail mem = 4098240512 (3908MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7f31 (47 entries)
bios0: vendor American Megatrends Inc. version "R1.00" date 01/31/2019
bios0: Caswell CAN-0261
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT TCPA MCFG WDAT APIC BDAT HPET UEFI SSDT DMAR 
SPCR HEST BERT ERST EINJ WSMT
acpi0: wakeup devices PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) 
PEX6(S4) PEX7(S4) XHC1(S4) LAN0(S4) LAN1(S4) LAN2(S4) LAN3(S4)
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 12 (boot processor)
cpu0: Intel(R) Atom(TM) CPU C3338 @ 1.50GHz, 1500.01 MHz, 06-5f-01
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,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
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 6, 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 24 (application processor)
cpu1: Intel(R) Atom(TM) CPU C3338 @ 1.50GHz, 1500.02 MHz, 06-5f-01
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,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 24KB 64b/line 6-way D-cache, 32KB 64b/line 8-way I-cache, 2MB 64b/line 
16-way L2 cache
cpu1: 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 1 (PEX0)
acpiprt2 at acpi0: bus 2 (PEX1)
acpiprt3 at acpi0: bus 3 (PEX2)
acpiprt4 at acpi0: bus 4 (PEX3)
acpiprt5 at acpi0: bus -1 (PEX4)
acpiprt6 at acpi0: bus 5 (PEX5)
acpiprt7 at acpi0: bus -1 (PEX6)
acpiprt8 at acpi0: bus -1 (PEX7)
acpiprt9 at acpi0: bus -1 (VRP2)
acpiprt10 at acpi0: bus 6 (VRP0)
acpiprt11 at acpi0: bus 7 (VRP1)
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, device 0x001a15d1 rev 0x10
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpitz0 at acpi0: critical temperature is 95 degC
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 9 function 0 "Intel C3000 PCIE" rev 0x11
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel I211" rev 0x03: 

Howto convert Sierra Wireless EM7455 from umsm to umb

2022-11-05 Thread Barbaros Bilek
Hi Misc,

I have Sierra Wireless EM7455 on my OpenBSD 7.2 router device.
OpenBSD detects this card like this:

umsm0 at uhub0 port 7 configuration 1 interface 0 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
3.00/0.06 addr 2
ucom0 at umsm0
umsm1 at uhub0 port 7 configuration 1 interface 2 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
3.00/0.06 addr 2
ucom1 at umsm1
umsm2 at uhub0 port 7 configuration 1 interface 3 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
3.00/0.06 addr 2
ucom2 at umsm2
umsm3 at uhub0 port 7 configuration 1 interface 8 "Sierra Wireless,
Incorporated Sierra Wireless EM7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev
3.00/0.06 addr 2
ucom3 at umsm3

# usbdevs -v -a 02

addr 02: 1199:9071 Sierra Wireless, Incorporated, Sierra Wireless EM7455
Qualcomm\M-. Snapdragon? X7 LTE-A

super speed, power 126 mA, config 1, rev 0.06, iSerial LF83917092031024

driver: umsm0

driver: umsm1

driver: umsm2

driver: umsm3

Is it possible to convert this card into MBIM mode to get an umb device?
Thanks.


find out which process fills into swap

2022-06-15 Thread Barbaros Bilek
Hello misc,

Nowadays I see swap usage with the top command.
How can I find out which process fills into swap?
Thanks.

--
Barbaros


PF table issue on 7.1-Current

2022-06-07 Thread Barbaros Bilek
Hello Misc,

I think there is an issue about PF tables at current.
Here my working PF config sample before 7.1-Current.
block log quick inet from 
pfctl -f /etc/pf.conf
Another software fills this Malicious table with this command:
# pfctl -t Malicious -T add 1.2.3.4
 1 table created.
 1/1 addresses added.
# pfctl -t Malicious -T show 1.2.3.4
 1.2.3.4

But with my newly upgraded OpenBSD version it doesn't.
OpenBSD 7.1-current (GENERIC.MP) #575: Mon Jun 6 10:11:31 MDT 2022
#pfctl -t Malicious -T add 1.2.3.4
1 table created.
pfctl: Table does not exist

#pfctl -t Malicious -T show
pfctl: Table does not exist


Thanks for your time.

--
Barbaros


CPU recommendation

2021-11-29 Thread Barbaros Bilek
Hello @misc,

I’m network administrator at a Hotel. We have nearly ~=1600 users
concurrently.
I’m trying to figure out which hardware covers my pc based OpenBSD firewall.
Disk : 1 TB SSD
RAM : 16 GB
Ethernet : Intel i211AT
But what about CPU. As far as I know CPU frequency is more important at
OpenBSD cause there is netlock() etc.
Right?

So which CPU is better at the moment?
Intel Core i3-6320 @ 3.90GHz
Intel Core i7-7700 @ 3.60GHz


Re: pf block port scanning

2021-10-10 Thread Barbaros Bilek
Hello Peter,

I think you suggest me some work around like max-src-conn-rate, right?

On Sat, Oct 9, 2021 at 5:07 PM Peter Nicolai Mathias Hansteen <
pe...@bsdly.net> wrote:

>
>
> > 7. okt. 2021 kl. 15:58 skrev Barbaros Bilek :
> >
> > Hello misc,
> >
> > I try to block port scanning attempts with OpenBSD 6.9/amd64 + PF.
> > At the top of my pf.conf i've added these lines but it didn't work.
> >
> > block in quick proto tcp all flags SF/SFRA label bps1
> > block in quick proto tcp all flags FPU/SFRAUP label bps3
> > block in quick proto tcp all flags /SFRA label bps4
> > block in quick proto tcp all flags F/SFRA label bps5
> > block in quick proto tcp all flags U/SFRAU label bps6
>
> I personally find rules that specific to be too much work to even decipher.
>
> What is it you are trying to achieve here?
>
> If you want specifically to detect port scans, I have a hunch you would be
> better off constructing something out of state tracking options and
> overload tables.
>
> That said, I have tended to generally recommend to start off your rules
> with a «block" (which will expand to "block drop all"), then fill in the
> ruleset with pass rules and whatever else you need that will let the
> traffic you want to allow to pass.
>
> If you search the net with the obvious keywords you will find quite a few
> examples that can be quite instructive (including some of my own screeds at
> the first URL in my .signature).
>
> All the best,
> Peter N. M. Hansteen
>
> —
> Peter N. M. Hansteen, member of the first RFC 1149 implementation team
> http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
> "Remember to set the evil bit on all malicious network traffic"
> delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
>
>
>
>
>


Re: pf block port scanning

2021-10-10 Thread Barbaros Bilek
Hi Stuart,

I have 'block log all' as a rule and yes i have several ports that are open.
I was told to take precautions against port scanning. I'm trying to achieve
that too. :/

On Sat, Oct 9, 2021 at 4:13 PM Stuart Henderson 
wrote:

> On 2021-10-07, Barbaros Bilek  wrote:
> > Hello misc,
> >
> > I try to block port scanning attempts with OpenBSD 6.9/amd64 + PF.
> > At the top of my pf.conf i've added these lines but it didn't work.
> >
> > block in quick proto tcp all flags SF/SFRA label bps1
> > block in quick proto tcp all flags FPU/SFRAUP label bps3
> > block in quick proto tcp all flags /SFRA label bps4
> > block in quick proto tcp all flags F/SFRA label bps5
> > block in quick proto tcp all flags U/SFRAU label bps6
>
> Why not just "block in quick proto tcp all"?
>
> Or are you trying to keep some ports open? If you do that, then the
> host can be scanned by some method or other, if you allow connections
> then there's no passive method to block, instead you need to detect
> the scan and block the origin (and that can be worked around too,
> by scanning from multiple source addresses, but it's harder).
>
> --
> Please keep replies on the mailing list.
>
>


pf block port scanning

2021-10-07 Thread Barbaros Bilek
Hello misc,

I try to block port scanning attempts with OpenBSD 6.9/amd64 + PF.
At the top of my pf.conf i've added these lines but it didn't work.

block in quick proto tcp all flags SF/SFRA label bps1
block in quick proto tcp all flags FPU/SFRAUP label bps3
block in quick proto tcp all flags /SFRA label bps4
block in quick proto tcp all flags F/SFRA label bps5
block in quick proto tcp all flags U/SFRAU label bps6

Interface1 : 192.168.91.1/24
Interface2 : 192.168.88.1/24

Client (192.168.91.121) scans ports of server (192.168.88.63)
Both devices' gateway is OpenBSD.
Here nmap command that the client uses:
nmap --send-eth 192.168.88.63

So at this point, OpenBSD doesn't block port scan. What should I do?
Thanks in advance for your help.

--
Best Regards,
Barbaros Bilek


OpenBSD ipv4 forwarding limits as pps

2021-09-18 Thread Barbaros Bilek
Hello OpenBSD misc list,

I am writing this email to ask clearly about the issues that I could not
clear in my mind despite reading about OpenBSD and ip forwarding limits.
First of all, thank you for reading.

What is the maximum ipv4 forwarding value in pps that I can reach with
OpenBSD on a super server? (e.g. 2 socket Intel® Xeon® Platinum 8360Y
Processor (54M Cache, 2.40 GHz), 256GB RAM and Intel/Mellanox ethernet
cards)

Is OpenBSD's ipv4 forwarding performance hardware dependent? Or are we
stuck at the limits of the OpenBSD operating system at this point?

Actually i would like to reach 9 Mpps ipv4 forwarding rate under OpenBSD.
Is this theory possible with the right hardware configuration? I'm trying
to understand this.
Thank you in advance for all the information you will give me.
Have a nice weekend...

Notes: PF would be disabled.

--
Best Regards
Barbaros Bilek