Re: boot openbsd from emmc on RockPro64
UPDATE By doing some research I found this to be a bug in ATF. Since this is another topic I left the message dedicated to it in hope some openbsd dev would implement a workaround in kernel. https://marc.info/?l=openbsd-misc&m=171448854117299&w=2 On Tue, Apr 30, 2024 at 4:13 PM OBI wrote: > > On Tue, 30 Apr 2024 13:39:55 +0200 > "Cristian Danila" wrote: > > > HI Olivier, > > > > I cannot express how grateful I am that finally is booting emmc. > > However, I still have an issue, power button does not seem to work > > and shutdown -p now does not really turn off the device. > > > > pw# shutdown -p now > > Shutdown NOW! > > shutdown: [pid 39459] > > pw# > > *** FINAL System shutdown message from root@*** *** > > System going down IMMEDIATELY > > > > System shutdown time has arrived > > syncing disks... done > > > > Attempting to power down... > > > > And from here nothing happens, the device is not really turned off, > > I still see hdmi active(black screen) and network leds still on. > > > > I have to keep power button pressed long to force power it off. > > > > Could be this related to dtb or maybe a bug? > > > > I am not sure if dtb file is loaded properly. > > Still struggling if there is a command to know if proper dtb is loaded > > > > this is the log: > > U-Boot 2021.10 (Mar 21 2024 - 02:36:56 -0600) > > > > SoC: Rockchip rk3399 > > Reset cause: POR > > Model: Pine64 RockPro64 v2.1 > > DRAM: 3.9 GiB > > PMIC: RK808 > > MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 > > Loading Environment from SPIFlash... SF: Detected gd25q128 with page > > size 256 Bytes, erase size 4 KiB, total 16 MiB > > *** Warning - bad CRC, using default environment > > > > In:serial > > Out: serial > > Err: serial > > Model: Pine64 RockPro64 v2.1 > > Net: Could not get PHY for ethernet@fe30: addr -1 > > No ethernet found. > > > > Hit any key to stop autoboot: 0 > > Card did not respond to voltage select! : -110 > > switch to partitions #0, OK > > mmc0(part 0) is current device > > Scanning mmc 0:1... > > 63169 bytes read in 33 ms (1.8 MiB/s) > > Card did not respond to voltage select! : -110 > > Scanning disk m...@fe31.blk... > > Disk m...@fe31.blk not ready > > Card did not respond to voltage select! : -110 > > Scanning disk m...@fe32.blk... > > Disk m...@fe32.blk not ready > > Scanning disk m...@fe33.blk... > > Found 3 disks > > No EFI system partition > > BootOrder not defined > > EFI boot manager: Cannot load any image > > Found EFI removable media binary efi/boot/bootaa64.efi > > 227979 bytes read in 49 ms (4.4 MiB/s) > > Booting /efi\boot\bootaa64.efi > > disks: sd0* > > >> OpenBSD/arm64 BOOTAA64 1.18 > > > > On Mon, Apr 29, 2024 at 8:36 AM OBI wrote: > > > > > > On Sat, 27 Apr 2024 17:11:56 +0200 > > > "Cristian Danila" wrote: > > > > > > > Dear Misc, > > > > > > > > I would really appreciate if someone can give > > > > me a hint on how can make emmc card bootable > > > > on a RockPro64 board. > > > > This is what I did: > > > > 1) prepared micro sd card: > > > > dd if=install75.img of=/dev/sdg bs=1024M > > > > dd if=idbloader.img of=/dev/sdg bs=512 seek=64 > > > > dd if=u-boot.itb of=/dev/sdg bs=512 seek=16384 > > > > > > > > copy "rk3399-rockpro64-v2.dtb" to boot partition at > > > > following location: /dtb/rockchip/rk3399-rockpro64-v2.dtb > > > > > > > > 2) I did installed openbsd on emmc card > > > > > > > > But after installed it, before reboot, I understood that I need to > > > > write the 3 files: idbloader.img, u-boot.itb and > > > > rk3399-rockpro64-v2.dtb into emmc card. > > > > So before reboot, use console and write the files. > > > > Could you please help me in telling how I do that? > > > > I think(still struggling with it) that somehow I have to copy the > > > > same sectors > > > > from sdcard and write it to emmc + copy the dtb file. > > > > > > > > Thank you. > > > > > > > > > > Hello, > > > > > > I wrote in the past "notes / process tasks" to follow for fresh > > > install OpenBSD on a RockPro 64, was done for 6.7-current. > > > I don't know if sti
rk3399 rockpro64 fails to power off
Dear Misc, I own a rockpro64 device + openbsd 7.5 and for some reason shutdown -p now does not powering off the device -> shutdown -p now - Shutdown NOW! shutdown: [pid 39459] *** FINAL System shutdown message from root@*** *** System going down IMMEDIATELY System shutdown time has arrived syncing disks... done Attempting to power down... --- And from here nothing happens, the device is not really turned off, I still see hdmi active(black screen) and network leds still on. I have to keep power button pressed long to force power it off. After some research I found out that is a bug in ATF https://tomscii.sig7.se/2022/03/Patches-for-OpenBSD-on-the-PinebookPro It seems we are stack with no fix from ATF side and I wonder if OpenBSD team can include a workaround in OS kernel similar to https://tomscii.sig7.se/files/pbp-openbsd/patches/05-fix-rkpmic-powerdown.patch.txt Also some interesting links on this subject: https://www.spinics.net/lists/linux-rockchip/msg28009.html http://patchwork.ozlabs.org/project/uboot/patch/20191128061433.1952869-2-anars...@gmail.com/ https://github.com/Tow-Boot/Tow-Boot/commit/818cae1b84a7702f2a509927f2819900c2881979 Kind Regards, Claudiu
Re: boot openbsd from emmc on RockPro64
HI Olivier, I cannot express how grateful I am that finally is booting emmc. However, I still have an issue, power button does not seem to work and shutdown -p now does not really turn off the device. pw# shutdown -p now Shutdown NOW! shutdown: [pid 39459] pw# *** FINAL System shutdown message from root@*** *** System going down IMMEDIATELY System shutdown time has arrived syncing disks... done Attempting to power down... And from here nothing happens, the device is not really turned off, I still see hdmi active(black screen) and network leds still on. I have to keep power button pressed long to force power it off. Could be this related to dtb or maybe a bug? I am not sure if dtb file is loaded properly. Still struggling if there is a command to know if proper dtb is loaded this is the log: U-Boot 2021.10 (Mar 21 2024 - 02:36:56 -0600) SoC: Rockchip rk3399 Reset cause: POR Model: Pine64 RockPro64 v2.1 DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Model: Pine64 RockPro64 v2.1 Net: Could not get PHY for ethernet@fe30: addr -1 No ethernet found. Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... 63169 bytes read in 33 ms (1.8 MiB/s) Card did not respond to voltage select! : -110 Scanning disk m...@fe31.blk... Disk m...@fe31.blk not ready Card did not respond to voltage select! : -110 Scanning disk m...@fe32.blk... Disk m...@fe32.blk not ready Scanning disk m...@fe33.blk... Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 227979 bytes read in 49 ms (4.4 MiB/s) Booting /efi\boot\bootaa64.efi disks: sd0* >> OpenBSD/arm64 BOOTAA64 1.18 On Mon, Apr 29, 2024 at 8:36 AM OBI wrote: > > On Sat, 27 Apr 2024 17:11:56 +0200 > "Cristian Danila" wrote: > > > Dear Misc, > > > > I would really appreciate if someone can give > > me a hint on how can make emmc card bootable > > on a RockPro64 board. > > This is what I did: > > 1) prepared micro sd card: > > dd if=install75.img of=/dev/sdg bs=1024M > > dd if=idbloader.img of=/dev/sdg bs=512 seek=64 > > dd if=u-boot.itb of=/dev/sdg bs=512 seek=16384 > > > > copy "rk3399-rockpro64-v2.dtb" to boot partition at > > following location: /dtb/rockchip/rk3399-rockpro64-v2.dtb > > > > 2) I did installed openbsd on emmc card > > > > But after installed it, before reboot, I understood that I need to > > write the 3 files: idbloader.img, u-boot.itb and > > rk3399-rockpro64-v2.dtb into emmc card. > > So before reboot, use console and write the files. > > Could you please help me in telling how I do that? > > I think(still struggling with it) that somehow I have to copy the > > same sectors > > from sdcard and write it to emmc + copy the dtb file. > > > > Thank you. > > > > Hello, > > I wrote in the past "notes / process tasks" to follow for fresh install > OpenBSD on a RockPro 64, was done for 6.7-current. > I don't know if still available: > > https://blog.burelli.fr/en/arm/arm64-install-openbsd-rockpro64/ > > For now i am using quartz-a-model from Pine64. > > > Succently: > > * dtb has to be installed on the USB Key, because kernel on usb key has > to detect the emmc and has to be able to write on it. Without > installing dtb on the USB key, it’s impossible to write to the emmc > card. > > --> After reboot the installed kernel should detect and write on the > emmc. install dtb if not. > > Ations to do on another machine to prepare the installation (sd1 is usb > key): > doas mount /dev/sd1i /mnt > doas mkdir /mnt/rockchip > doas cp /usr/local/share/dtb/arm64/rockchip/rk3399-rockpro64.dtb > /mnt/rockchip/ > doas umount /mnt > > > Olivier.
boot openbsd from emmc on RockPro64
Dear Misc, I would really appreciate if someone can give me a hint on how can make emmc card bootable on a RockPro64 board. This is what I did: 1) prepared micro sd card: dd if=install75.img of=/dev/sdg bs=1024M dd if=idbloader.img of=/dev/sdg bs=512 seek=64 dd if=u-boot.itb of=/dev/sdg bs=512 seek=16384 copy "rk3399-rockpro64-v2.dtb" to boot partition at following location: /dtb/rockchip/rk3399-rockpro64-v2.dtb 2) I did installed openbsd on emmc card But after installed it, before reboot, I understood that I need to write the 3 files: idbloader.img, u-boot.itb and rk3399-rockpro64-v2.dtb into emmc card. So before reboot, use console and write the files. Could you please help me in telling how I do that? I think(still struggling with it) that somehow I have to copy the same sectors from sdcard and write it to emmc + copy the dtb file. Thank you.
Re: Will tags length influence the performance in PF?
Many thanks for the clarification. On Fri, Apr 21, 2023 at 10:19 AM David Gwynne wrote: > > inside the kernel tags are given numeric identifiers, and these numbers are > used everywhere. the length of the tag name doesnt affect performance. > > > On 21 Apr 2023, at 04:10, Cristian Danila wrote: > > > > Hello Misc, > > > > I have a technical question in regards to PF tags. > > I was always wondering if the length of tags matters > > or not in terms of performance. > > For example will PF use the same effort to match a tag > > TEST_TEST_TEST_TEST_TEST as it would do for a tag A? > > I am wondering if PF internally would just translate initially all > > tags in a set of optimized id's and later will use only those id's > > when tag filtering is used. > > > > I appreciate your answer. > > With respect, > > Claudiu > > >
Will tags length influence the performance in PF?
Hello Misc, I have a technical question in regards to PF tags. I was always wondering if the length of tags matters or not in terms of performance. For example will PF use the same effort to match a tag TEST_TEST_TEST_TEST_TEST as it would do for a tag A? I am wondering if PF internally would just translate initially all tags in a set of optimized id's and later will use only those id's when tag filtering is used. I appreciate your answer. With respect, Claudiu
Recommended place to store static arp entries
Dear Misc, I would really appreciate if more experienced members of you could suggest if there is a dedicated place or recommended place for OpenBSD where static arp entries should be stored. I found many answers over the internet, in some books it is mentioning /etc/netstart. Also on very old thread fro OpenBSD I see it was discussed at some point a possible idea like /etc/arp.conf https://marc.info/?l=openbsd-bugs&m=103773290509612&w=2 In the same thread it was mentioned rc.conf but definitly rc.conf is a file that states that is should not be edited. Or maybe rc.conf.local as an alternative? Where do you recommend storing static arp entries? Thank you.
Re: Unable to permanently mute OpenBSD keyboard
Many many thanks! It seems the solution is a combination of two commands and only working if added in rc.local(so no wsconsctl .conf) wsconsctl -f /dev/wskbd1 keyboard.bell.volume.default=0 wsconsctl -f /dev/wskbd1 keyboard.bell.volume=0 Thank you. On Sun, Feb 5, 2023 at 2:07 PM Crystal Kolipe wrote: > > On Sun, Feb 05, 2023 at 01:59:34PM +0200, Cristian Danila wrote: > > After many tried and attempts, I was not able to find a way to permanently > > disable openbsd keyboard "beep". Reading in different books about this: > > > > adding keyboard.bell.volume=0 into /etc/wsconsctl.conf > > adding wsconsctl -f /dev/wskbd1 keyboard.bell.volume=0 into /etc/rc.local > > > > Nothing really works permanently. > > > > I do use an KVM to control multiple machines and it seems these settings are > > persistent only till I switch to another machine and when I come back, > > beep is also back again. As far i see, when the keyboard/mouse are > > reconnected > > (due to kvm switch), the beep is back. > > > > Any idea if it is possible to mute it once forever? > > I'm not in front of a machine that I can test this on, but you could try: > > keyboard.bell.volume.default=0
Unable to permanently mute OpenBSD keyboard
Hello, After many tried and attempts, I was not able to find a way to permanently disable openbsd keyboard "beep". Reading in different books about this: adding keyboard.bell.volume=0 into /etc/wsconsctl.conf adding wsconsctl -f /dev/wskbd1 keyboard.bell.volume=0 into /etc/rc.local Nothing really works permanently. I do use an KVM to control multiple machines and it seems these settings are persistent only till I switch to another machine and when I come back, beep is also back again. As far i see, when the keyboard/mouse are reconnected (due to kvm switch), the beep is back. Any idea if it is possible to mute it once forever? Thank you.
Re: OpenBSD as a transparent switch filter
Oh my... After lot of testing I think I am very close(I hope) to a working solution. In short I got back to somehow close what David suggested regarding proxy arp but I cannot find commarp package so for arp problem i just use static arp entries in different rdomain em0 -> rdomain 1 + static arp entries that responds to switch port 20 with em0 hw address em1 -> default rdomain that can communicate with switch port 21 So first em0 will resolve arp with his own address. The idea is to see now how can I pass the incoming traffic from em0 through em1 and be seen as switch as em1 since they have different rdomains. Ideally would be something more simple to not introduce unnecessarily overhead to cpu but what to say..this is what I have found till now. On Thu, Jan 26, 2023 at 12:59 AM Tom Smyth wrote: > > Hi Christian, > > if you have Port 20 and 21 isolated from each other ... ie in the same > protected port group 0 on the switch... > and ports 1-19 in a spearate protected port group eg 1 > ports 1-19 can talk to either 20 or 21 > and ports 20-21 cannot talk to each other (loop avoidance) > > then in openBSD Bridge you can add em0 and em1 to the same protected port > group eg 3 > you can do your filtering then... > However... you have to contend with mac flaps on your OpenBSD Bridge (as > broadcast traffic from clients will mean that client macs will be learned on > both em0 and em1) > > > anotther option and more granularly controlable ... to > create 19 vlans... > > port 1 vlan1, access (untagged) > port 2 vlan2 access (untagged) > port 3 vlan3 access (untagged) > ... > .. > port 19 vlan 19 access (untagged) > > make port 20 a trunk (tagged) port on the switch > > create 19 vlan interfaces in OpenBSD > bridge them all together with port isolation or filtering you get around the > hair pining etc... but your openbsd box will suffer if there is lots of > broadcast traffic > (copying frames to multiple ports can be challenging for your CPU) > > but if you are doing line rate stuff... you may just want to look at vlan > maps / Vlan ACLs... (extend acls...) ... on the switch... > > one piece of advice... on this non standard layer 2 stuff (port > isiolation on the switch and bridge is your friend always... in avoiding > loops... > watch the logs of the switch and cpu.. if the mac flaps are happinging you > will see your switch logs (ususally ) moan about it > > watch your mac address table size and your hardware capacity on your > switch...with this stuff... (know your switch hardware capacity and specs) > > i hope ths helps... > > On Wed, 25 Jan 2023 at 15:14, Cristian Danila wrote: >> >> Thank you so much Tom and David for giving me ideas where I can dig more. >> Definitely it is a good start in this journey and I am researching more. >> I have exact same situation with Wireless, for the moment all the clients are >> isolated but I need to achieve the same, to filter between them. >> I am evaluating also another idea(possible bad idea) like this: >> >> Switch having all the clients able to talk only with 2 ports: port 20 >> and 21 but port 20 and 21 cannot talk direct >> Having BSD setup with two NIC's em0 and em1 as transparent filter: veb, >> em0 connected to port 20 >> em1 connected to port 21 >> >> In short the only possible way to pass frames from one device to >> another is just through port 20 and 21 >> >> I am aware about headache related to possible loops but I am curious >> if it will work. >> >> >> On Wed, Jan 25, 2023 at 2:33 PM Tom Smyth >> wrote: >> > >> > Hey David... >> > (I have learned so much from you over the years and used your gear so >> > maybe I can give a lttle back on this one ) >> > >> > "Correct use of Proxy arp" Gateway of layer 2 isolated network... >> > clients cannot see or hear eachothers arp traffic or discovery traffic or >> > other broadcast nasties >> > so gateway knows everyones correct arp entry (because it can see everyone >> > and everyone can see the gateway0 >> > gateway knows correct arp entries for 2 example clients clienta and clientb >> > >> > if client a wants to talk to client b ...they are isolated in layer 2 >> > ...so arp between them is not posible... >> > enable proxy arp on gateway client a asks for clientbs mac address in an >> > arp request >> > gateway responds to client a with gateway mac address for clientb Ip >> > address >> > client a sends traffic for client b ip to gateway.mac .. gateway routes >> > the traffic to client b ip
Re: OpenBSD as a transparent switch filter
Hi Tom, I am just about trying your suggestion but I'm confused regarding one thing. You mentioned " then in openBSD Bridge you can add em0 and em1 to the same protected port group eg 3" Do you mean em0 and em1 should be isolated by each other? Then how is supposed to communicate em0 with em1? Thank you. On Thu, Jan 26, 2023, 00:59 Tom Smyth wrote: > Hi Christian, > > if you have Port 20 and 21 isolated from each other ... ie in the same > protected port group 0 on the switch... > and ports 1-19 in a spearate protected port group eg 1 > ports 1-19 can talk to either 20 or 21 > and ports 20-21 cannot talk to each other (loop avoidance) > > then in openBSD Bridge you can add em0 and em1 to the same protected port > group eg 3 > you can do your filtering then... > However... you have to contend with mac flaps on your OpenBSD Bridge (as > broadcast traffic from clients will mean that client macs will be learned > on both em0 and em1) > > > anotther option and more granularly controlable ... to > create 19 vlans... > > port 1 vlan1, access (untagged) > port 2 vlan2 access (untagged) > port 3 vlan3 access (untagged) > ... > .. > port 19 vlan 19 access (untagged) > > make port 20 a trunk (tagged) port on the switch > > create 19 vlan interfaces in OpenBSD > bridge them all together with port isolation or filtering you get around > the hair pining etc... but your openbsd box will suffer if there is lots of > broadcast traffic > (copying frames to multiple ports can be challenging for your CPU) > > but if you are doing line rate stuff... you may just want to look at vlan > maps / Vlan ACLs... (extend acls...) ... on the switch... > > one piece of advice... on this non standard layer 2 stuff (port > isiolation on the switch and bridge is your friend always... in avoiding > loops... > watch the logs of the switch and cpu.. if the mac flaps are happinging you > will see your switch logs (ususally ) moan about it > > watch your mac address table size and your hardware capacity on your > switch...with this stuff... (know your switch hardware capacity and specs) > > i hope ths helps... > > On Wed, 25 Jan 2023 at 15:14, Cristian Danila wrote: > >> Thank you so much Tom and David for giving me ideas where I can dig more. >> Definitely it is a good start in this journey and I am researching more. >> I have exact same situation with Wireless, for the moment all the clients >> are >> isolated but I need to achieve the same, to filter between them. >> I am evaluating also another idea(possible bad idea) like this: >> >> Switch having all the clients able to talk only with 2 ports: port 20 >> and 21 but port 20 and 21 cannot talk direct >> Having BSD setup with two NIC's em0 and em1 as transparent filter: veb, >> em0 connected to port 20 >> em1 connected to port 21 >> >> In short the only possible way to pass frames from one device to >> another is just through port 20 and 21 >> >> I am aware about headache related to possible loops but I am curious >> if it will work. >> >> >> On Wed, Jan 25, 2023 at 2:33 PM Tom Smyth >> wrote: >> > >> > Hey David... >> > (I have learned so much from you over the years and used your gear so >> maybe I can give a lttle back on this one ) >> > >> > "Correct use of Proxy arp" Gateway of layer 2 isolated network... >> > clients cannot see or hear eachothers arp traffic or discovery traffic >> or other broadcast nasties >> > so gateway knows everyones correct arp entry (because it can see >> everyone and everyone can see the gateway0 >> > gateway knows correct arp entries for 2 example clients clienta and >> clientb >> > >> > if client a wants to talk to client b ...they are isolated in layer 2 >> ...so arp between them is not posible... >> > enable proxy arp on gateway client a asks for clientbs mac address in >> an arp request >> > gateway responds to client a with gateway mac address for clientb Ip >> address >> > client a sends traffic for client b ip to gateway.mac .. gateway >> routes the traffic to client b ip via its connected route and correct arp >> address for client b >> > client B asks for clienta mac address... in an arp request... >> > gateway responds with an arp reply for clienta IP with its own mac >> address >> > client b sends traffic to client a ip to the gateway mac address, >> > gateway routes the traffic to client a via its connected route + >> correct arp entry for client a >> > >> > -
Re: OpenBSD as a transparent switch filter
Thank you so much Tom and David for giving me ideas where I can dig more.
Definitely it is a good start in this journey and I am researching more.
I have exact same situation with Wireless, for the moment all the clients are
isolated but I need to achieve the same, to filter between them.
I am evaluating also another idea(possible bad idea) like this:
Switch having all the clients able to talk only with 2 ports: port 20
and 21 but port 20 and 21 cannot talk direct
Having BSD setup with two NIC's em0 and em1 as transparent filter: veb,
em0 connected to port 20
em1 connected to port 21
In short the only possible way to pass frames from one device to
another is just through port 20 and 21
I am aware about headache related to possible loops but I am curious
if it will work.
On Wed, Jan 25, 2023 at 2:33 PM Tom Smyth wrote:
>
> Hey David...
> (I have learned so much from you over the years and used your gear so maybe I
> can give a lttle back on this one )
>
> "Correct use of Proxy arp" Gateway of layer 2 isolated network...
> clients cannot see or hear eachothers arp traffic or discovery traffic or
> other broadcast nasties
> so gateway knows everyones correct arp entry (because it can see everyone
> and everyone can see the gateway0
> gateway knows correct arp entries for 2 example clients clienta and clientb
>
> if client a wants to talk to client b ...they are isolated in layer 2 ...so
> arp between them is not posible...
> enable proxy arp on gateway client a asks for clientbs mac address in an arp
> request
> gateway responds to client a with gateway mac address for clientb Ip address
> client a sends traffic for client b ip to gateway.mac .. gateway routes the
> traffic to client b ip via its connected route and correct arp address for
> client b
> client B asks for clienta mac address... in an arp request...
> gateway responds with an arp reply for clienta IP with its own mac address
> client b sends traffic to client a ip to the gateway mac address,
> gateway routes the traffic to client a via its connected route + correct arp
> entry for client a
>
> ---
> proxy arp is (kindof) useful in a lan gateway (LAN interface only) were the
> IT admin hasnt a handle on routing and gives vpn clients an IP in the same
> range as the Lan in the office..
> Proxy arp allows the gateway to respond to arp requests for the vpn client
> IP... (but it is no substitute for teaching an IT person how to route and
> design/ number networks)
>
> ---incorrect use of proxy arp-
> EVERYWHERE ELSE ... (sorry for shouting )
>
> ps I hate proxy arp ... but it is useful in allowing client - client
> communications while minimising broadcast waste of bandwidth (on large
> wireless access networks)
>
>
>
>
> On Tue, 24 Jan 2023 at 23:53, David Gwynne wrote:
>>
>>
>>
>> > On 25 Jan 2023, at 09:47, Tom Smyth wrote:
>> >
>> > Hi David is that like a local proxy arp type setup (on typical
>> > networking gear) .. ?
>>
>> I’ve never had a clear idea about what proxy ARP is, and the only time it
>> comes up in converstaion is when people complain about problems it causes.
>> Do you have a definition of what you think it means before I say yes or no?
>>
>> >
>> > On Tue, 24 Jan 2023 at 23:45, David Gwynne wrote:
>> >>
>> >> I think you can do this on OpenBSD with
>> >> https://github.com/eait-itig/commarp and just routing on em0. I don’t
>> >> think any layer 2 things like bridge or veb are needed, and probably
>> >> won’t work anyway because as Claudio said, they don’t want to hairpin
>> >> anyway.
>> >>
>> >> That code doesn’t have any manpages unfortunately. commarp wants a config
>> >> file saying which interface it should run on and which IPs it should
>> >> intercept ARP for. eg:
>> >>
>> >> $ cat /etc/commarp.conf
>> >> interface em0 {
>> >>allow 192.168.1.16 - 192.168.1.254
>> >> }
>> >>
>> >> There’s no point rewriting ARP requests for the IP your router is using
>> >> on that subnet, or carp addresses on that subnet, etc.
>> >>
>> >>
>> >>> On 24 Jan 2023, at 22:16, Cristian Danila wrote:
>> >>>
>> >>> HI Tom,
>> >>>
>> >>> I am familiar with options you mentioned, veb, bridge and isolated ports.
>> >>> I am having another transparent filter based of veb also I am aware about
>> >>> protected members but my use case is different.
>> >>>
>
Re: OpenBSD as a transparent switch filter
HI Tom, I am familiar with options you mentioned, veb, bridge and isolated ports. I am having another transparent filter based of veb also I am aware about protected members but my use case is different. Let me try to explain maybe with different words. OpenBSD box is having only one cable input, so what would be the benefit of having protected members? Protected members are isolating the communication between members of a bridge, in my case I have only one NIC, so if a bridge would be helpful, I can have a bridge with single member, therefore isolating that member from who? OpenBSD box has only one wire connected to a physical switch, so it can communicate with all members of the switch, but the physical switch itself do not permit communication between members as explained. So it is a desire that OpenBSD box is the one that is making possible communication between different members of the switch through same wire. Let me try to draw it, I hope will help more DEVICE1 DEVICE2 DEVICE3 | | | | | | --- PORT1 PORT2PORT3 PORT 20 | | |_| | |_ | |__ | PHISICAL SWITCH DEVICE | ---| | | | OPEN BSD BOX Thank you. On Tue, Jan 24, 2023 at 1:43 PM Tom Smyth wrote: > > Hello Cristian, > if you want to filter on layer 2 ... you would need to use Bridge > have a look at man ifconfig(8) > bridge filter rules can be added to ports in the bridge... > you can also tag traffic in bridge filter rules and then use PF to > filter them... > > but if your objective is to isolate ports from each other.. this can > be achieved with protected port groups... > again check out ifconfig (8) > TLDR version bridge ports in the same protected port group are > isolated from each other... > If port isolation if all your looking for (no other detailed filtering > ) if (im not sure) veb(4) supports protected ports...then this would > be faster... > but to my shame I have not tried out veb(4) > > I hope this is of some use... > > > > > > > On Tue, 24 Jan 2023 at 11:29, Cristian Danila wrote: > > > > Hello > > > > I have a more difficult task that I would like to solve with OpenBSD > > and I would really > > appreciate any ideas if it is possible to achieve such. > > > > I have: > > - one OpenBSD box with one Ethernet port > > - one big switch with multiple devices connected > > > > All switch ports are isolated by each other with one exception: > > - All ports can communicate with only one Ethernet port(let's say port 20) > > > > Now what i would like to achieve is to connect an Ethernet cable between > > OpenBSD box and port 20 of the switch, and make OpenBSD a transparent > > filtering hub. > > > > So I need OpenBSD box to be a transparent bridge and filter between > > clients of the switch. > > > > Can anybody suggest a point where I can think about? > > I was thinking initially to add the nic(em0) to veb0 then with link1 > > achieve L3 filtering but > > definitely I think I miss something important. > > I am open to research everything is needed for it but I miss a > > starting point and I would > > really appreciate any hint. > > > > Kind regards, > > Claudiu > > > > > -- > Kindest regards, > Tom Smyth.
OpenBSD as a transparent switch filter
Hello I have a more difficult task that I would like to solve with OpenBSD and I would really appreciate any ideas if it is possible to achieve such. I have: - one OpenBSD box with one Ethernet port - one big switch with multiple devices connected All switch ports are isolated by each other with one exception: - All ports can communicate with only one Ethernet port(let's say port 20) Now what i would like to achieve is to connect an Ethernet cable between OpenBSD box and port 20 of the switch, and make OpenBSD a transparent filtering hub. So I need OpenBSD box to be a transparent bridge and filter between clients of the switch. Can anybody suggest a point where I can think about? I was thinking initially to add the nic(em0) to veb0 then with link1 achieve L3 filtering but definitely I think I miss something important. I am open to research everything is needed for it but I miss a starting point and I would really appreciate any hint. Kind regards, Claudiu
Re: DHCP server ignoring PF rules?
I was just about thinking to it, I will try it. Many thanks and have a wonderful day! On Sat, Dec 17, 2022 at 4:07 PM Barbaros Bilek wrote: > > 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: DHCP server ignoring PF rules?
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! > > >
DHCP server ignoring PF rules?
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!
IPS suggesion for OpenBSD 7.1
Good day everyone, I would really appreciate some suggestions/advice from more experienced users regarding a possible opensource IPS/IDS solution using OpenBSD 7.1 operating system. In short, I need to be able to have a runing IPS on openbsd to go deep and inspect for example TCP packets port 80 http and have some rules to decide in-line if packets would be allowed/blocked also in addition ideally if possible to be able to analyze packets later and review/introduce new rules. During my research I found the following possible solution that could partially fit my needs but i would really appreciate if you can offer me an advice regarding this or other possible solution that I am not aware of. I found Suricata/Snort as an IPS/IDS, suricata I understood it would be a better choice. So OpenBSD + PF + Suricata seems to be a nice fit, except the fact that to me would be ideal to centralize the logs and monitoring logs on another machine, to not overload OpenBSD machine with analyzing logs. For this task(analysis and collection) I found ELK stack(beats+elasticsearch+kibana). Now I am not so entuziastic necessarily about this fancy tools, they are not so trusted to me, and it would be even better if there would be a built-in solution of OpenBSD without these tools(or at least to not need to install any agent on openBSD machine to send logs data to another machine where analysis happens. Any suggestions are welcome. Thank you.
Re: Blocking ARP packet for specific MAC
[UPDATE] The only possible solution that I have found for now is that I have to create an vether interface, add it to the bridge and use the filtered vether interface as main. So I would deduce(but maybe I am wrong) that a single interface added to bridge cannot participate in this kind of filtering. I did not found some docs mentioning what is happening in a bridge configuration: if the filtered traffic is the one that is forwarded between interfaces by the bridge itself or the interface itself is doing filtering when it is marked as being part of a bridge. My concern with this new vether interface is that I am not sure yet how much overhead introduces in the process. I will try to look into sourcecode maybe I will find something useful. On Tue, Jul 26, 2022, 15:10 Cristian Danila wrote: > > Good day! > I've been having a headache for days(I still fight, no success yet) > in trying to find a way to block ARP for specific > MAC address(example 00:50:56:c0:00:08). > I want to see how I can achieve this on OpenBSD, > I would appreciate a technical answer or a hint/site/doc/book where > I can research more to expand my knowledge. > I've tried lot of combinations on config, many lookups over the > internet and I was not able to find an answer yet. > > This is what I've found and tried. > > OpenBSD can filter level 2 traffic only if the interface > is part of a BRIDGE. > By adding it to a bridge it put it in promiscuous mode so that it can > receive every packet sent on the network. > > So by having this requirement I have hostname.bridge0 > ---hostname.vic0 > inet autoconf > up > ---hostname.bridge0 > #add my network card to bridge > add vic0 > blocknonip vic0 > rule block in on vic0 > rule block out on vic0 src 00:50:56:c0:00:08 > rule block out on vic0 dst 00:50:56:c0:00:08 > up > --- > now I reboot and expect to see the packets blocked for 00:50:56:c0:00:08 > However these are not blocked and here is the log: > > 00:50:56:c0:00:08 ff:ff:ff:ff:ff:ff 0806 60: arp who-has > 192.168.121.131 tell 102.168.121.1 > 00:50:56:c0:00:08 ff:ff:ff:ff:ff:ff 0806 60: arp who-has > 192.168.121.131 tell 102.168.121.1 > 00:0c:29:c3:d9:a7 00:50:56:c0:00:08 0806 60: arp reply 192.168.121.131 > is-at 00:0c:29:c4:d9:a7 > > So I see a success request/response for 00:50:56:c0:00:08 > I would appreciate any help. > > Kind Regards, > Claudiu
Blocking ARP packet for specific MAC
Good day! I've been having a headache for days(I still fight, no success yet) in trying to find a way to block ARP for specific MAC address(example 00:50:56:c0:00:08). I want to see how I can achieve this on OpenBSD, I would appreciate a technical answer or a hint/site/doc/book where I can research more to expand my knowledge. I've tried lot of combinations on config, many lookups over the internet and I was not able to find an answer yet. This is what I've found and tried. OpenBSD can filter level 2 traffic only if the interface is part of a BRIDGE. By adding it to a bridge it put it in promiscuous mode so that it can receive every packet sent on the network. So by having this requirement I have hostname.bridge0 ---hostname.vic0 inet autoconf up ---hostname.bridge0 #add my network card to bridge add vic0 blocknonip vic0 rule block in on vic0 rule block out on vic0 src 00:50:56:c0:00:08 rule block out on vic0 dst 00:50:56:c0:00:08 up --- now I reboot and expect to see the packets blocked for 00:50:56:c0:00:08 However these are not blocked and here is the log: 00:50:56:c0:00:08 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.121.131 tell 102.168.121.1 00:50:56:c0:00:08 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 192.168.121.131 tell 102.168.121.1 00:0c:29:c3:d9:a7 00:50:56:c0:00:08 0806 60: arp reply 192.168.121.131 is-at 00:0c:29:c4:d9:a7 So I see a success request/response for 00:50:56:c0:00:08 I would appreciate any help. Kind Regards, Claudiu
Re: bridge rules are evaluated different compared to pf?
Thank you for info, I was confused by the book. Happy to see this is the intended behavior. Kind regards, Claudiu On Tue, Jul 26, 2022, 11:36 Claudio Jeker wrote: > On Tue, Jul 26, 2022 at 11:18:06AM +0300, Cristian Danila wrote: > > Good day! > > I hope someone could clarify if the following behavior is > > expected in a bridge configuration > > I have following rules added in hostname.bridge0 > > > > --- > > #this will result out to be blocked > > rule block in on vic0 > > rule block out on vic0 > > rule pass out on vic0 > > > > #this will result out to be passed > > #rule block in on vic0 > > #rule pass out on vic0 > > #rule block out on vic0 > > > > As you see in comments the uncommented section will block out > > traffic and second section will let it pass it. Somehow these > > rules behaves like rules added to pf but with 'quick' keyword. > > So I deduce that a catch all policy must be added last and not > > first like in pf > > > > In manpage of ifconfig I see this: > > "Rules are processed in the order in which they were added to > > the interface" > > So I believe it makes sense the behavior but I just want to > > confirm with you this behavior as I read in a book(Building > > Firewalls With OpenBSD And PF) the opposite: > > > > "rule block out on ne1 > > rule pass out on ne1 src 00:00:00:00:00:01 > > rule pass out on ne1 src 00:00:00:00:00:02 > > rule pass out on ne1 src 00:00:00:00:00:03 > > Please note that the last matching rule wins, hence the > > global block or pass rule should be listed before more > > specific rules." > > > > I would like to understand if the book has a mistake or I do > > something wrong. > > The manpage actually has a bit more: > Rules are processed in the order in which they were added to > the > interface. The first rule matched takes the action ... > > So the book got this wrong. bridge(4) uses a first match logic unlike > pf(4) where last match is the default. > > -- > :wq Claudio > >
bridge rules are evaluated different compared to pf?
Good day! I hope someone could clarify if the following behavior is expected in a bridge configuration I have following rules added in hostname.bridge0 --- #this will result out to be blocked rule block in on vic0 rule block out on vic0 rule pass out on vic0 #this will result out to be passed #rule block in on vic0 #rule pass out on vic0 #rule block out on vic0 As you see in comments the uncommented section will block out traffic and second section will let it pass it. Somehow these rules behaves like rules added to pf but with 'quick' keyword. So I deduce that a catch all policy must be added last and not first like in pf In manpage of ifconfig I see this: "Rules are processed in the order in which they were added to the interface" So I believe it makes sense the behavior but I just want to confirm with you this behavior as I read in a book(Building Firewalls With OpenBSD And PF) the opposite: "rule block out on ne1 rule pass out on ne1 src 00:00:00:00:00:01 rule pass out on ne1 src 00:00:00:00:00:02 rule pass out on ne1 src 00:00:00:00:00:03 Please note that the last matching rule wins, hence the global block or pass rule should be listed before more specific rules." I would like to understand if the book has a mistake or I do something wrong. Thank you.
Re: Blocking ping scan
Many thanks for the explanation. I really appreciate your answer and you gave to me a start point to research more on this subject. I will try to find some books in hope to expand my knowledge on this are. Kind regards, Cristian On Sat, Jun 18, 2022 at 12:42 PM Janne Johansson wrote: > > Den lör 18 juni 2022 kl 11:17 skrev Cristian Danila : > > Good day! Does anyone know if OpenBSD(7.1) has the capability to be hidden > > against a pingscan(nmap -sn xxx.xxx.xxx.xxx)? > > In PF I have only 2 rules to block everything: > > block in quick all > > block out quick all > > > > This is a fresh OpenBSD7.1 with no other configuration in place. > > The only thing set is the default interface vic0 to allow dhcp > > > > By running a test with nmap -sn 192.168.121.131 I see this: > > Starting Nmap 7.92(https://nmap.org)at 2022-06-18 11:52 GTB Daylight Time > > Nmap scan report for 192.168.121.131 > > Host is up (0.00s latency). > > MAC Address: 00:0C:29:C3:D9:A7 (VMware) > > Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds > > > > On scanned host I see this by running tcpdump -i vic0 > > 09:51:40.913770 arp who-has 192.168.121.131 tell 192.168.121.1 > > 09:51:40.913795 arp reply 192.168.121.131 is-at 00:0c:29:c3:d9:a7 > > arp is done "outside" of pf, that is why you see the arp exchange. > nmap lists this as "I know things about the hosts" and while it calls > it a "ping scan", it really hasn't got much in common with icmp pings, > but rather does an arp request and says that all hosts that respond > are "up". I'm sure a box can be all kinds of broken and still send out > arp replies, so you have to adapt your expectations of what "up" means > here. (first sentence on 'man nmap' on the part where it says what -sn > does is informative I guess?) > So while you can see an ethernet device with a mac and an IP does > exist on the local network, that is all you get. > > Then if you have "block in all" in PF no icmp, no tcp, no udp from any > host will get to the targets ip stack. > > The arp resolution is only visible for boxes on the same network, so > if I was to nmap from remote (assuming your gateway/router/fw allowed > the traffic) then the entity doing arp would be your gateway/router/fw > and not my box. Hence, I would not learn anything at all about your > machine except that it looks down from remote, but your > gateway/router/firewall would "learn" the info shown above in the nmap > output. > > If you REALLY wanted to not be visible even on the local ethernet, > then down the ethernet interface and do not put an ip on it. It would > also not be usable, but this is more or less what your PF config is > saying anyhow. > > > I am thinking(please correct me if I am wrong) that not all the traffic > > passes through pf hence this is why is not blocked. > > Sort of. arp is more like being on a lower level than the later ip > traffic for which pf will block all. > > > I would appreciate if someone could provide me a technical answer on this, > > even recommend me a book to read or docs regarding it. > > https://en.wikipedia.org/wiki/Address_Resolution_Protocol > > -- > May the most significant bit of your life be positive.
Blocking ping scan
Good day! Does anyone know if OpenBSD(7.1) has the capability to be hidden against a pingscan(nmap -sn xxx.xxx.xxx.xxx)? In PF I have only 2 rules to block everything: block in quick all block out quick all This is a fresh OpenBSD7.1 with no other configuration in place. The only thing set is the default interface vic0 to allow dhcp By running a test with nmap -sn 192.168.121.131 I see this: Starting Nmap 7.92(https://nmap.org)at 2022-06-18 11:52 GTB Daylight Time Nmap scan report for 192.168.121.131 Host is up (0.00s latency). MAC Address: 00:0C:29:C3:D9:A7 (VMware) Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds On scanned host I see this by running tcpdump -i vic0 09:51:40.913770 arp who-has 192.168.121.131 tell 192.168.121.1 09:51:40.913795 arp reply 192.168.121.131 is-at 00:0c:29:c3:d9:a7 I am thinking(please correct me if I am wrong) that not all the traffic passes through pf hence this is why is not blocked. I would appreciate if someone could provide me a technical answer on this, even recommend me a book to read or docs regarding it. Kind regards, Claudiu
