Re: Keyboard won't work during OpenBSD 7.1 or 7.2 installation.

[Bodie]

On 22.11.2022 06:54, Clint wrote:

Dear Sirs,



My name is Clint Wu, I had been told the DMP’s EBOX-336x mini PC 
(product
page  ) can run 
OpenBSD

7.1.

I had downloaded install71.img & install72.img ad use rufus 3.20 to 
crate

USB installer.

When I boot up my mini PC till installation program show up as below
picture.

My keyboard stop working at this stage. Did any one report this problem
before?

Can you tell me how to solve this? what should I do next?　Please 
advise,

thank you.



Based on this list https://www.compactpc.com.tw/products/about
it seems to have problems even with Linux support for its HW






Regards,
Clint

Re: Ipsec + bridge + egre issue with multiple bridges an non-static ip

[Markus Wipp]

Hi all,

Sorry for the noise. I found out that it was pf.
When I tested with pf disabled I always only did this with pf disabled on one 
side. Once I disabled on both sides it worked.
So I need to figure out now, what exactly is the issue.

Thanks
Markus

> On 26. Nov 2022, at 11:19, Markus Wipp  wrote:
> 
> Hi all,
> 
> I hope that someone here on the list could give me some hints on how I can 
> make my setup working.
> 
> I have the following setup:
> 
> "Virtual server 1" is connected to "Virtual server 2" via egre over ipsec on 
> both sides I’m using a bridge and a vether interface.
> Both virtual servers are located at different hosters and have public ip 
> addresses.
> Between them the mentioned private connection is always coming up and working 
> (I can ping 192.168.79.1 / 192.168.79.2 from each other)
> 
> In addition I have my router at home which connects via separate egre over 
> ipsec with a bridge and a vether interface connections
> to each of the virtual servers. This router unfortunately has only a dynamic 
> ipv4 address.
> The connection between the router and the virtual servers is for some reason 
> not coming up completely.
> To my analysis so far it seems that the router bridge learns the Mac 
> addresses of the remote virtual servers vether interfaces, but for
> some reason the bridges on the virtual servers do not learn the address of 
> the routers vether interface.
> tcpdump does show traffic coming into enc0, but it never reaches the bridge, 
> even with pf disabled.
> 
> 
> As I can ping the interface with ip 192.168.66.1 from each of the virtual 
> servers on the router, I’m leaving out the iced configuration.
> If this is needed I could also provide it.
> 
> Find here the corresponding configurations of each of the machines:
> 
> Virtual server 1:
> (Working between virtual server 1 and 2)
> /etc/hostname.bridge0
> add vether0
> add egre0
> up
> 
> /etc/hostname.vether0
> mtu 1500
> inet 192.168.79.1/24
> up
> 
> /etc/hostname.egre0
> mtu 1500 -tunneldf
> tunnel a.b.c.d w.x.y.z
> vnetid 12
> up
> 
> (Not working between virtual server 1 and router)
> /etc/hostname.bridge2
> add vether1
> add egre1
> up
> 
> /etc/hostname.vether1
> mtu 1500
> inet 192.168.80.1/24
> up
> 
> /etc/hostname.egre1
> mtu 1500 -tunneldf
> tunnel a.b.c.d 192.168.66.1
> vnetid 31
> up
> 
> Virtual server 2:
> (Working between virtual server 1 and 2)
> /etc/hostname.bridge0
> add vether0
> add egre0
> up
> 
> /etc/hostname.vether0
> mtu 1500
> inet 192.168.79.2/24
> up
> 
> /etc/hostname.egre0
> mtu 1500 -tunneldf
> tunnel w.x.y.z a.b.c.d
> vnetid 12
> up
> 
> (Not working between virtual server 1 and router)
> /etc/hostname.bridge2
> add vether2
> add egre2
> up
> 
> /etc/hostname.vether2
> mtu 1500
> inet 192.168.81.1/24
> up
> 
> /etc/hostname.egre2
> mtu 1500 -tunneldf
> tunnel w.x.y.z 192.168.66.1
> vnetid 32
> up
> 
> 
> Router:
> /etc/hostname.bridge0
> add vether1
> add egre1
> up
> 
> /etc/hostname.vether1
> mtu 1500
> inet 192.168.80.2/24
> up
> 
> /etc/hostname.egre1
> mtu 1500 -tunneldf
> tunnel 192.168.66.1 a.b.c.d
> vnetid 31
> up
> 
> /etc/hostname.bridge2
> add vether2
> add egre2
> up
> 
> /etc/hostname.vether2
> mtu 1500
> inet 192.168.81.2/24
> up
> 
> /etc/hostname.egre2
> mtu 1500 -tunneldf
> tunnel 192.168.66.1 w.x.y.z
> vnetid 32
> up
> 
> As an example I provide here the output of ifconfig for the relevant 
> interfaces on virtual server 1 (ipv6 stuff removed):
> 
> 
> vio0: 
> flags=e08843
>  mtu 1500
> lladdr 56:00:03:8c:96:8c
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect
> status: active
> inet a.b.c.d netmask 0xfe00 broadcast 199.247.3.255
> 
> enc0: flags=41
> index 2 priority 0 llprio 3
> groups: enc
> status: active
> 
> bridge0: flags=41 mtu 1500
> index 4 llprio 3
> groups: bridge
> priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
> egre0 flags=3
> port 6 ifpriority 0 ifcost 0
> vether0 flags=3
> port 8 ifpriority 0 ifcost 0
> 
> bridge2: flags=41 mtu 1500
> index 5 llprio 3
> groups: bridge
> priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
> egre1 flags=3
> port 12 ifpriority 0 ifcost 0
> vether1 flags=3
> port 9 ifpriority 0 ifcost 0
> 
> egre0: flags=8943 mtu 1500
> lladdr fe:e1:ba:d0:b9:3c
> index 6 priority 0 llprio 3
> encap: vnetid 12 txprio 0 rxprio packet
> groups: egre
> tunnel: inet a.b.c.d --> w.x.y.z ttl 64 nodf
> 
> vether0: flags=8943 mtu 1500
> lladdr fe:e1:ba:d2:eb:05
> index 8 priority 0 llprio 3
> groups: vether
> media: Ethernet autoselect
> status: active
> inet 192.168.79.1 netmask 0xff00 broadcast 192.168.79.255
> 
> vether1: flags=8943 mtu 1500
> lladdr fe:e1:ba:d3:94:e9
> index 9 priority 0 llprio 3
> groups: vether
> media: Ethernet autoselect
> status: active
> inet 192.168.80.1 netmask 0xff00 broadcast 192.168.80.255
> 
> egre1: flags=8943 mtu 1500
> lladdr fe:e1:ba:d4:c5:8f
> index 12 priority 0 llprio 3
> encap: vnetid 31 txprio 0 rxprio packet
> groups: 

Re: Documentation of wsconsctl keyboard.map format?

[unix]

On 2022-11-25 05:32, Mike Fischer wrote:


Am 24.11.2022 um 15:07 schrieb u...@disroot.org:

Hello!

I would like to find some supporting documentation too, if anything is 
available, but for certain other reasons 
(https://github.com/letoram/arcan/issues/263). Basically, this 
"desktop engine" has problems with figuring out my keyboard layouts, 
and I want to figure out why. This might've been more appropriate to 
post in ports@ but this thread catched my eye, so I'm here. It would 
be nice to be able to determine what keycodes correspond to what 
symbols in console, to figure out what goes wrong in the process of 
how Arcan determines my keyboard layout. Any help appreciated!


I'm not sure this will help with your issue but here is what I have 
been able to figure out so far:


One thing that helped me a bit (though I have not solved this issue 
yet) was the definition of the keycodes in the USB HID standards. I 
found this link where presumably the codes sent by USB keyboards are 
defined:

https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2
Or see https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf 
table 12 on page 53 for something more official.
You will still need to figure out which keycodes a specific keyboard 
will send for certain keys, as there is some ambiguity with regard to 
the labeling of keys, especially for non-us localizations. For example 
some of the Apple keyboards have a  modifier key. I don't see that 
mentioned in the USB spec. Maybe the keyboard handles this internally 
but that is simply guessing at the moment.


The usable entity names are somewhat defined (you need to chop off the 
prefix of the names) in source code:

/src/sys/dev/wscons/wsksymdef.h
Additionally Vlad Meșco mentioned that arbitrary Unicode values can be 
specified using e.g. unknown_50082 (for U+C3A2?) instead of a known 
entity. I have not tested this yet.


The actual predefined keyboard maps are compiled into OpenBSD drivers:
/src/sys/dev/pckbc/wskbdmap_mfii.c
/src/sys/dev/usb/ukbdmap.c (which seems to be derived from 
wskbdmap_mfii.c)


Note: All of the OpenBSD source files can be found at: 
https://cvsweb.openbsd.org


That doesn't explain the syntax of keyboard.map though.

And I have analyzed the de keyboard.encoding somewhat and found it to 
be quite different from the way macOS treats German Apple USB 
keyboards.


As a small experiment I tried to redefine the 7 key:
wsconsctl keyboard.encoding=de
wsconsctl keyboard.map+="keycode 36 = 7 slash bar backslash"

Note 1: The default definition for de is "keycode 36 = 7 slash 
braceleft braceleft"

However the actual mapping seems to be:
<7>: 7 (expected, ok)
<7>: / (expected, ok)
<7>: · (a small middle dot, and deleting with backspace 
doesn't work)
<7>: ¯ (some weird glyph with just a short horizontal 
line at the top, and deleting with backspace doesn't work)

<7>: { (expected, ok)
<7>: { (expected, ok)

Note 2: On macOS the actual mappings are:
<7>: 7
<7>: / (slash)
<7>: | (bar)
<7>: \ (backslash)
And it does not matter whether  or  is used for 
.


But this does not yield all of the expected results:
<7>: 7 (expected, ok)
<7>: / (expected, ok)
<7>: · (a small middle dot, and deleting with backspace 
doesn't work)
<7>: ¯ (some weird glyph with just a short horizontal 
line at the top, and deleting with backspace doesn't work)

<7>: | (expected, ok)
<7>: \ (expected, ok)
The  key still does weird things.

But apparently the 4 columns in the keycode entries are:  
  
Note: On non-Apple keyboards  may be labeled as . 
Apple labels both  and  as  and does not 
generally differentiate between the two.


Adding the very obscure:
wsconsctl keyboard.map+="keycode 226 = Cmd2 Mode_switch Multi_key"
(modified from the example Vlad Meșco mentioned to match the  
keycode from the USB spec) finally yielded the expected result:

<7>: 7 (expected, ok)
<7>: / (expected, ok)
<7>: | (expected, ok)
<7>: \ (expected, ok)
<7>: | (expected, ok)
<7>: \ (expected, ok)

I can use this but I don't understand how it works. :-(

Putting this into /etc/wsconsctl.conf gives me a persistent 
modification that is one step close to my goal:

# cat /etc/wsconsctl.conf
# Start out with a German keyboard layout:
keyboard.encoding=de
# Make the  modifier key behave the same as the  
key:

keyboard.map+="keycode 226 = Cmd2 Mode_switch Multi_key"
# Redefine the <7> key to match macOS:
keyboard.map+="keycode 36 = 7 slash bar backslash"
#

More enlightened but still puzzled…
Mike
Thank you! This helps to figure out a part the picture of how these 
specific keys are handled. If you find anything else which might be of 
use, please share! The same applies to me, if I will figure out 
something I will certainly share it here. Maybe, some diffs to document 
this behaviour will be produced in the end!

Re: Suggestions for miniPCI wireless card for an accesspoint on OpenBSD - 2022q4

[4]

> What does mean `broadcom ac chipset`?
> Do you have example product at hand?
> Which OpenBSD driver is that?
> Are you saying this in context of hostap mode?
i've tried everything from 11n and above that host ap supports. this is the 
best variant of the worst, but it definitely works(relatively works. each start 
of the system is a lottery in which the system can hang on initialization of 
the card):
 6:0:0: Broadcom BCM4371
0x: Vendor ID: 14e4, Product ID: 440d
0x0004: Command: 0006, Status: 0010
0x0008: Class: 02 Network, Subclass: 80 Miscellaneous,
Interface: 00, Revision: 02
0x000c: BIST: 00, Header Type: 00, Latency Timer: 00,
Cache Line Size: 10
0x0010: BAR mem 64bit addr: 0xa140/0x8000
0x0018: BAR mem 64bit addr: 0xa100/0x0040
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 103c Product ID: 81b5
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 0b Min Gnt: 00 Max Lat: 00
0x0048: Capability 0x01: Power Management
State: D0
0x0058: Capability 0x05: Message Signalled Interrupts (MSI)
Enabled: yes
0x0068: Capability 0x09: Vendor Specific
0x00ac: Capability 0x10: PCI Express
Max Payload Size: 256 / 256 bytes
Max Read Request Size: 512 bytes
Link Speed: 2.5 / 2.5 GT/s
Link Width: x1 / x1
0x0100: Enhanced Capability 0x01: Advanced Error Reporting
0x013c: Enhanced Capability 0x03: Device Serial Number
Serial Number: a8c2441c
0x0150: Enhanced Capability 0x04: Power Budgeting
0x0160: Enhanced Capability 0x02: Virtual Channel Capability
0x01b0: Enhanced Capability 0x18: Latency Tolerance Reporting
0x0220: Enhanced Capability 0x15: Resizable BAR
0x0240: Enhanced Capability 0x1e: L1 PM

but you'd better come to your senses and not go this way. if you don't have 
enough ports to connect an external access point, then aliexpress has a lan 
card for mini-pcie. yes, it will be five times more expensive(buying a used AP 
will cut your costs in half) than just the broadcom wifi card, but your nerves 
are more expensive

Re: Suggestions for miniPCI wireless card for an accesspoint on OpenBSD - 2022q4

[4]

Здравствуйте, Stuart.

Вы писали 25 ноября 2022 г., 11:54:13:

> On 2022-11-24, Mikolaj Kucharski  wrote:
>> Hi,
>>
> If you want something standalone (non OpenBSD) take a look at tp-link's
> omada range. Their java+mongo management software (unifi clone) won't
> run on OpenBSD but the APs have a web interface.
you offer an access point as a solution at a price almost three times more 
expensive than a toaster with router functions- if you take tp-link products 
for comparison. it is even more expensive than toasters from the top segment, 
for example keenetic, which produces almost full-fledged routers. don't you 
think that your offer is inadequate to the request, which, i remind you, 
contained a mention of mini-pcie, which means that we are talking about either 
an old laptop, an old PC or a chinese NUC. the same broadcom wifi card costs 
ten times less

Re: Suggestions for miniPCI wireless card for an accesspoint on OpenBSD - 2022q4

[Stuart Henderson]

On 2022-11-26, Mikolaj Kucharski  wrote:
> On Thu, Nov 24, 2022 at 05:31:45PM +, Tom Smyth wrote:
>> Hi Mikolaj,
>> 
>> im told that the broadcom ac chipset based ones are  an excellent choice as
>> the  card handles the vast majority of wi-fi protocols & advanced features
>> associated with newer 802.11 standards...  leaving you the admin to just
>> configure the WPA keys  and the ssids...
>> checking back through the archives and  there was a recenet enough
>> discussion on this very topic ...
>> 
>
> What does mean `broadcom ac chipset`?
>
> Do you have example product at hand?
>
> Which OpenBSD driver is that?

bwfm (Broadcom FullMAC); I'm not sure whether there are miniPCI though,
maybe just miniPCIe (and SDMMC/USB).

> Are you saying this in context of hostap mode?

The bwfm driver supports hostap mode, though most of the stack is run in
the embedded system in the Broadcom controller so it's not the standard
hostap implementation (config interface is the same but it's bypassing
much of OpenBSD's 802.11 layer).

OpenBSD's wifi client support is really quite good on the supported
modern devices; but you won't get the most out of that (or other
non-OpenBSD clients) connecting to OpenBSD hostap.

-- 
Please keep replies on the mailing list.

Ipsec + bridge + egre issue with multiple bridges an non-static ip

[Markus Wipp]

Hi all,

I hope that someone here on the list could give me some hints on how I can make 
my setup working.

I have the following setup:

"Virtual server 1" is connected to "Virtual server 2" via egre over ipsec on 
both sides I’m using a bridge and a vether interface.
Both virtual servers are located at different hosters and have public ip 
addresses.
Between them the mentioned private connection is always coming up and working 
(I can ping 192.168.79.1 / 192.168.79.2 from each other)

In addition I have my router at home which connects via separate egre over 
ipsec with a bridge and a vether interface connections
to each of the virtual servers. This router unfortunately has only a dynamic 
ipv4 address.
The connection between the router and the virtual servers is for some reason 
not coming up completely.
To my analysis so far it seems that the router bridge learns the Mac addresses 
of the remote virtual servers vether interfaces, but for
some reason the bridges on the virtual servers do not learn the address of the 
routers vether interface.
tcpdump does show traffic coming into enc0, but it never reaches the bridge, 
even with pf disabled.


As I can ping the interface with ip 192.168.66.1 from each of the virtual 
servers on the router, I’m leaving out the iced configuration.
If this is needed I could also provide it.

Find here the corresponding configurations of each of the machines:

Virtual server 1:
(Working between virtual server 1 and 2)
/etc/hostname.bridge0
add vether0
add egre0
up

/etc/hostname.vether0
mtu 1500
inet 192.168.79.1/24
up

/etc/hostname.egre0
mtu 1500 -tunneldf
tunnel a.b.c.d w.x.y.z
vnetid 12
up

(Not working between virtual server 1 and router)
/etc/hostname.bridge2
add vether1
add egre1
up

/etc/hostname.vether1
mtu 1500
inet 192.168.80.1/24
up

/etc/hostname.egre1
mtu 1500 -tunneldf
tunnel a.b.c.d 192.168.66.1
vnetid 31
up

Virtual server 2:
(Working between virtual server 1 and 2)
/etc/hostname.bridge0
add vether0
add egre0
up

/etc/hostname.vether0
mtu 1500
inet 192.168.79.2/24
up

/etc/hostname.egre0
mtu 1500 -tunneldf
tunnel w.x.y.z a.b.c.d
vnetid 12
up

(Not working between virtual server 1 and router)
/etc/hostname.bridge2
add vether2
add egre2
up

/etc/hostname.vether2
mtu 1500
inet 192.168.81.1/24
up

/etc/hostname.egre2
mtu 1500 -tunneldf
tunnel w.x.y.z 192.168.66.1
vnetid 32
up


Router:
/etc/hostname.bridge0
add vether1
add egre1
up

/etc/hostname.vether1
mtu 1500
inet 192.168.80.2/24
up

/etc/hostname.egre1
mtu 1500 -tunneldf
tunnel 192.168.66.1 a.b.c.d
vnetid 31
up

/etc/hostname.bridge2
add vether2
add egre2
up

/etc/hostname.vether2
mtu 1500
inet 192.168.81.2/24
up

/etc/hostname.egre2
mtu 1500 -tunneldf
tunnel 192.168.66.1 w.x.y.z
vnetid 32
up

As an example I provide here the output of ifconfig for the relevant interfaces 
on virtual server 1 (ipv6 stuff removed):


vio0: 
flags=e08843
 mtu 1500
lladdr 56:00:03:8c:96:8c
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect
status: active
inet a.b.c.d netmask 0xfe00 broadcast 199.247.3.255

enc0: flags=41
index 2 priority 0 llprio 3
groups: enc
status: active

bridge0: flags=41 mtu 1500
index 4 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
egre0 flags=3
port 6 ifpriority 0 ifcost 0
vether0 flags=3
port 8 ifpriority 0 ifcost 0

bridge2: flags=41 mtu 1500
index 5 llprio 3
groups: bridge
priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
egre1 flags=3
port 12 ifpriority 0 ifcost 0
vether1 flags=3
port 9 ifpriority 0 ifcost 0

egre0: flags=8943 mtu 1500
lladdr fe:e1:ba:d0:b9:3c
index 6 priority 0 llprio 3
encap: vnetid 12 txprio 0 rxprio packet
groups: egre
tunnel: inet a.b.c.d --> w.x.y.z ttl 64 nodf

vether0: flags=8943 mtu 1500
lladdr fe:e1:ba:d2:eb:05
index 8 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 192.168.79.1 netmask 0xff00 broadcast 192.168.79.255

vether1: flags=8943 mtu 1500
lladdr fe:e1:ba:d3:94:e9
index 9 priority 0 llprio 3
groups: vether
media: Ethernet autoselect
status: active
inet 192.168.80.1 netmask 0xff00 broadcast 192.168.80.255

egre1: flags=8943 mtu 1500
lladdr fe:e1:ba:d4:c5:8f
index 12 priority 0 llprio 3
encap: vnetid 31 txprio 0 rxprio packet
groups: egre
tunnel: inet a.b.c.d --> 192.168.66.1 ttl 64 nodf


And here the router side (ipv6 stuff removed):

em0: 
flags=808b43 
mtu 1500
lladdr 00:0d:b9:44:ec:dc
description: External Connection 1 Cable
index 1 priority 0 llprio 3
groups: egress
media: Ethernet autoselect (1000baseT 

Re: PC Engines APU alternative for OpenBSD - 2022h2

[Mikolaj Kucharski]

On Thu, Nov 24, 2022 at 08:50:53PM +0100, Jan Stary wrote:
> On Nov 24 17:01:55, miko...@kucharski.name wrote:
> > On Wed, Sep 28, 2022 at 04:50:39PM +0100, Stuart Henderson wrote:
> > > On 2022-09-28, Mikolaj Kucharski  wrote:
> > > > I'm looking for something similar like PC Engines APU board. Preferably
> > > > 4 network cards, 4GB of RAM, low power consumption, no graphic card,
> > > > serial console access, suitable for wired and Wi-Fi and/or LTE router,
> > > > based on OpenBSD.
> 
> Doesn't PC Engines itself have a model like that?
> 

PC Engines are / were not available for many months now. That is why I
started looking for alternatives.

I already bought few, as they have some models available again. Probably
not for too long.

However in long run, I would like to have some alternative :|

-- 
Regards,
 Mikolaj